今天准备重新整理下云原生方面的内容，对于云原生实际很多人还是没有做到对其本质的完全理解，包括我自己前面更多也是在从云原生仅仅是一系列的开发技术和过程管理最近实践的结合，如果这样实际很难真正理解云原生。

在华为云最近发布的云原生2.0整体解决方案白皮书中，明确谈到的从On Cloud到In Cloud，简单来说就是不是最终交付过程才将应用交付到云环境，而是说从一开始应用就生在云上的，应用的整个生命周期都在云上。

因此今天实际我思考的重点还是如何进一步将这个事情说清楚，即：

应用如何从On Cloud到In Cloud

当然，在这个之前还是重新回顾下云原生基础概念。

1.云原生的基础概念

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。

Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。因此云原生是一系列Cloud技术、企业管理方法的集合。

在一般用法中，“云原生”是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，和位置无关。这意味着应用程序位于云中，而不是传统数据中心。

CNCF将“云原生”定义得更为狭窄，意味着使用开源软件堆栈进行容器化，其中应用程序的每个部分都打包在自己的容器中，动态编排，以便每个部分都被主动调度和管理，以优化资源利用率和面向微服务的应用程序，以提高应用程序的整体灵活性和可维护性。

云原生核心要素

云原生应用程序开发通常包括DevOps，敏捷方法，微服务，云平台，Kubernetes和Docker等容器，以及持续交付，简而言之，每种新的和现代的应用程序部署方法。

CNCF给出了云原生应用的三大特征：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用。

• 动态管理：通过集中式的编排调度系统来动态的管理和调度。

• 面向微服务：明确服务间的依赖，互相解耦。

