多运行时微服务架构

创建良好的分布式应用程序并非易事：此类系统通常遵循12要素应用程序和微服务原则。 它们必须是无状态的，可伸缩的，可配置的，独立发布的，容器化的，可自动化的，并且有时是事件驱动的和无服务器的。 创建后，它们应该易于升级，并且长期可以承受。 在当今的竞争需求之间找到良好的平衡仍然是一项艰巨的努力。
在本文中，我将探讨分布式平台如何发展以实现这种平衡，更重要的是，在分布式系统的演进中还需要发生什么事情，以简化可维护的分布式体系结构的创建。 如果您希望看到我在同一主题上的演讲，请在InfoQ上查看我的QConLondon录音。

分布式应用程序需求

在本次讨论中，我将把现代分布式应用程序的需求分为四个类别-生命周期，网络，状态，绑定-并简要分析它们在最近几年中的发展情况。

与传统的ESB时代相比，此体系结构将业务逻辑与平台更好地分离了，但是还没有完全分离。 许多分布式原语，例如经典的企业集成模式（EIP）：拆分器，聚合器，过滤器，基于内容的路由器； 流处理模式：映射，过滤，折叠，联接，合并，滑动窗口； 仍然必须包含在业务逻辑运行时中，并且许多其他依赖于多个不同且重叠的平台附加组件。

如果我们将在不同领域进行创新的各种云原生项目进行堆叠，那么最终将得到如下图所示：

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

微逻辑运行时特征

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

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

Mecha运行时特征

以下是一些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运行时。

这种架构的主要好处是什么/h3>

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

另一方面，Mecha架构为中间件独立性优化了微服务。 尽管微服务彼此独立，但它们在很大程度上依赖于嵌入式分布式基元。 Mecha架构将这两个问题分为单独的运行时，从而允许独立团队独立发布它们。 这种脱钩可以改善第二天的操作（例如修补和升级）以及业务逻辑内聚单元的长期可维护性。 在这方面，Mecha体系结构是微服务体系结构的自然发展，它通过根据引起最大摩擦的边界拆分软件来进行开发。 与功能模型相比，该优化以软件重用和演进的形式提供了更多好处，而功能模型却以代码的过度分配为代价进行了优化，以实现极大的可伸缩性。

结论

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

应用程序功能的这种商品化主要是使用进程外模型进行功能扩展，而不是运行时库或纯平台功能。 That means that in the future it is highly likely that we will use multiple runtimes to implement distributed systems. Multiple runtimes, not because of multiple microservices, but because every microservice will be composed of multiple runtimes; a runtime for the custom micro business logic, and an off-the-shelf, configurable runtime for distributed primitives.

This article was originally published on InfoQ here .

翻译自: https://www.javacodegeeks.com/2020/06/multi-runtime-microservices-architecture.html

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览208235 人正在系统学习中 相关资源：TranslationLoaderBundle:具有数据库翻译加载器的Symfony2捆绑软件

来源：danpu0978