作者 | 易立 阿里云资深技术专家
本系列文章：
- 第一篇 – 云原生基础设施
- 第二篇 – 云原生软件架构
- 第三篇 – 云原生利用交付与运维体系
前言
在《解读云原生基础设施》一文中，咱们谈到了云原生计算蕴含三个维度的内容：云原生基础设施，软件架构和交付与运维体系，本文将聚焦于软件架构层面。
“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 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”