一、什么是云原生

       到底什么是云原生？不同的企业对于云原生有不同的解释，当前在业界具有广泛影响力的云原生计算基金会（Cloud Native Computing Foundation, CNCF）认为，云原生是一类技术的统称，通过云原生技术，我们可以构建出更易于弹性扩展的应用程序。

这些应用可以被运行在不同的环境当中，比如说私有云、公有云、混合云、还有多云的场景。

云原生到底包含了哪些具体的技术呢？它包含了当前业界的一些热门的技术，比如容器、微服务、服务网格、Serverless、DevOps，API管理、不可变基础架构等。

通过云原生技术构建出来的应用程序，称之为云原生应用，底层基础架构的耦合比较轻，因此易于迁移，它可以充分地利用云所提供的能力，因此云原生应用的开发、部署、管理相对于传统的应用程序更加高效和便捷。

二、 云原生计算基金会（CloudNative Computing Foundation, CNCF）

       云原生计算基金会（Cloud Native ComputingFoundation, CNCF）成立与2015年12月11日，由谷歌与Linux基金会联合创办，成立这个非盈利组织的初衷为推广孵化和标准化云原生相关的技术：

• 推动云原生计算可持续发展；

• 帮助云原生技术开发人员快速地构建出色的产品。

云原生涉及到许多技术领域，每一个技术领域都有相应的工具、框架与平台，来帮助落地具体的应用。

CNCF维护了一个云原生技术全景图，在其中收集了和云原生技术相关的工具、平台和项目，全景图的内容十分丰富，可谓种类繁多、琳琅满目。通过这个云原生全景图可以快速地了解到每一个技术领域当中流行的工具。

云原生的生态体系：

三、云原生的作用：

       对于应用开发团队而言，原来云原生技术可以提升应用开发的效率，提升应用交付的质量。比如通过容器，技术开发团队可以更容易地获取开发所需要的环境与资源，开发出来的应用可以被运维团队更容易地部署和管理。通过DevOps的最佳实践，应用交付的速度和质量可以被有效的提升。

      对于业务方来说，云原生的好处是所提交的需求，可以更快地被响应和实现。因为云原生技术可以有效地缩短应用交付的周期，让需求更快地变成代码，代码更快地变成线上的应用，最终为用户服务，实现价值。

云原生应用可以更好地弹性扩展，满足不同业务的需求。例如容器应用提供的应用自愈能力，可以帮助减少应用的停机时间提升用户的体验。

云原生技术可以提升应用开发的交付效率，缩短应用上线所需要的时间，开发和业务团队人员可以有更多的时间和精力进行业务创新，有效地提升团队的创新能力，从而提升企业在市场的竞争能力。

四、如何拥抱云原生技术

        经过几年的发展，云原生这个概念已经得到了社区、企业和市场的广泛认可。从当前比较热门的云原生技术、容器来看，云原生已经在众多行业和领域，有了许多落地的案例，包括高科技、金融、制造、零售、教育、政府，甚至是军事等。

近日有报道称美军在f16战斗机上，成功地测试和部署了容器管理平台Kubernetes和服务网格Istio。

当一个企业拥抱云原生技术，具体要在什么方面来落实？CNCF有一个建议的技术路线图。这个图上列出了10个方面，比如说通过应用容器化，使得应用更易于迁移的交付，通过持续集成的区域部署提升云原生软件的质量，通过容器编排简化应用的部署

五、云原生的主要技术架构

大企业疑问，云原生是不是只适合一些小企业？小企业觉得云原生是不是只适合成熟的大企业？其实云原生对大企业、小企业都有帮助。

对于有着数字化转型战略和上云计划的大企业来说，云原生可以充分地利用云的优势，让企业在云上的投资获得最大的收益。

对于较小企业来说，通过云可以获取以往只有大企业才拥有的计算资源，小企业由于人员、财力等资源相对紧张，通过云原生技术倡导自动化和智能化的想法，可以提升产品开发的交付效率，把有限的精力放在核心业务的创新上，可以让企业更具竞争能力。

云原生涉及的技术领域众多，有6个方面值得大家重点关注：

1. 容器（Containers）

容器是一种轻量级的虚拟化技术，通过容器可以简化应用的部署、管理和交付。目前各大IT厂商已经投入了大量的资源进行容器产品和服务的研发，可以预见，未来容器将会是一种主流的应用交互手段，非常有前景。

2. 微服务（Microservices）

微服务倡导运用化整为零，实现各个功能的独立开发与部署、提升应用架构的灵活性，从而提升对业务的响应速度。在提倡敏捷的今天，微服务已经成为应用架构的一种默认的选择。

3. 无服务（Serverless）

无服务器架构并不是说，未来不再需要服务器，而是不再着重关注底层的基础架构，更多的注意力可以放在和业务更相关的一些逻辑实现上，例如一些函数的代码片段，平台自动根据负载按需部署和启动，以及自动伸缩代码逻辑来满足业务处理的需求。

