我对云原生软件架构的观察与思考

做者 | 易立  阿里云资深技术专家

本系列文章：

• 第一篇 - 云原生基础设施 
• 第二篇 - 云原生软件架构
• 第三篇 - 云原生应用交付与运维体系

前言

在《解读云原生基础设施》一文中，咱们谈到了云原生计算包含三个维度的内容：云原生基础设施，软件架构和交付与运维体系，本文将聚焦于软件架构层面。

“Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. ”  - 维基百科

我的理解，软件架构主要目标是解决下列挑战：

• 控制复杂性：因为业务的复杂性，须要咱们用更好的手段帮助研发组织克服认知障碍，更好的分工协做。分而治之，关注点分离等手段皆是如此。

• 应对不肯定性：业务在快速发展，需求在不断变化。即便再完美的软件架构，然而随着时间的推移，团队的变化，软件架构的调整不可避免。读《设计模式》，《微服务设计》等书字里行间写的都是“解耦”两字，让咱们关注架构中肯定性和不肯定性的分离，提高架构的稳定性和应变能力。

• 管理系统性风险：管理系统中的肯定性以及不肯定性风险，规避已知陷阱，对未知的风险作好准备。

云原生应用架构的目标是构建松耦合、具有弹性、韧性的分布式应用软件架构，能够更好地应对业务需求的变化和发展，保障系统稳定性，本文将分享一下在这个领域的观察和思考。

缘起 - 12 要素应用

2012 年，Heroku 创始人 Adam Wiggins 发布十二要素应用宣言。它为构建一个优雅的互联网应用，定义了须要遵循的一些基本原则和方法论，也普遍影响了众多的微服务应用架构。十二要素重点关注：应用程序的健康成长，开发者之间的有效的协做，以及避免软件架构腐化的影响。其内容在今天也值得每一个同窗认真体会。

图片来源：https://12factor.net/zh_cn/

12 要素应用为咱们提供了很好的架构指导，帮助咱们：

• 构建水平伸缩的弹性应用架构，更好支撑互联网规模应用。

• 提高研发流程的标准化、自动化水平，提高研发效率。

• 减小开发环境和生产环境的差别，并使用持续交付实施敏捷开发。

• 提高应用的可移植性，适合云化部署，下降资源成本和管理复杂性。

松耦合架构设计

微服务的核心理念是，系统中的各个服务可被独立开发、独立部署，独立升级，各个服务之间是松耦合的。云原生应用架构理念是进一步强调架构的松耦合，下降服务之间相互依赖的程度。

1. API 优先的应用架构设计

在面向对象的软件架构中，最重要的是定义对象以及对象的接口契约。SOLID 原则是最被人广为熟知的设计原则：

• Single responsibility principle - 单一职责原则

• Open/closed principle - 开放/封闭原则

• Liskov substitution principle - 里氏替换原则

• Interface segregation principle - 接口隔离原则

• Dependency inversion principle - 依赖翻转原则

将以上五个原则的英文首字母拼在一块儿就是 SOLID 原则，这也是帮助咱们构建高内聚，低耦合、具有柔性的应用架构。在分布式微服务应用架构中，API 优先是契约优先（Contract First）的天然拓展。

API 应该是被优先设计的：咱们知道用户需求是复杂多变的，好比从桌面到移动端，应用的展示方式和操做流程都有可能不一样；然而业务逻辑的概念模型和服务交互是相对稳定的。相对而言，API 的接口是更加稳定的，而具体的实现是能够迭代实现和持续变化的。定义良好的 API 能够更好保障应用系统的质量。

API 应该是声明式，可描述/自描述的：经过规范化的描述，API 易于沟通、易于理解、易于验证，简化开发协同。支持服务的消费者和提供者并行开发，加速开发周期。支持不一样的技术栈的实现，好比对于同一个 API 接口，其服务实现采用 Java 。前端应用可使用 JavaScript ，而服务器端应用可使用 Golang 进行服务调用等等。这样可让开发组织能够根据本身的技能栈和系统要求灵活选择合适的技术。

