同步异步客户端服务器
正如React式宣言所说，React式系统是：响应式，弹性式，弹性式和消息驱动式。 最后一个原则通常与非阻塞异步协议一起使用。 这种通信方式“使接收者仅在活动时消耗资源，从而减少了系统开销”。 这完全符合从云提供商的弹性模型得出的新效率要求。 但是，并非每个系统都是异步的，因此将异步系统与同步客户端集成可能会很棘手。
整合策略
我们可以通过两种策略来解决沟通方式的不匹配问题。
轮询
这涉及到双方的工作。 该协议的第一次往返涉及客户端向服务器发送一些请求，结果为ACK / NACK。 这就是所谓的失火。 假设使用HTTP，服务器将返回状态码202（已接受）。 异步过程最终将成功或失败，并且该结果将由服务器在另一个端点中公开。 客户端将必须定期轮询该端点以了解操作状态。
轮询本质上效率低下，但是当技术堆栈不允许Web套接字等双向协议时，轮询可能是一个好的解决方案。
隐藏异步性
如果我们无法控制这些客户端，则可能必须将异步特性隐藏在某些同步层下。 该层将实现受超时限制的轮询或发布/订阅机制。
以身作则
在这一系列文章中，我们将使用pub / sub机制实现最后一个策略。 我们将为我们的领域添加一些基本的复杂性，以使练习更加多汁。
我们将与类似于Craiglist的网站进行合作，Craiglist是具有分类广告的网站。 但是，我们的平台将专注于社交（时至今日）。 这意味着用户可以将项目发布到某个组中和/或发布到其关注者中。 人们可以举报可疑物品，我们会认真对待那些举报，因为它们威胁到我们的声誉。 如此之多，以至于当局可以直接访问可以立即删除某项的API。
我们的系统由几个基于Akka的微服务组成，使用Kafka进行进程间通信。 警察平台只有同步客户端，他们似乎并不热衷于采用轮询机制来验证是否已真正删除某项。 我们需要与他们同步沟通，这是不可商议的。 在下一篇文章中，我们将看到我们解决方案的详细信息，但作为一项进步，让我们看一下高级架构。 如果您还不了解所有内容，请不要担心。
翻译自: https://www.javacodegeeks.com/2016/05/async-systems-sync-clients.html
同步异步客户端服务器