多运行时微服务架构（系列一）

关键要点

• 创建分布式系统并非易事。围绕“微服务”架构和“12 因素应用”设计出现了最佳实践。这些提供了与交付生命周期、网络、状态管理和绑定到外部依赖项相关的指南。
• 但是，始终如一地实施这些原则，并使用可扩展且可维护的方法具有挑战性。
• 解决这些原则的传统以技术为中心的方法包括企业服务总线 （ESB） 和面向消息的中间件 （MOM）。虽然这些解决方案提供了良好的功能集，但主要挑战是单片架构以及业务逻辑和平台之间的紧密技术耦合。
• 随着云、容器和容器编排器 （Kubernetes） 的流行，出现了解决这些原则的新解决方案。例如，Knative 用于交付，服务网格用于网络，Camel-K 用于绑定和集成。
• 通过这种方法，业务逻辑（称为“微逻辑”）构成了应用程序的核心，并且可以创建 sidecar“mecha”组件，提供强大的开箱即用分布式原语。
• 这种微观和机甲组件的解耦可以改善第 2 天的操作，例如修补和升级，并有助于维持业务逻辑内聚单元的长期可维护性。

创建良好的分布式应用程序并非易事：此类系统通常遵循 12 因素应用程序和微服务原则。它们必须是无状态的、可扩展的、可配置的、独立发布的、容器化的、可自动化的，有时甚至是事件驱动的和无服务器的。一旦创建，它们应该易于升级并且长期维护起来负担得起。在当今技术的这些竞争需求之间找到良好的平衡仍然是一项艰巨的工作。

在本系列中，我将和大家一起探讨分布式平台如何演进以实现这种平衡，更重要的是，在分布式系统的演进过程中还需要发生什么，以简化可维护的分布式架构的创建。

分布式应用程序需求

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

分布式应用程序需求

Lifecycle

让我们从基础开始。当我们编写一个功能时，编程语言决定了生态系统中可用的库、打包格式和运行时。例如，Java使用.jar格式，所有Maven依赖项作为生态系统，JVM作为运行时。如今，随着发布周期的加快，生命周期更重要的是能够以自动化方式部署、从错误中恢复和扩展服务。这组功能大致代表了我们的应用程序生命周期需求。

Networking

从某种意义上说，今天几乎每个应用程序都是分布式应用程序，因此需要网络。但现代分布式系统需要从更广泛的角度掌握网络。从服务发现和错误恢复开始，到启用现代软件发布技术以及各种跟踪和遥测。出于我们的目的，我们甚至将在此类别中包含不同的消息交换模式、点对点和发布/订阅方法以及智能路由机制。

State

当我们谈论状态时，通常是关于服务状态以及为什么最好是无状态的。但是管理我们服务的平台本身需要状态。这是执行可靠的服务编排和工作流、分布式单例、临时调度（cron 作业）、幂等性、有状态错误恢复、缓存等所必需的。此处列出的所有功能都依赖于在后台设置状态。虽然实际的状态管理不是本文的范围，但依赖于状态的分布式原语及其抽象是有趣的。

Binding

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

在不涉及一次性用例的情况下，以上内容代表了创建良好的分布式系统所需的常见原语的良好集合。今天，许多平台都提供这样的功能，但我们在本文中寻找的是我们在过去十年中使用这些功能的方式如何变化，以及它在下一个平台中的外观。为了进行比较，让我们看看过去十年，看看基于 Java 的中间件是如何满足这些需求的。