云原生：革新企业基础设施与应用架构

Posted 2021-04-02 百林哲

Play

出品：百林哲

导·语

近几年在云基础设施和应用架构领域，云原生的概念受到了大家的关注。它结合了容器、调度、自动化运维、微服务等技术与架构，提出了面向弹性、韧性、可观测性、确定性构建基础设施和相应应用架构的观点。不少互联网企业率先尝试云原生理念，推动基础设施和应用架构升级。

什么是云原生

云原生是比较宽泛的定义，不同的组织，不同的机构，不同的公司，可能对云原生的看法和想法都不尽相同。

技术视角

1.技术特点

CNCF认为云原生相关的基础设施和相关的应用都应该能适应混合的环境，也就是在共有云，私有云或者未来的混合云便利的场景都能进行适配。那适应云原生技术的也具有这种弹性可扩展的技术的特点。

2.技术目标

云原生希望能够在技术上做到高的容错性，便于观察，便于监控。去做发布，做变更运维的操作，也能非常高效和便捷。

3.典型技术

云原生整个技术特点，技术目标需要有典型技术项目支撑。因此像容器、微服务、声明式API，这些都是云原生时代典型技术来支撑云原生想去达到的技术特点以及技术目标。

理念视角

除了从技术上面维度去看，自底向上去看，云原生还可以自顶向下去看，以更业务视角的维度看一看云原生到底在讲什么。这里举两个例子：

微软：

微软是希望云原生能够帮助重构对企业非常重要的业务系统。云原生希望让这些系统能够做到快速的变化，能够拥抱这些变化，制成非常大规模，用户的体量；也能够非常具有韧性，能够在故障情况下快速恢复，做到真正集成24小时为用户提供可靠稳定的服务。

VMWare：

VMWare认为，云原生不光是一个技术，它更多还是团队，文化上的改进，让大家能够拥抱自动化，拥抱云原生的这些松耦合架构；让今天企业的IT和系统这么复杂情况下还能够管理，而且是非常良好的稳定管理这些复杂度；并且能够加速企业应用的迭代，服务好用户。

所以云原生不仅仅是像Kubernetes项目；像这样的Containers、Microservices、Service Mesh这样的技术；也不仅仅像Google这样公司引领、宣导的技术理念或者是CNCF推导的开源生态。云原生并不存在一个非常确定性的统一定义，在云时代，它代表技术和理念的趋势。

阿里云视角

1.云原生技术

围绕基础设施、应用架构、开发运维等场景，让系统更加弹性可靠容错、松耦合、易管理可观测，充分发挥云计算的优势，提升技术效率。代表性技术为容器、声明式API、不可变基础设施、服务网格、 Serverless。

2.云原生架构

有了技术以后，需要将技术组合成业务系统或者基础架构系统支撑业务发展从而形成云原生架构。云原生的架构是生于云上，长于云上，最大化利用云的能力；是依赖于云上的服务和产品构建的IT架构。这些架构能够帮助开发人员以及研发业务人员聚焦于业务的研发而不是花费精力到基础设施的研发、运维等操作。

区别与 Lift and Shift（搬站模式） 的传统 IT 上云，开发者无法享受云红利。而现在很多企业上云的模式还是传统的搬站模式，这样的架构需要逐步向云原生架构演进。

3.云原生产品

在云上提供的数据库、大数据中间件、函数计算、容器服务等具有一些开放的标准，能跟生态有一定的结合，能够让大家充分地利用起来，而不需要做很多定制化改造产品。并且这些产品具有弹性、高可用能力，更符合云的设计原则产品和服务。这区别于单纯基于虚拟机模型 Host 的低弹性、弱标准的产品。

阿里云认为云原生一定会成为释放云计算最佳红利最短的路径。

云原生相关的产品、技术及架构会成为云计算的新界面。云原生会把云计算的界面抽象程度地进行一定的提高，大家更多的是面向云上的服务，面向云上的应用，而不会持续面向资源进行研发，所以云上一定会出现新的服务界面。

云原生时代会重塑软件的整个生命周期，包括研发、CI/CD，软件的开发和交付模式。云原生模式倡导以自动化流程进行软件开发的驱动和软件开发的扭转；以平台化的思路去解决问题，而不是以工具化的思路去解决问题。

