云原生2.0应用架构的发展趋势思考

Posted 2021-04-03 TCTP

CNCF对云原生的定义

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

容器、服务网格、微服务很好理解，这里不做过多解释。

不可变基础设施是由Chad Fowler于2013 年提出的构想：在这种模式中，任何基础设施的实例（包括服务器、容器等各种软硬件）一旦创建之后便成为一种只读状态，不可对其进行任何更改。如果需要修改或升级某些实例，就是创建一批新的实例进行替换。这种模式的可以减少了配置管理工作的负担，保障系统配置变更和升级可以可靠地重复执行，避免令人头疼的配置漂移问题；易于解决部署环境间的差异，让持续集成与持续部署过程变得更流畅；支持更好的版本管理，在部署出错时可进行快速回滚。

所谓“声明式API”，就是当用户向 Kubernetes 提交了一个 API 对象（如POD、NODE）的描述之后，Kubernetes 会负责为你保证整个集群里各项资源的状态，都与你的 API 对象描述的需求相一致。更重要的是，这个保证是一项“无条件的”、“没有期限”的承诺：对于每个保存在etcd 里的 API 对象，Kubernetes 都通过启动一种叫做“控制器模式”（Controller Pattern）的无限循环，不断检查，然后调谐，最后确保整个集群的状态与这个 API 对象的描述一致。

总结概括起来说，主要围绕三个方面：

基础设施：可编程的、动态的、弹性基础设施，支持公共云、专有云、边缘计算等不同环境。

应用架构：分布式应用架构，具备松耦合、可弹性扩展、高容错性等特点。

应用生命周期管理：新的应用开发、交付方式，基于自动化、可观测、可管理的软件交付流程，加速创新效率的同时保障系统稳定性。

云原生基础设施

我们可以看到这几类基础设施，计算单元的粒度越来越细，也越来越多体现的云原生的特质：

• 模块化程度越来越高 - 自包含的应用打包方式，应用与底层物理基础设施解耦。

• 自动化运维程度越来越高 - 自动化的资源调度和弹性伸缩能力，用户将关注点逐渐聚焦到应用自身。

• 弹性效率越来越高 - VM 可以实现分钟级扩容；容器可以实现秒级扩容；函数可以做到毫秒级扩容。

• 故障恢复能力越来越高 - 随着系统自愈性的增强，大大简化了应用架构容错的复杂性。

• IaC（Infrastructure as Code）基础设施即代码 -  基础设施即代码，这个在2014年就提出来了，这个概念不单单是自动化，作为最佳实践，基础设施及代码授权所有准备计算资源所需要做的工作都可以通过代码来完成。

  
  

云原生应用

分布式应用架构，具备松耦合、可弹性扩展、高容错性等特点。

新的应用开发、交付方式，基于自动化、可观测、可管理的软件交付流程，提升效率的同时保障系统稳定性。

# 趋势一：标准化平台协议：API+配置

将平台/服务和应用之间的协议进行标准化。如果IaaS层用云的话协议就是机器，就是虚拟机、容器等，对于业务应用而言，看到的就是一个操作系统，这样应用就可以使用操作系统上的各种资源，这样做的好处在于不需要关心物理机以及机器的故障等问题。统筹来看，协议就是API+配置。对于API而言，大家使用开源的协议当做API，这样的协议通常会比闭源的协议更加友好。比如HTTP、GRPC等。此外还有对于基础设施的协议，比如Terraform、Pulumi这些其实是在定义一种开源的配置语言，这些配置语言能够帮助声明所需要的基础设施，比如容器、磁盘、网络、存储等，虽然现在的配置语言种类比较多，但是未来最终会形成1到2种语言，就像是Java的SDK一样，未来使用云资源必然会呈现出一套SDK来，这个SDK必然是根据一套配置代码化语言来构建的。进一步的，GitOps等将发布流程、发布策略也定义成了一套语言，而这在未来将会应用程序与云之间的标准协议。

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

# 趋势二：与业务无关能力进一步解耦至平台

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

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

