分布式微服务中的第三方系统交互规范 _分布式

一、交互方式1.1 第一个维度关注的是一对一和一对多：

一对一：每个客户端请求由一个服务实例来处理。
一对多：每个客户端请求由多个服务实例来处理。

1.2 第二个维度关注的是同步和异步：

同步模式：客户端请求需要服务端实时响应，客户端等待响应时可能导致堵塞。
异步模式：客户端请求不会阻塞进程，服务端的响应可以是非实时的。

1.3 一对一的交互方式有以下几种类型：

请求/响应：一个客户端向服务端发起请求，等待响应；客户端期望服务端很快就会发送响应。在一个基于线程的应用中，等待过程可能造成线程阻塞。这样的方式会导致服务的紧耦合。
异步请求/响应：客户端发送请求到服务端，服务端异步响应请求。客户端在等待响应时不会阻塞线程，因为服务端的响应不会马上就返回。
单向通知：客户端的请求发送到服务端，但是并不期望服务端做出任何响应。

1.4 一对多的交互方式有以下几种类型：

发布/订阅方式：客户端发布通知消息，被零个或者多个感兴趣的服务订阅。
发布/异步响应方式：客户端发布请求消息，然后等待从感兴趣的服务发回的响应。

二、同步模式2.1 使用REST2.1.1 定义REST API按照研发前后端约定的API规范来制定API文档，Swagger用于开发和记录REST API的工具。
2.1.2 在一个请求中获取多个资源这种方法在许多场景中都很有效，但对于更复杂的场景来说，它通常是不够的。实现它也可能很耗时。可使用GraphQL来支持高效的数据获取。
2.2 使用RPC（Dubbo）按照dubbo接口设计规范来制定接口文档。
2.3 使用服务发现（Nacos）2.3.1 应用层服务发现模式这种服务发现方法是两种模式的组合。第一种模式是自注册模式。服务实例调用服务注册表的注册API来注册其网络位置。它还可以提供运行状况检查URL，运行状况检查URL是一个API端点，服务注册表会定期调用该端点来验证服务实例是否正常且可用于处理请求。服务注册表还可能要求服务实例定期调用“心跳” API以防止其注册过期。
2.3.2 客户端发现模式当客户端想要调用服务时，它会查询服务注册表以获取服务实例的列表。为了提高性能，客户端可能会缓存服务实例。然后，服客户端使用负载平衡算法（例如循环或随机）来选择服务实例。然后它向选择的服务实例发出请求。
2.4 使用断路器（Hystrix）分布式系统中，当服务试图向另一个服务发送同步请求时，永远都面临着局部故障的风险。因为客户端和服务端是独立的进程，服务端很有可能无法在有限的时间内对客户端的请求做出响应。服务端可能因为故障或维护的原因而暂停。或者，服务端也可能因为过载而对请求的响应变得极其缓慢。
客户端等待响应被阻塞，这可能带来的麻烦就是在其他客户端甚至使用服务的第三方应用之间传导，并导致服务中断。
2.4.1 开发可靠的调用代理

网络超时：在等待针对请求的响应时，一定不要做成无限阻塞，而是要设定一个超时。使用超时可以保证不会一直在无响应的请求上浪费资源。

限制客户端向服务器发出请求的数量：把客户端能够向特定服务发起的请求设置一个上限，如果请求达到了这样的上限，很有可能发起更多的请求也无济于事，这时就应该让请求立刻失败。

断路器模式：监控客户端发出请求的成功和失败数量，如果失败的比例超过一定的阈值，就启动断路器，让后续的调用立刻失效。如果大量的请求都以失败而告终，这说明被调服务不可用，这样即使发起更多的调用也是无济于事。在经过一定的时间后，客户端应该继续尝试，如果调用成功，则解除断路器。

2.4.2 从服务失效故障中恢复使用Hystrix只是解决方案的一部分。还必须根据具体情况决定如何从无响应的远程服务中恢复服务。一种选择是服务只是向其客户端返回错误。返回备用值（fallback value，例如默认值或缓存响应）可能会有意义。
三、异步模式3.1 基于消息机制的API3.1.1 记录异步操作