作者gavin_zhang·2021-02-25 11:36

系统架构师·某股份制银行

云原生技术及未来发展趋势探讨

字数 7311阅读 8585评论 0赞 9

云计算经过十几年的发展，从一开始讨论什么是云计算，到争论云计算是否是旧瓶装新酒，再到讨论如何建设云基础能力，到如何建设云平台上的应用，随着业界对云计算技术的不断探索，我们对云计算的理解和期望在日益提升。当前，大部分的企业已经确实体会到了云计算带来的竞争优势，并已经建成企业内部的私有云基础能力，或是将数据中心迁移到公有云上。应用如何使用好云计算基础设施，使云计算发挥最大能力，是目前云计算技术中最重要的议题。基于云计算平台设计的应用，业界称之为云原生应用。

# 一．云原生的定义

云原生（Cloud Native）是一种构建和运行应用程序的方法，是一套技术体系和方法论。Cloud Native是一个组合词，Cloud+Native。Cloud是适应范围为云平台，Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

## 1、原生云的历史
2013年，Pivotal公司的Matt Stine于首次提出原生云（CloudNative）的概念，用于区分为云而设计的应用和云上部属传统应用。

2015年，Matt Stine在《迁移到云原生架构》一书中定义了符合原生云架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；

2015年云原生计算基金会（CNCF）成立,CNCF作为一个厂商中立的基金会，致力于云原生应用推广和普及。

2017年，Matt Stine将原生云架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

## 2、CNCF对云原生的定义
CNCF(Cloud Native Computing Foundation)于 2015 年 7 月成立,隶属于 Linux 基金会,初衷围绕“云原生”服务云计算。CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的开源技术的推广，如Kubernetes、Prometheus、Envoy等，帮助开发人员更快更好的构建出色的产品。

原生计算基金会（CNCF）成立，是云计算的一个旅程碑，标志着云计算的建设关注点从基础设施的建设向应用的云架构转变。CNCF对云原生的定义是个不断优化的过程。目前CNCF对于原生云的定义为：

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

**这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。“**

CNCF对云原生的描述，前半部分是给出了云原生的定义，并给出目前云原生最佳的技术实践。后半部分指出构建云原生应用的目标。

CNCF还给出了构建云原生的相关技术栈，已经基金会相关的孵化项目信息。

![CNCF 云原生全景图（Cloud Native Landscape）](/home/attachment/202102/25/1210973_161422346934715.png)

## 3、云原生的关键技术
CNCF在定义中给出了云原生的关键技术，容器、服务网格、微服务、不可变基础设施和声明式API，是目前云原生应用的最佳实践
![云原生技术栈](/home/attachment/202102/25/1210973_161422355826391.png)

## - 容器
容器技术是一种轻量级的虚拟化技术。通过操作系统内核的能力，对每个进程的资源使用（包括CPU、内存、硬盘I/O、网络等）进行隔离，达到容器里运行的进程与其他进程进行一定程度的隔离，同时避免了虚拟机（Virtual Machine）过高的额外消耗。

容器通常与容器编排系统一起工作，容器编排系统提供容器的部署和组织能力。容器编排系统通常可以将大量的机器（物理机或虚拟机）作为一个集群进行统一管理，通过设定的策略，将容器部署到这个集群的机器上；实现容器多实例的部署和应用路由的自动化配置；对基础设施和容器进行监控。

容器和容器编排技术对于云原生的意义巨大，容器为云原生应用提供了一个轻量级的运行平台， 首先相对于传统虚拟化技术，容器极其轻量，；可以实现秒级部署；同时容器应用易于移植，一次构建，随处部署。而容器编排技术可以将容器部署到一个很大的集群的同时，还能为应用提供弹性伸缩，故障转移的能力，实现了容器上应用的高可用。提升应用部署的自动化能力和快速部署的能力。

目前常见的容器技术有Linux Container（简称LXC）和runC等。runC是目前的被广泛认可的容器实现，他是基于根据 OCI 标准来创建和运行容器。而 OCI(Open Container Initiative)组织，旨在围绕容器格式和运行时制定一个开放的工业化标准。