基于这三大特征，实际上又包括了敏捷IT基础设施(容器云），持续集成和部署，微服务，DevOps四个技术要素，如下图：

在原来谈云原生要素的时候，我个人一直不太明白为何将CI/CD和DevOps要做为两个独立的要素来进行表达。当重新回顾的时候可以看到，DevOps本身是偏组织过程支撑的，而其它三个则是常说的技术要素。

通过DevOps将其它三个核心技术要素融合在一起。

云三层架构和云原生要素映射

在谈云计算的时候，我们经常谈的就是云的IaaS，PaaS和SaaS三层架构。

对于IaaS层即提供基础设施即服务，不论是公有云还是私有云平台提供弹性计算和弹性存储能力，重点在服务器，网络，存储这些IT物理基础设施的虚拟化提供。将物理资源转变为虚拟的逻辑资源提供服务能力。

即你使用虚拟机，但你并不关心物理机在哪里或是哪台物理机提供的能力。

而到了PaaS阶段进一步抽象，即平台层能力即服务，注意这个平台层能力实际分为两个大类，其一是类似数据库，应用中间件等最基础的中间件能力；其二是类似消息，缓存，文件，安全等技术服务能力。

传统在谈PaaS的时候谈得更多的是提供中间件资源池服务，实现应用托管和自动部署，通过应用托管后PaaS平台提供资源弹性调度能力。

即到了PaaS阶段，你无须关注虚拟机，你只需使用中间件资源池技术服务。

但是在传统云服务商提供IaaS和PaaS层能力的时候，实际有一个重点即都没有过多地去关注你的开发过程，开发架构，开发框架选型，以及开发完成的东西如何快速的交付到云环境上，或者说你开发的东西是否适合向云端交付。

这也就出现了传统公有云下的问题，即：

企业开发完成的IT系统或应用往往并不适合一键托管到云环境，或者开发的应用无法充分地利用云平台提供的高可用性，弹性伸缩扩展等能力。同时应用向云端交付过程也极其繁琐或复杂，导致对业务的敏捷性响应要求也无法满足。

如何让应用更好地使用云带来的便利？

简单来说就是从最早的只关心结果的云平台，要过渡到对传统IT应用开发框架，开发技术，开发集成和交付过程的关注。极好的开发框架和过程可以更好地利用云平台的敏捷IT基础设施和能力。

2.云原生发展演进过程分析

对于云原生的发展演进过程实际上有两个视角来看，其一是从主流公有云服务商的视角，即云原生是公有云厂商的IT服务触角朝企业内部IT应用开发建设的触达能力；其二是从企业内部IT建设视角，那么云原生实际是整个其它内部IT架构，SOA和微服务化，云平台发展演进的一个整合。

云原生本质-抽象和标准化

对于公有云厂商的视角谈云原生，最多谈的就是云原生本质是抽象和标准化，对于企业IT建设关注重心的不断上移。

整个关注点的上移实际上又包括了两个关键层面：

• 从对资源的关注转变为对服务能力的关注

• 彻底分离应用，从IT技术+业务的全关注转变为只关注业务

如何理解两点？

简单来说就是应用开发前就要考虑充分采用云环境所提供给你的平台支撑能力，技术支撑能力，充分考虑云环境已有的各种标准和约束来进行应用的开发。这样开发出来的应用可以做到平滑从私有云环境迁移到公有云环境，或者说这样开发的应用方便后续进行更好的对应用进行管理和弹性扩展。

同时最终应用开发期望达到的目标是完全实现IT技术和业务的解耦，只要是和业务无关的技术开发都无须太多关心底层实现逻辑，而是只关心如何使用这些技术服务能力。

对于公有云厂商给出过一个整体IT架构从最初的集中化准备发展到分布式并迁移到云原生的一个发展阶段图。实际上这个图很多底层细节并没有展开描述清楚，但是从上图我们只是可以看到以下几个关键点。

• 大单体应用应该去做微服务化拆分

• 中心化架构应该逐步转变为分布式和去中心化架构

• 云平台应该提升敏捷和高效能力

如何做到敏捷和高效？

这里面就需要将传统单体应用尽量打散为更小的微服务单位，将微服务部署的依赖转变为更加轻量高效的容器单位，所有这样做的目的都是更好的实现应用的持续敏捷交付能力。要知道在传统模式下，整个过程从私有云交付到公有云往往需要一个很复杂的过程，而且很多内容还需要手工完成，这种集成方式是很难真正做到敏捷和持续性的交付能力。

3.企业内部IT架构向云原生演进

最后来谈下企业内部IT架构朝云原生的整体发展演进过程，这个云平台服务能力可以是企业内部的私有云平台，也可以是外部的公有云服务平台。

仅仅使用IaaS平台提供能力

企业在早期可以是购买公有云厂商的弹性计算和存储资源，也可以是自己构建基于IaaS的虚拟化资源池，实现基础设施层的云化和服务化。

IT应用和资源来说完全弱相关，你拿到虚拟机后具体是要作为数据库服务器，还是应用服务器，还是缓存服务，都是开发团队自己来搭建完成的。所以这种仅仅提供资源层服务能力对传统的IT架构和开发模式基本无任何影响。

不论你原来采用什么架构开发，都可以平滑切换到IaaS云服务。

在这个时候可以看到两个重点：

• 对于IaaS服务来说只关心你运行态不关心你开发态

• IT部署架构如何设计和IaaS层无关，IaaS只提供虚拟机

所以在这个时候IaaS云服务对应用开发架构的侵入是最小的，容忍度也是最高的。但是带来的问题就是你无法充分享用云环境带来的弹性扩展能力。

举例来说，当你发现IT应用中数据库出现显著瓶颈的时候，但是你数据库原来采用的是HA架构，那么在这种情况下云平台也无法帮你弹性扩展数据库能力。

从IaaS能力到PaaS服务能力

最早谈PaaS服务能力的时候谈得最多的是中间件资源池，即实现动态部署和应用托管，对于托管后的应用可以充分利用云环境的能力来实现弹性资源调度。

在轻量容器技术没有大规模应用前，谈得比较多的是开源的开源的Cloudfoundry和Cloudify等PaaS平台。这些平台可以实现应用托管和资源动态调度能力。

但是调度的单元一般为偏重的虚拟机。

简单来讲就是你准备好部署包和虚拟机模板，然后上传你的应用部署包。PaaS平台会基于虚拟机模板动态创建虚拟机，并将部署包部署到虚拟机上，同时将虚拟机挂接到集群出口。同时平台具备心跳检测和健康检查能力，当检测到CPU或内存等性能数据超过了阈值的时候，会自动进行基于虚拟机为单元的资源扩展能力。

但是在这个时候对数据库的支撑是相对弱的。

你可以通过PaaS层申请一个数据库服务能力，PaaS层仅仅做了基于已有的数据库虚拟机模板进行创建，而实际的后续管理运维还是你需要直接操作虚拟机进行，其次数据库层往往很难做到弹性自动扩展，当数据库能力不足时候还需要手工申请虚拟资源进行扩展。

再次，应用节点虽然可以通过PaaS层调度和扩展，但是整个基于虚拟机的调度单位整体偏重量级，调度过程很难做到敏捷高效响应。这个也是在这个阶段实际上PaaS没有得到大范围应用的一个关键原因。

从资源到服务，最难的往往就是DB数据库，这个问题没有解决的话实际上对整个应用架构来说并没有做到完全的从IaaS层抽象到PaaS平台层。

平台+应用-》PaaS技术服务能力提供

传统企业内部IT建设思路就是纵向独立建设，而结合SOA和云计算思想下的企业内部私有云平台建设思路就是共性能力下沉，构建平台+应用的私有云平台体系。

这个共性能力下沉的重点就是技术服务能力下沉。

只要是各个业务系统建设中都存在的共性技术服务能力，如流程引擎，消息，缓存，中间件等都应该是统一构建，然后以技术服务的方式提供给业务系统使用。

在这种构建思路下形成了整个私有云PaaS平台的完整架构体系。

从这个图也可以看到PaaS已经从单纯地提供中间件资源池，变成了同时提供各种技术服务和业务服务能力，提供能力集成和开放的厚PaaS平台。这个PaaS平台不仅仅提供运行态的执行能力，还包括了对开发态和运维态的管控治理能力。

在共性能力下沉后，上层应用构建能够更加关注业务场景和业务逻辑的实现，而不用再关注底层技术细节，同时按SOA的思路，PaaS层提供的技术和业务服务能力是能够复用的，能够灵活组装来满足业务需求的。

注意到了这个时候，PaaS平台不需要开始关注传统应用的部署架构和构建逻辑，但是重点仍然是在运行态，即考虑运行态有哪些内容能够真正从资源层迁移到服务层。

如上图，实际上应用中间件，缓存，流程等都可以从原来的资源层能力需求转变为对技术服务能力需求。当然对于数据库同样可以考虑从资源层转变为试用数据库服务能力。

比如当前公有云服务厂商都在提供各种数据库服务，而非再提供虚拟机给开发商，由开发商自己去安装数据库和进行能力扩展。

云服务触角延伸-从运行态到开发态

前面强调的重点一直在运行态，同时运行态从最早期的提供IaaS层能，到提供PaaS层应用托管能力，再到提供各类中间件和技术组件的技术服务能力。

整体看起来应用确实越来越轻，技术层能力都在逐步下沉和移出。但是应用本身选择的开发框架和技术是否适合云平台弹性扩展？这个就变成了云平台服务商最关心的一个问题。

即应用开发需要遵循一定的开发标准和开发模式，这样开发的应用才能够更好的满足向云平台的交付，后续应用的敏捷，动态弹性扩展，高效运维。

到了这里，实际上包括两个关键点如下：

• 传统的单体应用太重，需要拆分为轻量微服务

• 传统向云端仅仅是交付部署过程，需要实现整体持续集成和交付

当到了这个阶段后，云原生的两个关键要素出现，即微服务和DevOps，包括了持续集成和持续交付能力。即整个云原生不仅仅关注运行和运维态。而是将触角延伸到了应用的设计态和开发态。

为了使用云服务的各种优势，那么开发和集成交付过程需要转变。

简单来说就是整个开发框架和环境有了新要求，这个要求就是引入了微服务架构来实现传统单体应用的拆分，其次就是增加了开发态到运行态之间的衔接，即我们常说的持续集成和持续交付过程衔接。

在这个时候实际可以理解为做了两个关键事情

• 开发框架下移：推荐微服务框架对单体拆分

• 持续交付过程上移：推荐DevOps实现持续从本地到云端交付

当到了这个点的时候，实际微服务和DevOps全部引入了。

引入微服务的目的是实现传统单体应用的拆分，拆分后单个微服务粒度更小，更加容易实现高效，轻量的从开发端或私有云环境向云端的交付能力。其次就是这个交付过程必须要管起来，最后是能够自动化并确保连续性，因此引入了DevOps和持续集成交付来实现整个过程。

到了这个时候云原生的核心要素才基本形成。所有的要素都是为了企业本地应用能够快速高效地向云端交付，企业应用在一开始进行开发的就是依云而生，是真正扎根在云上。

治理和管控运维能力的提升

当企业内部IT应用基本实施了微服务化，也实施了DevOps和持续集成交付后，那么问题自然会从开发运行态转变到运维治理态。

到了运维和管控治理阶段核心的重点又在于单体应用拆分为多个微服务后导致了整个集成模型的复杂度。这个时候治理包括了如下几个方面内容：

微服务治理
整体IT应用的的监控和性能分析
IT运维过程

也就是说当你实施了微服务或云原生后，后期的重点一定是治理和运维，如果治理和运维能力跟不上，由于微服务拆分得更细，集成复杂度增加，链路调用复杂度也增加，那么对于整体系统运行管控反而是灾难。

当重新思考这个问题的时候，你可以看到云原生的思路就是只要是非业务相关的技术内容，不管是开发框架环境，开发架构，服务治理都迁移到云端提供。这样开发人员在进行功能开发的时候可以最大限度地减少技术复杂度。

到了这个点你可以理解为云服务本身的治理管控能力提升。

其一就是微服务治理，传统方式可能是微服务开发团队要自己考虑服务如何治理，而到了云服务下微服务治理能也云化和去中心化，即开发态的时候你不用关系服务治理能力的开发，当你最终持续交付到云环境后，云平台通过类似SideCar边车模式来实现微服务治理。

其次就是微服务开发在前后端分离后，云原生核心目标是从传统的整个应用开发演进到Serverless无服务器模式。即应用的开发更加的轻量，连传统应用开发中的比较重的开发框架和开发组件都没有了全部云化，应用的开发更多的变成了前端应用的开发和对后端API接口服务能力的组合。当然在整个过程中仍然需要通过DevOps来实现开发态到运行态的衔接，来实现企业内部私有云环境到公有云服务之间的衔接。

对于Serverless无服务器化当前作为很多公有云服务宣传云原生的一个终结目标状态，但是前面已经提到了实际要真正做到Serverless这个路相当漫长，特别是对于传统企业内部的业务系统开发，其核心原因就在于一个企业内部IT应用开发不仅仅是组合技术服务能力，更加重要的是组合可复用的业务服务能力。

来源： 人月聊IT
作者：何明璐