云原生会加速信息产业转型升级。当云上出现新的服务界面、软件研发生命周期加速一定会帮助企业更快地在云上研发产品，加速业务迭代。最终帮助整个产业进行快速转型升级。

基础设施革新

传统意义上来讲，没有云计算之前提供IT服务或者提供互联网的服务，需要使用物理机并将物理机在机房中进行托管。对于大企业则需要自建机房管理，前期启用成本及后期持有成本较高且不具有非常强的弹性。当企业想要更多资源时，要花数月的时间进行资源的预算、采购、准备，整个周期非常长。

因此产生了云的概念，希望能够利用这种池化理念将机器提供给不同的租户使用，让大家能够在同一个基础设施上去使用资源而不需要关心底下基础设施具体的构建。同时进行虚拟化，即把大机器进行拆分，渐渐降低前期启动成本。虚拟化加上池化技术同时让基础设施具有一定弹性，可以进行以天为单位或者以小时为单位的扩缩容。随着业务不断上升，通过不断增加虚拟机数目，让企业容量变得更大，服务更多用户。

不管是物理机也好，还是现在的云时代所使用的虚拟机也好，还都是面向资源的体系，围绕着资源进行构建。而在云原生时代，Serverless希望把面向资源体系转化为面向应用与服务的体系，面向应用与服务的视角。其中非常重要就是Serverless。

当在阿里云上使用数据库的时候，早期需要购买三个虚拟机，在虚拟机上部署Redis数据库。如果面向未来思考，未来就需要定义这个数据库要去支撑什么样体量的业务，它要支撑多少的QPS。未来的云服务自动屏蔽、自动进行弹性的扩缩。也就是不再去面向资源进行采购，而是面向服务进行采购。

使用Serverless体系，能够做到按需计费、免去运维、而且做到秒接的弹性。这也是云原生时代会进行的改革：用户会弱化资源、机器的概念，强化应用与服务体系的概念。

最开始使用云的时候，需要登录云的控制台、购买虚拟机、购买SLB，构成三方架构提供服务。简单、易学但是不易被集成。随着企业规模扩大云上业务管理的服务随之增加导致低效繁琐。为了解决这些问题，云在每一个产品上都开放了API，可以以编程的形式请求云的资源或者云的服务，云具有初步的开放性和易集成的能力。但是每个云产品都具有自己独立的API，它的抽象程度还是非常低的，都是原子化的操作并且是面向过程的。

一方面在云原生时代，随着业务体系、企业IT架构跟云资源充分的融合，对于云资源、云的可操控性的管理会进一步增强。因此我需要去提供高级别的抽象，能够通过描述式的语言来定义需要的云服务或云资源。以往是用代码以描述式方式描述要三个数据库；分别要跟哪些应用进行打通连接；哪些应用要进行授权。而云自身就会把这些描述式的语言变成执行动作进行执行，也不需做具体的原子针对API的操作。所以阿里在推广一个概念Infrastructure as Code，把基础设施作为代码，以描述式的方式来管理云上各种各样的资源和服务，增强云管理的能力，增强在云上使用资源和服务的确定性。

另一方面在云原生的时代，基础软件在云上会有极大的丰富，大家会尝试使用更多云上的这些软件。在云开始的这个阶段，更多的人还是使用人的资源，在上面去自建自己的服务。从云厂商的角度看，肯定希望能够为用户提供更多的价值，让用户在云上更舒适方便。因此阿里构建了对于开源服务的托管，运维的体系，可以把更为繁琐的东西交付给云，让云来做。这是在云原生时代之前，云帮助大家做的事情。

云原生可以帮助大家做更多的事情，阿里提供更多更开放标准的云原生服务，同时还持续地为大家提供开源服务。但是阿里不仅使用开源服务，还要优化开源服务。让开源体系能够跟云有更好的融合更好的打通，比如像PolarDB，EMR。

除此之外，阿里生态体系持续与社区共建。现在Pass类型开源的厂商，Sass类型的厂商都会基于云的体系，以云为第一个业务的场景来构建自己的平台。所以在云原生时代会涌现出大批量基础软件的基础服务在云上。用户不再需要自建基础服务，而是使用云上或者是用云厂商持有提供的或者是用云上的生态伙伴提供的服务，这些都能够大大地降低用户日常运维负担。