目前最主流的容器编排实现就是Kubernetes了，Kubernetes 是用于自动部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 源自Google 15 年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。目前商用和开源的容器平台，基本都是基于Kubernetes的。

## - 不可变基础设施
传统运维的基础设施通常是申请一台或一组服务器，运维人员通过SSH或是Agent的方式，讲软件的二进制包的安装到服务器上并进行环境的配置。如果需要进行版本升级和参数变更等变更操作，就需要逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。这些服务器承载的应用和参数是可以改变的，所以是可变基础设施。这种运维方式也被称为“雪花服务器（ Snowflake Server）”，服务器像雪花一样，每一片都独特的与众不同。

不可变基础设施不同于传统的运维，服务器在部署后永远不会被修改。如果需要以任何方式更新，如版本升级或是参数配置，需要构建新服务器以替换旧服务器。 在不可变基础设施中，服务器的构建通常是以镜像（Image）的方式提供的，任何一个更改都对应一个镜像。不可变基础设施又被称为“凤凰服务器（Phoenix Server）”，服务器应该像凤凰，能够从灰烬中重生。

不可变基础架构的好处包括基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。它可以减少或完全杜绝可变基础架构中常见的问题，例如配置漂移、集群配置一致性和环境复制问题。

不可变基础设施的一个实现方式就是被我们熟知的Docker。Docker通常被作为容器技术被人熟知，实际上Docker提供的是一种容器打包的技术。Docker的核心理念就是不可变基础设施，Docker通过镜像（Docker Images）或是Dockerfile来交付软件。每一次新的版本的发布都对整个运行环境进行重建，每一次更新都是一个新版本的Image。Docker利用容器的轻量化部署，可以达到最高的收益。

## - 微服务
随着需求不断增加，单体应用可能会出现的诸多问题，比如每个小的变更都需要重新部署整个应用，一个小模块的代码缺陷可能导致所有业务不可用等问题。微服务是为解决这些问题的一种架构模式，微服务通过将业务应用由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

微服务将应用拆分为小的独立部署的服务的方式，和容器存在着天然的契合。云上的应用要求可以故障转移，弹性伸缩和快速启停，这些也是微服务应用的设计要求。可以说容器和容器编排技术的发展，大大的推动了微服务的发展；反过来，微服务应用的发展，也推动了容器技术的推广。

由于微服务是一种分布式系统，分布式系统设计的复杂性。为解决微服务系统设计复杂性，各种微服务治理框架层出不穷。比较流行的有Spring Cloud，Dubbo和Istio等。

Spring Cloud是基于微服务优秀开源项目的一个微服务治理全家桶。可以选择不同的解决方案和开源组件，比较完备的解决方案有Spirng cloud Neflix。Spring Cloud是目前全球用的最多的微服务治理框架，可以利用现有Spring的完整生态，和SpringBoot无缝写作文。

Dubbo是国内阿里巴巴提供的服务治理开源项目，同样和Spring整合。国内很多互联网公司选用Dubbo作为微服务框架。

Istio是一个服务网格的开源项目，我们会在下章介绍。

## - 服务网格

前面我们讲了，Docker和Kubernetes已经解决了应用部署，调度和更新的问题。但是微服务应用作为一种分布式系统，运行时的很多问题都需要应用去处理，比如服务的发现、故障熔断和负载均衡等。为了解决这些问题，业界逐渐发展出了微服务治理框架。初期的微服务治理都是基于开发框架的，如Spring Cloud和Dubbo。这些开发框架很好的解决了微服务运行时的问题，但是存在开发语言锁定，对应用存在侵入性、开发运维职责不清等弊端。服务网格（ServiceMesh）就是在这种环境下出现的。

服务网格是最近很火的一个概念，服务网格是用于控制和监控微服务应用程序中的内部服务到服务流量的软件基础结构层。它通常采取与应用程序代码一起部署，作为网络代理的 "数据平面" 和与这些代理交互的 "控制平面" 的形式。在此模型中，服务网格对于业务开发人员是透明的， 而平台运维人员也可以在不关心业务的情况下，有效的运维应用，确保应用的可靠性、安全性和可见性。而且服务网格对对业务应用开发过程的侵入性降到最低，对所有语言友好。