4. DevOps

DevOps这个框什么都可以往里装，提供了指导思想、流程和工具，为应用的迭代更新保驾护航，运维行业的未来之路。

5. Service Mesh(服务网格)

Service Mesh是近年兴起的一个话题，在容器微服务的基础上，通过Service Mesh可以让用户更精细、更智能的去管理服务之间的通讯。ServiceMesh社区的旗舰项目Istio，当前的热度正在迅速的飙升。

6. 云（Cloud）

云是云原生的基础，没有云也就没有云原生。没有对云正确地理解，也不可能对云原生有正确的打开方式。对于非技术人员来说，至少要理解云的多种不同的服务模型，比方IaaS、PaaS、SaaS以及各种服务模型的应用场景和价值。

---

容器（Containers）、微服务（Microservices）、无服务（Serverless）、DevOps、ServiceMesh(服务网格)、云（Cloud）这6个方面，并不是孤立的，而是相互联系的。

云是一切的基础，为上层应用的运行提供了计算、网络、存储等基础架构资源；

容器在云的基础架构和应用之间，集有了应用和基础架构资源；

应用层面，用户可以根据场景来选择微服务架构或者是无服务器架构；

在复杂的交互场景当中，通过服务网格，可以对服务组建的通讯进行管控；

通过DevOps构建一个应用架构不断迭代更新的正向循环。

这六个方面都可以具体展开来讲，下面主要从容器化、微服务、服务网格、devOps来阐述，云是基础设施和Serverless目前实施多就不具体阐述了！

容器化：

   -- 虚拟化技术：

由于KVM（ for Kernel-based Virtual Machine ）hypervisor虚拟化技术仍然存在⼀些性能和资源使⽤效率⽅⾯的问题，因此出现了⼀种称为容器技术（Container）的新型虚拟化技术来帮助解决这些问题。

虚拟化技术可以在宿主机上安装多个不同的操作系统，运⾏多套不同的应⽤。但可能就是为了运⾏⼀个微应用，却还要在虚拟机⾥运⾏⼀个完整的操作系统，内核和其它⽆关程序，这种做法资源利⽤不⾼。

所以我们希望更多的关注应⽤程序本身，⽽不再分精⼒去关注操作系统与⽆关程序，操作系统内核直接与宿主机共享。

-- docker容器：

Docker容器本质上是宿主机的进程. 可以把docker容器内部跑的进程看作是宿主机的线程。
Docker通过namespace实现了资源隔离，通过cgroups实现了资源限制。

Linux内核实现namespace的⼀个主要⽬的就是实现轻量级虚拟化(容器)服务。在同⼀个namespace下
的进程可以感知彼此的变化，⽽对外界的进程⼀⽆所知。

Linux容器技术是⼀种轻量级的虚拟化技术。主要特点有:

1. 轻量:只打包了需要的bins/libs(也就是命令和库⽂件)。与宿主机共享操作系统,直接使⽤宿主机的内核。
2. 部署快: 容器的镜像相对虚拟机的镜像⼩。部署速度⾮常快，秒级部署。
3. 移植性好: Build once，Run anywhere (⼀次构建,随处部署运⾏)。
4. 资源利⽤率更⾼: 相对于虚拟机，不需要安装操作系统，所以⼏乎没有额外的CPU，内存消耗。

--虚拟化与容器化得对比：

虚拟化（VM）Docker容器操作系统宿主机OS上运行虚拟机OS与宿主机共享OS存储大小镜像庞大（vmdk、vdi等）镜像小，便于存储于传输运行性能操作系统额外的CPU、内存开销几乎无额外的性能损失移植性笨重，与虚拟化耦合度高轻便、灵活、适应于linux硬件亲和性面向硬件开发者面向软件开发者部署速度较慢、10秒级别快速、秒级

--容器的编排和调度

Kubernetes（k8s）是Google基于Borg开源的容器编排调度引擎，作为CNCF（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动得达到和维持在这个状态。

Kubernetes用户可以通过编写一个yaml或者json格式的配置文件，也可以通过工具/代码生成或直接请求Kubernetes API创建应用，该配置文件中包含了用户想要应用程序保持的状态，不论整个Kubernetes集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求Kubernetes API来改变应用程序的状态。

Kubernetes 架构图：

其他容器编排与调度技术方案：
Swarm、Mesos

微服务：

微服务是一种分布式架构设计理念，为了推动细粒度服务的使用，这些服务要能协同工作，每个服务都有自己的生命周期。一个微服务就是一个独立的实体，可以独立的部署在PAAS平台上，也可以作为一个独立的进程在主机中运行。服务之间通过API访问，修改一个服务不会影响其它服务。

微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。

--spring生态体系

