基于分布式跨容器的异步转同步调用方法及装置

技术领域

本发明属于大数据技术领域，特别是涉及分布式系统服务调用，具体涉及一种基于分布式跨容器的异步转同步调用方法及装置。

背景技术

现有技术中，异步调用服务转变为同步调用服务的实现方式均是在调用服务后阻塞当前线程，等待被调用方返回结果或超时。这里要求被调用方必须返回有效的信息，调用方才能根据返回的信息进行下一步处理。但目前有些被调用方的服务只提供异步模式，无论成功失败都是返回一样的结果，甚至不会返回结果，而真实的处理结果他们只能通过回调调用方的另一服务来告知。在分布式系统中，接受结果线程与等待结果的线程存在不在同一个容器上的情况，若希望接受结果的线程在收到结果后通知等待结果的线程，这就出现了两个线程之间相互通讯的问题，同时还存在等待线程在等待过程中消耗系统资源的问题。若两个线程不在同一个服务器上，则还涉及两个进程之间相互协作通讯的问题，从而增加等待线程在等待过程中消耗的系统资源。

发明内容

本发明属于大数据技术领域，其所提供的基于分布式跨容器的异步转同步调用方法及装置，克服了目前分布式系统中异步调用服务还需要同步返回结果给调用方的问题。大大提高系统资源的利用率。并且引入超时清理器清理超时的记录以保持映射表的有效性，提供查找的效率，更是唤醒睡眠线程尽早完成业务逻辑释放线程以避免系统崩溃。对于通知发送器发送的异常情况和超时清理器的超时清理情况，本方法结合系统内的监控系统及时发送报警，使得应用运维人员可以及时掌握系统的服务调用情况。

为解决上述技术问题，本发明提供以下技术方案：

第一方面，本发明提供一种基于分布式跨容器的异步转同步调用方法，包括：

利用系统内的第一容器中的线程将当前服务调用的事件ID以及线程信息写入等待线程映射表中；

根据所述事件ID以及所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内；

响应于所述第二容器中的线程的调用结果通知，根据所述第一容器中的线程在所述等待线程映射表中查找对应的等待线程信息。

一实施例中，在所述根据所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内之前：所述第一容器中的线程为睡眠状态。

一实施例中，所述响应于所述第二容器中的线程的调用结果通知，根据所述第一容器中的线程在所述等待线程映射表中查找对应的等待线程信息，包括：

将调用结果以及所述事件ID写入通知发送队列中；

根据所述通知发送队列告知所述第一容器中的线程所述调用结果通知；

在所述等待线程映射表中查找所述事件ID对应的等待线程信息。

一实施例中，基于分布式跨容器的异步转同步调用方法还包括：

当在所述等待线程映射表中查找到所述事件ID对应的等待线程信息时，根据所述等待线程信息唤醒所述第一容器中的线程。

一实施例中，基于分布式跨容器的异步转同步调用方法还包括：

当在预设时间段内没有收到所述第二容器中的线程的调用结果通知，删除所述等待线程映射表中的事件ID以及线程信息，并通知所述第一容器中的线程调用已超时。

第二方面，本发明提供一种基于分布式跨容器的异步转同步调用装置，包括：

数据写入模块，用于利用系统内的第一容器中的线程将当前服务调用的事件ID以及线程信息写入等待线程映射表中；

线程调用模块，用于根据所述事件ID以及所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内；

结果通知模块，用于响应于所述第二容器中的线程的调用结果通知，根据所述第一容器中的线程在所述等待线程映射表中查找对应的等待线程信息。

一实施例中，在所述根据所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内之前：所述第一容器中的线程为睡眠状态；

所述结果通知模块包括：

结果写入单元，用于将调用结果以及所述事件ID写入通知发送队列中；

通知告知单元，用于根据所述通知发送队列告知所述第一容器中的线程所述调用结果通知；

信息查找单元，用于在所述等待线程映射表中查找所述事件ID对应的等待线程信息。

一实施例中，基于分布式跨容器的异步转同步调用装置还包括：

线程唤醒模块，用于当在所述等待线程映射表中查找到所述事件ID对应的等待线程信息时，根据所述等待线程信息唤醒所述第一容器中的线程；

