penghuima
commented
3 years ago 分布式应用的需求
在文章中 Bilgin Ibryam 首先总结了现代分布式应用的四大需求: 生命周期（Lifecycle）、网络（Networking）、状态（State）、捆绑（Binding）
传统中间件限制
然后列举了传统解决方案如企业服务总线（ESB）及其变体在现代分布式应用四大需求方面的限制
ESB虽然可以提供良好的功能集，但ESB的主要挑战是单体架构以及业务逻辑和平台之间紧密的技术耦合
生命周期（Lifecycle）
在传统的中间件中，通常只有一个受支持的语言运行时（例如 Java），它规定了软件的打包方式、可用的库、需要维护的频率等。业务服务必须使用这些库，使其与平台（平台编写语言与业务服务是一样的）紧密结合。在生产实践中，这导致服务和平台的升级必须要协调，常规服务与平台的发布不能够独立进行
网络（Networking）
尽管传统中间件具有与内部和外部服务交互的高级功能，但它有一些主要缺点，网络功能集中于一种主要语言及其相关技术，更重要的是，网络问题和语义也深深地刻在业务服务中。有一些抽象能力的库来解决网络问题，但是该库的抽象“泄漏”到了服务的编程模型、交换模式、错误处理语义以及库本身中。意味着该库与业务逻辑耦合在一个实现中。
状态（State）
为了进行可靠的服务编排、业务流程管理等，需要对数据库进行集群化和弹性，但主要约束在于与状态交互的库和接口没有完全抽象出来，也没有与服务运行时分离。通常，这些库必须配置有数据库详细信息，并且它们存在于服务中，从而将语义和依赖关系泄漏到应用程序域中。
捆绑（Binding）
使用集成中间件的一个主要原因是能够使用不同的协议、数据格式和消息交换模式连接到其它各种系统。但是，这些连接器必须与应用程序一起使用，这意味着必须将这些依赖与业务逻辑一起进行更新和维护
企业服务总线（ESB）无法满足现代应用快速扩展和维护更改的能力，这也是微服务架构出现及解决的问题
未来架构的趋势
下图展示了传统中间件平台和云原生平台的对比，云原生平台则通过各种外围 Runtime 实现了业务逻辑与平台的解耦分离，不过还没有完全分离，许多分布式原语，例如经典的企业集成模式（EIP）：分离器、聚合器、过滤器、基于内容的路由器；流处理模式：映射、过滤、折叠、联接、合并、滑动窗口；仍然必须包含在业务逻辑运行时中。
因此作者引入了 Multiple Runtime 的概念，下图中，将不同领域的各类创新性云原生项目进行汇总并特意选择了一些代表性项目并将其映射到一组分布式原语上。
- Kubernetes和容器在多语言应用程序的生命周期管理中取得了巨大飞跃，并为未来的创新奠定了基础。
- 服务网格技术通过高级网络功能在对 Kubernetes 进行了改进，并开始涉足到应用程序。
- 虽然 Knative 通过快速扩展主要专注于 serverless 工作负载，但它也满足了服务编排和事件驱动的绑定需求。
- Dapr 以 Kubernetes、Knative 和 Service Mesh 的思想为基础，并深入应用程序运行时以解决有状态的工作负载、绑定和集成需求，充当现代的分布式中间件。
可以看出来在未来架构中，就是将分布式能力进行封装下沉作为运行时来简化分布式应用开发，开源项目 Dapr 的理念也是如此。
多运行时微服务
多个运行时，不是因为有多个微服务，而是因为每个微服务由多个运行时组成：一个用于自定义微业务逻辑的运行时（Micrologic runtime），以及一个用于分布式原语的现成的可配置运行时(Mecha runtime)。
下图展示了多运行时（进程外）微服务架构
其中 Mecha runctime就好比《阿凡达》电影中的机甲套装，它们为类人驾驶员赋予超能力，穿上套装就能获得力量以及破坏性武器。
这是一个类似于客户端--服务器架构的两组件模型，其中每个组件都是独立的运行时。它与纯粹的客户端--服务器架构的不同之处在于，这两个组件都位于同一主机上，彼此之间有可靠的网络连接。这两个组件的重要性相当，它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为 Micrologic，在剥离所有分布式系统问题后，它只拥有非常少的业务逻辑。另一个随附的组件是Mecha，它提供了我们在本文中一直讨论的所有分布式系统功能（生命周期除外，它是一个平台功能）。
Micrologic和Mecha可能是一对一的部署（称为sidecar模型），也可以是几个Micrologic运行时共享一个Mecha。第一种模型最适用于Kubernetes等环境，而第二种模型则适用于边缘部署。
这种架构的主要好处是什么？
Mecha的好处和未来
好处是业务逻辑和越来越多分布式系统问题之间的松耦合。软件系统的这两部分具有完全不同的动态特征。业务逻辑始终是内部编写的、唯一自定义代码。它经常更改，取决于你的组织优先级和执行能力。另一方面，分布式原语则负责解决本文中列出的众所周知的问题。这些由软件供应商开发，并作为库、容器或服务使用。这些代码的修改取决于供应商的优先级、发布周期、安全补丁、开放源代码管理规则等。这两个组之间几乎不可见，也无法相互控制。
微服务通过限界上下文实现不同业务领域之间的解耦，每个微服务都可以独立发展。但是微服务架构无法解决业务逻辑与中间件关注（concern）耦合带来的难题。对于某些依赖于集成用例的微服务，这可能不算一个大问题。但是，如果你的领域涉及复杂的集成（情况越来越普遍），那么遵循微服务原则也难以让你摆脱与中间件耦合。即使中间件只是你微服务中的依赖库，当你开始迁移和更改这些库时，这种耦合也将会变得明显。另外随着你需要越来越多的分布原语，你与集成平台的耦合也会越多。通过预定义的API（而不是库），将中间件作为独立运行时/进程来使用，有助于降低耦合，并实现每个组件的独立演化。
这是供应商发行和维护复杂中间件更好的一种方法。只要与中间件的交互是通过开放API和标准的进程间通信进行，软件供应商就可以按照自己的节奏自由发布补丁和升级。消费者也可以自由使用他们喜欢的开发语言、库、运行时、部署方法和过程。
与中间件的交互采用 预定义的API（而不是库），实现了解耦、
Bilgin Ibryam 博客原文 https://www.infoq.com/articles/multi-runtime-microservice-architecture/