API 应该具有 SLA：API 做为服务间的集成界面，与系统的稳定性息息相关。SLA 应该做为 API 设计的一部分，而不是部署后再考虑。在分布式系统中，稳定性风险无处不在，经过 API 优先的设计模式，咱们对独立的服务进行稳定性架构设计、容量规划；咱们还能够对独立的 API 进行故障注入、稳定性演练，来消除系统性的稳定性风险。

在 API 领域，最重要的趋势是标准化技术的崛起。gRPC 是 Google 开源的的高性能、通用的、平台无关的 RPC 框架。它采用分层设计，其数据交换格式基于 Protobuf  (Protocol Buffers) 协议开发，具有优秀的序列化/反序列化效率，也支持众多开发语言。在传输层协议， gRPC 选择了 HTTP/2，相较于 HTTP/1.1，其传输效率有了很大提高。此外 HTTP/2 做为一个成熟的开放标准，具有丰富的安全、流控等能力，同时拥有良好的互操做性。gRPC 不只能够用于 Server 端服务调用，也能够支持浏览器、移动 App 和 IoT 设备与后端服务的交互。gRPC 在功能上已经具有完整的 RPC 能力，也提供了扩展机制来支持新的功能。

在 Cloud Native 的潮流下，跨平台、跨厂商、跨环境的系统间互操做性的需求必然会催生基于开放标准的 RPC 技术，而 gRPC 顺应了历史趋势，获得了愈来愈普遍地应用。在微服务领域， Dubbo 3.0 宣布了对 gRPC 协议的支持，将来咱们也会看到更多的微服务架构基于 gRPC 协议开发，并提供良好的多语言支持。此外，在数据服务领域，gPRC 也成为一个优秀的选择，你们能够参考 Alluxio 的文章。

此外在 API 领域 Swagger (OpenAPI 规范)，GraphQL 都是你们值得关注的开放标准。你们根据本身的业务诉求灵活选用，本文再也不赘述。

2. Event Driven Architecture 的崛起

谈事件驱动架构 （EDA - Event Driven Architecture），咱们首先来解释一下什么是事件。事件是指对已经发生的事情、状态变化等的记录。它们是不可变的（没法更改或删除），而且按其建立顺序排序。相关各方能够经过订阅已发布的事件来获取有关这些状态变化的通知，而后使用所选择的业务逻辑根据这些信息采起操做。

事件驱动架构是一种构建松耦合的微服务系统的架构方式，微服务之间经过异步事件通讯来进行交互。

事件驱动架构实现了事件的生产者和消费者的完全解耦。生产者无需关注事件如何被消费，同时消费者无需关注事件的生产方式；咱们能够动态添加更多消费者而不影响生产者，能够增长消息中间件对事件进行动态路由和转换。这还意味着事件的生产者和消费者没有时序上的依赖，即便因为应用宕机没法及时处理消息，在从新恢复后，程序能够继续从消息队列中获取这些事件继续执行。这样的松耦合架构，为软件架构提供更高的敏捷性、灵活性和健壮性。

事件驱动架构的另外一个重要优势是提高了系统的可伸缩性。事件生产者在等待事件消费时不会被阻塞，而且能够采用 Pub/Sub 方式，让多个消费者并行处理事件。

事件驱动架构还能够完美地与 Function as a Service (FaaS) 相整合。事件触发函数执行业务逻辑，在函数中也能够编写集成多个服务的“胶水代码”，简单、高效地构建事件驱动架构的应用。

可是 EDA 架构依然存在不少挑战：

• 分布式的松耦合架构大大增长了应用基础设施的复杂性。基于云的部署交付方式和云服务（消息队列、函数计算服务等）可使得该架构的稳定性，性能和成本效益进一步提升。

• 与传统同步处理方式相比，异步事件处理存在与事件排序、幂等性、回调和异常处理相关的要求，总体设计难度更大一些。

