在微服务架构中，服务是独立部署和运行的进程，因此服务之间的协作必须通过网络进行，这就是进程间通信（IPC）的核心。第三章深入探讨了IPC的机制、模式及其在信息系统集成服务背景下的实践与权衡。
一、IPC机制概览
微服务间的IPC主要有两种风格：
- 同步请求/响应通信：通常基于HTTP/REST或gRPC。客户端发送请求并等待响应，适用于需要直接、即时结果的交互。其优点是简单、直观，但存在耦合风险（客户端需知晓服务实例位置）和可用性问题（若服务端不可用，客户端可能阻塞）。
- 异步消息传递通信：使用消息代理（如RabbitMQ、Apache Kafka）作为中介。服务通过发布/订阅或点对点模式交换消息，发送者无需等待响应。这种方式解耦性极佳，提升了系统的可伸缩性与可用性，但复杂性较高，需处理消息传递的可靠性、顺序性等问题。
二、API定义与演进
无论选择何种机制，清晰定义服务API至关重要。对于RESTful服务，应使用OpenAPI（Swagger）规范；对于gRPC，则使用Protocol Buffers定义。API一旦发布，必须考虑向后兼容的演进策略，例如通过添加新字段而非修改或删除旧字段，以避免破坏现有客户端。
三、消息格式的选择
文本格式（如JSON、XML）人类可读、易于调试，但消息体积较大；二进制格式（如Protocol Buffers、Avro）则高效、紧凑，对带宽和序列化/反序列化性能更友好。选择时需权衡可读性、性能与互操作性需求。
四、信息系统集成服务视角下的IPC
在为企业构建信息系统集成服务时，微服务的IPC决策直接影响集成的敏捷性与可靠性：
- 内部服务间通信：在可控的领域内，可优先选用高性能、强类型约束的gRPC，或采用异步消息实现事件驱动架构，确保核心业务流的解耦与弹性。
- 对外部系统或遗留系统的集成：REST over HTTP因其广泛支持和防火墙友好性，常成为首选。此时，API网关模式尤为重要，它作为系统唯一入口，负责路由、聚合、协议转换（如将内部gRPC转换为外部REST）、认证与限流，有效隔离内部微服务的复杂性。
- 数据一致性挑战：跨服务的业务事务无法依赖传统数据库事务。书中引入了Saga模式——通过一系列本地事务和补偿事务来管理分布式事务，确保最终一致性。这在集成不同部门或企业的信息系统时，是维护业务规则一致性的关键模式。
五、服务发现与可靠性模式
动态环境中，服务实例地址常变，因此不能硬编码。服务发现机制（客户端发现或服务端发现通过负载均衡器）是IPC的基础设施。必须实施可靠性模式以应对部分故障：
断路器模式：防止客户端持续调用故障服务，避免资源耗尽。
重试机制：透明处理临时故障。
* 后备操作：服务不可用时提供降级响应。
这些模式对于保障集成服务的SLA（服务等级协议）至关重要。
六、与启示
本章阐明，微服务架构中的IPC绝非简单的技术选型，而是一系列影响系统耦合度、韧性及演进能力的战略决策。在设计信息系统集成服务时，应根据交互场景（查询vs.操作）、耦合度要求、性能与可维护性需求，审慎选择同步或异步通信、定义稳健的API契约、并辅以服务发现与容错机制。成功的集成不是简单地连接端点，而是通过恰当的IPC模式构建一个松散耦合、健壮且易于演进的分布式系统。
