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

传统中间件局限性

满足上述老一代需求的众所周知的传统解决方案之一是企业服务总线 （ESB） 及其变体，例如面向消息的中间件、更轻的集成框架等。ESB 是一种中间件，它使用面向服务的体系结构（即经典 SOA）在异构环境之间实现互操作性。

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

以下是使 ESB 在现代没有用处的每种需求类别的一些问题和限制。

Lifecycle

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

Networking

虽然传统的中间件具有专注于与其他内部和外部服务交互的高级功能集，但它有几个主要缺点。网络功能以一种主要语言及其相关技术为中心。对于Java语言，即JMS，JDBC，JTA等。更重要的是，网络问题和语义也深深地刻在了业务服务中。有一些库具有抽象来处理网络问题（例如曾经流行的Hystrix项目），但是库的抽象“泄漏”到服务中的编程模型，交换模式和错误处理语义以及库本身。虽然在一个位置编码和读取与网络方面混合的整个业务逻辑很方便，但这将这两个问题紧密地耦合到一个实现中，并最终形成了一条联合进化路径。

State

为了执行可靠的服务编排、业务流程管理和实现模式（如 Saga 模式和其他运行缓慢的流程），平台需要在后台保持持久状态。同样，临时操作（如触发计时器和 cron 作业）构建在状态之上，并且要求数据库在分布式环境中具有群集和弹性。这里的主要约束是与状态交互的库和接口没有完全抽象并与服务运行时分离。通常，这些库必须配置数据库详细信息，并且它们位于服务中，将语义和依赖项问题泄漏到应用程序域中。

Binding

使用集成中间件的主要驱动因素之一是能够使用不同的协议、数据格式和消息交换模式连接到各种其他系统。然而，这些连接器必须与应用程序共存的事实意味着依赖项必须与业务逻辑一起更新和修补。这意味着数据类型和数据格式必须在服务中来回转换。这意味着代码必须结构化，并且必须根据消息交换模式设计流。这些是抽象端点如何影响传统中间件中的服务实现的几个示例。