作者：人月神话，新浪博客同名

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天准备谈下云原生的概念，在前面文章里面已经对微服务，DevOps有了比较详细的一个描述和说明，对于Docker容器云网上材料比较多，因此不准备再详细去描述。

云原生的基础概念

在我很早谈传统企业IT架构转型，企业数字化的时候就曾经谈到过，微服务架构+容器化+DevOps 将成为后续企业信息化转型的主流趋势。

当时没注意到云原生的说法，而现在云原生刚好是这些关键技术的一个整合解决方案。

什么是云原生？

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

Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。

因此云原生是一系列Cloud技术、企业管理方法的集合。

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

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

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

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

1. 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用。
2. 动态管理：通过集中式的编排调度系统来动态的管理和调度。
3. 面向微服务：明确服务间的依赖，互相解耦。

可以参考网上的要给核心导图

图片来源网络

实际上我们看到对于完整的DevOps是包括了持续交付方面的内容的。因此对于云原生的概念完全和我前面经常谈到的微服务，容器化PaaS和DevOps相吻合。

即云原生 = 微服务+ DevOps + 容器化PaaS

云原生本身包括了云原生平台和云原生应用，而平台则是指容器PaaS平台和DevOps能力支撑平台，而云原生应用可以理解为基于微服务思想和开发框架开发的微服务应用。

如果仅仅如此，那么对云原生的理解还是关键技术和方法的一个集合，那么这些集合的目标又是什么？简单理解来说元原生核心是让软件的开发和交付面向云平台或云服务基础设施而进行，能够充分利用云平台提供的能力和服务快速的完成软件的开发和集成，面向客户的持续交付，同时又能够做到足够的敏捷响应变化。

如何做到，核心底层技术是容器化PaaS，小而灵活，而且具备编排属性和能力，传统应用架构通过微服务化后变得足够小而自治，方便进行敏捷开发和迭代，快速的交付和响应，同时也方便部署和托管到容器中。而DevOps更多是一套完全适应云端协同的敏捷管理方法和流程，来实现持续集成和交付。

软件因云而生，即云原生，需要的就是上面三者的密切配合来完成。

云原生的核心究竟在哪里？

图片来自阿里云

在前面一部分我们比较多的引用了当前的云原生概念的基础定义，但是要看到对于微服务，DevOps和容器云只是云原生所表现出来的三大基础特征，那么云原生本身的核心概念又在哪里？

要解释这个还是得回到云原生这三个字开始。

云原生 = 面向云环境的原生应用

即云原生核心是我们开发了面向云环境的核心原生应用。

什么叫面向云环境？

这里的云环境我们重点指公有云环境，当然也可以指企业私有云+公有云的混合环境。为何我们开发的应用要面向云环境而开发？

简单来说就是希望充分的利用云环境的关键特性，这些关键特性包括了高可用，高可靠，高弹性扩展能力，高安全等各个方面。而这些刚好都是云环境所能够提供出来的规模化和集中化优势。

什么是原生应用？

简单来说就是应用开发前就要考虑充分采用云环境所提供给你的平台支撑能力，技术支撑能力，充分考虑云环境已有的各种标准和约束来进行应用的开发。

这样开发出来的应用可以做到平滑从私有云环境迁移到公有云环境，或者说这样开发的应用方便后续进行更好的对应用进行管理和弹性扩展。

为什么微服务，DevOps和容器化是云原生的重点？

通过前面两点解释我们已经看到，我们希望开发的应用能够天生就适合在云环境中生存，其次我们希望应用能够快速的向云端敏捷交付。

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

云原生是即企业核心技术中台

对于云原生解决方案可以看到跟我们前面谈到的企业应该构建核心技术中台概念类似。基于云原生的核心内容理解我们可以构建一个简单的技术中台架构图。

微服务开发框架和运行环境，技术中台服务提供

对于微服务大家会觉得之间采用SpringCloud微服务开发框架体系即可。但是实际上整个微服务开发框架和技术组件绝对不是单个开源软件就解决的，往往涉及到多个开源组件的集成和整合。

其次，在提供微服务开发框架时候，我们整合我们的技术中台服务能力。技术中台服务既包括了传统企业信息化经常谈到的流程引擎服务，4A技术服务，也包括了类似消息，缓存，分布式存储，数据库，文件，通知等各类技术服务能力。技术服务本身和业务无关，同时具备高复用可共享性，因此更加适合下沉统一建设再暴露API接口服务能力。

DevOps过程支撑平台

对于DevOps过程支撑是面向云原生整体解决方案里面的一个关键内容，我们整体的平台本身也是基于DevOps能力成熟度标准来构建。包括了类似研发过程管理，持续集成，持续交付，数据管理，测试管理，度量分析等各个大的模块。

在这个平台中集成了大量的开源组件工具链，实现了整个软件开发项目从代码管理到检入，到自动化编译构建，打包，部署，发布，环境迁移的完整流水线作业能力。

容器化PaaS平台

DevOps过程支撑平台本身底层基于容器化PaaS平台，我们本身提供容器化PaaS平台的完整能力，核心还是基于Docker+k8s的整体容器部署，编排和动态调度方案。但是整个DevOps过程支撑平台也可以实现和当前公有云容器化PaaS平台的无缝集成能力。

通过微服务架构+DevOps过程支撑+容器化PaaS平台，基本就可以实现一个传统应用完整的面向云原生的构建，迁移和后期自动化运维治理能力。

不要自己建技术中台

在我前面对云原生的关键技术概念做完阐述后，可以看到云原生更多的是大的公有云厂商提出的一个概念，而非企业自身提出的一个概念。

