6、微服务通信与集成：原理、挑战与解决方案

微服务通信与集成：原理、挑战与解决方案

1. 基于业务概念的通信

在系统开发中，我们对系统所做的更改往往源于业务对系统行为改变的需求，即改变向客户展示的功能。若系统按照代表业务领域的有界上下文进行分解，那么所做的更改更可能局限于单个微服务边界内，这减少了需要更改的地方，还能实现快速部署。

同时，以相同的业务概念来思考微服务之间的通信也很重要。软件按照业务领域建模不应仅停留在有界上下文的概念上，组织各部分共享的术语和思想应反映在接口中。可以把微服务之间的通信想象成组织内部表单的传递。

2. 技术边界问题

当服务建模不正确时，可能会出现各种问题。曾有团队在拆分系统时，将前端应用设计为无状态的公共网站，后端则是基于数据存储的远程过程调用（RPC）接口。这种拆分导致两个服务都频繁需要更改，且采用低级的、RPC 风格的方法调用，接口过于脆弱，性能也存在问题，还需要复杂的 RPC 批处理机制。这种架构就像洋葱一样，有很多层，处理起来令人头疼。

虽然从地理或组织层面拆分单体系统有时是合理的，但不应将基于技术边界建模服务边界作为首要驱动因素，而应作为次要因素。

3. 理想集成技术的选择标准

在微服务集成中，选择合适的技术至关重要。以下是选择集成技术时应考虑的几个标准：
- 避免破坏性更改 ：尽量选择能使消费者受影响最小的技术。例如，当微服务添加新的数据字段时，现有消费者不应受到影响。
- 保持 API 与技术无关 ：IT 行业变化迅速，应确保微服务间通信的 API 与技术无关，避免使用限制微服务实现技术栈的集成技术