云原生时代，应用架构将如何演进？

云原生已经进入了PaaS上云为主的阶段

阿里巴巴已经经历了IaaS上云的阶段，迈进到了PaaS上云的时代。在去年的“双11”，阿里巴巴就已经实现了电商核心系统的全面上云，这里的上云主要是在IaaS层。所谓IaaS主要就是对计算、网络、存储的虚拟化，经过了这个阶段，阿里巴巴就进入了PaaS上云的阶段。在PaaS上云这个阶段就需要使用更多的云产品，包括中间件、存储、缓存甚至是应用托管平台等。

​​

​​

IaaS阶段和PaaS阶段其实存在很大的差别。在IaaS阶段，对于应用研发来说，所关心的往往就是基础设施和资源，通俗来讲就是虚拟机或者容器等，这些对应用架构几乎没有任何侵入。但是在PaaS上云阶段，当你使用云产品，比如云Redis、云RDS、云OSS、云RabbitMQ等的时候，都会对于应用架构产生比较强的侵入。那么，这样的侵入会对应用架构产生什么样的影响，是所有研发架构师所需要思考的一个问题。

云原生技术

如果大家尝试去搜索云原生技术，就会看到Google Cloud的定义、CNCF的定义以及其他很多的云产商以及开源软件的定义，而这些定义看法都各有不同。简单归纳可以分为如下图所示的几类，纵向来看，分为了应用架构、生命周期管理、流量管理，以及基础设施及依赖四个维度;横向来看，又分为了微服务、12 Factor Apps、容器、BaaS、GitOps/IaC以及Service Mesh几个维度。

​​

​​

今天，大家都会谈到基于微服务架构做云原生，而不是基于巨石应用架构或者简单的CS架构。Quarkus提出了12 Factor Apps，意思就是说如果在今天想要让应用跑在Quarkus等这些应用托管平台上，对于应用具有一定的要求，大概是12条原则，比如配置和代码分离等，当然后续还有很多的扩展。这些原则中的很多条目的意思都是说只要你符合这些原则，那么应用托管平台就能够为你提供更多的能力，比如免运维等。容器的核心是使用一种标准的交互方式让平台能够管理应用的生命周期，包括发布、扩容以及自愈等。

BaaS——Backend as a Service，能够尽量使用现有的服务来构建应用程序。Service Mesh的本质是管理流量，今天的应用程序都在接收流量，提供服务时流量又需要出去，在这个过程中如何管理服务发现、流量路由规则等都需要Service Mesh技术。最后需要重点介绍的就是GitOps和IaC(Infrastructure as Code)，这些技术如今在行业里面得到了越来越多的关注，尽管还没有事实上的标准，但是很多云计算公司正在不断努力。其含义是说今天在使用基础设施的时候，可以用代码去声明这些基础设施的需求。总而言之，上述这些内容都是围绕应用架构、生命周期管理、流量管理，以及基础设施及依赖这四个维度的。

业务关心的是交付速度

对于业务而言，最关心的往往是交付速度。如果你和业务总监或者CTO去聊，他们就会问你，拥有这么多的技术对于业务有什么好处?可能会谈到成本的优势、管理的优势，但是对于几乎所有业务而言，最核心的是研发效率的提升。所以我们应该思考云原生技术如何才能帮助实现更快的交付。

借助云原生技术来提升交付服务的速度可以大致分为三个步骤。

标准化平台/服务和应用的协议

将平台/服务和应用之间的协议进行标准化。如果IaaS层用云的话协议就是机器，就是虚拟机、容器等，对于业务应用而言，看到的就是一个操作系统，这样应用就可以使用操作系统上的各种资源，这样做的好处在于不需要关心物理机以及机器的故障等问题。

与业务无关能力进一步解耦至平台

对于业务应用而言，看到的就不是一个操作系统了，会给到一个更加上层的协议，让平台帮助应用实现自动伸缩以及自愈等，还可以帮助应用实现自动腾挪，当底层基础设施发生故障的时候，可以将应用从一台机器迁移到另外一台机器，也就是生命周期管理。基于上述协议，平台的很多能力就能够下沉，比如原本需要手工管理的事情只需要通过代码声明就可以很好地实现了，有了这些协议之后，业务应用就能够将相关的生命周期管理托管给平台。

应用架构升级

除了上述两点之外，第三步就是让应用架构需要通过升级来适应，这样才能让相关能力下沉到云平台。

IaaS上云阶段到云原生上云阶段的转变

进一步细化就会发现，在原来的IaaS上云阶段，除了需要关心业务逻辑之外，还需要关心业务应用的生命周期管理、流量管理，还需要自己进行搭建和配置中间件，比如在云环境中搭建Redis、kafka等，也就是说花费了大量时间在应用依赖管理的事情上，无法让云平台进行管理。今天，在PaaS上云或者云原生上云的阶段，想要做到的就是尽量使用云平台提供的能力，将更多的精力集中在业务本身，而将业务无关的通用技术能力都交给云来管理。