超时通知模块，用于当在预设时间段内没有收到所述第二容器中的线程的调用结果通知，删除所述等待线程映射表中的事件ID以及线程信息，并通知所述第一容器中的线程调用已超时。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现基于分布式跨容器的异步转同步调用方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现基于分布式跨容器的异步转同步调用方法的步骤。

从上述描述可知，本发明实施例提供的基于分布式跨容器的异步转同步调用方法及装置，首先利用系统内的第一容器中的线程将当前服务调用的事件ID以及线程信息写入预先生成的等待线程映射表中；接着，根据事件ID以及系统外的RPC服务内的线程调用第二容器中的线程；第一容器以及第二容器均在系统内；最后响应于第二容器中的线程的调用结果通知，根据第一容器中的线程在等待线程映射表中查找对应的等待线程信息。本发明克服了现有技术中分布式系统中异步调用服务需要同步返回结果给调用方的问题。并且利用分布式消息队列解决跨容器、跨数据库无法通知问题，利用线程锁解决同一容器内线程协作问题，大大提高系统资源的利用率。为减小因网络延迟或系统异常导致通知接收器长时间没有收到信息的问题，本发明还引入队列超时清理器清理超时的记录以保持映射表的有效性，提供查找的效率，更是唤醒睡眠线程尽早完成业务逻辑释放线程以避免系统崩溃。对于通知发送器发送的异常情况和超时清理器的超时清理情况，本发明结合系统内的监控系统及时发送报警，使得应用运维人员可以及时掌握系统的服务调用情况。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明的实施例中基于分布式跨容器的异步转同步调用方法流程示意图一；

图2为本发明的实施例中等待线程映射表的内部结构图；

图3为本发明的实施例中基于分布式跨容器的异步转同步调用方法中步骤300的流程示意图；

图4为本发明的实施例中基于分布式跨容器的异步转同步调用方法流程示意图二；

图5为本发明的实施例中基于分布式跨容器的异步转同步调用方法流程示意图三；

图6为本发明的具体应用实例中收单业务的服务调用链路图；

图7为本发明的具体应用实例中收单系统内部系统结构图；

图8为本发明的具体应用实例中基于分布式跨容器的异步转同步调用方法流程示意图一；

图9为本发明的具体应用实例中分布式系统中跨容器的异步转同步服务调用示意图；

图10为本发明的具体应用实例中超时清理器清理策略流程图；

图11为本发明的具体应用实例中基于分布式跨容器的异步转同步调用方法流程示意图二；

图12为本发明的具体应用实例中基于分布式跨容器的异步转同步调用装置的结构示意图一；

图13为本发明的具体应用实例中结果通知模块30的结构示意图；

图14为本发明的具体应用实例中基于分布式跨容器的异步转同步调用装置的结构示意图二；

图15为本发明的具体应用实例中基于分布式跨容器的异步转同步调用装置的结构示意图三；

图16为本发明的实施例中的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本发明的实施例提供一种基于分布式跨容器的异步转同步调用方法的具体实施方式，参见图1，该方法具体包括如下内容：

步骤100：利用系统内的第一容器中的线程将当前服务调用的事件ID以及线程信息写入等待线程映射表中。

具体地，第一容器的线程将本次服务调用的时间ID以及线程信息存入等待线程映射表中。该等待线程映射表是一个KV键值对的哈希表结构。KEY保存的是事件ID，其实质含义是指在分布式系统下能够在当前时间当前容器生成的唯一序号，可以使用雪花算法生成，也可以使用UUID，也可以应用自定义的规则。VALUE保存的线程对象的信息，其包括Condition对象、超时时间、存入时间、线程输入对象。Condition对象是指当前线程锁创建的条件对象，其能够使得线程进入睡眠或唤醒。超时时间是指本次服务调用后，线程等待多久时间就不再等待。存入时间是指存入映射表的时间，用于出现异常后分析问题使用。线程输入对象是指本次服务调用的输入内容，用于线程唤醒后的后续处理，也可以作为分析问题使用，详情参见图2。

步骤200：根据所述事件ID以及所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内。

在步骤100的基础上，根据时间ID以及系统外部的RPC服务中(RPC(RemoteProcedure Call)是一种进程间通信方式。它允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数，)的线程调用第二容器中的线程，然后将第一容器中的线程调整为睡眠状态，等待后续步骤环形，需要强调的是，所述第一容器以及所述第二容器均在所述系统内，而RPC服务在该系统外部，可以理解的是，通过该种设置方式，可以大大提高系统资源的利用率。

