软件架构模式：云原生架构服务的集成方案

在云原生架构中，我们往往将一个大的业务子系统拆分为很多独立运行的微小的服务，以便于独立开发、独立测试、独立运维、独立演变，服务之间的修改需不影响。那么问题来了，在原来单体架构中，一个业务子系统可以独立运行来完成某种特定的业务功能，那么这些服务如何协同工作完成某一特定的业务功能呢？这里给出几种参考的方案，请读者按照自己实际的业务场景来决策。

一、服务之间直接通信

例如在《医疗急救一体化管理子系统》中的急救信息管理服务、计算机急救受理、 区特别服务、地理信息服务等等，采用服务之间直接通信的集成方式，这种方式缺点是造成复杂的调用关系，不利于管控，所以不是很特别的类似急救系统这样的服务功能，我们很少采取这种调用关系。

二、通过API 关来集成

通过API 关来集成服务的好处是可以对服务的调用进行集中的管控，这种方式是项目中比较常见的选择，如下图所示。

三、通过服务的编排来实现

通过服务的编排来实现服务间的相互调用来形成新的业务能力，供客户端调用，如下图所示。

四、通过消息中间件来实现服务间的调用

采用消息中间件机制的系统中，不同的对象之间通过传递消息来激活对方的事件，完成相应的操作。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。通过消息中间件来实现服务间的调用这种方式比较适合服务关系简单且明确的应用场景，也是分布式事务处理的一个手段。如下图所示。