云原生下一步的发展趋势分析.docx

《云原生下一步的发展趋势分析.docx》由会员分享，可在线阅读，更多相关《云原生下一步的发展趋势分析.docx（13页珍藏版）》请在第一文库网上搜索。

1、云原生下一步的发展趋势分析【摘要】云原生技术是目前技术阶段，企业IT系统的最优模式的集合。云原生技术也是一个不断更新迭代的过程，相应的开发习惯和方法也会跟着改变。云计算经过十几年的发展，从一开始讨论什么是云计算，到争论云计算是否是旧瓶装新酒，再到讨论如何建设云基础能力，到如何建设云平台上的应用，随着业界对云计算技术的不断探索，我们对云计算的理解和期望在日益提升。当前，大部分的企业已经确实体会到了云计算带来的竞争优势，并已经建成企业内部的私有云基础能力，或是将数据中心迁移到公有云上。应用如何使用好云计算基础设施，使云计算发挥最大能力，是目前云计算技术中最重要的议题。基于云计算平台设计的应用，业界

2、称之为云原生应用。一.云原生的定义云原生(CIOUc1Native)是一种构建和运行应用程序的方法，是一套技术体系和方法论。C1oudNatiVe是一个组合词，C1oud+NativeoC1oUd是适应范围为云平台，NatiVe表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性十分布式优势。1、原生云的历史2013年，PiVOta1公司的MattStine于首次提出原生云(C1oUdNatiVe)的概念，用于区分为云而设计的应用和云上部属传统应用。2015年，MattStine在迁移到云原生架构一书中定义了符合原生云架构的几个特征：12因素

3、、微服务、自敏捷架构、基于AP1协作、抗脆弱性；2015年云原生计算基金会(CNCF)成立,CNCF作为一个厂商中立的基金会，致力于云原生应用推广和普及。2017年，MattStine将原生云架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而PiVotaI最新官网对云原生概括为4个要点：DeVOps+持续交付+微服务+容器。2、CNCF对云原生的定义CNCF(C1oudNativeComputingFoUndation)于2015年7月成立，隶属于1inux基金会,初衷围绕“云原生”服务云计算。CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的开源技术的推广，如

4、KuberneteSsPrometheusEnVC)y等，帮助开发人员更快更好的构建出色的产品。原生计算基金会(CNCF)成立，是云计算的一个里程碑，标志着云计算的建设关注点从基础设施的建设向应用的云架构转变。CNCF对云原生的定义是个不断优化的过程。目前CNCF对于原生云的定义为：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。“CN

5、CF对云原生的描述，前半部分是给出了云原生的定义，并给出目前云原生最佳的技术实践。后半部分指出构建云原生应用的目标。CNCF还给出了构建云原生的相关技术栈，已经基金会相关的孵化项目信息。ACNCF云原生全景图(C1OUdNative1andscape)3、云原生的关键技术CNCF在定义中给出了云原生的关键技术，容器、服务网格、微服务、不可变基础设施和声明式API,是目前云原生应用的最佳实践。云原生技术栈-容器容器技术是一种轻量级的虚拟化技术。通过操作系统内核的能力，对每个进程的资源使用（包括CPU、内存、硬盘I/O、网络等）进行隔离，达到容器里运行的进程与其他进程进行一定程度的隔离，同时避免了

6、虚拟机（Virtua1Machine）过高的额外消耗。容器通常与容器编排系统一起工作，容器编排系统提供容器的部署和组织能力。容器编排系统通常可以将大量的机器（物理机或虚拟机）作为一个集群进行统一管理，通过设定的策略，将容器部署到这个集群的机器上；实现容器多实例的部署和应用路由的自动化配置；对基础设施和容器进行监控。容器和容器编排技术对于云原生的意义巨大，容器为云原生应用提供了一个轻量级的运行平台，首先相对于传统虚拟化技术，容器极其轻量，；可以实现秒级部署；同时容器应用易于移植，一次构建，随处部署。而容器编排技术可以将容器部署到一个很大的集群的同时，还能为应用提供弹性伸缩，故障转移的能力，实现了

7、容器上应用的高可用。提升应用部署的自动化能力和快速部署的能力。目前常见的容器技术有1inUXContainer（简称1XC）和runC等。runC是目前的被广泛认可的容器实现，他是基于根据OC1标准来创建和运行容器。而OCI（OpenContainerInitiatiVe）组织，旨在围绕容器格式和运行时制定一个开放的工业化标准。目前最主流的容器编排实现就是KUberneteS了，Kubernetes是用于自动部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes源自GOOgIe15年生产环境的运维经验，同时凝聚了社区的最佳创意

8、和实践。目前商用和开源的容器平台，基本都是基于KUberneteS的。-不可变基础设施传统运维的基础设施通常是申请一台或一组服务器，运维人员通过SSH或是Agent的方式，将软件的二进制包的安装到服务器上并进行环境的配置。如果需要进行版本升级和参数变更等变更操作，就需要逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。这些服务器承载的应用和参数是可以改变的，所以是可变基础设施。这种运维方式也被称为“雪花服务器(Snowf1akeServer)”,服务器像雪花一样，每一片都独特的与众不同。不可变基础设施不同于传统的运维，服务器在部署后永远不会被修改。如果需要以任何方式更新，如版本升级

