转载

将业务逻辑和云架构分离的多运行时Muilti-Runtime的微服务架构〜Bilgin Ibryam

微服务原理可以通过有界上下文使不同的业务领域脱钩解耦，每个微服务都可以独立开发，但是微服务架构无法解决将业务逻辑与中间件问题耦合在一起带来的困难。如果您的领域涉及复杂的集成，那么遵循微服务原则无法避免与中间件耦合。即使中间件作为包含在微服务中的库，当您开始迁移和更改这些库时，这种耦合也会变得显而易见。还有您需要的更多分布式技术，这些让微服务与集成平台的耦合就越多。

尽管传统的单体中间件（SOA/ESB）提供了分布式系统所需的所有必要技术功能，但它缺乏业务所需的快速更改，适应和扩展的能力。这就是为什么基于微服务的架构背后的思想为容器和Kubernetes的快速普及做出了贡献的原因。随着云原生领域的最新发展，我们现在通过将所有传统中间件功能转移到平台和现成的辅助运行时中来全面发展。

Kubernetes和容器在多语言应用程序的生命周期管理中取得了巨大飞跃，并为未来的创新奠定了基础。
服务网格技术通过高级网络功能在Kubernetes上进行了改进，并开始涉足应用程序方面。
尽管Knative主要通过快速扩展专注于无服务器工作负载，但它也满足了服务编排和事件驱动的绑定需求。
Dapr以Kubernetes，Knative和Service Mesh的思想为基础，并深入应用程序运行时以解决有状态的工作负载，绑定和集成需求，充当现代的分布式中间件。

该图可帮助您直观地看到，很可能在将来，我们最终将使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务都将由多个运行时组成， 最有可能是两个运行时环境：自定义业务逻辑运行环境和分布式原语运行环境。

拥有两个运行环境的微服务

在这种软件体系结构中，您将拥有构成应用程序核心的业务逻辑（称为微逻辑）和提供强大的现成分布式原语的sidecar mecha组件。

这是一个类似于客户端-服务器体系结构的两组件模型，其中每个组件都是独立的运行时。它与纯客户端-服务器体系结构的不同之处在于，这两个组件都位于同一主机上，并且它们之间没有可靠的网络连接。这两个组件的重要性相同，它们可以在任一方向上启动操作并充当客户端或服务器。其中的一个组件称为Micrologic，它拥有从几乎所有分布式系统问题中剥离出来的非常少的业务逻辑。另一个随附的组件是Mecha，它提供了本文中我们一直在讨论的所有分布式系统功能（生命周期除外，它是一个平台功能）。

将业务逻辑和云架构分离的多运行时Muilti-Runtime的微服务架构〜Bilgin Ibryam

Micrologic和Mecha可能是一对一的部署（称为sidecar模型），也可以是带有几个Micrologic运行时的共享Mecha。第一种模型最适用于Kubernetes等环境，而第二种模型则适用于边缘部署。

1. 让我们简要地探讨Micrologic运行时环境的一些特征：

Micrologic组件本身不是微服务。它包含微服务将具有的业务逻辑，但是该逻辑只能与Mecha组件结合使用。另一方面，微服务是自包含的，没有整体功能的一部分，也没有一部分处理流程扩展到其他运行时中。Micrologic和其Mecha对应产品的组合形成了微服务。
这也不是功能或无服务器架构。无服务器最著名的是其托管的快速扩展和从零扩展到零的功能。在无服务器体系结构中，函数实现单个操作，因为这是可伸缩性的单位。在这方面，功能不同于实现多种操作的Micrologic，但实现方式不是端到端的。最重要的是，操作的实现分布在Mecha和Micrologic运行时上。
这是客户端-服务器体系结构的一种特殊形式，针对无需编码即可使用众所周知的分布式基元进行了优化。另外，如果我们假设Mecha扮演服务器角色，那么每个实例都必须经过专门配置以与单个客户端一起工作。它不是旨在与典型的客户端-服务器体系结构同时支持多个客户端的通用服务器实例。
Micrologic中的用户代码不会直接与其他系统交互，也不会实现任何分布式系统原语。它通过事实上的标准（例如HTTP / gRPC， CloudEvents 规范）与Mecha进行交互，并且Mecha使用丰富的功能并在配置的步骤和机制的指导下与其他系统进行通信。
尽管Micrologic仅负责实施从分布式系统问题中剥离出来的业务逻辑，但仍必须至少实现一些API。它必须允许Mecha和平台通过预定义的API和协议与其进行交互（例如，通过遵循Kubernetes部署的云原生设计原则）。

