Year: 2020
link: https://www.infoq.com/articles/multi-runtime-microservice-architecture/
writer: Bilgin Ibryam
标签: 技术

💡 【About Article】云原生的发展，极大的改变了现有的服务架构。作者将微服务的需求总结到了四个方面：状态、绑定依赖、网络、生命周期。软件的生命周期被k8s和CI/CD所覆盖，Networking由service mesh做出了良好实践。Dapr将服务的状态和依赖进行了接管。云原生产品的本质就是提供基础设施和业务的解耦，以及基础设施的自身标准化。它发展在某种程度上消除了二线公司和一线公司的基础设施差距。在这篇文章里我们也可以看到作者的对于这种架构的介绍和思考。

以下是原文内容

多运行时微服务架构

💡关键要点

• 创建分布式系统并不是一件容易的事。围绕 "微服务"架构和 "12因素应用 "设计已经出现了最佳实践。它们提供了与交付生命周期、网络、状态管理和与外部依赖关系绑定有关的准则。
• 然而，始终如一的实施这些原则，并采用可扩展和可维护的方法，是具有挑战性的。
• 传统的专注于解决这些原则的方法包括企业服务总线（ESB）和面向消息的中间件（MOM）。虽然这些解决方案提供了一个很好的功能集，但主要挑战是业务逻辑和平台之间的单体架构和紧密的技术耦合。
• 随着云，容器和容器编排（Kubernetes）的流行，产生了解决这些原则的新方案。例如，使用Knative进行交付部署，服务网格（service mesh）作为网络，Camel-K用于绑定和集成。
• 通过这种方法，业务逻辑（称为“Micrologic”）形成应用程序的核心，通过sidecar “mecha” 组件，提供强大的开箱即用的分布式基础单元。
• 这种mircologic和mecha组件的去耦合能够改善DAY-2 Operation，例如补丁和升级，并有助于维持业务逻辑的单元的长期可维护性。

😃

开发一个好的分布式应用程序不是一项简单的任务：分布式系统通常需要遵循12-factor和微服务原则。它们必须是无状态，可扩展，可配置的，independently released，容器化的，可自动化的，有时也可能是事件驱动和serverless。一旦创建，他们应该易于升级和易于长期维护。在这些相互对立的要求中，用今天的技术找到一个很好的平衡点，仍然是一个困难。

在这篇文章中，我将探讨分布式平台如何发展以实现这样的平衡，更重要的是，在分布式系统的发展中还需要发生什么，以方便创建可维护的分布式架构。（该内容在2020年3月的QCon伦敦会议上，做了公开演讲）

Distributed application needs

分布式操作系统的需求

对于此问题，我将使现代分布式应用程序的需求分为四类 - 生命周期(life cycle)，网络(networking)，状态(state)，绑定(binding) - 并简要分析它们近年来如何发展。

lifecycle

Packaging, health check, deployment, scaling, configuration.

让我们从基础开始。当我们编写一个功能时，使用的语言的生态决定了我们可以使用的库以及打包格式、运行时。比如，java使用.jar格式，Maven进行依赖管理，使用JVM作为运行时。现在，随着发布周期的加快，lifecycle中重要的是部署能力，错误恢复比如回档，以及能够自动的进行扩容。这一组能力大致代表了一个应用在生命周期中的需求。

Networking

Service discovery, A/B testing, canary rollouts, Retry timeout, circuit breaker, Point to point, pub/sub, security, observability.

从某种程度上来说，现在的每一个应用基本上都是分布式的，因为需要连接网络。但是，现代的分布式系统则需要从更广泛的角度来掌握网络。从服务发现和错误恢复，到现代软件的发布技术以及各种链路追踪可观测性的内容。为了达到我们的需求，我们在这之中也加入了不同的消息分发模式，比如p2p，pub/sub 和智能路由机制。

State

Workflow management, Idempotence, Temporal scheduling, Caching, Application State.
当我们谈论状态时，通常是关于服务状态以及为什么最好是无状态。但管理我们服务的平台本身也需要状态。服务编排和工作流、分布式单例（distribute singleton）、时间调度（cron jobs）、幂等性、有状态的错误恢复、缓存等等。这里列出的所有功能在底层都依赖于状态。虽然实际的状态管理不是这篇文章的范围，但是分布式基元和它们的抽象所基于的状态是有意义的。

