异步精髓
异步通信-方法和策略，异步通信是提升性能和缩短CPU损耗周期的一种技术手段
1.异步通信
异步通信是一种广泛应用于不同进程和系统之间的通信方法，在异步通信中，客户机向服务器发送一个请求（这需要长时间的处理），并立即收到一个传递确认。与同步通信不同，此响应还没有所需的信息。
在客户机收到确认之后，它将继续执行它的其他任务，假设最终在服务器端准备好所需信息时会通知它。
异步通信的最大好处是提高了性能，由于客户机不会为了等待而阻塞其宝贵的CPU周期，因此它可以在同一时间段内提供更多服务。增加客户机-服务器交互之间的分离也将导致更好的可伸缩性。
我们到处都可以看到异步通信模式。以下是一些例子： “设计和分配”请求从订单管理应用程序提交到库存管理应用程序。从库存管理应用程序请求“完全转储”。监控应用程序通过短信网关向受服务影响的客户发送1000条短信。示例可以成倍增加，但原则是相同的：当冗长的过程完成时通知调用者，并且可以使用信息。
2.常规异步设计
实现异步通信有三种方法：异步回调、使用消息Broker发布订阅消息（或MOM）、轮询状态更改。
2.1 异步回调
在异步回调机制中，执行以下步骤
- 客户端对服务器进行身份验证。
- 客户端调用服务器操作。（Web服务、RPC、本地方法调用等）
- 客户机还向服务器订阅其“回调端点地址”。（解释如下）
- 服务器同步确认收到请求。
- 客户机等待来自另一个预定义通道（servlet、php页面、本地句柄等）的回复。
- 服务器完成所需的工作并从通道通知客户机。
- 客户机获取信息并进行处理。
2.2 基于代理的发布/订阅
在此方法中，创建一个“主题”以启用客户机-服务器通信。这些步骤与异步回调类似，但在这里，介质不同。服务器从不直接通知客户机。它通过一个缓冲区（即代理）来实现这一点。
- 客户端对服务器进行身份验证。
- 客户端调用服务器操作。（Web服务、RPC、本地方法调用等）
- 客户机订阅了代理，并开始从不同的线程监听主题。
- 服务器完成所需的工作并向主题发布消息。
- 客户机获取信息并进行处理。
由于我们依赖不同的代理组件来在系统之间进行调解，因此我们应该对该代理的内部工作有一个扎实的了解。需要对消息持久性、TTL和路由等特性进行详细说明。
2.3 轮询
从性能和可伸缩性的角度来看，轮询应该是最不可取的方法，因为它会给客户端和服务器端带来额外的压力。但是，在某些情况下（尤其是当您无法控制遗留服务器应用程序的代码或存储库时），可能会强制实现它。以下是轮询的典型步骤：
- 客户端对服务器进行身份验证。
- 客户端调用服务器操作。（Web服务、RPC、本地方法调用等）
- 服务器同步确认收到请求。服务器将请求放入其数据库或通过外部服务（如Web服务）公开其状态。
- 每隔X秒，客户机通过连接到存储库或公开的接口来轮询请求的状态。
- 如果请求的状态转换为“就绪”，客户机将获取信息并对其进行处理。
在设计异步通信体系结构时，需要考虑某些策略。
3. 异步通信策略库
3.1 关键策略
参与者应该能够唯一地标识每个请求。也就是说，如果客户机要求服务器将其数据库转储到FTP服务器，则服务器应返回其确认，并使用标识此单个请求的密钥。
然后，客户机可以在其侦听通道中等待这个特定的密钥，并将传入的通知与原始请求关联起来。理想情况下，这个密钥应该由服务器生成。但是，在某些情况下（云跟踪需求或遗留应用程序参与），客户机提供附加到请求的唯一密钥。当回调时间到来时，服务器有责任用相同的键进行响应。第二种方法的缺点是关键冲突。如果一个单独的客户机同时提供相同的密钥，服务器将需要拒绝该请求。
基于代理的发布/订阅方法通常为所有客户端使用一个共享主题。关键策略变得非常重要，尤其是当选择这种方法时。
3.2 重试策略
假设您正在使用外部URL实现回调方法。远程客户端已经传递了请求，得到了确认，并等待回调事件被传递。如果由于某种原因，客户端的端点此时不可用，该怎么办？（网络中断、由于补丁部署而重新启动等）
如果服务器只是忽略了这个回调，当客户机返回时，它将永远不会收到回调。因此，永远无法满足请求；客户机资源将被不必要地消耗。
为了避免这种情况，服务器应该实现重试。它应该多次重试回调，等待固定/增加之间的间隔。如果远程部件从未激活，那么回调消息可以放在存储库中，支持人员可以手动“重新播放”。
使用代理方法，重试策略可能更具挑战性。发布/订阅模型有一个缺陷，当您发布消息时，它将被传递给所有订户。但是，如果订户当时没有在听，则消息将丢失！有一些解决方法可以避免这种情况，例如持久的应用程序服务器主题、附加队列或一些工具（如ApacheKafka）。请注意，这些解决方法可能会增加可维护性成本，因此应在推出前进行可行性研究。
3.3 订阅策略
异步回调方法需要订阅策略。客户端应向服务器提供其地址。对于Webhook，这是一个托管在客户机Web服务器上的URL。对于其他情况，它甚至可以是主机名和端口号。
我们应该实现一种动态端点订阅方法，而不是在集成开始之前将客户机URL放到中央数据库中。实现这一点的现代方法是提供一个RESTfulWebServiceEndpoint，它接受请求ID、URL和密钥。“请求ID”来自我们发出的初始同步请求，它将用作相关键。“url”是客户端的回调地址。“key”是应该与URL回调一起传递给客户机的密码。
在回调发生之前，服务器可以从查找表（以前由订阅提供）中查找“请求ID”，并找到要调用的端点地址。如果这是一次性请求/响应对，则可以从存储库中当场删除查找行。
3.4 有效载荷策略
在服务器端生成的响应可以表示任何信息。它可以是一个十位数字或一个十兆字节的文件。有效负载策略描述了如何将此信息传递到客户端。
负载可以直接在异步通知本身内部传递。如果大小以千字节表示，我们可以将信息传递给回调。如果不是这样，那么应该在通知中传递指向文件的指针。如果信息捕获在一个10兆字节的文件中，那么可以在通知中传递一个文件名和一个FTP服务器IP地址。然后，客户将负责继续获取该文件。
设计异步系统需要仔细的设计。我们需要问自己的第一个问题是，“同步这样做更可行吗？”“。如果非功能性需求允许，我们应该坚持同步的做事方式。如果您最终决定了异步路径，本文中提到的方法和策略可以使您的旅程更加顺利。