首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

盛图科技 | 什么是多运行时架构?

服务化演进中的问题

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

我们熟知的“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 梳理了分布式应用的各类需求后,将其划分到了四个领域内:

分别是:

生命周期:即应用从开发态到运行态之间进行打包、部署、扩缩容等需求。

网络:分布式系统中各应用之间的服务发现、容错、灵活的发布模式、跟踪和遥测等需求。

状态:我们期望服务是无状态的,但业务本身一定需要有状态,因此包含对缓存、编排调度、幂等、事务等需求。

绑定:与外部服务之间进行集成可能面临的交互适配、协议转换等需求。

Bilgin Ibryam 认为,应用之间对分布式能力的需求,无外乎这四大类。且在 Kubernetes 成为云原生场景下运行时的事实标准后,对生命周期这部分的需求已经基本被覆盖到了。

因此实际上我们更关注的是如何归一化其他三种需求。

与单机应用的类比

单机应用一般大都是以用户态进程的形式运行在操作系统上。显然,与微服务类似,单机应用的核心关注点也是业务逻辑,与业务关系不大的支撑能力,都要依赖操作系统来完成。

因此上述由 Bilgin 归纳的分布式应用四大类需求,其实我们很容易就可以和单机应用进行合理地类比:

从上述类比来看我们发现,单单是 Kubernetes 可能还不足以称为是 “云原生操作系统”,除非有一种解决方案,能在分布式环境下,把其他几项支撑能力也进行归一化整合,才能理直气壮的冠此大名。

Service Mesh 的成功

Service Mesh 在近几年的高速发展,让我们认识到网络相关的需求是如何被归一化并与业务本身解耦的:

通过流量控制能力实现多变的发布模式以及对服务韧性的灵活配置,通过安全能力实现的开箱即用的 mTLS 双向认证来构建零信任网络,通过可观察性能力实现的网络层 Metrics,Logging 和 Tracing 的无侵入式采集。

而上述服务治理能力,全部被代理到 Sidecar 进程中完成。这就实现了 codebase level 的解耦,网络相关的分布式能力完全抛弃 SDK。

伴随着 Service Mesh 的成功,我们不禁会想到,是否可以将另外的两种需求——状态和绑定 ——也进行 Mesh 化改造呢?

分布式能力 Mesh 化

基于对 Service Mesh 的拓展,我们大可以将其他的能力也进行 Mesh 化,每一类能力都以 Sidecar 的形式部署和运作:

在业界也有不少从某些能力角度切入的方案:

我们可以发现,各类方案都有自己的一套对某些能力需求的 Mesh 化方案,合理地选择它们,的确满足了分布式能力 Mesh 化的要求,但却引入了新的问题:

复杂度从业务服务下沉到了 Mesh 层:多种 Mesh 化方案之间缺乏一致性,导致选型和运维的成本很高

多个 Sidecar 进程会带来不小的资源开销,很多解决方案还需要搭配控制面进程,资源消耗难以忽视

对业务复杂度上升的归一化,现在变成了对 Mesh 复杂度上升的归一化。

以上为本次所有分享内容

  • 发表于:
  • 原文链接https://page.om.qq.com/page/OHGyxBH03ViPKdjhOiRWmqAw0
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券