破解云原生技术难题前，至少要先想清楚这几点

云计算已经成为信息化、数字化发展的重要基础设施，而云原生作为近几年云计算领域最火热的技术架构，呈现愈演愈烈的趋势，并推动企业在数字化浪潮中不断创新发展。云原生已经不是少数几个大企业的专属技术，越来越多的企业正在拥抱它，享受由它带来的技术红利。

云原生技术生态

云原生不是一个产品，而是一套技术体系和一套方法论。云原生即包含技术（微服务，容器等基础设施），也包含管理（DevOps，持续交付，重组等）。云原生也可以说是一系列云技术、企业管理方法的集合。

云原生目前主要的技术包括：容器化，DevOps，CI/CD，微服务。

容器化

在容器技术之前，业界的主流的技术是虚拟机。虚拟机技术的代表是VMware和OpenStack。虚拟机就是在操作系统里安装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。在“子电脑”里，可以和正常电脑一样运行程序，例如微信、Word。“子电脑”和“子电脑”之间，相互隔离互不影响。

虚拟机虽然可以隔离出很多“子电脑”，但占用空间大，启动慢，虚拟机软件可能还要花钱（例如VMware）。而容器技术恰好没有这些缺点，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。虚拟机和以Docker为代表的容器都是虚拟化技术，不过容器属于轻量级的虚拟化。

容器化技术LXC（Linux Container）是将Linux的 Cgroups 的资源管理能力和 Linux Namespace（命名空间）的视图隔离能力组合在一起，这就是如今被广泛应用的容器技术的实现基础。

Docker

说到容器，就不得不说Docker。

Docker本身其实也是属于LXC的一种封装，提供简单易用的容器使用接口。它最大的特性就是引入了容器镜像。Docker通过容器镜像，将应用程序与运行该程序需要的环境，打包放在一个文件里面。运行这个文件，就会生成一个虚拟容器。

更为重要的是，Docker项目还采用了Git的思路 —— 在容器镜像的制作上引入了“层”的概念。基于不同的“层”，容器可以加入不同的信息，使其可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。通过制作Docker镜像，开发者可以通过DockerHub 这样的镜像托管仓库，把软件直接进行分发。

也就是说，Docker的诞生不仅解决了软件开发层面的容器化问题，还一并解决了软件分发环节的问题，为“云”时代的软件生命周期流程提供了一套完整的解决方案。

Kubernetes

随着越来越多的开发者使用Docker来部署容器，编排平台的重要性日益突出。在激烈的竞争中，Kubernetes 逐渐脱颖而出，占据了主导地位。

Kubernetes的主要功能包括

• 资源调度：资源调度是一套分布式系统最基本的核心指标；

• 资源管理：控制Pod对计算资源、网络资源、存储资源的使用；

• 服务发现：管理外在的程序或者内部的程序如何访问Kubernetes里面的某个Pod；

• 健康检查：监控检测服务是否正常运行非常重要；

• 自动伸缩：因为涉及到环境的快速迁移和复制，虚拟机时代之前都非常难实现。容器化时代很自然的解决了这个问题，Kubernetes保证了资源的按需扩容；

• 更新升级：Kubernetes为服务的滚动和平滑升级提供了很好的机制。

DevOps

DevOps（Development & Operations，开发和运维）是2009年提出来的概念，但一直没有太火。直到2014年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。

CI/CD

CI（Continuous Integration，持续集成）

指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

CD（Continuous Delivery，持续交付/Continuous Deployment，持续部署）

持续交付

完成CI中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保CI已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

持续交付的好处

• 繁琐的部署工作没有了。团队不再需要花费几天的时间去准备一个发布；

• 可以更快的进行交付，这样就加快了与客户之间的反馈环；

• 轻松应对小变更，加速迭代。

持续部署

对于一个成熟的CI/CD管道（Pipeline）来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。

签约持续部署的好处

• 发布频率更快，因为不需要停下来等待发布。每一处提交都会自动触发发布流；

• 在小批量发布的时候，风险降低了，发现问题可以很轻松的修复；

• 客户每天都可以看到持续改进和提升，而不是每个月或者每季度，或者每年。

微服务

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上线时间。

微服务的特征包括

• 小：粒度小，专注于一件事；

• 独：单独的进程。微服务不等于组件，服务是可以直接使用的商品，组件是待加工的原材料；