• 在大多数状况下，因为缺少跨多个系统的分布式事务支持，维护数据一致性是很是具备挑战性的。开发者可能须要权衡可用性和一致性之间的关系。好比经过 Event Sourcing（事件溯源）实现最终一致性，查看详情。

• 互操做性。在现实世界中，事件无处不在，然而不一样生产者对事件的描述却不尽相同。开发者但愿不管事件是从哪里发出，都可以以一致的方式构建事件驱动的应用程序。CloudEvents 是一种以通用、一致的方式描述事件数据的规范，由 CNCF Severless 工做组提出，提高了事件驱动应用的可移植性。目前，阿里云 EventBridge、Azure Event Grid 等事件处理中间件，以及 Knative Eventing，阿里云函数计算等 FaaS 技术已经提供了对 CloudEnvents 的支持。

因为 EDA 自身架构的优势，在互联网应用架构，业务数据化和智能化、IoT 等场景有很是广阔的前景。关于 EDA 的架构讨论，不在此继续展开。

面向交付的应用架构

在云原生软件架构中，咱们在设计阶段不仅是关注软件如何被构建，也须要以终为始。关注如何合理设计和实现软件，才能够被更好地交付和运维。

1. 应用和运行环境解耦

在 12 要素应用中，应用和运行环境解耦就已经被提出。而 Docker 容器的出现则进一步增强了这个理念。容器是一种轻量化的应用虚拟化技术，容器之间共享操做系统内核，支持秒级启动，Docker 容器镜像是一个自包含的应用打包格式，将应用和其依赖（如系统库、配置文件）等打包在一块儿，在不一样环境保持部署一致性。

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

Kubernetes 做为容器的分布式编排调度系统，进一步提高了容器应用的可移植性。K8s 经过一系列抽象如 Loadbalance Service / Ingress / CNI / CSI，帮助业务应用能够屏蔽底层基础设施的实现差别，灵活迁移。经过这样的能力，咱们能够实现工做负载在数据中心、边缘计算和云环境的动态迁移。

在应用架构中，咱们须要避免将静态环境信息，好比 IP / mac 地址等与应用逻辑耦合。在微服务架构中，能够利用 Zookeeper/Nacos 等实现服务的注册发现；在 Kubernetes 中，咱们能够经过 Service / Service Mesh 减小对服务端点 IP 的依赖。此外，对应用状态的持久化也尽量经过分布式存储或者云服务等实现，这样能够大大提高应用架构可伸缩性和自愈能力。

2. 自包含可观测性

分布式系统所面对的最大挑战之一就是可观测性。可观测性能够帮助咱们解系统当前的状态，并做为应用自愈，弹性伸缩和智能运维的基础。

在云原生架构中，微服务应用是自包含的，应该本身具有可观测性，能够方便地被系统进行管理和探查。首先是，应用应该具有自身健康状态的可视化能力。

在 Kubernetes 中，业务应用能够提供一个 liveness 探针，能够经过 TCP、HTTP 或者命令行方式对应用就绪进行检测。对于 HTTP 类型探针，Kubernetes 会定时访问该地址，若是该地址的返回码不在 200 到 400 之间，则认为该容器不健康，会杀死该容器重建新的容器。

对于启动缓慢的应用，为了不在应用启动完成以前将流量导入。Kubernetes 支持业务容器提供一个 readiness 探针，对于 HTTP 类型探针，Kubernetes 会定时访问该地址，若是该地址的返回码不在 200 到 400 之间，则认为该容器没法对外提供服务，不会把请求调度到该容器。

同时在新的微服务架构中已经内置了可观测探针，好比在 SpringBoot 的 2.3 发布了两个新的 actuator 地址：/actuator/health/liveness 和 /actuator/health/readiness ，前者用做存活探针，后者用做就绪探针。业务应用能够经过Spring系统事件机制来读取、订阅、修改 Liveness State 和 Readiness State ，这样可让 Kubernetes 平台能够作更加准确的自愈和流量管理。

参考更多信息

此外，应用可观测性包含三个关键能力：日志、监控与链路追踪。

