今天我们来学习微服务的通信设计模式。沟通是保证服务请求的核心要素。选择合适的通信协议可以使系统达到事半功倍的效果。1、RPC调用方式目前在各种微服务通信社区中，很多都支持RPC方式。有同步请求/响应通信机制，例如REST或GraphQLoverHTTP，或gRPC。或者您可以使用异步的、基于消息的通信机制，例如AMQP（高级消息队列协议）或STOMP（简单/流式文本导向消息协议）。此外，还有许多不同的消息格式。这些格式可以是人类可读的，例如JSON和XML。他们还可以使用更高效的二进制格式，例如Avro或Protobuf。1.RPC选择因素在选择RPC机制之前，有必要考虑服务如何与其客户端进行交互。客户服务交互有两个维度。(1)一对一或一对多：每个客户端请求由一个服务处理。一对多：每个客户端请求由多个服务处理。(2)同步或异步同步：客户端在等待服务响应时可能会阻塞。异步：客户端不阻塞，不立即发送响应（如果有）。2、一对一交互同步请求/响应：服务客户端请求服务，等待响应。服务的紧密耦合是这种交互方式的结果。异步请求/响应：服务客户端向服务发送请求，服务异步回复。单向通知：客户端向服务发送请求，但不期望响应。3、一对多交互式异步发布/订阅：客户端发布一条通知消息，该消息被一个或多个订阅服务使用。异步发布/异步响应：在这种情况下，客户端发布一条消息，然后等待感兴趣的服务的响应。4、消息格式RPC本质上是一种消息交换。重要的设计之一是消息包含数据的格式。消息格式的选择会影响RPC的效率、API的可用性及其可演化性。有两种主要类型的消息格式：文本和二进制。(1)基于文本的消息格式JSON和XML是最流行的基于文本的格式。基于文本的消息格式的优点是高度可读和自我描述。基于文本的消息格式的缺点消息冗长。除了它们的值外，还包括不必要的属性和其他标签。解析文本在性能上是昂贵的。(2)二进制消息格式Thrift、ProtocolBuffers(Protobuf)和Avro是最流行的二进制格式。二进制消息格式的优点是元数据很少，因此有效载荷很小。比基于文本的消息解析更快。二进制消息格式的缺点是可读性差，不能自我描述。二、远程过程调用方式当客户端请求服务时，服务会处理请求并发回响应。虽然一些客户端可能会在等待响应时阻塞，但其他客户端可能具有反应性、非阻塞架构。代理接口通常封装底层通信协议。有多种通信协议可供选择，例如REST、gRPC和GraphQL等。三、使用同步方式进行通信1.REST（RepresentationalStateTransfer）REST是基于资源的概念，它代表一个单一的业务对象。HTTP（超文本传输??协议）用于实现REST。REST使用HTTP来操作URL引用的资源。2、HTTP调用方法GET：GET方法向特定资源发送请求。GET方法不应用于产生“副作用”的操作，例如Web应用程序。其中一个原因是GET可能会被网络蜘蛛随意访问：HEAD方法向服务器请求一个与GET请求一致的响应，但是不会返回响应体。该方法无需传输整个响应内容即可获取响应小消息头中包含的元信息。POST：POST请求数据包含在请求正文中。POST请求可能会导致创建新资源和/或修改现有资源。PUT：PUT方法用请求负载替换目标资源的所有当前表示。DELETE：DELETE方法请求服务器删除Request-URL标识的资源CONNECT：CONNECT方法建立到目标资源标识的服务器的隧道。OPTIONS：OPTIONS方法描述了目标资源的通信选项。TRACE：TRACE方法沿着到目标资源的路径执行消息环回测试。PATCH：PATCH方法对资源应用部分修改。3.指定RESTAPIAPI必须使用IDL（InterfaceDefinitionLanguage）定义。最流行的RESTIDL之一是开放API规范，它是从Swagger开源项目演变而来的。4.挑战一：一次请求获取多个资源由于RESTAPI通常是基于业务对象的，因此一次请求请求多个相关对象是RESTAPI设计中的常见难点之一。客户端必须至少对相关对象提出一个请求。使用查询参数，API使客户端能够在获取相关资源时检索它们。由于这种方法缺乏可扩展性，GraphQL和NetflixFalcor等替代API技术变得越来越流行。5.挑战2：将操作映射到HTTP动词另一个常见的RESTAPI设计问题是将要在业务对象上执行的操作映射到HTTP请求。RESTAPI使用PUT来更新，但是有多种方式可以操作订单，包括取消订单、修改订单等。一种解决方案是定义一个子资源，如/orders/{orderId}/cancel或/orders/{orderId}/修改以更新资源的特定方面或在URL查询参数中指定动词。但是这些解决方案并不是真正的RESTful。由于这个问题，REST的替代方案（例如gRPC）越来越受欢迎。6.REST的优点目前很多微服务框架都支持REST，实现起来比较容易。Postman等插件可以方便地在浏览器中测试HTTPAPI。它支持直接请求/响应通信。7.REST的缺点是只支持请求/响应通信。由于要求客户端和服务器同时在线，可用性降低。客户端必须使用服务发现来发现服务实例的URL。在一个请求中获取多个资源可能具有挑战性。将多个更新操作映射到HTTP动词可能具有挑战性。第四，gRPC因为HTTP只提供了一组有限的请求方法，所以设计一个支持多个更新操作的RESTAPI可能具有挑战性。Google的跨语言客户端和服务器框架gRPC可以解决这个问题。gRPCAPI是使用基于ProtocolBuffers的IDL定义的，这是Google用于序列化结构化数据的语言设计机制。它是一种同步通信机制。使用HTTP/2，客户端和服务器以协议缓冲区格式交换二进制消息。1.gRPC的优点是很容易设计一个具有丰富的更新操作集的API。消息格式紧凑高效。双向流支持RPC和消息传递。它支持以多种语言编写的客户端和服务的互操作性。2.gRPC的缺点JS客户端必须做更多的工作才能使用基于gRPC的API而不是基于REST/JSON的API。5.GraphQLGraphQL解决了一次请求获取多个资源的问题。GraphQL主要用于从客户端应用程序查询数据库。在后端，GraphQL指示API如何将数据呈现给客户端。GraphQL重新定义了开发者使用API的方式，提供了更大的灵活性和更快的在线速度；改进客户端-服务器交互，使前者能够进行精确的数据请求并仅获取他们需要的数据。GraphQL服务器为客户端提供模式：可以请求的数据模型。1.GraphQL的优势客户端可以准确地指定他们需要从服务器获取什么，服务器将以可预测的方式反馈这些数据。API消费者确切地知道哪些数据可用以及它是什么形式，因为它是强类型的。2.GraphQL的缺点无论查询成功与否，总是返回一个HTTP状态码200没有内置缓存支持比REST复杂6.使用异步消息模式进行通信使用消息时，服务异步交换消息。基于消息的应用程序通常使用像RabbitMQ这样的消息代理，充当服务之间的中介。服务客户端通过向服务发送消息来向服务发出请求。如果需要响应，服务实例将向客户端发送一条单独的消息。由于通信是异步的，因此客户端不会等待响应。相反，客户端假定不会立即收到响应。1.单向通知异步消息使得实现单向通知变得容易。通常，客户端将消息发送到服务拥有的点对点通道。服务订阅一个通道来处理消息。没有回复。2.发布/订阅发布/订阅交互风格内置于消息传递中。客户端将消息发布到由多个订阅者读取的发布-订阅通道。3.发布/异步响应结合了发布/订阅和请求/响应的元素，形成更高层次的交互风格。客户端向发布-订阅通道发布一条消息，指定回复通道标头。消费者将包含相关id的回复消息写入回复通道。客户端将回复消息与请求进行匹配，以使用关联ID收集响应。