公有云厂商提出这个概念很简单，就是希望企业的应用开发可以完全基于云服务厂商提供的各类服务能力来完成，和业务无关的你都不需要关心，你只需要关心和业务相关的微服务模块设计开发和持续集成交付即可。

我们再来看下云原生的几个关键：

• 微服务：本身偏设计和开发态要求，和云端能力提供关系不大
• DevOps：当前阿里，华为云已经提供全面的DevOps支撑集成和交付能力
• 容器云：同样，各大公有云厂家已经全面支持Docker+K8s的容器云和集群管理

谈云原生就不得不谈云原生计算基金会

CNCF，英文全称为Cloud Native Computing Foundation，中文译为“云原生计算基金会”。成立于2015年12月11日。CNCF是Linux基金会旗下的基金会，可以理解为一个非盈利组织。

对于国内的阿里，华为，京东等都是云原生基金会成员，而且也可以看到类似阿里和华为本身也贡献了大量的开源软件给云原生基金会，共同促进云原生的发展。

那么云原生整个开源生态究竟想告诉我们什么？

简单来说开源生态里面列出的各类中间件，工具，技术等就是云原生整个生态里面推荐选择的一些标准技术和产品，当企业开发自己的业务系统和应用的时候，当然就是推荐采用这里面的开源软件进行。

比如对于阿里Nacos,Dragonfly、Dubbo、RocketMQ、OpenMessaging、 PouchContainer和Sentinel均已经列入了云原生解决方案图谱中，你构建应用的时候就可以选择这些开源工具和技术来进行。那么这些技术的采用后续公有云就能够更好的支撑。

企业应用面向云原生真正难点

在前面把一些基础概念谈清楚后可以看到对于微服务，DevOps，容器云这些都不是问题，当前的公有云服务也能够很好的提供。

云原生的真正难点来源于两点：

• 其一是企业内传统遗留IT系统的微服务架构改造和拆分
• 其二是企业剩余技术服务中台能力的完全云化

对于第一点的难度估计大家都比较清楚，今天重点谈下第二点。

我们再重申下云原生希望做的的一个核心目标，即：

企业的应用开发只关心业务，无须关注任何技术层面的内容。

在我们进行微服务架构改造的时候就谈到，企业应该首先要做到共性技术平台的建设，将共性技术平台下沉为PaaS层核心技术服务能力提供。但是我们实际希望的是将这个共性技术平台自己也不要建设了，全部采用云端PaaS层的技术服务能力。

如上图所示，后期企业应用设计开发只需要关注业务流程和业务逻辑的实现，不再需要关注任何IT基础设施，也不需要关注任何技术能力和服务建设。

这些技术服务能力就包括了我们经常说的流程引擎，消息，缓存，存储，日志等，当然公有云PaaS技术服务对这块的支撑越来越好，但是真正的难点却在企业遗留系统的改造往往很难。其次就是这些技术服务如果全部采用公有云技术服务能力，本质是增加了企业微服务和公有云PaaS平台层的耦合，这本身也是增加了集成和联调测试的工作量。

这实际上是云原生发展的一个关键目标，包括云原生里面提到的ServiceMesh，也是同样的道理，即业务应用构建的过程中彻底去中心化，去中心化后才方便后续弹性扩展。

但是类似微服务架构里面API网关层的一些关键能力我们还是需要保留。那么这些共性能力就下沉到各个微服务内部形成一个依托Sidecar。

那么微服务设计开发的时候是否需要去关心这个Sidecar，答案是不用，你只需要按照标准的微服务开发框架和标准去开发，后续这个本地代理依托我们可以在容器镜像制作和部署的时候自动帮你内置进去，这样进一步实现业务和技术管控的解耦。

如上图，采用ServiceMesh后我们可以去掉上层的API网关的单点。

也就是说在新的云原生架构下，我们希望是企业原来构建应用的底层技术平台，上层的接口能力聚合平台这些单点和集中化的点全部都去掉。一个方面是全部迁移到新的云基础设施服务中去，一个方面是将中心化架构进一步转换为非中心化架构。

理解了这个思路，再来看当前的ServerLess无服务器架构就更加容易。

你可以看下ServerLess的基础定义：

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

但是看完也很难理解这个概念。

但是基于我们前面讲解的内容，你可以看到ServerLess架构本质是希望通过拆分实现对应用基础设施的进一步弱化(中间件，容器，开发框架）。

首先可以看到Serverless架构下本身就体现了微服务，而且这种微服务API的粒度更加细，更加小，一个API往往仅仅能够完成一个微功能。因此不再像传统应用必须是一个大的组件模块，实现多个功能并打包在一起。

大的功能拆分为微功能-》微功能本身拆分为无状态的微服务API

在完成了这种拆分后，要实现一个大功能那么就是对诸多的微服务API的的组装过程。

在传统的应用开发和云平台模式下，我们开发一个应用还是能够明确的感受到虚拟机，感受到中间件容器资源，同时应用开发必须依托一个很重的开发框架，类似springcloiud，类似传统的ssh框架等等。

但是新架构下可以看到没有复杂的开发框架，不需要技术服务平台支撑，也没有重的中间件容器，只有一个个新粒度的微服务API，微功能的实现，这些实现也不存在传统的打包和部署动作。也就是说整个软件的开发过程实现完全的面向服务化，你可以使用第三方已有的服务，你开发完成的微功能也是服务，你呈现给用户的是多个服务的串联和组装。

即ServerLess更像是云原生发展的一个终极目标，即企业应用开发只关注业务和逻辑实现，无须关注任何IT基础设施，技术开发框架，技术服务能力提供等。