步骤300：响应于所述第二容器中的线程的调用结果通知，根据所述第一容器中的线程在所述等待线程映射表中查找对应的等待线程信息。

具体地，第二容器接收到由RPC服务内的线程发起的回调服务请求之后，将结果存入数据库，并把事件ID存入通知发送队列中。通知发送器通过不断扫描通知发送队列的内容，将内容发布到其主题上。第一容器的通知接收器收到了发布的信息之后，即得到了事件ID。根据事件ID，通知接收器从等待线程映射表中查找等待线程信息。

从上述描述可知，本发明实施例提供的基于分布式跨容器的异步转同步调用方法，首先利用系统内的第一容器中的线程将当前服务调用的事件ID以及线程信息写入预先生成的等待线程映射表中；接着，根据事件ID以及系统外的RPC服务内的线程调用第二容器中的线程；第一容器以及第二容器均在系统内；最后响应于第二容器中的线程的调用结果通知，根据第一容器中的线程在等待线程映射表中查找对应的等待线程信息。本发明克服了现有技术中分布式系统中异步调用服务需要同步返回结果给调用方的问题。并且利用分布式消息队列解决跨容器、跨数据库无法通知问题，利用线程锁解决同一容器内线程协作问题，大大提高系统资源的利用率。为减小因网络延迟或系统异常导致通知接收器长时间没有收到信息的问题，本发明还引入队列超时清理器清理超时的记录以保持映射表的有效性，提供查找的效率，更是唤醒睡眠线程尽早完成业务逻辑释放线程以避免系统崩溃。对于通知发送器发送的异常情况和超时清理器的超时清理情况，本发明结合系统内的监控系统及时发送报警，使得应用运维人员可以及时掌握系统的服务调用情况。

一实施例中，在步骤100之后以及步骤200之前，所述第一容器中的线程为睡眠状态。

可以理解的是，将第一容器中的线程调整为睡眠状态的本质上是领用线程锁解决同一容器内线程协作问题。

一实施例中，参见图3，步骤300进一步包括：

步骤301：将调用结果以及所述事件ID写入通知发送队列中；

步骤302：根据所述通知发送队列告知所述第一容器中的线程所述调用结果通知；

步骤303：在所述等待线程映射表中查找所述事件ID对应的等待线程信息。

在步骤301至步骤302中，第二容器的线程将调用结果存入数据库中之后，把时间ID存入通知发送队列中。通知发送器通过不断扫描通知发送队列的内容，将内容发布到其主题上。第一容器的通知接收器收到了发布的信息，即得到了事件ID。根据事件ID，通知接收器从等待线程映射表中查找对应等待线程信息。

一实施例中，参见图4，基于分布式跨容器的异步转同步调用方法还包括：

步骤400：当在所述等待线程映射表中查找到所述事件ID对应的等待线程信息时，根据所述等待线程信息唤醒所述第一容器中的线程。

一实施例中，参见图5，基于分布式跨容器的异步转同步调用方法还包括：

步骤500：当在预设时间段内没有收到所述第二容器中的线程的调用结果通知，删除所述等待线程映射表中的事件ID以及线程信息，并通知所述第一容器中的线程调用已超时。

在步骤400以及步骤500中，当第一容器的接收器从等待线程映射表中查找到对应等待线程信息则唤醒等待线程告知其已回调完成；若找不到则忽略该信息。

当第一容器的通知接收器长时间没有收到信息后，利用超时清理器清理等待线程映射表中记录，并唤醒等待线程告知其已超时。最后，等待线程根据唤醒的类型来进行具体的业务处理。

另一方面，这里的超时清理器是指一个清理等待线程映射表内数据的延迟线程池。超时清理器能够及时清理异常超时的等待线程，保持等待线程映射表内数据的有效性，使得不会因线程无限等待导致无法回收使用，得到一个保护系统的作用。

为进一步地说明本方案，本发明以银行与商户之间的收单业务为例，提供基于分布式跨容器的异步转同步调用方法的具体应用实例。

图6为收单业务的服务调用链路图，一个服务请求调用经过5个系统，分别是商户系统1、API系统2、收单系统3、外联系统4、银联系统5。

