江苏龙网

  1. 主页 > 生活百科 > >

什么是多运行时架构？( 四 )

架构


就像今年 Cilium 发布支持 Service Mesh 能力的办法 ， 通过 eBPF 在内核态实现 L3 L4 层能力 ， 而对应的 L7 层能力则交给用户态的 Envoy 处理这种将问题一分为二的思想 ， 也许多运行时架构的未来方案也可能是折中或是多种方式结合的 。例如采用在 Node 上按 Service Account 或 Namespace 运行多实例 ， 或是轻量级 Sidecar 做协议转换＋DaemonSet 做流量管理和网络调用 。
当然 DaemonSet 也有其固有的缺陷 ， 资源被共享从而降低消耗的同时 ， 故障也被共享了 ， 而且故障产生的伤害面也变大了 ， 此外还会导致 DaemonSet 被应用使用的争抢问题 ， 以及应用之间的数据暴露风险 。到底后续将会如何演进 ， 我们拭目以待 。
定义抽象能力的（API）的困境 
分布式能力抽象层 ， 是对分布式场景下需求的抽象性定义 ， 抽象作为一种共识 ， 其要义就在于保留共性而排除个性 。但实际当中会发现 ， 同类型中间件的差异化恰恰体现在了一些高级的、细分的专有特性上 ， 很多业务对中间件选型的原因也在于这些专有特性上 。
这就引出了一个困境：抽象能力所覆盖的需求 ， 其丰富程度与可移植性成反比 。

什么是多运行时架构？

文章插图
图片
就如上图所示 ， 如果抽象能力范围只覆盖到红色的部分 ， 则组件 ABC 的专有特性都无法被引入 ， 而如果抽象能力范围覆盖到绿色 ， 那么就无法迁移到组件C 。
Dapr 的 Building Blocks 中 ， State management 就存在这样的一个例子：
State management 定义了基于事务操作的能力 /v1.0/state/<storename>/transaction ， 支持 State management 能力的 Component 有很多 ， 对于支持事务的中间件如 Redis 就一切正常 ， 但有一些并不支持事务的如 DynamoDB ， 则这种能力就无法使用 。
定义抽象能力的困境 ， 本质上是一种对能力收敛的权衡 ， 这种权衡可能是与具体的业务需要高度相关的 。
关于如何降低专有特性对能力集合可移植性的冲击 ， 敖小剑在他的文章《死生之地不可不察：论API标准化对Dapr的重要性》中提到了四种解决思路：
(1) 在 Mecha 层弥补能力缺失 
如果缺失的能力支持用基础能力来间接实现 ， 就可以在 Mecha 内做处理 。例如对于不支持批量写入的基础设施 ， 在 Dapr 中通过 forloop 连续调用单次写入也能间接地弥补这一能力（虽然无法做到性能一致） 。 然而这样也可能导致 Dapr 越来越臃肿 ， 怎么权衡见仁见智 。
(2) 在 Component 层弥补能力缺失 
Component 作为某种具体基础设施与 Dapr 的适配器 ， 可以将 1 中的方案下沉到 Component 里面 ， 避免 Dapr 本身的臃肿 ， 然而这种办法的缺陷在于每种基础设施只要想弥补缺失的能力 ， 就都要分别在自己的 Component 中实现一遍 。
(3) 直接忽略某些缺失的能力 
例如在 State management 中对多副本强一致性的配置属性 consistency ， 假如实际的存储中间件是单副本架构 ， 那么就可以直接忽略掉该属性 。
(4) 其余的情况 ， 只能在业务侧处理 
就像前文提到的事务能力 ， 对于不支持的基础设施必须要明确报错 ， 否则可能导致业务不正确 。这种情况就只能在业务侧做限制 ， 本质上是侵入了业务层 。
这四种解决思路从权衡与折中的角度 ， 覆盖了绝大多数能力缺失的场景 ， 本质上这些思路属于 “坚守API 能力交集” 的办法 。假如跳出“抽象共识”这一限制 ， 我们是否可以试图构建出一套包含了所有分布式能力的“大全集”呢？显然只是理论可行 ， 但不现实 。
然而 ， 在企业实际的场景下 ， 这个“全集”的规模可能并不一定像我们想象的那么庞大 ， 因此就有可能提供额外的一种思路 ， 即对分布是抽象层进行扩展 ， 将有限规模的“个性”全部包含进去 ， 形成 “并集” 从而规避上述问题 。
什么是多运行时架构？

文章插图
图片
 


推荐阅读


上一篇：什么样的程序员在35岁后仍然保持竞争力？

下一篇：简化Java单元测试数据