• Logging – 日志（事件流）：用于记录离散的事件，包含程序执行到某一点或某一阶段的详细信息。不但包括应用、 OS 执行过程的日志，还应包含运维过程当中的日志信息，如操做审计等。

• Metrics – 监控指标：一般是固定类型的时序数据，包括 Counter、Gauge、Histogram 等，是可聚合的数据。系统的监控能力是多层次的，既包含计算、存储，网络等基础设施服务层次的监控指标，也应该包含业务应用的性能监控和业务指标监控。

• Tracing – 链路追踪 - 记录单个请求的完整处理流程，能够为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、应用依赖分析等能力，可以帮助开发者快速分析和诊断分布式应用架构下的性能和稳定性瓶颈。

在分布式系统中，稳定性、性能、安全等问题可能发生在任何地方，须要全链路可观测性能力保障，须要覆盖基础设施层、 PaaS 层，应用等不一样层次，而且能够在不一样系统间实现可观测性数据的关联、聚合、查询和分析。

软件架构的可观测领域具有广阔的前景，也涌现出众多的技术创新。2020 年 9 月 CNCF 发布了云原生可观测性的技术雷达。

其中，Prometheus 已成为企业首选的云原生应用程序的开源监控工具之一。Prometheus 培养了一个活跃的开发者和用户社区。在 Spring Boot 应用架构中，经过引入 micrometer-registry-prometheus 的依赖，既可让应用的监控指标被 Prometheus 服务所采集。更多信息能够参考文档。

在分布式追踪领域，OpenTracing 是 CNCF 下属的开源项目。它是一个技术中立的分布式追踪的规范，提供统一接口，可方便开发者在本身的服务中集成一种或多种分布式追踪的实现。Jaeger 是Uber 开源的分布式追踪系统，兼容 OpenTracing 标准，已经成功在 CNCF 毕业。此外OpenTelemetry是一个潜在的标准，它试图在融合 OpenTracing 和 OpenCensus 这两个项目，造成统一的技术标准。

对于不少遗留的业务系统，现有应用并不具有完备的可观测性能力。新兴的服务网格技术能够成为提高系统可观测性的新方式。经过数据平面代理的请求拦截，网格能够获取服务间调用的性能指标。此外，在服务调用方应用中只需加入须要转发的消息 header，在服务网格上便可得到完整的链路追踪信息。这样的方式极大简化了可观测性能力的建设，可让现有的应用低成本融入云原生可观测性体系中。

阿里云提供了丰富的可观测性能力。XTrace 分布式追踪提供了对  OpenTracing/OpenTelemetry 标准的支持。ARMS 提供了托管 Prometheus 服务，可让开发者无需关注系统的高可用和容量挑战。可观测性是 AIOps 的基础，在将来企业IT应用架构中将扮演更加剧要的角色。

3. 面向失败的设计 - Design For Failure

根据”墨菲定律“ — “Anything that can go wrong will go wrong”。分布式系统可能受到硬件、软件等因素、或者内部和外部的人为破坏。云计算比自建数据中心提供了更高 SLA、更加安全的基础设施，可是咱们在应用架构设计时依然要时刻关注系统的可用性，关注潜在的”黑天鹅“风险。

系统化的稳定性须要在软件架构，运维体系和组织保障等方面全局考虑。在架构层面，阿里经济体有着很是丰富的经验，好比防护式设计、限流、降级、故障隔离等，并且也向社区贡献了 Sentinel、ChaosBlade 等优秀的开源项目。

本文，咱们将会谈谈几个在云原生时代能够进一步思考的地方。我的的总结是 “Failures can and will happen, anytime, anywhere. Fail fast, fail small, fail often and recover quickly.”