商户系统1是指商户自己的业务处理系统，其包括前端和后端系统。商户处理完自己的业务逻辑后，按照API接口的规范对接口进行加密签名处理，调用API系统提供的接口。

API系统2是指工行提供的接入商户请求的统一入口系统。API系统2对API接口进行解密验签处理，验证请求的合法性和安全性，并将HTTPS请求转换为更高效率的RPC请求，通过内网调用收单系统3的服务。

收单系统3是指工行收单业务处理的核心系统。收单系统3提供一系列的服务给API系统2调用，提供不同的回调服务给外联系统4调用。收单系统3内部系统结构图详见图7。其中包括注册中心3-1、分布式消息队列3-2、业务服务器组3-3-3、业务服务器组3-3-4、数据库服务器组3-5、数据库服务器组3-6，具体地：

注册中心3-1是指服务的注册中心，记录了服务和服务地址的映射关系。其具有服务发现、服务配置、服务健康检查等功能，常见的分布式注册中心有Zookeeper、Eureka、Consul、Nacos。注册中心3-1是一个高可用的注册中心集群，进行跨园区部署，保证当一个园区发生灾难性问题时，另一个园区仍可以正常运行。或者单个注册中心出现异常的时候，其他注册中心还可以提供稳定的功能，保证系统稳定运行。在收单系统中，每个容器启动时都会将服务注册到注册中心3-1上。当有容器下线时，注册中心3-1会将该容器的所有服务提供者下线，再通知其他容器上消费者将该服务的提供者剔除，保证服务调用的可用性。

分布式消息队列3-2是指在分布式场景下，解决应用耦合、异步消息、流量削锋等问题而实现的高性能、高可用、可伸缩和最终一致性的中间件，常见的分布式消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ等。分布式消息队列3-2解决了不同容器之间的消息同步问题，使得架构能够松耦合。在收单系统中，同一个业务服务器组的每个容器都会订阅同一个主题，而不同的业务服务器组的容器订阅的不是同一个主题。如业务服务器组3-3内的每个容器订阅的主题是一样的，而业务服务器组3-3内的容器与业务服务器组3-4内的容器订阅的主题是不一样的。每个容器都可以往分布式消息队列3-2中发布信息，该容器所在的业务服务器组的其他容器都可以收到该消息。这样可以减少广播的范围，减少系统资源的消耗。

业务服务器组3-3、业务服务器组3-4是指收单系统内完成业务处理的两个服务器群组。业务服务器组3-3、业务服务器组3-4分别包含3个容器，每个容器的功能是一样的，这样使得系统可用性更高。每个业务服务器组内的容器是动态可伸缩的，可以按照系统当前的资源使用情况和并发数及时调整，表明了系统具有可伸缩性的能力。若业务量长期增大，系统还可以再部署多个业务服务器组。不同容器之间可以进行RPC服务调用，可以通过消息队列生产消费信息。每个业务服务器组的容器都会与一个数据库服务器组相连，不同业务服务器组连接的数据库服务器组不同。如业务服务器组3-3的每个容器连的是数据库服务器组3-5，业务服务器组3-4的每个容器连的是数据库服务器组3-6。

数据库服务器组3-5、数据库服务器组3-6是指一个一主三备的高可用数据库集群。正常情况下，业务服务器组3-3、业务服务器组3-4读和写操作都是在主数据库上进行。当发生异常时，系统可以进行主从切换，读写操作都在备库进行。主库与备库之间采用半同步的方式同步数据，以保障数据的实时性和最终一致性。数据库通常使用关系型数据库来保存数据，如MYSQL、ORACLE、DB2等。

综上所述，收单系统内部系统之间的关系是：业务服务器组3-3、业务服务器组3-4内的容器通过注册中心3-1登记服务注册和服务订阅的信息；通过分布式消息队列3-2发布和订阅各组自己的主题信息；通过数据库服务器组3-5、数据库服务器组3-6来完成数据的读写；通过RPC协议进行服务调用。

外联系统4是指工行统一与卡组织对接的基础系统。外联系统4根据不同的服务，通过专线或互联网将请求发送给对应卡组织，并提供回调接口给卡组织进行通知，其主要实现证书签名认证、验签卸载等基础功能。