最后云未来一定是无限拓展可以覆盖到各个场景的形态。从资源层向上看，不同云之间有不同的行为。最开始专有云、共有云有不同的服务特点、安全的诉求和不同的资源模式。但是如果在云原生时代，从应用的角度看，应用更多地需要统一的标准、云的管理界面、对等的云的服务界面和更为完善的网络和安全管理。

如果从上层去看云，可以使用混合云的理念向应用方屏蔽不同云在底层基础设施层的差异。这样应用就可以做到一次编写、一次描述、多地部署。

如果把云推向不同的场景，比如边缘计算，以云为核心的架构，让云的管理能够覆盖到边缘上面。在边缘上面部署使用软件能够跟云有类似一样的体验，然后屏蔽掉它的真正基础设施上面的差异性，使大家得到一致的体验。因此这个理念可以拓展到更多场景，未来的云从管理界面上来看，如果能够用好云更上一层的抽象，不要去知道底下的资源层，那么云会是一致的界面并覆盖了多种多样的场景。因此，未来的云一定是从底层，是没有边界的云，更易操控的云，更开放的云，面向Serverless的云。

应用架构革新

Service Mesh服务网格

Service Mesh服务网格本质上是微服务衍生的概念。在微服务时代，服务与服务之间需要做很多远程调用、流量控制、流量管理的工作，所以开发了很多微服务的框架。这样的架构导致不同框架的微服务互联互通的问题。比如开源或者社区上的服务是基于Spring的，阿里内部服务是基于HSF的，他们两个组成一个架构，提供一个业务的能力。由于使用不同的RPC框架或者是使用不同服务注册的框架，导致他们两个无法互联互通。但由于基础设施或SDK框架能力不足，导致了上面业务逻辑要重复建设。

在云原生时代，阿里在推动使用不同语言构建不同系统，这样能够做到最好的效率，充分利用每一个语言的特性。为了解决多语言、微服务体系的互联互通问题，阿里提出Service Mesh，希望能够进一步解耦业务逻辑，以微服务体系流量管理，互联互通的逻辑。把流量管理下沉到基础设施层转变为基础设施，转变为一个环境所提供默认的能力。由此通过管控平面，从而管控基础设施，做到让不一样的微服务进行互联互通。这是能力下沉的过程，让基础设施做更多的事情，让业务变得更加轻量级。

目前在开源体系中有两个必要，Evnoy，本质上的作用是透明地去拦截来自于业务的流量。Istio管控平面，管理流量之间怎么去互联互通、管理流量的安全并对流量进行监测。一个是大脑，一个是四肢，目前很多企业都在实践Service Mesh，使用Evnoy和Istio。

BaaS Runtime

流量管理从业务体系中解耦之后，在业务体系中还有和后端服务所进行通讯逻辑连接的代码，那么这部分代码是不是也归于同样的问题？不同的语言都要写一份不同的SDK给业务使用，这部分能不能用同一种语言写一次就能交付给不同的业务使用，把这部分也变得更加轻量级？

因此提到BaaS Runtime的概念，把后端服务的内核层从业务层、应用层解耦出来变成基础设施服务。并且业务使用标准可扩展的轻量级的多语言的API，最终它真正和后端的服务进行通讯做到把后端服务和业务代码进行解耦，做到基础服务层的解耦。

开源上的项目Dapr就是这样，它向应用代码的提供两个非常标准的API，基于HTTP/gRPC API，都是有标准的定义并且能够跨语言的。Dapr自身定义了一系列的后端服务的能力，像状态的管理、资源的管理、可监控性、密钥的管理，它都会提供一套标准的接口。这样在不同的云上，不同的环境上只要实现不一样的Dapr Runtime就能访问不一样的服务。但是从用户侧看到的体验还是一致的。真正能做到业务代码编写一次就能到不同的环境上运行；不同语言的业务代码都能使用同样的API和后端服务进行通讯。

易观测性

在云原生时代之前，观测主要围绕着对于环境的观测，而且是被动的观测，也就是监控系统关注黑盒指标，比如操作系统级别CPU的利用率或者TCP指标。需要利用这些指标推断应用自身的健康状态。另外监控体系一般也都不是打通的。监控体系暴露出来的数据和能力面向运维人员的。由运维人员看到问题后人为排查故障进行修复。