Binding

Connectors, Protocol conversion, Message transformation, Message routing, Transactionality

分布式系统的组件不仅要相互通信，而且也需要与外部系统进行通信和集成。这就要求连接器能够转换各种协议，支持不同的消息交换模式，如轮询、事件驱动、请求/回复、转换消息格式，甚至能够执行自定义错误恢复程序和安全机制。

在不涉及一次性用例的情况下，上面的四个分类里代表了开发好的分布式系统所需的常见基础集合。今天，许多平台都提供了这样的功能，但我们在这篇文章中要寻找的是，我们使用这些功能的方式在过去十年中是如何变化的，以及在下一个十年中会是什么样子。

为了进行比较，让我们看看过去的十年，看看基于Java的中间件如何解决这些需求。

Traditional middleware limitations

传统中间件的限制

传统解决方案能满足老一代的上述需求是企业服务总线（ESB）及其变体，如面向消息的中间件(Message Oriented Middleware MOM)、较轻的集成框架等。ESB是一种中间件使用面向服务的架构（即经典的SOA）实现异构环境之间的连通。

虽然ESB会给你提供一系列很好的功能，但ESB的主要挑战是单体架构和业务逻辑与平台之间的紧密技术耦合，这导致了技术和组织的集中化。当一个服务被开发并部署到这样的系统中时，它与分布式系统框架深度耦合，这反过来限制了服务的发展。这通常只有在软件生命周期的后期才会显现出来。

下面是每一类需求的一些问题和限制，这些问题和限制使得ESB在当今没有用处。

Lifecycle

在传统的中间件中，通常只有一个单一的语言运行时，（如Java），它决定了软件是如何打包的，有哪些库可以使用，它们多久更新一次等等。业务服务不得不使用这些库，才能将其与用相同语言编写的平台紧密结合。在实践中，这导致了协调的服务和平台的升级，阻止了独立常规服务和平台发布。

Networking

虽然传统的中间件能够很好的与其他内部和外部服务的通信，但它有几个主要的缺点。网络功能是以一种主要语言及其相关技术为中心的。对于Java语言来说，是JMS、JDBC、JTA等。更重要的是，网络问题和语义也被深深地刻在了业务服务中。有一些抽象的库来处理网络问题（比如曾经流行的Hystrix项目），但是库的抽象"leak"到服务的编程模型、交换模式和错误处理语义中，以及库本身。虽然在一个地方编码和阅读整个业务逻辑与网络方面的内容是很方便的，但这将两个关注点紧密的耦合到了一个实现里，导致最终需要一起进行升级。

State

为了进行可靠的服务协调、业务流程管理和实现一些模式，如Saga模式和其他缓慢运行程序，平台需要在后台保持状态。同样，时间性动作，如取消定时器和cron作业，也是建立在状态之上的，需要数据库在分布式环境中是集群部署能够保证可用性的。这里的主要制约因素是，与状态交互的库和接口并没有完全抽象化，也没有与服务运行时解耦。通常情况下，这些库必须用数据库进行配置，而且它们存在于在服务中，将语义和依赖性问题泄露给了应用域。

Download the paper of sagas

Binding

使用集成中间件的主要目的之一是能够使用不同的协议、数据格式和消息交换模式连接到其他各种系统。然而，这些连接器必须与应用程序一起工作，这意味着依赖关系必须与业务逻辑一起被更新。这意味着数据类型和数据格式必须在服务中来回转换。这意味着代码必须被结构化，流程必须根据消息交换模式来设计。这些都是一些例子，说明在传统的中间件中，即使是抽象endpoints也会影响服务的实现。

Cloud-native tendencies

云原生趋势

传统的中间件是强大的。它拥有所有必要的技术特性，但它缺乏快速变化和扩展的能力，而这正是现代数字业务需求所要求的。这是微服务架构及其设计现代分布式应用的指导原则所要解决的。

微服务背后的理念及其技术要求促进了容器和Kubernetes的普及和广泛使用。这开启了一种新的创新方式，将在未来几年影响我们开发和处理分布式应用。让我们看看Kubernetes和相关技术如何影响这些需求。

Lifecycle