l 服务注册 & 发现

l 流量路由

l 流量回放

l 发布过程中流量控制

对于分布式应用，Bilgin Ibryam 在Multi-Runtime Microservices Architecture文中分析并总结了典型的四大类需求：

·  生命周期（Lifecycle）

·  网络（Networking）

·  状态（State）

·  捆绑（Binding）

例子2：Dapr 是一个事件驱动的，可移植的，构建微服务应用的运行时环境。支持应用在云或边缘部署，支持语言与框架的多样性。Dapr 利用 Sidecar 的模式，把应用逻辑中的一些横切关注点需求（Cross-cutting）分离和抽象出来，从而达到应用与运行环境的解耦以及对外部依赖（包括服务之间）的解耦。

Dapr 的功能和定位如上图所示：

• 最底下基础设施是各种云平台或者边缘环境。

• 其上是 Dapr 运行时和“building block” (构件)。Dapr 构件解耦了外部服务和服务的消费者，可以按需加载。构件以统一的 HTTP/gPRC API 为应用层提供服务访问。我们可以将外部服务从 Amazon DyanamoDB 切换为 Azure ComosDB，上层应用无需修改任何代码。Dapr 运行时作为一个独立的 sidecar 进程，独立于应用逻辑。

• 应用通过轻量化的 SDK 来简化对构件 API 的调用，基于 gRPC/HTTP 开放协议可以轻松支持多语言。

尽管 Dapr 和 Service Mesh 在架构上有些类似，服务治理功能有所重叠，但两者在本质上却大有不同。服务网格对应用是透明的基础设施；而 Dapr 为状态管理，服务调用和故障处理，资源绑定，发布/订阅，分布式跟踪等提供抽象，需要应用程序通过 SDK/HTTP/gRPC 显式调用 Dapr 能力，它是面向开发人员的开发框架。

Dapr 还非常年轻，还在快速迭代中，距离被广大开发者和三方厂商所支持还有很长的路要走。但是 Dapr 给我们揭示出一个新的方向：通过关注点分离，让开发者只需关注业务逻辑自身，而分布式架构的系统关注下沉到基础设施中实现；让业务逻辑与外部服务解耦，避免厂商绑定；同时应用和应用运行时是两个独立的进程，通过标准化 API 进行交互、生命周期解耦，便于升级和迭代。

# 趋势三：Serverless 的机遇与挑战

FaaS 的核心思维是：开发者不必关心基础设施运维、容量规划或者扩容缩容，只需为使用的云资源和服务付费既可。这个思考的背后是：让开发者避免投入基础设施的运维，尽可能复用现有的云服务能力，让开发时间重新分配到对用户有更有直接影响和价值的事情上，比如健壮的业务逻辑、能吸引用户的界面及快速响应、可靠的 API 上。

在软件架构层面中， FaaS 将复杂的业务逻辑拆解成一系列细粒度的函数，并通过事件驱动的方式触发调用。函数之间是松耦合的，可以通过如下两种典型的模式进行协同、组合：

Workflow Orchestration 工作流编排

以阿里云 Serverless 工作流为例，可以通过一个声明式的业务流程来编排任务。这种方式简化了开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作，让开发者聚焦于业务逻辑开发。

Event Choreography 事件协调

函数服务之间通过事件交换消息，由事件总线等消息中间件来进行事件的转发，并触发其他函数执行。下面是一个示例应用场景，通过 EventBridge，将订单，用户通知、商家通知、接单、结单等基于函数实现的业务逻辑串联在一起。这种方式更加灵活，系统的健壮性也更好。但是缺点是缺乏显式的建模，开发和维护相对较复杂。

# 趋势四：从以资源为中心到以应用为中心

Open Application Model(OAM)

OAM 的本质是帮助你构建一个“以应用为中心“的 Kubernetes 标准规范和框架，相比较前面的方案，OAM 专注于做这三个层次：

应用组件 Components