当前最成熟最完整的微服务框架Spring，而Spring又仅限于Java语言开发，其架构本身又跟Kubernetes存在很多重合的部分，如何探索将Kubernetes作为微服务架构平台就成为一个热点话题。就拿微服务中最基础的服务注册发现功能来说，其方式分为客户端服务发现和服务端服务发现两种，Java应用中常用的方式是使用Eureka和Ribbon做服务注册发现和负载均衡，这属于客户端服务发现，而在Kubernetes中则可以使用DNS、Service和Ingress来实现，不需要修改应用代码，直接从网络层面来实现。

服务网格

Kubernetes中的应用将作为微服务运行，但是Kubernetes本身并没有给出微服务治理的解决方案，比如服务的限流、熔断、良好的灰度发布支持等。

--Service Mesh可以用来做什么：

• Traffic Management：API网关
• Observability：服务调用和性能分析
• Policy Enforcment：控制服务访问策略
• Service Identity and Security：安全保护

--Service Mesh的特点

• 专用的基础设施层
• 轻量级高性能网络代理
• 提供安全的、快速的、可靠地服务间通讯
• 扩展kubernetes的应用负载均衡机制，实现灰度发布
• 完全解耦于应用，应用可以无感知，加速应用的微服务和云原生转型

当前开源的Service Mesh有哪些？
使用Service Mesh将可以有效的治理Kubernetes中运行的服务：

Linkderd：https://linkerd.io，由最早提出Service Mesh的公司Buoyant开源，创始人来自Twitter
Envoy：https://www.envoyproxy.io/，Lyft开源的，可以在Istio中使用Sidecar模式运行
Istio：https://istio.io，由Google、IBM、Lyft联合开发并开源
Conduit：https://conduit.io，同样由Buoyant开源的轻量级的基于Kubernetes的Service Mesh
此外还有很多其它的Service Mesh鱼贯而出，请参考awesome-cloud-native。

DevOps

--持续集成

Continuous integration，简称CI
是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

--持续交付

 Continuous Delivery，简称CD
持续交付是指软件开发过程，从原始需求到最终产品开发过程中，较短周期内以需求的小颗粒度（小批量）频繁提交的过程。

目的

1. 开发过程的快速迭代，小步快跑，及时纠正偏离主线
2. 小颗粒度实现，避免颗粒度大，出现问题解决麻烦
3. 迅速反馈软件功能，避免⽅向性错误
4. 团队角色（含客户）协作密切，减少时间浪费

--持续部署
Continuous Deployment，简称CD
基于持续交付的基础上，把功能稳定，符合产品需求的版本有方法地部署至生产环境中。

--持续发布
Continuous Release，简称CR
发布是周期性或不定期地对项目在部署后，进行整体软件版本的更新，例如，更新功能或展示页面框架等。

目的

产品快速迭代，小步快跑
适应市场变化
匹配市场策略
应对市场风险

--持续测试
Continuous Testing，简称CT
持续测试是贯穿着整个软件开发过程，验证程序员提交代码，检验合规性及降低bug，减少最终错误，实现敏捷及精益开发。

目的

为了降低开发、部署、发布等可能出现的错误
防止代码出错
防止功能出错
防止业务逻辑出错等

--Jenkins
Jenkins是一款由Java编写的开源的持续集成工具。

Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中。它支持软件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以执行基于Apache Ant和Apache Maven的项目，以及任意的Shell脚本和Windows批处理命令。

应用构建和发布流程说明：

1、用户向Gitlab提交代码，代码中必须包含Dockerfile。
2、将代码提交到远程仓库。
3、用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数，确定后触发Jenkins自动构建。
4、Jenkins的CI流水线自动编译代码并打包成Docker镜像推送到Harbor镜像仓库。
5、Jenkins的CI流水线中包括了自定义脚本，根据我们已准备好的Kubernetes的YAML模板，将其中的变量替换成用户输入的选项。
6、生成应用的Kubernetes YAML配置文件。
7、更新Ingress的配置，根据新部署的应用的名称，在Ingress的配置文件中增加一条路由信息。
8、更新PowerDNS，向其中插入一条DNS记录，IP地址是边缘节点的IP地址。
9、Jenkins调用Kubernetes的API，部署应用。
 

总结： 云原生四大体系的基础架构思维导图

六、云原生与开源

最后，基于过去几年推广开源软件和解决方案的工作习惯，和大家强调一下云原生和开源的关系。目前云原生领域的大部分关键技术，例如容器引擎、容器编排Kubernetes、服务网格Istio，都来自于开源社区。

开源社区是云原生技术的创新根据地，因此企业拥抱云原生技术的过程，也是拥抱开源社区的一个过程。在不久的未来，经过云原生浪潮之后，IT企业当中的技术堆栈里面，开源软件的比例将会大幅提升，这将给市场提供许多新的机遇。
 

（完）