而在云原生时代推广的理念就是自动化，即围绕应用去做白盒化监控，监控应用自身指标而不是监控环境指标。同时监控能力要做到标准、面对自动化系统，通过统一的监控告警系统收取应用指标，由自动化运维管理系统进行统一自动化运维和处理。人就会变成旁路，更多地对系统自动化流程监控。

阿里的云原生实践

阿里云原生历程

2018年前，阿里使用云上的弹性的能力，对云进行验证。在其他场景会向云采购虚拟机，然后把业务系统部署到虚拟机上帮助阿里抗一定的峰值流量，做到弹性扩缩容、降低成本。验证的几年发现云非常稳定，能够做到高弹性能力、降低很多成本。

2019年-2020年，把阿里巴巴的核心系统100%进行上云。

2020年+，阿里将全面运用云的能力，最终提高研发运维效率、成本、稳定性。

全面运用云能力

首先需要全面更多利用云的原生能力。全面运用云的能力，阿里希望分布稳固的演进，能够不停地打磨云上的能力。因此将全面运用云能力分为三个步骤实现：

1.弹性算力。把计算搬到云上，使用虚拟机和底层计算技术在云上使用容器的服务，利用容器编排和调度资源。

2.做到高效、可靠。阿里开始使用云上的存储是需使用云盘提供更强的高可用及更强的数据持久化的保证。在场景下面，阿里使用OSS、文件服务来降低特有存储的成本，提高特有存储的效率。

3.使用云的服务让整个阿里基础设施变得更加便捷强大。在应用运维上面，阿里从自建的监控体系开始使用云上提供的监控和日志体系。在云的管理上面，云的成本分析、控制台都逐渐地移到云上面，包括应用管理、Pass也尽量使用云上的Pass使之更加标准。因此，全面应用云的能力阿里在逐步进行稳步的前进。

应用架构升级

第二步阿里希望在利用云能力基础上，给应用架构做云原生化的升级。

在云原生时代，对于应用架构的升级最重要的是应用架构跟基础设施架构能进行松耦合。标准化应用架构和基础设施架构，并能充分使用平台化特点。为了实现应用架构标准化平台化，第一件事情是容器化，把应用的运行环境和结点的环境充分地解耦。

无服务化，业务价值明显，同时基础设施挑战巨大。

实践发现不需要管理底层资源，按需计费。这需要强自动扩缩容能力，从零到无限都可以支持。基础设施方面，池化、混合部署、强QNS保证阿里的服务质量；也包括提升安全隔离、计量计费支持、观测性。真正做到这些，才能做到全面的无服务化。因此无服务化也是阿里在上云的过程中，在云原生化的过程中，不断演进不打磨基础设施的过程。 

Server Mesh，全局统一管控演进，透明安全能力

从全局视角来看，Server Mesh全局统一管控演进，利用体系将流量管理、可监控性与安全融为一体，在同一管控平面进行演进。同时提供对应用透明的云安全特性。

多模演进

从应用架构升级来看，阿里认为不是所有应用都演进到某一模式，而是多模演进的过程。

容器对于应用自身的入侵较小，不需要应用做很多改动，同时升级基础设施就能够进行容器化。也就是说容器化实际上是可以全场景布开的；

阿里认为应用是强力，是大于微服务的。在微服务体系中Mesh化是需要进一步铺开的，同时Mesh化入侵性较小，大部分流量治理是透明的进行拦截的。目前阿里也在进一步铺开Mesh化；

BaaS化则被认为在新的应用场景中更好实践。如果想做后端服务，还是要做应用层面的入侵、接口，标准化无差别使用后端服务需要对应用做相应调整，将后端服务能力下沉到基础设施层。因此阿里在BaaS化方面主要做新的能够承受BaaS化的应用；

领域FaaS化是更加轻量级、业务研发更专注业务视角的。比如业务写更少的代码，就能完成特定的业务领域的能力。FaaS化是在独特领域进行推进的，运行FaaS化一些能力也在基础设施层进行提供。目前FaaS化能够将通用问题一起在Run time解决，因此阿里正在前端场景包括具有特性的场景推进FaaS化。

研发运维升级