银联系统5是指银联相关的业务系统。银联系统5接受各银行的请求，转接到对应的收单组织。

综上所述，收单业务的服务调用链路图中各系统的关系为：商户系统1通过互联网发起HTTPS请求到API系统2，同步等待API系统2返回结果。API系统2收到请求后，将HTTPS请求转为RPC请求，再通过内网调用收单系统3其中一个服务，同步等待收单系统3返回结果。收单系统3收到请求后，经过业务处理，通过内网异步调用外联系统4的服务，同步等待外联系统4的回调结果。外联系统4通过专线或互联网发起HTTPS或HTTP请求到银联系统5。银联系统5将回调结果通过专线或互联网发起HTTPS或HTTP请求到外联系统4来通知，外联系统4收到后转为RPC请求，再通过内网调用收单系统3其中一个回调服务。收单系统3收到回调请求后，将处理结果返回给API系统2。

参见图8以及图9，基于上述收单业务的服务调用链路图，本具体应用实例中的基于分布式跨容器的异步转同步调用方法包括：

S1：容器A的线程1将本次服务调用的事件ID和线程信息存入等待线程映射表2中，再RPC服务调用线程5以调用线程6，最后进行睡眠状态等待唤醒。

S2：线程5收到请求处理完业务后，调用回调服务。容器B的线程6收到回调服务的请求，将结果存入数据库7，并把事件ID存入通知发送队列8中。

S3：通知发送器9通过不断扫描通知发送队列8的内容，将内容发布到其主题上。容器A的通知接收器4收到了发布的信息，即得到了事件ID。

S4：根据事件ID，通知接收器4从等待线程映射表2中查找等待线程信息，若找到则唤醒等待线程1告知其已回调完成；若找不到则忽略该信息。

S5：当容器A的通知接收器4长时间没有收到信息后，超时清理器3会清理等待线程映射表2中记录，并唤醒等待线程1告知其已超时。

S6：等待线程1根据唤醒的类型来进行具体的业务处理。

图9为分布式系统中跨容器的异步转同步服务调用示意图，其中包括线程1、等待线程映射表2、超时清理器3、通知接收器4、线程5、线程6、数据库7、通知发送队列8、通知发送器9。

线程1是指业务服务器组内的某个容器中的线程(如图8中所示的容器A的线程1)，特指负责服务调用处理的线程，如Dubbo线程。一个容器内会有多个线程，此处只列举在服务调用中的一个线程示意图。线程1在服务调用之前，会将自己的信息存入到等待线程映射表2中，再进行RPC调用线程5，最后进入睡眠状态等待唤醒。

等待线程映射表2是指一个关于调用事件ID与等待线程相关信息的映射关系表，是一个线程安全的哈希表。等待线程映射表2随着容器启动而创建，KEY值为调用事件ID，VALUE值为线程1的相关信息，具体结构见图2。

超时清理器3是指一个清理等待线程映射表2内数据的延迟线程池。超时清理器3能够及时清理异常超时的等待线程，保持等待线程映射表2内数据的有效性，使得不会因线程无限等待导致无法回收使用，得到一个保护系统的作用。

通知接收器4是指一个订阅某个分布式消息队列主题的线程。通知接收器4通过订阅主题，能够及时收到回调通知，并根据收到的事件ID从等待线程映射表2查找等待线程将其唤醒。

线程5是指外联系统内的某个容器中的线程，特指负责服务调用处理的线程，如Dubbo线程。该线程是服务提供方的实际处理者，其在收到请求后处理完业务内容，最后调用收单系统提供的回调服务。

线程6其本质与线程1是一样的。唯一的区别在于，其与线程1不在同一个容器内，是逻辑隔离的。如线程1在容器A，线程6在容器B。线程6在收到回调后，首先将结果存入数据库7中，以作为后续查询、兜底处理的一个依据。接着将事件ID存入通知发送队列8，结束回调的处理。线程6的工作内容应尽可能的少，加快等待线程的唤醒时间，这样能够减少总的等待时间。这里需要特别说明，等待线程1所在的容器A和接受通知线程6所在容器B里的每个组件都是一样的，都包括等待线程映射表2、超时清理器3、通知接收器4、通知发送队列8、通知发送器9。图中只说明跨容器的异步转同步调用的关键流程，所以未一一列举出来。