2. 以下是一些Mecha运行时环境特征：

Mecha是一个通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的功能。
Mecha的每个实例都必须配置为与一个Micrologic组件（边车模型）一起使用，或者配置为与几个组件共享。
Mecha不对Micrologic运行时做任何假设。它与使用开放协议和格式（例如HTTP / gRPC，JSON，Protobuf，CloudEvents）的多语言微服务甚至单片系统一起使用。
Mecha以简单的文本格式（如YAML，JSON）声明性地配置，该格式指示要启用的功能以及如何将其绑定到Micrologic端点。对于专业的API交互，可以为Mechan附加规范，例如 OpenAPI ， AsyncAPI ，ANSI-SQL等。对于由多个处理步骤组成的有状态工作流，可以使用诸如 Amazon State Language 的规范。对于无状态集成，可以使用与 Camel-K YAML DSL 类似的方法使用企业集成模式（ EIP ）。。这里的关键点是，所有这些都是Mecha无需编码即可实现的简单的，基于文本的，声明性的，多种语言的定义。请注意，这些都是未来派的预测，目前，尚无用于状态编排或EIP的Mechas，但我希望现有的Mechas（Envoy，Dapr，Cloudstate等）很快就会开始添加此类功能。Mecha是应用程序级别的分布式原语抽象层。
与其依靠多个代理来实现不同的目的（例如网络代理，缓存代理，绑定代理），不如使用一个Mecha提供所有这些功能。一些功能（例如存储，消息持久性，缓存等）的实现将被其他云或本地服务插入并支持。
管理平台（例如Kubernetes或其他云服务）可以提供一些与生命周期管理有关的分布式系统问题，而不是使用诸如 Open App Model 这样的通用开放规范的Mecha运行时。

两个运行环境的架构好处

好处是业务逻辑和越来越多的分布式系统问题之间的松耦合。软件系统的这两个要素具有完全不同的动力学。业务逻辑始终是内部编写的唯一的自定义代码。它经常更改，具体取决于您的组织优先级和执行能力。另一方面，分布式原语是解决这篇文章中列出的问题的人，它们是众所周知的。这些由软件供应商开发，并作为库，容器或服务使用。该代码根据供应商的优先级，发布周期，安全补丁，开放源代码管理规则等而更改。这两个组之间几乎没有可见性并且无法相互控制。

将业务逻辑和云架构分离的多运行时Muilti-Runtime的微服务架构〜Bilgin Ibryam

这也是为技术平台供应商分发和维护复杂的中间件软件提供了更好方法。只要与中间件的交互是通过涉及开放API和标准的进程间通信进行的，软件供应商就可以按照自己的节奏自由发布补丁和升级。消费者可以自由使用他们喜欢的语言，库，运行时，部署方法和流程。

两种运行环境的主要缺点

进程间通信。分布式系统的业务逻辑和中间件机制（您知道名称的来源）在不同的运行时中，并且需要HTTP或gRPC调用而不是进程内方法调用。Micrologic运行时和Mecha应该以较低的延迟和最小的网络问题并置在同一主机上。
复杂。应用程序的一部分将用高级编程语言编写，部分功能将由必须进行声明性配置的现成组件提供。这两个部分的互连不是在编译时或在启动时通过进程内依赖注入，而是在部署时通过进程间通信互连。该模型可实现更高的软件重用率和更快的变更速度。

更详细分析点击标题见原文。

原文 https://www.jdon.com/54335

正文到此结束