​​

​​

核心问题：

• 业务无关能力如何解耦至平台?
• 平台和业务(应用)之间的协议如何定义?
• 应用架构需要如何适应?

以前在IaaS上云阶段，应用和操作系统进行交互存在标准的协议，而今天在PaaS上云阶段，这样的协议应该是什么，需要被重新定义。此外，基于这样的协议如何实现能力下沉，也是很多包括阿里云在内的很多云厂商所做的事情，比如阿里云基于RocketMQ做了RocketMQ Service，基于容器的一些协议提供容器服务等等。当然，现在只是一个开始，未来这部分内容将会更加丰富和完整。

例子1：Service Mesh把服务发现和流量从业务剥离

与此同时，应用架构也需要去适应。这里以Service Mesh为例，之前在应用内部的流量是SDK的形式，那么在演进的过程中如何将服务发现和流量等从业务SDK中剥离出来放到Sidecar里面去，进而交给云平台处理，这就是应用架构演进的一个例子。

​​

​​

• 服务注册 & 发现
• 流量路由
• 流量回放
• 发布过程中流量控制

例子2：轻量化容器把日志采集从业务中剥离

以前在做日志采集的时候，需要在各个虚拟机中开启一个日志采集进程，并将采集到的日志传输到日志采集平台，并通过可视化界面进行分析。而今天，在云原生时代，更好的做法是让容器服务从stdout来抓取日志，也可以通过配置的方式去特定日志目录获取日志数据。但是采集这个事情需要搬到Sidecar里面去实现Agent的升级。所以轻量化容器把日志采集从业务中剥离也是一个架构演进的例子。

​​

​​

• 资源隔离
• 独立升级

例子3：业务提供探针，让平台实现生命周期管理

生命周期管理对于应用架构的要求就是原来的应用程序启动之后是健康的还是不健康的，都是应用程序的运维或者研发需要负责和关心的。而在云原生时代，希望将这种协议固定住，通过业务提供探针，来判断应用程序是健康的还是不健康的，这就需要在应用内部通过HTTP协议或者Shell来提供健康信息，这样才能够应用生命周期管理落到平台中去。

​​

​​

• 自动弹性
• 自动腾挪
• 自动重启(自愈)

协议(Contract)=API+Configuration

统筹来看，协议就是API+配置。对于API而言，如果大家使用缓存，那么基本会将开源的协议当做API，这样的协议通常会比闭源的协议更加友好。对于RPC协议，开源的GRPC和DUBBO会优于私有的HSF。此外还有对于基础设施的协议，比如Terraform、Pulumi这些其实是在定义一种开源的配置语言，这些配置语言能够帮助声明所需要的基础设施，比如容器、磁盘、网络、存储等，虽然现在的配置语言种类比较多，但是未来最终会形成1到2种语言，就像是Java的SDK一样，未来使用云资源必然会呈现出一套SDK来，这个SDK必然是根据一套配置代码化语言来构建的。进一步的，GitOps等将发布流程、发布策略也定义成了一套语言，而这在未来将会应用程序与云之间的标准协议。

Docker (& OCI) 是标准的软件交付 API。

• 作为 RPC 协议，开源的 GRPC/DUBBO 优于私有的 HSF。
• 作为缓存协议，开源的 Redis 优于私有的 Tair。
• 微软的 Dapr 尝试基于 sidecar 架构将 API 标准化到 HTTP/GRPC 层，以去 SDK，并支持多语言。
• Terraform，Pulumi 等 IaC 产品，通过配置语言声明基础设施。
• GitOps 进一步的使用代码声明环境、发布流程、发布策略内容。

研发关注点的转变

原来的时候，应用程序所需要关心的东西太多，比如各种SDK、各种运维事件，但是这些东西实际上都可以被抽象成一种模型，并且使用一种新的语言来定义，这也是整个云产业所关心的事情。

​​

​​

之所以一直强调新语言和新协议，是因为定义了新的语言或者协议之后，应用程序所需要关心的就是这些了。对于开发者而言，最关心的就是代码，那么如果能够用代码来描述应用对于基础设施、运维、托管的需求，那么就会对应用程序非常友好。应用程序只需要能够对接这个协议，那么就能够在专有云、公有云、阿里云上同时运行。

​​

​​

总结

未来，云上的资源会越来越丰富，在基础设施之上，云平台提供了更多的PaaS能力，就像是操作系统在提供了进程这些能力之上，还有很多的SDK。但是，这些能力目前在使用上还非常低效和不标准，使用过程也比较麻烦。今天我们在以类似汇编的形式使用云，云原生则在重新定义应用程序与云平台之间的契约，并围绕这个契约来构建更高级的编程语言和工具。这就是云原生时代背景下，应用架构演进非常重要的一个方向。

【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件，转载请联系原作者】

​​戳这里，看该作者更多好文​​