服务网格目前最主要的开源项目时Istio。Istio基于Kubernetes环境提供的一个完整的解决方案来满足微服务应用程序的各种需求。通过Kubernetes的Pod，Istio为每一个微服务实例注入一个Sidecar，代理（Proxy）业务实例的所有外部流量，从而实现微服务治理框架所需要的行为洞察和操作控制的能力，如服务注册发现、配置管理、熔断和链路追踪等。还可以提供灵活的灰度发布策略配置。

## - 声明式API
和声明式相对的是命令式的API。命令式的API是给出每一个操作步骤，目标系统只需要按照步骤进行执行，目标系统将结果返回给调用者，调用者对结果进行处理；声明式API是给出一个最终的状态，目标系统对资源进行操作，以到达要求，调用者不需要进行干预。

声明式API的优势在于让分布式系统之间的交付变的简单。我们不需要关心任何过程细节。声明式的方式能够大量地减少使用者的工作量，极大地增加开发的效率，这是因为声明式能够简化需要的代码，减少开发人员的工作，如果我们使用命令式的方式进行开发，虽然在配置上比较灵活，但是带来了更多的工作。

声明式API的一个最好实例就是Kubernetes。用于操作K8s的yml文件都是声明式的。另外还有一些用于部署的声明式API开源项目，如Terraform。

# 二．云原生的发展趋势

## 1、运维继续下沉，服务网格将成为主流，Serverless逐步推广
云计算的一个发展方向就是运维下沉，将和业务无关的管理功能和运维工作尽量下沉到基础设施中，应用可以聚焦在业务能力的开发和运营。这个趋势演化的过程，影响了云计算的发展方向。从一开始的虚拟化，到IaaS，到PaaS都是将应用系统的部分运维职责交给平台运维的过程。
![运维职能下移](/home/attachment/202102/25/1210973_161422360126345.png)

PaaS为云应用提供了运行容器，解决了应用部署的问题和运行时管理的问题，但是应用仍然有大量的运维工作，特别是对于微服务应用，需要解决诸多的问题，如服务的发布和感知，多实例应用的负载均衡，服务故障检测和隔离，已经应用灰度发布的策略等。这些在PaaS层面是无法解决的，通常是由开发框架解决，就是我们前面提到的微服务治理框架。

因为业务功能的提供才是业务开发团队的价值体现，业务开发团队应该聚焦于业务功能的实现，非功能的需求应该交给平台处理。基于这个诉求服务网格出现了，微服务治理的问题可以有服务网格统一运维管理，业务应用只需关注业务能力的实现。

服务网格出现后，业务应用本身的生命周期还是需要应用来运维保障。这就逐步演化出了Serverless的概念，Serverless并非没有Server，而是对于开发团队来说根本不在意Server是什么样的。开发团队只需要提交业务代码，就可以得到需要的运行实例，对应用开发团队来说，Server是不存在的。

从目前业界的技术趋势来看，ServiceMesh的概念已经被大部分的大型云上企业接受，ServiceMesh被诟病的性能问题也在被逐步解决中，可以预测今年将有更多的微服务应用采用这一基础能力。Serverless目前发展还比较初期，包括了全托管的服务和FaaS（函数即服务），全托管服务在公有云已经逐步成熟，随着混合云的普及，全托管服务会逐步发展。FaaS由于涉及开发模式的转变，目前要取代现有的开发模式还需要时日，不过有些合适的应用场景应该会有越来越多的应用。

## 2、软硬结合，解决虚拟化性能问题的利器

随着云计算的发展，虚拟化技术越来越多的被使用，从计算虚拟化到存储虚拟化到网络虚拟化。虚拟化技术带来了很多的好处，虚拟化是基础设施服务化的基础，通过虚拟化，可以实现基础设施即代码，大大提升了资源的可管理性和自动化程度。但是虚拟化带来了另外一个问题，就是性能的损耗和软件进程之间的相互影响问题。