数据库7是指数据库服务器组内的关系型数据库，与上面介绍数据库服务器组的数据库是一样的，这里不在阐述。

通知发送队列8是指一个存放待发送事件ID的链式结构队列。通知发送队列8是一个有界的、线程安全的队列，引入该队列的目的是接受通知线程6只需要把事件ID存入队列，不需要关心如何发送、何时发送的问题，达到与通知发送器9解耦的作用。同时这样能够使得接受通知线程6能够快速结束，释放出线程出来，提供系统资源利用率。

通知发送器9是指一个发布某个分布式消息队列主题的线程。通知发送器9通过不断读取通知发送队列8的内容，然后将读取到的事件ID发布到其主题上，最后在发送完毕后将事件ID从通知发送队列8移除。

参见图10，步骤S5进一步包括：

步骤S101：超时清理器从线程池中取出一个线程来调起清理作业。

步骤S102：根据事件ID去查找等待线程映射表，若能够找到，则说明等待线程还没有被唤醒，走步骤S103；若没有找到，则说明等待线程已被唤醒，走步骤S109。

步骤S103：取出等待线程映射表当前记录中的超时时间，判断当前时间是否大于等于超时时间，若是则说明确实已经超时了，走步骤S105；若不是则表示延迟作业启动时间与实际记录时间有差距，还没有超时，走步骤S104。

步骤S104：还没有超时，再等待5毫秒，走回到步骤S102重复流程。此步骤是一个兼容性处理步骤，一般情况下不会走到。

步骤S105：已经超时了，打印出错误信息，报错信息格式为：“当前服务为：XXX，事件ID为：XXX，超时时间为：XXX，存入时间为：XXX，服务输入内容为：XXX，线程等待已超时。”，其中XXX需要按照等待线程映射表记录的内容进行实例化。

步骤S106：将上面的错误信息发送到统一的监控平台。

步骤S107：使用Condition对象唤醒等待线程，并告知本次唤醒原因是超时。

步骤S108：将该记录从等待线程映射表移除。

步骤S109：延迟作业处理完成退出，归还线程给线程池。

参见图11，基于步骤S101至步骤S109，本发明还进一步提供基于分布式跨容器的异步转同步调用方法的更为具体的实施步骤：

步骤S201：收单系统中的容器A上的某个线程1(下面简称为线程1)在RPC服务调用外联系统的容器B上的某个线程2(下面简称为线程2)之前，先使用雪花算法生成事件ID，并把本次调用的事件ID作为KEY，本次调用的Condition对象、超时时间、存入时间、输入对象作为VALUE存入到等待线程映射表。同时设置一个延迟作业，由队列超时清理器调度，延迟时间与超时时间一致。

步骤S202：线程1异步调用线程2提供的服务，同时送入本次调用事件ID，还要求线程2回调时把该事件ID原样返回。

步骤S203：Condition对象使线程1进入睡眠状态，等待唤醒。

步骤S204：线程2处理完后，RPC异步调用收单系统中的容器C上的某个线程3(下面简称为线程3)的服务，同时把原事件ID原样返回。

步骤S205：线程3收到回调后，把结果存入数据库中，以备后续查询和分析问题使用。

步骤S206：线程3把事件ID送入通知发送队列中，结束流程。

步骤S207：通知发送器随着容器启动就启动，持续不断的从通知发送队列中取出数据。当取出为空时，则等待5毫秒后再去取；当取出有值时，则走步骤S208。

步骤S208：利用Kafka发布主题为TOPIC_ASYNTOSYN_SETX(X是数字，表示业务服务器组的编号)的信息。当发送成功后，将该事件ID从发送队列中移除；否则重试3次。重试3次后，若仍发送失败，则将该事件ID从发送队列中移除，打印并发送报警信息到统一监控平台。报警信息格式为：“当前服务为：XXX，事件ID为：XXX，发布信息失败”，其中XXX需要按照服务和事件ID进行实例化。

步骤S209：通知接收器订阅了主题为TOPIC_ASYNTOSYN_SETX的信息，当收到信息后，利用事件ID作为KEY值在等待线程映射表中查找。若找到跳转至步骤S211；否则进行步骤S210。

