因此上述由 Bilgin 归纳的分布式应用四大类需求 , 其实我们很容易就可以和单机应用进行合理的类比:
文章插图
从上述类比来看我们发现 , 单单是 Kubernetes 可能还不足以称为是 “云原生操作系统” , 除非有一种解决方案 , 能在分布式环境下 , 把其他几项支撑能力也进行归一化整合 , 才能理直气壮的冠此大名 。」
Service Mesh 的成功
Service Mesh 在近几年的高速发展 , 让我们认识到网络相关的需求是如何被归一化并与业务本身解耦的:
通过流量控制能力实现多变的发布模式以及对服务韧性的灵活配置 , 通过安全能力实现的开箱即用的 mTLS 双向认证来构建零信任网络 , 通过可观察性能力实现的网络层Metrics , Logging 和 Tracing 的无侵入式采集 。
而上述服务治理能力 , 全部被代理到 Sidecar 进程中完成 。这就实现了 codebase level 的解耦 , 网络相关的分布式能力完全抛弃 SDK 。
文章插图
图片
伴随着 Service Mesh 的成功 , 我们不禁会想到 , 是否可以将另外的两种需求——状态和绑定 ——也进行 Mesh 化改造呢?
分布式能力 Mesh 化
基于对 Service Mesh 的拓展 , 我们大可以将其他的能力也进行 Mesh 化 , 每一类能力都以 Sidecar 的形式部署和运作:
文章插图
图片
在业界也有不少从某些能力角度切入的方案:
文章插图
图片
(来源:Multi-Runtime Microservices Architecture)
我们可以发现 , 各类方案都有自己的一套对某些能力需求的 Mesh 化方案 , 合理地选择它们 , 的确满足了分布式能力 Mesh 化的要求 , 但却引入了新的问题:
- 复杂度从业务服务下沉到了 Mesh 层:多种 Mesh 化方案之间缺乏一致性 , 导致选型和运维的成本很高
- 多个 Sidecar 进程会带来不小的资源开销 , 很多解决方案还需要搭配控制面进程 , 资源消耗难以忽视
Multi-Runtime = Micrologic + Mecha
Bilgin Ibryam 在多运行时微服务架构中 , 对前述讨论的各种问题点进行了整合 , 提出了 Micrologic + Mecha 的架构形态:
文章插图
图片
(来源:Multi-Runtime Microservices Architecture)
在 Micrologic 中只包含业务逻辑 , 尽可能的把分布式系统层面的需求剥离出去 , 放到 Mecha 中 。从 Mecha 的命名就可以明白它的功能:
由提供各种分布式能力的 “机甲” 组成的 Sidecar 进程 , 与 “裸奔的” 业务逻辑一起部署 。因为是 Micrologic 进程和 Mecha 进程共同部署的这种多个 “运行时” 的架构 , 所以称之为 “多运行时架构” 。
Mecha 不仅成功地将分布式能力从耦合的业务进程中抽取出来 , 还整合了方案 , 避免了多种方案混合的额外成本 。可以说 Mecha 在本质上提供了一个分布式能力抽象层 。
因此与其叫 “多运行时架构” , 不如叫 “面向能力的架构” 。
微软的尝试:Dapr
Dapr 是微软主导开发并开源的一种 Mecha runtime , 从宏观上看它处在整个架构的中间层:
文章插图
图片
(来源:Dapr)
自上而下分别是业务层、Dapr Runtime层、基础设施层 。Dapr 通过 Http 或 gRPC API 向业务层提供分布式能力抽象 , 通过称为 “Component” 的接口定义 , 实现对具体基础设施的插件式管理 。
Building Blocks
作为一个合格的 Mecha , 最关键的就是如何定义分布式能力抽象层 。如何把各类中间件提供的分布式能力定义清楚是一项挑战 。Dapr 中定义的分布式能力抽象层 , 称为 Building Blocks 。顾名思义 , 就是一系列的 “构建块” , 每一个块定义了一种分布式能力 。
推荐阅读
- 什么样的程序员在35岁后仍然保持竞争力?
- ChatGPT新特性: 能够记住你是谁和你喜欢什么
- 吃完油腻的东西后吃什么 吃完油腻的东西后吃什么水果解油腻
- 电动剃须刀剃须要上泡沫么 电动剃须刀需不需要泡沫还是直接刮
- 做馒头泡打粉什么时候放最好 做馒头泡打粉什么时候放最好吃
- 花卷一次发酵还是两次发酵好 花卷一次发酵还是两次发酵好呢
- 山药坏了是什么样 山药坏了是什么样图片
- a2-70是什么材质 螺丝a2-70是什么材质
- 太空沙是什么材料做的不用沙视频 太空沙是什么材料做的
- 水晶是什么材质 水晶是什么材质做的