阿里最终达到的是研发运维升级，把基础设施、应用架构的革新传到业务层，提升业务研发的迭代效率，增加业务竞争力。 

在云原生时代，大家可能有一个想法：每一个工程师可能都变成了配置工程师。原来云上的能力与服务需要工程师自己写代码实现，现在则需要配置这些能力与服务。代码编写变成了配置的过程，并且不仅要配置云的服务还需要将云的服务跟应用本身的代码发布结合。

在以人为中心处理软件研发的处境下，在云时代研发工程师很容易成为软件发布与迭代的瓶颈。因此阿里推动的是以流水线与定义流程为中心推动软件发布与研发的流程，形成流水线发布体系。工程师写完代码进行容器镜像打包、环境配置，如果有特殊场景，工程师在最后一公里做细小变更后被自动发布到不同环境。在不同环境上用不同PaaS体系进行部署和运维的操作。因此在云原生时代环境配置与代码管理一定会被流水线化、自动化、会被代码完成而不是人去组装。

传统的运维模式与云原生运维模式比较，传统运维模式以人为中心，人需要并发处理很多事情，非常容易成为瓶颈；云原生时代通过流水线，人发起动作后流水线以自动化的模式进行下推，人在其中的工作极大程度上得到了减轻。比如将过程式、分散式的管理转变为声明式管理，免去基础软件运维使用BaaS化云产品；免去手工操作转变为流水线化无需关注服务本身的服务器层面演进；从向资源发布到向应用流量发布，提供更强大的发布策略。这样就构建起了自动化发布研发运维模式。

阿里云原生成熟度模型

在云原生时代，怎样的架构与理念才是更为云原生的？阿里的云原生成熟度模型提出，企业从服务化能力、弹性能力、无服务器化程度、可观测性、韧性能力、自动化能力六个维度进行评估打分，以这个标准帮助企业评估在云原生时代企业自身的发展状况。

 总  结 

云原生本身还是比较年轻的领域，它的内涵是非常充分的，外延也是非常多的。这个领域还在不断的蓬勃发展中，云原生到底是什么，它未来到底怎么去走，要靠大家一起来去定义，一起来去创造。从阿里巴巴来讲，阿里非常坚信云原生会成为企业充分去利用云，享受云红利享受最短的路径。

作者简介

李响，阿里云资深技术专家（美国）。

全球顶级开源社区云原生计算基金会（Cloud Native Computing Foundation，简称 CNCF）TOC。浙江大学本科和卡耐基梅隆大学硕士学位，是CoreOS最早期的工程师之一，参与创建了etcd、operator framework、rkt等开源项目。

在加入阿里云后，主要负责阿里巴巴大规模集群调度与管理系统，帮助阿里巴巴通过云原生技术初步完成了基础架构的转型，实现了资源利用率与软件的开发和部署效率的大幅提升，并同步支撑了云产品的技术演进。

会 / 议 / 回 / 顾 

参会企业：微软、阿里巴巴、小米、腾讯、华为、360、平安集团、渣打银行、巟商银行、招商银行、随行付、易方达、长亮科技、乐融软件、广州银联、穆迪信息、拍拍贷、宇信集团、投哪儿金融、天维信息、萨摩耶、招商证券、国信证券、陆金所、广发基金、中国银联、恒天软件、天阳宏业、中数通、电信规划设计院、oppo、步步高、vivo、爱立信、百富计算机、厦门航空、福建联迪、恒大物联网、星网视易、升腾科技、视睿电子、飞利浦、金山软件、金山游戏、欧特克、顺丰、深信服、yy、虎牙信息、珠海健康云、优视科技（UC）52TT、21cn、凯米网络、苏州耕耘无忧、ADmaster、博思软件、网宿科技、珍爱网、金蝶、唯品会、大宇无限、华讯网络、传动数码、无限极、云湾信息、珠海网博、上海别样红、同盾科技、杭州顺网、蓝凌软件、诚毅科技、长园深瑞、中南民航、远光软件、中国移动、中国电信、中国联通、物理研究所、深研院等。

特 / 别 / 鸣 / 谢 

精 / 彩 / 推 / 荐

＋

＋

＋

＋

＋

精品推荐

欢迎点击“阅读原文”，时刻学习一线大咖技术经验，同时欢迎大家分享、评论