容器和Kubernetes将我们打包、分发和部署应用程序的方式演变为一种独立于语言的格式。关于Kubernetes模式和Kubernetes对开发者的影响有很多文章，我在这里就不多说了。不过请注意，对于Kubernetes来说，要管理的最小单元是容器，它专注于在容器级别和流程模型上提供分布式基础能力。这意味着它在管理应用程序的生命周期方面做得很好，健康检查、恢复、部署和扩展，但它在分布式应用程序的其他方面做得不是很好，这些方面是在容器内的，如灵活的网络、状态管理和绑定。

你可能会指出，Kubernetes拥有有状态的工作负载、服务发现、cron作业和其他功能。这是真的，但所有这些基础都是在容器级别，在容器内部，开发人员仍然必须使用特定语言的库来访问我们在本文开头列出的更细化的能力。这就是推动Envoy、Linkerd、Consul、Knative、Dapr、Camel-K等项目的原因。

Networking

事实证明，Kubernetes提供的围绕服务发现的基本网络功能是一个很好的基础，但对现代应用来说是不够的。随着微服务数量的增加和部署速度的加快，对更高级的发布策略、管理安全、指标、跟踪、错误恢复、模拟错误等的需求，在不触及服务的情况下变得越来越有吸引力，并自行创造了一个新的软件类别，称为服务网格 (service mesh)。

这里更令人兴奋的是，将网络相关的关注点从包含业务逻辑的服务中移出，移到一个单独的运行时中，无论是sidecar还是节点级代理。今天，service mesh可以做高级路由，帮助测试，处理某些方面的安全问题，甚至可以使用特定的应用协议（例如，Envoy支持Kafka、MongoDB、Redis、MySQL等）。虽然service mesh作为一种解决方案，可能还没有被广泛采用，但它触及了分布式系统中的一个真正的痛点，我相信它将会找到自己存在的形式和方式。

除了典型的service mesh，还有其他一些项目，如Skupper，证实了将网络功能放入外部运行时代理的趋势。Skupper通过一个7层的虚拟网络解决了多集群通信的难题，并提供了先进的路由和连接能力。但它没有将Skupper嵌入到业务服务运行时中，而是在每个Kubernetes命名空间运行一个实例，作为一个共享的sidecar。

总而言之，容器和Kubernetes在应用程序的生命周期管理方面迈出了一大步。service mesh和相关技术击中了一个真正的痛点，并为将更多的责任从应用中转移到代理中奠定了基础。让我们看看接下来会发生什么。

State

管理状态是困难的，应该委托给专门的存储软件和管理服务。这不是这里的主题，但在语言中立的抽象中使用状态来帮助集成用例才是。今天，许多努力试图在语言中立的抽象背后提供有状态的基本单元。有状态的工作流管理是基于云的服务中必须具备的能力，例如AWS Step Functions、Azure Durable Functions等。在基于容器的部署中，CloudState和Dapr，都依赖于sidecar模型，为分布式应用中的有状态抽象提供更好的解耦。

我所期待的是将上述所有有状态的功能抽象成一个独立的运行时。这将意味着工作流管理、单例、idempotency（幂等性）、事务管理、cron job触发器和有状态的错误处理都在一个sidecar（或一个主机级代理）中可靠地发生，而不是在服务中存在。业务逻辑不需要在应用程序中包含这样的依赖和语义，它可以从绑定环境中声明地请求这样的行为。例如，sidecar可以作为cron job触发器、idempotent消费者和工作流管理器，自定义的业务逻辑可以作为回调被调用，或者在工作流的某些阶段插入、错误处理、时间性调用或独特的idempotent请求等。

另一个有状态的用例是缓存。无论是由service mesh层执行的请求缓存，还是用Infinispan、Redis、Hazelcast等进行的数据缓存，都有将缓存能力从应用的运行时中剥离出来的例子。

Binding

当我们在讨论将所有分布式需求与应用程序运行时解耦的话题时，这种解耦趋势也会在bindings方面继续。连接器、协议转换、消息转换、错误处理和安全调解都可以从服务运行时中移出。我们还没有做到这一点，但Knative和Dapr等项目已经在这个方向上做出了尝试。将所有这些职责从应用程序运行时中移出，将导致更小的、以业务逻辑为重点的代码。这样的代码将存在于独立于分布式系统需求的运行时中，可以作为预打包的功能使用。