对于性能损耗，会导致需要的资源比实际业务耗费的资源更多，提升了服务器资源的成本；进程之间的相互影响则会导致云平台的整体性能问题，网络虚拟化和存储虚拟化都需要通过软件进程的方式，来处理网络流量和IO。为了实现分布式高可用和减少数据包转发，基础的SDN，SDS的进程通常是和应用进程部署在同一套集群上。这就导致了有可能部分的SDN和SDS的管理进程所在服务由于各种原因，CPU或是内存占用过大，导致无法及时处理网络和IO请求，导致云平台整体性能下降。

为了解决这两个问题，目前一个解决思路就是软硬结合，讲云平台的管理进程，如调度管理，网络的虚拟交换机，存储的虚拟存储网关从操作系统进程中剥离出来，让这些进程跑在专门设计的服务器板卡上，这些板卡专门设计的，通常含有定制化的芯片（FPGA），可以进行编程，从而可以保持虚拟化话的优势的同时，使的管理进程和业务进程隔离，避免相互影响；同时由于通过定制芯片（如FPGA）来处理，性能会有很大提升，大大降低了虚拟化的损耗。

目前大的公有云厂商都有相关的产品在自身的公有云应用。

## 3、容器虚拟机进一步融合
容器和虚拟机的优势和劣势，从容器技术诞生的那天起就一直在争论。容器轻量化，良好的封装能力和部署简便的特点，特别是在Kubernetes出现后，大有取代虚拟机的气势。但是在处理重应用（如关系型数据库，大数据等）的这点上，容器技术显得又些力不从心。另外容器技术在资源隔离和安全性上，还达不到虚拟机的水准，所以在很多场景，仍然是虚拟机的用武之地。

在这种情况下，如何实现容器技术和虚拟化技术的融合，发挥两者的长处，成为云计算的一个发展课题。目前的技术主要有三种，一种是容器虚拟机的混布；一种是轻量级虚拟机；最后是安全容器。

容器虚拟机的混布。通过修改容器或是虚拟机的编排引擎，使得可以通过一套API，支持容器和虚拟机的部署，同时打通虚拟化层和容器的网络，使之更高效率的进行互访。这是一些传统的虚拟化厂商目前的做法。目前比较成熟的实现有Redhad的Kubevirt。

轻量级虚拟机。解决虚拟机镜像过于庞大，启动慢，耗费资源大的问题，业界提出了轻量级虚拟机的解决方案。轻量级虚拟机使用精简专属的库操作系统(LibraryOS)，它能够使用高级语言编译并直接运行在商用云平台虚拟机管理程序之上。相比于容器技术它们有很多的优点，不仅仅有着媲美虚拟机的隔离能力，而且有更快的启动时间和更小的攻击面。轻量级虚拟机的由于使用了专属的操作系统，在语言支持和兼容性上都不如其他解决方案。目前轻量级虚拟机的技术有很多，例如Unikernel，Drawbridge, MirageOS 和HaLVM等。

安全容器，或是叫沙箱容器。为了解决容器的隔离性上的弱点，安全容器为容器的运行提供了一层沙箱（Sandbox），容器在沙箱中运行的应用程序有自己的内核和虚拟设备，与主机和其它沙箱区分开来。安全容器的优点是可以兼容目前的容器镜像，不需要对容器编排Kubernetes做出大的修改就可以直接应用，缺点是牺牲了部分的性能和灵活度。目前安全容器的开源项目有Kata container，Google的gVisor等。

安全容器和轻量级虚拟机的实现上，可能会有一些重叠，但是不管哪一个方向，都是向这虚拟机和容器融合这个大的方向发展。目标都是在发挥容器的轻量级，快速交付和灵活调度能力的同时，提升业务应用的隔离性和安全性。

# 三．综述
云原生技术是目前技术阶段，企业IT系统的最优模式的集合。企业通过遵循云原生的技术和设计模式，可以充分发挥云计算平台的优势的同时，可以最大限度的减少对开发效率的影响，实现稳定而高效的系统。技术是不断发展的，云原生技术也是一个不断更新迭代的过程，相应的开发习惯和方法也会跟着改变。

云原生容器云微服务

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

云原生技术及未来发展趋势探讨

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料