10、微服务架构：消息驱动的设计与实践

微服务架构：消息驱动的设计与实践

1. 微服务的特性与设计原则

1.1 避免使用消息模式和强制服务契约

在设计微服务时，要抵制使用消息模式和强制服务间契约的诱惑。虽然这样做在当时看似是个好主意，但完美的模式可能会让你陷入困境。微服务适用于处理复杂多变的业务逻辑，严格的模式往往难以适应这种环境。

1.2 可组合性

组件加速软件开发的真正力量并非来自可重用性（它只是线性加速器），而是来自组件的组合。组件可以组合成更强大的组件，进而构建更大的系统。例如，UNIX管道就是最成功的组件架构之一，通过将集成接口限制为字节流，单个命令行实用程序可以组合成复杂的数据处理管道，这也是UNIX操作系统成功的重要原因。

微服务具有很强的可组合性，因为消息的网络流可以按需操作。例如，一个微服务可以通过拦截另一个微服务的所有消息、进行修改后再传递给被包装的服务，从而实现对其的包装。

1.3 微服务作为组件的实践

以报纸系统中的文章服务为例，展示了微服务作为组件的实用性。最初的设计中，文章服务需要了解缓存服务，这增加了额外的逻辑。为了优化设计，可以引入一个文章缓存服务，它拦截文章服务的所有消息，转发大部分消息，但对于获取文章、添加文章和删除文章的消息，会相应地在缓存中注入或删除文章。从系统的其他部分来看，文章消息的处理方式不变，但实现了文章的缓存功能，成功将文章缓存服务和文章服务组合在一起。

要实现这一功能，需要编排消息交互。通常，希望在不中断服务的情况下对生产系统进行此类更改。可以采用以下两种方法：
- 使用智能负载均衡器 ：在文章服务前使用智能负