• 轻：轻量级通信机制，通常是HTTP Restful的接口。此处区别于传统的SOA（面向服务的架构）；

• 松：松耦合，可以独立部署。每个微服务可以独立编译、独立部署、独立运行。

微服务架构的好处

• 易于开发与维护：微服务相对小，易于理解；

• 独立部署：一个微服务的修改不需要协调其它服务；

• 伸缩性强：每个服务都可按硬件资源的需求进行独立扩容；

• 与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力；

• 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本；

• 企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡。

企业可以利用云原生这一系列云技术和企业管理方法的集合，通过实践及与其他工具相结合更好地帮助用户实现数字化转型。

元年ECS平台与云原生

元年ECS（Enterprise Cloud Services，企业云服务）平台是元年近年来全力打造的新一代技术中台，在最初的设计中就融入了云原生的设计思想和理念，而云原生，元数据驱动，引擎化则是元年ECS平台的主要特点。

元年云原生架构

元年ECS平台的云原生架构体系包括了微服务体系，DevOps体系，CI/CD平台以及容器管理平台等部分，并将技术中台中的快速开发平台，集成平台串联起来，实现从开发，测试，部署，发布等全流程管理。主要的过程如下：

1. 产品开发通过快速开发平台完成元数据定义，业务规则定义，组件定义，接入各个平台引擎，提交代码仓库，完成业务服务的构建。

2. DevOps平台管理环境，管理代码仓库，根据代码分支自动构建流水线，发布新版本到容器管理平台。

3. CI/CD自动检查容器管理平台的变化，动态为各个环境（开发/测试/生产）部署新的服务。

4. 微服务体系自动发现并注册新服务，管理服务以及监控服务。并根据需要完成灰度发布，动态扩容，熔断限流等服务治理功能。

元年微服务体系

元年微服务体系包括了微服务底座以及微服务注册与发现，负载均衡，通信调用，熔断，降级，限流，网关，配置中心及管理监控等模块。通过一整套的微服务基础功能和治理体系完成企业对微服务架构的使用，发挥微服务架构敏捷性，灵活扩展，轻松部署，技术自由，复用性及弹性的优点。

元年DevOps体系

从元年DevOps总览图可以了解到元年DevOps体系包括组件管理，代码管理，环境管理，流水线管理，容器管理等部分

组件管理：平台通过模版的方式预置了可应用到DevOps各个环节的基础组件，并可以在模版的基础上进行自定义配置，从而更加灵活的为流水线服务。

代码管理：可以管理代码仓库，代码分支。

环境管理：管理物理机，VM虚拟机以及构建容器使用的环境。

流水线管理：管理流水线模版，参数，及对应的插件。可以创建，运行和回收流水线。基于流水线动态构建容器，部署服务，发布版本等。

容器管理：管理容器仓库，编排容器，构建容器，弹性扩缩容，并监控容器运行状况，故障转移等。

元年ECS平台使用完整的微服务体系让企业可以快速打造微服务应用，通过统一的DevOps体系打通微服务开发、测试、部署、发布的整个流程环节，实现快速迭代，自动部署，独立高效的架构体系，将云原生的优点充分发挥出来，加速企业的数字化转型进程。

背景资料

什么是云原生?

云原生（Cloud Native）是一种基于云的基础之上的软件架构思想，以及基于云进行软件开发实践的一组方法论。

而回答“什么是云原生”这个问题时，还是会有些困难：在过去几年间，云原生的定义一直在变化和发展演进，不同时期不同的公司对此的理解和诠释也不尽相同，因此往往会带来一些疑惑和误解。

我们一起来看看云原生定义在不同时期的变化。

Pivotal公司的定义

Pivotal 是Cloud Native/云原生应用的提出者，并推出了Pivotal Cloud Foundry和Spring系列开发框架，是云原生的先驱者和探路者。

Pivotal公司的Matt Stine于2013年首次提出云原生（Cloud Native）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、抗脆弱性；到了2017年，又将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6个特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

CNCF的定义

2015年云原生计算基金会（CNCF）成立，开始围绕云原生的概念打造云原生生态体系。最初CNCF把云原生定义为包括：容器化封装+自动化管理+面向微服务。

到了2018年6月，CNCF正式对外公布了更新之后的云原生的定义v1.0版本：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

CNCF把云原生的概念更广泛地定义为“让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等”，希望能够让开发者最好的利用云的资源、产品和交付能力。