当我们的项目拆分为微服务后，就难免遇到跨服务的通讯，通常我们会使用Query查询的方式实现跨服务通讯，Query查询的方式有4中：请求/响应消息 、物化视图 、服务聚合模式 和 请求(Request)/答复(Reply)模式。下面我们对这四种方式进行讲解一下。
一、请求/响应消息
请求/响应消息是对目标微服务直接发出HTTP请求来进行查询，我们在这一小节模拟一次注册的操作。客户端注册请求发送到网关后，网关将通过HTTP请求直接访问用户服务，然后用户服务将请求拆分为四个步骤来完成注册流程：用户服务通过HTTP请求调用邮件服务发送欢迎邮件，调用头像服务生成默认头像，调用空间服务生成用户初始空间，最后用户服务将注册用户的基本信息存入数据库。
这种操作看似简单无漏洞，但是我们在实际开发中还是要尽量避免使用。首先，服务间的调用都是同步的，这样就阻塞了后续的处理过程，直到返回结果或者请求超时才会继续执行后续步骤。然后，这样也增加服务间的耦合度，那么微服务架构的优势也就被削弱了。接着，频繁的使用HTTP请求直接调用服务，对系统的性能、可伸缩性以及可用性，产生不良影响。最后它也会增加调用链的深度，对于复杂的业务，很有可能出现A服务调用B服务，B服务再调用C服务，C服务再调用D服务，如果某个服务出现严重延迟甚至不可用，那么我们该如何处理，如果所有服务全部出现延迟，那么请求的延迟时间等于调用链上所有服务延迟的综合。
二、物化视图
上一小结我们提到了耦合问题，要这个问题我们可以使用物化视图模式。所谓物化视图模式，就是微服务会在本地存储自己的非规范化数据副本，这个非规范化数据副本是其他微服务所管理的数据在本地的缓存。比如用户服务会在本地缓存头像信息和空间信息，每次查询请求就不需要跨多个服务进行查询数据了。物化视图模式下，整个操作在同一个进程内执行，消除了不必要的耦合提高了可靠性和响应时间。
Tip：由于物化视图模式内容比较多，因此在这里不进行详细讲解，我们会另起文章进行详细的讲解。
三、服务聚合模式
解决微服务间耦合的另一个方法是使用微服务聚合器模式。微服务聚合器模式中，客户端不会直接访问后端服务而是通过聚合器来完成。例如客户端要获得用户的信息、头像和空间信息，请求到达用户聚合器后，分别请求用户服务、头像服务和空间服务，收到每个服务返回的值后组装数据，最后将数据返回给客户端。服务聚合器模式隔离了调用多个后端微服务的操作，将其逻辑集中到专用微服务中，虽然仍然使用HTTP调用，但聚合器微服务减少了后端微服务之间的直接依赖关系。
四、请求(Request)/答复(Reply)模式
同样，我们可以使用解耦请求-答复模式来解决服务间耦合的问题，这个模式的核心是使用队列通讯，并且队列始终是单向通道，由生产者发送消息，消费者接收消息，我们可以通过实现请求队列和响应队列而实现。例如，获取用户信息服务向请求通道中发出获取头像信息和空间信息的请求，头像服务和空间服务通过订阅请求通道收到信息后开始处理，处理完成后将结果通过响应通道发送给用户服务，用户服务收到数据并组装数据返回给客户端。
五、总结
微服务架构中，常用的四种跨服务通讯方式是请求/响应消息、物化视图、服务聚合模式和请求/答复模式。请求/响应通过HTTP直接调用其他服务；物化视图在本地缓存外部数据以减少查询；服务聚合模式集中管理多服务调用；请求/答复模式使用队列异步通讯。开发中应根据实际需求选择适合的模式。