购物网站的建设与维护,wordpress外贸主题免费,爱网站免费一站二站,软件开发外包是什么意思本文创意来自一次业务需求#xff0c;这次需要接入一个第三方外部服务。由于这个服务只提供异步 API#xff0c;为了不影响现有系统同步处理的方式#xff0c;接入该外部服务时#xff0c;应用对外屏蔽这种差异#xff0c;内部实现异步请求同步。全文摘要#xff1a;异步…本文创意来自一次业务需求这次需要接入一个第三方外部服务。由于这个服务只提供异步 API为了不影响现有系统同步处理的方式接入该外部服务时应用对外屏蔽这种差异内部实现异步请求同步。全文摘要异步给现有架构带来的问题Dubbo 异步转同步解决方法异步转同步架构设计方案0x00. 前言现有一个系统整体架构如下所示:这是一个很常见的同步设计方案上游系统需要等待下游系统接口返回调用结果。现在需要接入另外一个第三方服务 B该服务与服务 A 最大区别在于这是一个异步 API。调用之后仅仅返回受理成功处理结果后续通过异步通知返回。接入之后整体架构如下所示由于网络隔离策略通知接收程序与通信服务需要单独分开部署。若没此要求可以将通信服务 B 与通知接收程序合并成一个应用。另外图中所有应用采用双节点部署。为了不影响 OpenAPI 上游系统同步处理逻辑通信服务 B 调用第三方服务之后不能立刻返回需要等待结果通知拿到具体返回结果。这就需要通信服务 B 内部将异步转为同步。这就是一个典型的异步转同步问题整个过程涉及两个问题。通信服务 B 业务线程如何进入等待状态又如何唤醒正确等待线程由于通信服务 B 双节点部署通知接收程序如何将结果转发到正在等待处理的节点问题 1 的解决方案参考了 Dubbo 设计思路。我们在使用 Dubbo 调用远程服务时默认情况下这是一种阻塞式调用方式即 Consumer 端代码一直阻塞等待直到 Provider 端返回为止。由于 Dubbo 底层基于 Netty 发送网络请求这其是一个异步的过程。为了让业务线程能同步等待这个过程就需要将异步转为同步。0x01. Dubbo 异步转同步解决办法1.1 业务线程同步阻塞Dubbo 发起远程调用代码位于 DubboInvoker#doInvokeDubbo 版本为2.6.X 版本。2,7.X 重构 DefaultFuture 但是本质原理还是一样。默认情况下Dubbo 支持同步调用方式这里将会创建 DefaultFuture 对象。这里有个非常重要逻辑每个请求生成一个唯一 ID然后将 ID 与 DefaultFuture 映射关系存入 Map 中。这个请求 ID 在之所以这么重要是因为消费者并发调用服务发送请求同时将会有多个业务线程进入阻塞。当收到响应之后我们需要唤醒正确的等待线程并将处理结果返回。通过 ID 这个唯一映射的关系很自然可以找到其对应 DefaultFuture唤醒其对应的业务线程。业务线程调用 DefaultFuture#get方法进入阻塞。这段代码比较简单通过调用 Condition#await 阻塞线层。1.2 唤醒业务线程当消费者接收到服务提供者的返回结果将会调用 DefaultFuture#received 方法。通过响应对象中的唯一 ID找到其对应 DefaultFuture 对象从而将结果设置 DefaultFuture 对象中然后唤醒的相应的业务线程。这里实际有个优化点使用 done#signalAll 代替 done#signal。使用 condition 等待通知机制的时候需要注意这一点。详情参考:https://github.com/apache/dubbo/issues/36781.3 设计注意点正常情况下当消费者接收到响应之后将会从 FUTURES 这个 Map 移除 DefaultFuture 。但是在异常情况下服务提供者若处理缓慢不能及时返回响应结果消费者业务线程将会因为超时苏醒。这种情况下 FUTURES 积压了无效 DefaultFuture 对象。如果不及时清理极端情况下将会发生 OOM 。DefaultFuture 内部将会开启一个异步线程定时轮询 FUTURES 判断 DefaultFuture 超时时间及时清理已经无效(超时)的 DefaultFuture。0x02. 转发方案设计根据 Dubbo 解决思路问题 1 解决办法就比较简单了。具体流程如下通信服务 B 内部生成一个唯一请求 ID 发给第三方服务若请求成功内部版使用 Map 存储对应关系并使业务线程阻塞等待通信服务 B 收到异步通知结果通过 ID 查找对应业务线程唤醒的相应的线程这个设计过程需要注意设置合理的超时时间这个超时时间需要考虑远程服务调用耗时可以参考如下公式业务线程等待时间通信服务 B 接口的超时时间 - 调用第三方服务 B 接口消耗时间这里就不贴出具体的代码详细代码参考 Dubbo DefaultFuture。接下来重点看下通知服务如何将结果转发给正确的通信服务 B 的节点。这里想到两种方案SocketServer 方案MQ 方案2.1 SocketServer通信服务 B 使用 SocketServer 构建一个服务接收程序当通知接收程序收到第三方服务 B 通知时通过 Socket 将结果转发给通信服务 B。整个系统架构如下所示由于生产服务双节点部署通知接收程序就不能写死转发地址。这里我们将请求 ID 与通信服务 B socket 服务地址关系存入 Redis 中然后通知接收程序通过 ID 找到正确的地址。这个方案说实话有点复杂。第一 SocketServer 编码难度较大编写一个高效 SocketServer 就比较难一不小心可能产生各种 Bug。第二通信服务 B 服务地址配置在配置文件中由于两个节点地址不同这就导致同一应用存在不同配置。这对于后面维护就很不友好。第三额外引入 Redis 依赖系统复杂度变高。2.2 MQ 方案相对 SocketServer 方案MQ 方案相对简单这里采用 MQ 广播消费的方式架构如图所示通知接收程序收到异步通知之后直接将结果发送到 MQ。通信服务 B 开启广播消费模式拉取 MQ 消息。通信服务 B1 拉取消息通过请求 ID 映射关系没找到内部等待的线程知道这不是自己的等待消息于是 B1 直接丢弃即可。通信服务 B_2 拉取消息通过请求 **ID** 映射关系顺利找到正在等待的线程然后可以唤醒等待线程返回最后的结果。对比 SocketServer 方案MQ 方案整体流程比较简单编程难度低也没用存在特殊的配置。不过这个方案十分依赖 MQ 消息实时性若 MQ 消息投递延迟很高这就会导致通信服务 B 业务线程超时苏醒业务异常返回。这里我们选择使用 RocketMQ长轮询 Pull 方式可保证消息非常实时综上这里采用 MQ 的方案。0x03. 总结异步转同步我们需要解决同步阻塞以及如何唤醒的问题。阻塞/唤醒可以分别使用 Condition#await/signalAll。不过这个过程我们需要生成一个唯一请求 ID并且保存这个 ID 与业务线程映射关系。后续等到结果返回我们才能通过唯一 ID 唤醒正确等待线程。只要了解上面几点异步转同步的问题就就可以迎刃而解。另外如果你也有碰到异步转同步问题本文的方案希望对你有帮助。如果你有其他设计方案欢迎留言一起讨论~参考资料http://dubbo.apache.org/zh-cn/docs/sourcecodeguide/service-invoking-process.htmlhttp://dubbo.apache.org/zh-cn/blog/dubbo-invoke.html
