从单体架构到微服务的转变需要构成应用程序的不同服务之间的通信。服务实例通常是需要以某种方式相互通信的进程，这就是进程间通信（IPC）--有时称为服务间通信（ISC）--的作用。
往往想到的IPC机制是RESTful APIs，因为这仍然是使用最广泛的，但其他选择已经出现，可能更适合特定的使用案例。在这篇文章中，除了REST，我们还考虑了其他三种流行的选择：GraphQL、gRPC和Messaging。但是，在确定哪种通信类型最适合你时，有几个类别需要考虑。
同步或异步
同步通信意味着微服务或客户端在等待对请求的响应时被阻塞，而异步通信在收到响应之前能够继续进行（可能稍后或永远不会收到）。
点对点或多点
服务要1：1通信（称为点对点），其中每个请求由一个其他服务处理？那么可以选择同步的请求/响应通信，或者只是简单的异步单向通知。
如果请求要到达多个其他服务（1:n，又称多点），那么异步发布/订阅交互会更好。这些通常使用消息代理来实现：这样，一个请求仍然只需要发送一次就可以被多个服务处理。流行的开源代理选项包括RabbitMQ和Apache Kafka，而主要的供应商产品包括IBM的古老的MQ，最初于1993年推出，以及TIBCO的基于JMS的企业消息服务。
消息格式
如果发送的数据将被人们检查，你可能想选择一种他们可以阅读的消息格式（如JSON或XML）。否则，二进制格式（如协议缓冲区或Apache Avro）会更有效。
API的作用
API通常作为服务之间或服务与客户之间的契约。对于内部微服务之间的通信，建议通常不使用同步（因此是阻塞）协议，但这仍然是面向公众或客户的API的标准。
根据架构和微服务之间的预期交互，有不同的机制可供选择。纵观进程间通信的选项，每一种都有自己的优点和缺点，并有不同的最佳使用情况。下面是微服务架构中IPC选项的一些例子。
REST
RESTful APIs是与服务进行通信的事实上的行业标准。它们由三个部分定义：URI、标准的HTTP方法（如GET和PUT）以及媒体类型。数据用资源表示--例如，客户或其他业务对象。
使用REST有几个优点：
- 简单的接口，容易上手
- 众所周知的，成熟的
- 防火墙友好（因为它使用HTTP/S端口）
- 用浏览器或简单的curl命令测试
有一些缺点：
- 通常是同步的请求/响应互动
→ 替代方法：消息传递 - URI必须由客户知道-需要服务发现
- 端点是由资源定义的，因此很难在一个请求中从多个资源中获得数据，这可能导致类似的请求：
GET /customers/customer_id?expand=orders当试图同时获得客户和订单资源时。
→ 替代方案：GraphQL - 对HTTP动词的依赖会导致更复杂的URI端点结构（例如，更新请求很难映射到PUT，因为更新不是等价的）
→ 替代方案：gRPC - 没有中间缓冲区，所以请求和响应服务都需要在交换期间运行
（如果你在手机上查看这篇博文，你可以下载 以下表格的PDF ，以方便阅读。)
GraphQL
与REST不同，GraphQL查询确切地定义了他们想要的数据，并且只接收这些数据。
他们不只是针对每个请求的一个资源，而是遵循它们之间的引用，以便通过单个请求实现更快的数据检索。这是通过使用类型和字段而不是多个资源端点来实现的。
GraphQL最初是由Facebook在2012年发明和使用的，然后在2015年成为开放源代码。类似的项目大约在同一时间共同发展，包括Netflix的Falcor，但没有看到那么多的采用，而Netflix本身已经开始转向GraphQL。其他已经采用GraphQL的大公司包括Airbnb、Coursera和GitHub。GraphQL 通过HTTP工作，但像REST一样，也可以使用其他协议，包括RSocket。
当使用HTTP时，你可以使用各种工具来查询GraphQL API，例如：