另一个有趣的方法是由Apache Camel-K项目采取的。这个项目没有使用代理运行时来伴随主要的应用程序，而是依靠一个智能的Kubernetes Operator，用Kubernetes和Knative的额外平台能力来构建应用程序运行时。在这里，单一代理是负责包含应用程序所需的分布式系统原语的operator。不同之处在于，一些分布式原语被添加到应用程序运行时，而一些在平台中启用（也可能包括sidecar）。

Future architecture trends

从广义上看，我们可以得出结论，分布式应用的商品化，通过将功能转移到平台级别，达到了新的阶段。除了生命周期，现在我们可以观察到网络、状态抽象、声明性事件和入口绑定，这些都是现成可用的，而EIPs是这个列表中的下一个。有趣的是，商品化是使用进程外模型（sidecars）进行功能扩展，而不是运行时库或纯平台功能（如Kubernetes新功能）。

我们现在正通过将所有传统的中间件功能（ESB）转移到其他运行时中来形成闭环，很快，我们在服务中所要做的就是编写业务逻辑。

与传统的ESB时代相比，这种架构将业务逻辑与平台解耦得更好，但还不完全。许多分布式原语，如经典的企业集成模式（EIPs）：分割器、聚合器、过滤器、基于内容的路由器；以及流处理模式：地图、过滤器、折叠、连接、合并、滑动窗口；仍然必须包含在业务逻辑运行时中，并且许多其他依赖于多个不同且重叠的平台附加组件

如果我们把在不同领域各种创新的云原生项目叠加起来，我们最终会得到如下图：

这里的图表只是为了说明问题，它特意挑选了一些有代表性的项目，并将它们映射到分布式基元的类别中。在实践中，你不会同时使用所有这些项目，因为其中一些项目是重叠的，不兼容的工作负载模型。如何解释这张图？

• Kubernetes和容器在多语言应用中的生命周期管理中实现了巨大的飞跃，为未来的创新奠定了基础。
• Service mesh在Kubernetes的基础上改进了网络功能，并开始挖掘应用的痛点。
  虽然Knative主要是通过快速扩展关注无服务器工作负载，但它也解决了服务协调和事件驱动的绑定需求。
• Dapr建立在Kubernetes、Knative和Service Mesh的理念之上，并深入到应用运行时中，以解决有状态的工作负载、绑定和集成需求，作为现代分布式中间件。

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

Introduction multi-runtime microservices

多运行时微服务

以下是对形成的多运行时微服务架构的简要描述。

你还记得电影《阿凡达》和科学家开发的用于探索潘多拉荒野的放大移动平台（AMP）“机甲套装”吗？这种多运行时间的架构类似于这些机甲服，给他们的人形驾驶员提供了超能力。在电影中，人类穿上机甲服来获得力量，并获得毁灭性的武器。在这个软件架构中，你的业务逻辑（被称为微逻辑）构成了应用程序的核心，而sidecar机甲组件则提供了强大的开箱即用的分布式原语。微逻辑与Mecha的功能相结合，形成了一个多运行时的微服务，它使用进程外的功能来满足其分布式系统的需求。而最重要的是，《阿凡达2》很快就会问世，以帮助推广这种架构。我们终于可以在所有的软件会议上用令人敬畏的机甲图片取代复古的挎斗摩托车了;-)。接下来让我们看看这个软件架构的细节。

这是一个类似于客户-服务器架构的双组件模型，其中每个组件都是独立的运行时间。它与纯粹的客户-服务器架构不同的是，在这里，两个组件都位于同一台主机上，它们之间的可靠联网并不是一个问题。这两个组件的重要性是相同的，它们可以在任何一个方向发起行动，充当客户或服务器。其中一个组件被称为Micrologic，它持有从几乎所有分布式系统关注点中剥离出来的非常小的业务逻辑。另一个配套的组件是Mecha，它提供了我们通过文章所谈到的所有分布式系统特性（除了生命周期是一个平台特性）。

Micrologic和Mecha可能是一对一的部署（被称为sidecar模式），也可能是一个共享的Mecha和几个Micrologic运行时。第一种模式最适合于环境，如Kubernetes，而后者则适合于边缘部署。

Micrologic运行时特点

让我们简单地探讨一下Micrologic运行时的一些特点。