首先是“Failures can and will happen”，咱们须要提高服务器的可替换性。在业界有一个很是流行的隐喻：“Pets vs. Cattle”，宠物和家畜。咱们面对一个架构选择：对于应用所在服务器咱们是须要精心伺候，防止系统宕机，出现问题后不惜一切代价抢救 （Pet）；仍是倾向于出现问题后，能够经过简单抛弃和替代进行恢复（Cattle）。云原生架构的建议是：容许失败发生，确保每一个服务器，每一个组件都可以在不影响系统的状况下发生故障而且具有自愈和可替代能力。这个设计原则的基础是应用配置和持久化状态与具体运行环境的解耦。Kubernetes 的自动化运维体系让服务器的可替换性变得更加简单。

**此外是 “Fail fast, fail small, recover quickly” **。当即失效（Fail fast）是一个很是反直觉的设计原则，它背后的哲学是既然故障没法避免，问题越及早暴露、应用越容易恢复，进入生产环境的问题就越少。采用了 Fail-fast 策略之后，咱们的关注点将从如何穷尽系统中的问题转移到如何快速地发现和优雅处理失败。只要跑的够快，故障就追不上我。:-) 在研发流程上，经过集成测试尽量在早期发现应用存在的问题。在应用级别，能够采用断路器（Circuit Breaker）等模式防止一个依赖服务的局部故障引发全局问题；此外经过 K8s 的健康监测、可观测性能够实现对应用故障的探知，经过服务网格的断路器功能，能够将故障发现、流量切换和快速自愈这些能力外置到应用实现以外，由系统能力保障。Fail small 的本质在于控制故障的影响范围——爆炸半径。这个原则在架构设计和服务设计上都须要咱们持续关注。

最后是“Fail often”，混沌工程是一种在生产环境周期性引入故障变量，验证系统对非预期故障防护的有效性的思想。Netflix 引入混沌工程概念解决微服务架构的稳定性挑战，也获得了众多互联网公司的普遍应用。在云原生时代又有了更多新的手段，Kubernetes 让咱们能够轻松注入故障，杀死 pod，模拟应用失效和自愈过程。利用服务网格咱们能够对服务间流量进行更加复杂的故障注入，好比 Istio 能够模拟缓慢响应、服务调用失败等故障场景，帮助咱们验证服务间的耦合性，提高系统的稳定性。

更多关于交付和运维架构的更多稳定性思考，咱们会在下一篇文章中和你们分享。

应用基础设施能力下沉

云原生软件架构的重要目标让开发者关注业务逻辑，让平台去承载系统复杂性。云原生计算从新定义了应用与应用基础设施的边界，进一步提高了开发效率，下降了分布式应用开发的复杂性。

1. 服务治理能力与业务逻辑解耦

在微服务时代，以 Spring Cloud 与 Apache Dubbo 为表明的应用框架取得了巨大的成功，它们经过代码库方式提供了服务通讯、服务发现和服务治理能力（流量转移、熔断、限流、全链路追踪等）。这些代码库被构建在应用程序自己中，随着应用一块儿发布和维护。这样的架构存在一些没法回避的挑战：

• 侵入性：服务治理本质是横向的系统级关注，是与业务逻辑正交的。但在现有微服务框架中，其实现方式和生命周期与业务逻辑耦合在一块儿的。服务治理能力的加强须要微服务框架的升级，会致使整个系统全部组件的从新构建和部署，致使升级和维护成本提高。

• 实现绑定：因为微服务框架代码库一般由特定语言实现，难以支持多语言（polyglot）实现。随着业务的快速发展，异构系统之间的集成逐渐成为挑战。

图片出处

为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构，它将业务逻辑与服务治理能力解耦。下沉到基础设施，在服务的消费者和提供者两侧以独立进程的方式部署。这样既达到了去中心化的目的，保障了系统的可伸缩性；也实现了服务治理和业务逻辑的解耦，两者能够独立演进不相互干扰，提高了总体架构演进的灵活性；同时服务网格架构减小了对业务逻辑的侵入性，下降了多语言支持的复杂性。

Google、IBM、Lyft 主导发起的 Istio 项目就是服务网格架构的一个典型的实现，也成为了新的现象级“网红”项目。