9、或是参数配置，需要构建新服务器以替换旧服务器。在不可变基础设施中，服务器的构建通常是以镜像(Image)的方式提供的，任何一个更改都对应一个镜像。不可变基础设施又被称为“凤凰服务器(PhoenixServer)”,服务器应该像凤凰，能够从灰烬中重生。不可变基础架构的好处包括基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。它可以减少或完全杜绝可变基础架构中常见的问题，例如配置漂移、集群配置一致性和环境复制问题。不可变基础设施的一个实现方式就是被我们熟知的DockeroDocker通常被作为容器技术被人熟知，实际上DoCker提供的是一种容器打包的技术。DOCker的核心理念就是不

10、可变基础设施，DOCker通过镜像(DockerImages)或是Dockerfi1e来交付软件。每一次新的版本的发布都对整个运行环境进行重建,每一次更新都是一个新版本的ImageoDOCker利用容器的轻量化部署，可以达到最高的收益。-微服务随着需求不断增加，单体应用可能会出现的诸多问题，比如每个小的变更都需要重新部署整个应用，一个小模块的代码缺陷可能导致所有业务不可用等问题。微服务是为解决这些问题的一种架构模式，微服务通过将业务应用由通过明确定义的API进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间

11、。微服务将应用拆分为小的独立部署的服务的方式，和容器存在着天然的契合。云上的应用要求可以故障转移，弹性伸缩和快速启停，这些也是微服务应用的设计要求。可以说容器和容器编排技术的发展，大大的推动了微服务的发展；反过来，微服务应用的发展，也推动了容器技术的推广。由于微服务是一种分布式系统，分布式系统设计的复杂性。为解决微服务系统设计复杂性，各种微服务治理框架层出不穷。比较流行的有SPringCIOUd,Dubbo和Istio等。SpringC1OUd是基于微服务优秀开源项目的一个微服务治理全家桶。可以选择不同的解决方案和开源组件，比较完备的解决方案有SPirngc1oudNef1ixoSpringC

12、1OUd是目前全球用的最多的微服务治理框架，可以利用现有SPri1Ig的完整生态，和SpringBoot无缝写作文。DUbbo是国内阿里巴巴提供的服务治理开源项目，同样和SPring整合。国内很多互联网公司选用Dubbo作为微服务框架。Istio是一个服务网格的开源项目，我们会在下章介绍。-服务网格前面我们讲了，DoCker和KUberneteS已经解决了应用部署，调度和更新的问题。但是微服务应用作为一种分布式系统，运行时的很多问题都需要应用去处理，比如服务的发现、故障熔断和负载均衡等。为了解决这些问题，业界逐渐发展出了微服务治理框架。初期的微服务治理都是基于开发框架的，如SPringCIoU

13、d和DUbb0。这些开发框架很好的解决了微服务运行时的问题，但是存在开发语言锁定，对应用存在侵入性、开发运维职责不清等弊端。服务网格(ServiceMesh)就是在这种环境下出现的。服务网格是最近很火的一个概念，服务网格是用于控制和监控微服务应用程序中的内部服务到服务流量的软件基础结构层。它通常采取与应用程序代码一起部署，作为网络代理的“数据平面”和与这些代理交互的“控制平面”的形式。在此模型中，服务网格对于业务开发人员是透明的，而平台运维人员也可以在不关心业务的情况下，有效的运维应用，确保应用的可靠性、安全性和可见性。而且服务网格对对业务应用开发过程的侵入性降到最低，对所有语言友好。服务网格

14、目前最主要的开源项目是Istio0Istio基于Kubernetes环境提供的一个完整的解决方案来满足微服务应用程序的各种需求。通过Kubernetes的Pod,IStio为每一个微服务实例注入一个SideCar,代理(Proxy)业务实例的所有外部流量，从而实现微服务治理框架所需要的行为洞察和操作控制的能力，如服务注册发现、配置管理、熔断和链路追踪等。还可以提供灵活的灰度发布策略配置。-声明式AP1和声明式相对的是命令式的API。命令式的AP1是给出每一个操作步躲，目标系统只需要按照步骤进行执行，目标系统将结果返回给调用者，调用者对结果进行处理；声明式AP1是给出一个最终的状态，目标系统对资

15、源进行操作，以到达要求，调用者不需要进行干预。声明式AP1的优势在于让分布式系统之间的交付变的简单。我们不需要关心任何过程细节。声明式的方式能够大量地减少使用者的工作量，极大地增加开发的效率，这是因为声明式能够简化需要的代码，减少开发人员的工作，如果我们使用命令式的方式进行开发，虽然在配置上比较灵活，但是带来了更多的工作。声明式AP1的一个最好实例就是KUbernetes。用于操作K8s的ym1文件都是声明式的。另外还有一些用于部署的声明式AP1开源项目，如Terraforn1。二.云原生的发展趋势1、运维继续下沉，服务网格将成为主流，SerVer1eSS逐步推广云计算的一个发展方向就是运维下

16、沉，将和业务无关的管理功能和运维工作尽量下沉到基础设施中，应用可以聚焦在业务能力的开发和运营。这个趋势演化的过程，影响了云计算的发展方向。从一开始的虚拟化，到IaaS,到PaaS都是将应用系统的部分运维职责交给平台运维的过程。运维职能下移PaaS为云应用提供了运行容器，解决了应用部署的问题和运行时管理的问题，但是应用仍然有大量的运维工作，特别是对于微服务应用，需要解决诸多的问题，如服务的发布和感知，多实例应用的负载均衡，服务故障检测和隔离，已经应用灰度发布的策略等。这些在PaaS层面是无法解决的，通常是由开发框架解决，就是我们前面提到的微服务治理框架。因为业务功能的提供才是业务开发团队的价值体现，业务开发团队应该聚焦于业务功能的实现，非功能的需求应该交给平台处理。基于这个诉求服务网格出现了，微服务治理的问题可以有服务网格统