什么是多运行时架构？ _架构

作者 | 张旭海,刘振伟
服务化演进中的问题
自从数年前微服务的概念被提出，到现在基本成了技术架构的标配。微服务的场景下衍生出了对分布式能力的大量需求：各服务之间需要相互协作和通信，以及共享状态等等，因此就有了各种中间件来为业务服务提供这种分布式能力。

文章插图
图片
我们熟知的“Spring Cloud 全家桶”正是凭借着对各种中间件优秀的集成与抽象能力，成为了当时炙手可热的项目。
然而随着业务的快速发展，组织规模的不断扩大，微服务越来越多，系统规模越来越大则是服务化体系架构演进的必然。这就带来了两方面复杂度的上升：
1.服务治理与接入的复杂度服务治理代表了系统中服务资源的地图及其获取途径，例如通过注册发现服务提供图谱能力，路由、网关、负载均衡服务提供获取途径。
服务接入则代表了如何使用系统中的服务能力，例如通过中间件提供的API 协议或是封装的 SDK 来接入该中间件。各种业务服务越多、中间件越复杂，整个系统服务治理与接入的复杂度就会急剧上升。
2.团队协作的复杂度该复杂度主要体现在团队的认知负载上，复杂的依赖、沟通、协作将明显拖慢交付进度。正如康威定律所述的，由于服务复杂度的上升，团队之间的交互成本也随之上升。
如下是复杂度上升问题的一个显而易见的例子。

文章插图
图片
当系统中的中间件都通过 SDK 作为其外化能力的控制方式，来封装协议、数据结构与操作方法。随着中间件数量和种类不断增多，大量孤立的 SDK 被绑定在业务服务上，导致两方面问题：

版本升级困难：SDK 与业务服务的强依赖性导致想要升级 SDK 版本变得异常复杂与缓慢
业务服务难以异构：SDK 所支持的语言反向限制了业务服务所能选择的语言，例如 Spring Cloud 几乎没有官方的多语言支持

如何治理这种不断上升的复杂度呢？复杂问题归一化是一种不错的手段。
什么是多运行时架构
多运行时微服务架构（Multi-Runtime Microservice Architecture）也被简称为多运行时架构，是由 Red Hat 的首席架构师 Bilgin Ibryam 在 2020 年初所提出的一种微服务架构形态，它相对完整地从理论和方法的角度阐述了多运行时架构的模型（实际上，在 2019 年末，微软的 Dapr v0.1.0 就已经发布）。
暂时先抛开到底什么是“多运行时”不谈（因为多运行时这个名字个人觉得起得可能不太妥当），先看看多运行时架构都包括了哪些内容。
分布式应用四大类需求
上一节提到，为了治理不断上升的复杂度问题，归一化是手段之一。归一化的第一步就是对问题进行归类。
Bilgin Ibryam 梳理了分布式应用的各类需求后，将其划分到了四个领域内：

文章插图
图片
（来源：Multi-Runtime Microservices Architecture）
分别是：

生命周期：即应用从开发态到运行态之间进行打包、部署、扩缩容等需求。
网络：分布式系统中各应用之间的服务发现、容错、灵活的发布模式、跟踪和遥测等需求。
状态：我们期望服务是无状态的，但业务本身一定需要有状态，因此包含对缓存、编排调度、幂等、事务等需求。
绑定：与外部服务之间进行集成可能面临的交互适配、协议转换等需求。

Bilgin Ibryam 认为，应用之间对分布式能力的需求，无外乎这四大类。且在 Kube.NETes 成为云原生场景下运行时的事实标准后，对生命周期这部分的需求已经基本被覆盖到了。
因此实际上我们更关注的是如何归一化其他三种需求。
与单机应用的类比单机应用一般大都是以用户态进程的形式运行在操作系统上。显然，与微服务类似，单机应用的核心关注点也是业务逻辑，与业务关系不大的支撑能力，都要依赖操作系统来完成。