• Micrologic组件本身不是一个微服务。它包含了一个微服务会有的业务逻辑，但这种逻辑只能与Mecha组件结合使用。另一方面，微服务是独立的，没有整体功能的片段或部分处理流程分散到其他运行时中。一个微逻辑和它对应的Mecha的组合形成了一个微服务。
• 这也不是一个功能或无服务器架构。serverless大多以其管理的快速扩展和扩展到零的能力而闻名。在无服务器架构中，一个函数实现了一个单一的操作，因为那是可扩展性的单位。在这方面，一个函数与一个微逻辑不同，后者实现了多个操作，但其实现并非端到端。最重要的是，操作的实现是分散在Mecha和Micrologic运行时中。
• 这是一种专门的客户-服务器结构形式，为消费众所周知的分布式原语而优化，无需编码。此外，如果我们假设Mecha扮演着服务器的角色，那么每个实例都必须被专门配置为与单个客户端一起工作。它不是一个通用的服务器实例，旨在像典型的客户端-服务器架构那样同时支持多个客户端。
• Micrologic中的用户代码不与其他系统直接交互，也不实现任何分布式系统原语。它通过事实上的标准与Mecha进行交互，如HTTP/gRPC、CloudEvents，而Mecha则使用丰富的能力与其他系统进行通信，并由配置的步骤和机制引导。
• 虽然微逻辑只负责实现从分布式系统关注中剥离出来的业务逻辑，但它仍然必须至少实现一些API。它必须允许Mecha和平台通过预定义的API和协议与它互动（例如，通过遵循Kubernetes部署的云原生设计原则）。

Mecha运行时间特点

以下是Mecha运行时的一些特点:

• Mecha是一个通用的、高度可配置的、可重复使用的组件，提供开箱即用的分布式原语
• Mecha的每个实例必须被配置为与一个Micrologic组件（sidecar模型）一起工作，或者被配置为与几个组件共享。
• Mecha不对Micrologic运行时做任何假设。它可以使用开放的协议和格式，如HTTP/gRPC、JSON、Protobuf、CloudEvents，与多语言的微服务或甚至单体系统一起工作。
• Mecha通过简单的文本格式（如YAML、JSON）进行声明性配置，它决定了哪些功能需要启用，以及如何将它们绑定到Micrologic Endpoint。对于专门的API交互，Mechan可以额外提供一些标准，如OpenAPI、AsyncAPI、ANSI-SQL等。对于由多个处理步骤组成的有状态的工作流，可以使用一个标准，如Amazon State Language。对于无状态的集成，可以使用企业集成模式（EIPs），其方法类似于Camel-K YAML DSL。这里的关键点是，所有这些都是简单的、基于文本的、声明性的、多语言的定义，Mecha无需编码即可完成配置。请注意，这些都是未来的预测，目前，还没有针对有状态编排或EIP的Mecha，但我希望现有的Mecha（Envoy、Dapr、Cloudstate等）能很快开始增加这样的功能。Mecha是一个应用层的分布式原语抽象层。
• 与其为不同的目的依赖多个代理，如网络代理、缓存代理、绑定代理，不如由一个Mecha来提供所有这些能力。一些能力的实现，如存储、消息持久性、缓存等，将被插入并由其他云或内部服务支持。
• 一些关于生命周期管理的分布式系统关注点由管理平台提供，例如 Kubernetes 或其他云服务，而不是使用通用开放规范（Open App Model）的 Mecha 运行时

这种架构的好处是什么

好处是业务逻辑和逐步增加的分布式系统之间的轻耦合。 软件系统的这两个组建具有完全不同的作用范围。 业务逻辑始终是内部编写的独特的自定义代码。 它经常更改，具体取决于您的组织优先级和执行能力。 另一方面，分布式原语是解决本文中列出的问题的原语，它们是众所周知的。 这些由软件供应商开发并作为库、容器或服务使用。 该代码会根据供应商的优先级、发布周期、安全补丁、开源管理规则等而变化。这两个组建彼此几乎没有可见性和控制权。

微服务原则有助于通过有界上下文解耦不同的业务领域，每个微服务可以独立发展。但是微服务架构并没有解决业务逻辑与中间件耦合所带来的困难。对于某些集成用例较少的微服务来说，这可能不是一个大因素。但是，如果你的领域涉及复杂的集成（对每个人来说，这越来越成为一种情况），遵循微服务原则将不能帮助你避免与中间件的耦合。即使中间件表现为你在微服务中包含的库，当你开始迁移和改变这些库的时候，耦合就会变得明显。你需要的分布式原语越多，你与集成平台的耦合度就越高。将中间件作为一个单独的运行时间/进程，通过预定义的API而不是库来使用，有助于松散耦合，并使每个组件独立发展。

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