第一个叫做应用层抽象，OAM 对用户暴露出自己定义的应用层抽象，第一个抽象叫做Components。Components 实际上是帮助我们定义 Deployment、StatefulSet 这样的Workload 的。暴露给用户，让他去定义这些应用的语义。

应用特征 Traits

第二个叫做应用特征，叫做 Traits。运维侧的概念，比如扩容策略，发布策略，这些策略通过一个叫做 Traits 的 API 暴露给用户。首先 OAM 给你做了一个应用层定义抽象的方式，分别叫做 Components 和 Traits。由于你需要将 Traits 应用特征关联给应用组件 Components，例如Deployment 需要某种扩容策略或者是发布策略，怎么把他们关联在一起呢？

应用配置 Application Configuration

这个就需要第三种配置叫做 Application Configuration 应用配置。最终这些概念和配置都会变成 CRD，如果你的 K8s 里面安装了 OAM 的 Kubernetes Runtime 组件，那么那就能解析你CRD 定义的策略和 Workload，最终去交给 K8s 去执行运行起来。就这么一个组件帮助你更好地去定义抽象应用层，提供了几个标准化的方法。

能力定义对象 Definitions

这些抽象和能力交给 K8s 去处理之后，我这些能力需要的 Controller 插件在哪？有没有Ready？这些版本是不是已经有了，能不能自动去安装。这是第四个能力了：能力定义对象。这是 OAM 提供的最后一个 API，通过这个 API 可以自己去注册 K8s 所有插件，比如Tekton、KEDA、istio 等。

把它注册为组件的一个能力，或者是某一个特征。比如说 Flager，可以把它注册为金丝雀发布的能力，用户只要发现这个发布策略存在，说明这个集群支持 Flager，那么他就可以去使用。这就是一个以应用为中心的一个玩法。以用户侧为出发点，而不是以集群侧为出发点，用户侧通过一个上层的 api，特征和组件来去了解他的系统，去操作他的系统。以上就是 OAM 提供的策略和方法。

总结下来就是 OAM 可以通过标准化的方式帮助平台构建者或者开发者去定义用户侧，应用侧的抽象。第二点是提供了插件化能力注册与管理机制。并且有了这些抽象和机制之后，可以非常方便的构建可扩展的 UI 层。这就是 OAM 最核心的功能和价值。

# 趋势五：应用运行时的敏捷进化

更快、更轻、更敏捷的应用运行时技术是云原生计算的持续追求。

• 体积更小 - 对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度。

• 启动速度更快 - 对于传统单体应用，启动速度与运行效率相比不是一个关键的指标。原因是，这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言，更快的的启动速度就意味着更高的交付效率，和更加快速的回滚，以及更快的故障恢复速度。

• 占用资源更少 - 运行时更低的资源占用，意味着更高的部署密度和更低的计算成本。

正因为此，Golang、Node.js、Python 等语言开发者在持续攀升，有几个值得大家关注的技术：

在 Java 领域，GraalVM已经逐渐成熟。它是基于 HotSpot 上增强的一个跨语言的全栈虚拟机，支持众多语言的运行平台（包括Java、Scala、Groovy、Kotlin、javascript、Ruby、Python、C、C++ 等）。GraalVM 允许您将程序提前编译为本地可执行文件。
与经典 Java VM 相比，生成的程序具有更快的启动时间和更低的运行时内存开销。Quarkus/Micronaut等作为云原生定制的新一代 Java 框架，可以实现惊艳的启动时间和资源开销。

WebAssembly 则是另外一个令人激动的技术。WebAssembly 作为一个面向现代 CPU 体系架构设计的，安全的、可移植、高效率的虚拟机沙箱，可以在任何地方（服务器、浏览器、IoT等等）、任何平台（不同操作系统，不同 CPU 体系架构下）安全运行应用。WebAssembly System Interface（WASI）是来标准化 WebAssembly 应用与系统资源的交互抽象，比如文件系统访问，内存管理，网络连接等，提供类似 POSIX 这样的标准 API 。

总结

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

作者简介

easoncchen(陈广胜)

基础科技产品部/中间件平台室