上图是 Istio 的架构，逻辑上分为数据平面和控制平面。数据平面负责服务之间的数据通讯。应用和以 sidecar 方式部署的智能代理 Envoy 成对出现。其中由 Envoy 负责截获和转发应用网络流量，收集遥测数据而且执行服务治理策略。在最新的架构中， istiod 做为控制平面中负责配置的管理、下发、证书管理等。Istio 提供了一系列通用服务治理能力，好比：服务发现和负载均衡、渐进式交付(灰度发布)、混沌注入与分析、全链路追踪和零信任网络安全等。能够供上层业务系统将其编排到本身的 IT 架构和发布系统之中。

服务网格在架构上实现了数据平面与控制平面的分离，这是一个很是优雅的架构选择。企业客户对数据平面有着多样化的需求，好比支持等多样化协议（如 Dubbo），须要定制化的安全策略和可观测性接入等。服务控制平面的能力也是快速变化的，好比从基础的服务治理到可观测性，再到安全体系、稳定性保障等等。可是控制平面与数据平面之间的 API 是相对稳定的。

CNCF 创建了通用数据平面 API 工做组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API。通用数据平面 API（UDPA）的目标是：为 L4/L7 数据平面配置提供实现无关的标准化 API，相似于 OpenFlow 在 SDN 中对 L2/L3/L4 所扮演的角色。UDPA API 涵盖服务发现、负载均衡、路由发现、监听器配置、安全发现、负载报告、运行情况检查委托等。

UDPA API 基于现有的 Envoy xDS API 逐步演进，目前除支持 Envoy 以外，将支持客户端负载均衡实现 (好比 gRPC-LB)，更多数据平面代理，硬件负载均衡和移动客户端等等。

咱们知道 Service Mesh 不是银弹，其架构选择是经过增长一个服务代理来换取架构的灵活性和系统的可演化性，可是也增长了部署复杂性（sidecar 管理）和性能损失（增长两跳）。UDPA 的标准化和发展将给服务网格架构带来的新一次变化。

gRPC 在最新版本中提供了对 UDPA 负载均衡的初步支持。

“proxyless” 服务网格概念浮出水面，一个概念示意图以下：

gRPC 应用直接从控制平面获取服务治理的策略， gPRC 应用之间直接通讯无需额外代理。这个能够看到开放的服务网格技术的雄心，进化成为一套跨语言的服务治理框架，能够兼顾标准化、灵活性与运行效率。Google 的托管服务网格产品已经率先提供了对 “proxyless” gRPC 应用的支持。

2. 新一代分布式应用运行时

对于分布式应用，Bilgin Ibryam 在 Multi-Runtime Microservices Architecture。

文中分析并总结了典型的四大类需求：

• 生命周期（Lifecycle）

• 网络（Networking）

• 状态（State）

• 捆绑（Binding）

熟悉传统企业架构的同窗可能发现，传统的 Java EE (如今更名为 Jakarta EE )应用服务器的目标也是解决相似的问题。一个典型 Java EE 应用服务器的架构以下图所示：应用生命周期由各类应用容器管理，如 Web 容器、EJB 容器等。应用的安全管理、事务管理、链接池管理都是交给应用服务器完成。应用能够经过 JDBC 、JMS 等标准 API 接口访问外部的企业中间件，如数据库、消息队列等。

不一样的外部中间件经过 Java Connector Architecture 规范实现与应用服务器的插拔。应用经过 JNDI 在运行时实现与具体资源的动态绑定。Java EE 将系统的 cross-cutting concern下沉到应用服务器来解决，让开发者只关注应用的业务逻辑，开发效率有了较好的提高；同时减轻应用对环境和中间件实现的依赖，好比能够在开发环境中用 ActiveMQ ，在生产环境中使用 IBM MQ 替换，而无需修改应用逻辑。

在架构上，Java EE 是一个大的单体应用平台，拖慢了自身架构迭代的速度，跟不上时代的变化。因为 Java EE 过于复杂、沉重，在微服务兴起以后已经被大多数开发者所遗忘。

在云原生的时代，咱们到底须要什么样的应用运行时？