这种架构的缺点是什么

进程间通信。事实上，分布式系统的业务逻辑和中间件机制是在不同的运行时间，这就需要一个HTTP或gRPC调用，而不是进程内方法调用。但请注意，这不是一个去到不同的机器或数据中心的网络调用。Micrologic运行时和Mecha应该集中在同一台主机上，具有低延迟和最小的网络问题的可能性。

复杂性。下一个问题是，为了获得利益，是否值得开发和维护这样的系统的复杂性。我认为答案会越来越倾向于 "值得"。分布式系统的要求和发布周期的速度正在增加。而这种架构正是为此而优化的。我在前段时间写道，未来的开发者必须具备混合开发技能。这个架构证实并进一步强化了这一趋势。部分应用程序将用高级编程语言编写，部分功能将由现成的组件提供，这些组件必须以声明的方式进行配置。这两部分不是在编译时，或在启动时通过进程内的依赖注入相互连接，而是在部署时，通过进程间的通信相互连接。这种模式使软件的重用率更高，而且变化的速度更快。

在微服务到来之后是什么

微服务架构有一个明确的目标。它对变化进行了优化。通过将应用程序分割成业务领域，这种架构为软件的进化和可维护性提供了最佳的服务边界，这些服务被解耦，由独立团队管理，并以独立的速度发布。

如果我们看一下serverless架构的编程模型，它主要是基于函数的。函数是为可扩展性而优化的。通过函数，我们把每一个操作都拆分成一个独立的组件，这样就可以快速、独立、按需扩展。在这个模型中，部署粒度是一个函数。而选择函数是因为它是有输入的代码结构，其速率与扩展行为直接相关。这是一个为极端可扩展性而优化的架构，而不是复杂系统的长期可维护性。

Serverless 的另一个方面呢？它来自于 AWS Lambda 的流行及其完全托管的运营性质？ 在这方面，“AWS Serverless”以缺乏控制和锁定为代价优化了交付速度。 但完全托管不是应用程序架构，而是一种软件消费模型，类似于使用基于 SaaS 的平台，在理想世界中，该平台应可用于任何类型的架构，无论是单体、微服务、Mecha还是函数。 在许多方面，AWS Lambda 类似于一个完全托管的 Mecha 架构，但有一个很大的不同：Mecha 不强制执行函数模型，而是允许围绕业务领域构建更具凝聚力的代码结构，从所有中间件问题中分离出来。

另一方面，Mecha架构优化了微服务的中间件独立性。虽然微服务是相互独立的，但它们在很大程度上依赖于嵌入式分布式源于。Mecha架构将这两个问题分割成独立的运行时，允许独立团队独立发布。这种解耦改善了day-2 的操作（如打补丁和升级）和保证了业务逻辑单元的长期可维护性。在这方面，Mecha 架构是微服务架构的自然发展，它根据产生分歧的边界拆分软件。 这种优化以软件重用和发展的形式提供了比函数模型更多的好处，函数模型以代码的过度分布为代价优化了极高的可伸缩性。

Conclusion

分布式应用有许多要求。创建有效的分布式系统需要多种技术和良好的集成方法。虽然传统的单体中间件提供了分布式系统所需的所有必要技术功能，但它缺乏业务所需的快速变化、适应和扩展的能力。这就是为什么基于微服务的架构背后的想法促成了容器和Kubernetes的迅速普及；随着云原生领域的最新发展，我们现在正通过将所有传统的中间件功能转移到平台和现成的辅助运行时中来完成这一循环。

这种应用功能的模式化主要是使用进程外模式进行功能扩展，而不是运行时库或纯平台功能。这意味着，在未来，我们极有可能使用多个运行时来实现分布式系统。多个运行时，不是因为有多个微服务，而是因为每个微服务将由多个运行时组成；一个用于定制的微业务逻辑的运行时，以及一个现成的、可配置的用于分布式原语的运行时。

版权属于：秋

本文链接：https://blog.lyneee.com/60.html

本站文章采用 知识共享署名4.0 国际许可协议 进行许可，请在转载时注明出处及本声明！