步骤S210：找不到该事件ID对应的记录，情况有两种：一是本次收到信息的时间晚于等待时间，记录已被队列超时清理器移除；二是订阅同一个主题的有多个容器，本次服务调用并不是发生在该容器上。此时直接将该事件ID忽略即可。

步骤S211：找到该事件ID对应的记录，从VALUE中取出该记录的Condition对象，利用Condition对象将线程1唤醒，并告知本次唤醒原因是已回调完成，最后将记录从等待线程映射表中移除。

步骤S212：该步骤是独立步骤，队列超时清理器随着容器启动就启动，每当延迟时间到达之后，队列超时清理器从线程池中取出线程调用作业。具体清理策略与图10所阐述的一样。

从上述描述可知，本发明提供了一种在分布式系统中出现跨容器的异步调用服务转变为同步调用服务的实现方法，利用分布式消息队列解决两个进程之间的通讯问题，减少等待线程在等待过程中消耗系统资源的问题。并通过线程间协作方式阻塞和唤醒等待线程，使得系统资源得到解放。

基于同一发明构思，本申请实施例还提供了一种基于分布式跨容器的异步转同步调用装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于基于分布式跨容器的异步转同步调用装置解决问题的原理与基于分布式跨容器的异步转同步调用方法相似，因此基于分布式跨容器的异步转同步调用装置的实施可以参见基于分布式跨容器的异步转同步调用方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现基于分布式跨容器的异步转同步调用方法的基于分布式跨容器的异步转同步调用装置的具体实施方式，参见图12，基于分布式跨容器的异步转同步调用装置具体包括如下内容：

数据写入模块10，用于利用系统内的第一容器中的线程将当前服务调用的事件ID以及线程信息写入等待线程映射表中；

线程调用模块20，用于根据所述事件ID以及所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内；

结果通知模块30，用于响应于所述第二容器中的线程的调用结果通知，根据所述第一容器中的线程在所述等待线程映射表中查找对应的等待线程信息。

一实施例中，在所述根据所述系统外的RPC服务内的线程调用第二容器中的线程；所述第一容器以及所述第二容器均在所述系统内之前：所述第一容器中的线程为睡眠状态；

一实施例中，参见图13，所述结果通知模块30包括：

结果写入单元301，用于将调用结果以及所述事件ID写入通知发送队列中；

通知告知单元302，用于根据所述通知发送队列告知所述第一容器中的线程所述调用结果通知；

信息查找单元303，用于在所述等待线程映射表中查找所述事件ID对应的等待线程信息。

一实施例中，参见图14，基于分布式跨容器的异步转同步调用装置还包括：

线程唤醒模块40，用于当在所述等待线程映射表中查找到所述事件ID对应的等待线程信息时，根据所述等待线程信息唤醒所述第一容器中的线程；

一实施例中，参见图15，基于分布式跨容器的异步转同步调用装置还包括：

超时通知模块50，用于当在预设时间段内没有收到所述第二容器中的线程的调用结果通知，删除所述等待线程映射表中的事件ID以及线程信息，并通知所述第一容器中的线程调用已超时。

从上述描述可知，本发明实施例提供的基于分布式跨容器的异步转同步调用装置，首先接收待升级应用的原生负载均衡模型以及目标镜像版本；确定原生负载均衡模型所对应的pod列表；根据pod列表修改pod文件中的镜像文件为目标镜像版本。本发明可以基于Kubernetes原生workload进行容器的原地升级，无需将基于Kubernetes原生负载模型部署的应用迁移至自定义负载模型，节省了应用迁移的工作量并避免了迁移带来的风险。另一方面，本发明节省了重新调度pod的时间，加快了升级速度。

下面参考图16，其示出了适于用来实现本申请实施例的电子设备600的结构示意图。

如图16所示，电子设备600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM))603中的程序而执行各种适当的工作和处理。在RAM603中，还存储有系统600操作所需的各种程序和数据。CPU601、ROM602、以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡，调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装如存储部分608。

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述基于数据机房场景下的人员距离确定方法的步骤，该步骤包括：

步骤100：接收待升级应用的原生负载均衡模型以及目标镜像版本；

步骤200：确定所述原生负载均衡模型所对应的pod列表；

步骤300：根据所述pod列表修改pod文件中的镜像文件为目标镜像版本。

在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上该仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。