Dapr 是微软给出的答案。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 进行交互、生命周期解耦，便于升级和迭代。

1. Serverless 的机遇与挑战

在上一篇文章中，咱们已经对 Serverless 应用基础设施，如函数即服务（FaaS）， Serverless 容器作了介绍。本文谈谈函数即服务 FaaS 应用在架构方面的一些思考。

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

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

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

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

Serverless 具有不少优点, 好比：下降运维成本，提高系统安全性，提高研发效率，加速业务交付等等。然而 Serverless 还有一些不能回避的问题须要咱们来作判断：

成本管理：对于“Pay as you go”的收费模式的一个弱点是：没法准确预测具体会产生多少费用，这于许多组织预算管理的方式不一样。

厂商锁定：即便 Serverless 应用基于开放的语言和框架，可是多数Serverless应用还依赖一些非标准化的 BaaS（Backend as a Service）服务，如对象储存、Key- Value 数据库、认证、日志、和监控等。

调试和监控：与传统应用开发相比， Serverless 应用的调试与监控工具能力还不完善。良好的可观测性是将 Serverless 计算的重要助力。

架构复杂性：Serverless 开发者无需关注底层基础设施的复杂性，可是应用架构的复杂性须要格外关注。事件驱动架构和细粒度函数微服务，与传统开发模式很是不一样。你们须要根据业务需求和本身的技术能力，在合适的场景应用，而后逐渐扩大应用范围。

关于典型的 Serverless 应用架构，你们能够参考《What a typical 100% Serverless Architecture looks like in AWS ! 》。

《Cloud Programming Simplified: A Berkeley View on Serverless Computing》也是深刻了解 Serverless 计算的一个好的参考。

应用运行时的敏捷进化

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

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

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

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

正由于此，Golang、Node.js、Python 等语言开发者在持续攀升，有几个值得你们关注的技术：

在 Java 领域，GraalVM 已经逐渐成熟。它是基于 HotSpot 上加强的一个跨语言的全栈虚拟机，支持众多语言的运行平台（包括 Java、Scala、Groovy、Kotlin、JavaScript、Ruby、Python、C、C++ 等）。GraalVM 容许您将程序提早编译为本地可执行文件。

与经典 Java VM 相比，生成的程序具备更快的启动时间和更低的运行时内存开销。Quarkus /Micronaut 等做为云原生定制的新一代 Java 框架，能够实现惊艳的启动时间和资源开销。更多分析能够参考 Java 的云原生进化。

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

平台开发商能够针对具体的操做系统和运行环境提供 WASI 接口不一样的实现，能够在不一样设备和操做系统上运行跨平台的 WebAssembly 应用。这可让应用执行与具体平台环境实现解耦，使得应用“Build Once, Run Anywhere”的理想逐渐造成现实。虽然目前 WebAssembly 已经超越了浏览器的领域，可是其发展还在很是初期，期待社区共同推进。有兴趣的同窗能够看看 WebAssembly 与 Kubernetes 双剑合璧。

趋势总结

云原生软件架构还在快速发展中，涉及的内容也很是普遍。上述内容更可能是我的总结、理解和判断，期待与你们的交流和深刻探讨。

更多参考：

• 《Software Architecture Guide》：https://martinfowler.com/architecture/

• 《7 Missing Factors from 12-Factor Applications》：https://www.ibm.com/cloud/blog/7-missing-factors-from-12-factor-applications

• 《Principles for Microservice Design: Think IDEALS, Rather than SOLID》：https://www.infoq.com/articles/microservices-design-ideals/

• 《Software Architecture and Design InfoQ Trends Report—April 2020》：https://www.infoq.com/articles/architecture-trends-2020/

• 《Choreography vs Orchestration in the land of serverless》：https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/

阿里云容器平台团队求贤若渴！社招技术专家/高级技术专家，base 杭州/北京/深圳。欢迎发简历到：jiaxu.ljx@alibaba-inc.com。

点击连接当即查看容器服务 ACK：https://www.aliyun.com/product/kubernetes

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”