CN114021052B 一种推理服务方法、设备及系统 （度小满科技(北京)有限公司）

(19)国家知识产权局(12)发明专利(65)同一申请的已公布的文献号(73)专利权人度小满科技(北京)有限公司院西区4号楼6层606(72)发明人王少添(74)专利代理机构北京知帆远景知识产权代理有限公司11890专利代理师刘岩磊审查员刘莹一种推理服务方法、设备及系统本发明公开了一种推理服务方法，该方法中消息总线在接收到客户端发送的推理请求后，将其投入至与其服务类型对应的消息队列中，并向订阅该消息队列的服务实例发送新请求通知，服务实例在接收到新请求通知后可以根据自身的实际性能，包括负载情况以及可用性确定是否承接该请求，若可以承接，则从消息总线获取推理请求并处理。这一请求的处理过程中服务实例根据自身实际性能进行请求的承接，保证请求的均衡处理；而且当推理请求发送到消息总线后，请求可以在网络恢复后继续被处理，容错性高；同时各服务实例可以同时进行请求的承接以及处2消息总线接收到客户端发送的推理请求后，确定所述推理请求的服务类型；将所述推理请求添加至主题与所述服务类型相对应的消息队列中；向订阅所述消息队列的服务实例发送新请求通知，以便所述服务实例根据自身负载以及服务可用性接收或拒绝所述推理请求的处理；其中，在所述向订阅所述消息队列的服务实例发送新请求通知之后，所述方法还包括：在接收到服务实例发送的请求处理通知后，确定处理的请求，作为目标请求；向所述目标请求添加文件锁；在接收到请求处理完成通知后，将所述目标请求删除；在所述向所述目标请求添加文件锁之后，还包括：若所述目标请求的处理异常，解开所述目标请求的文件锁；其中，各所述服务实例根据自身负载从消息队列中读取若干推理请求，并同时批量处理各推理请求。2.一种消息总线，其特征在于，包括：若干设置有用于指示服务类型的主题的消息队所述消息总线用于：接收到客户端发送的推理请求后，确定所述推理请求的服务类型；将所述推理请求添加至主题与所述服务类型相对应的消息队列中；向订阅所述消息队列的服务实例发送新请求通知，以便所述服务实例根据自身负载以及服务可用性接收或拒绝所述推理请求的处理；其中，在所述向订阅所述消息队列的服务实例发送新请求通知之后，所述方法还包括：在接收到服务实例发送的请求处理通知后，确定处理的请求，作为目标请求；向所述目标请求添加文件锁；在接收到请求处理完成通知后，将所述目标请求删除；在所述向所述目标请求添加文件锁之后，还包括：若所述目标请求的处理异常，解开所述目标请求的文件锁；其中，各所述服务实例根据自身负载从消息队列中读取若干推理请求，并同时批量处理各推理请求。服务实例接收订阅的消息总线中的消息队列发送的新请求通知；其中，所述新请求通知为所述消息总线将客户端发送的推理请求添加至所述消息队列后触发；所述消息队列的主题与所述服务实例的推理服务类型相对应；根据自身负载以及服务可用性判断是否可以承接所述推理请求；若可以承接，从所述消息队列读取所述推理请求并进行推理处理；其中，在所述服务实例接收订阅的消息总线中的消息队列发送的新请求通知之后，所述方法还包括：在接收到服务实例发送的请求处理通知后，确定处理的请求，作为目标请求；向所述目标请求添加文件锁；在接收到请求处理完成通知后，将所述目标请求删除；在所述向所述目标请求添加文件锁之后，还包括：3若所述目标请求的处理异常，解开所述目标请求的文件锁；所述从所述消息队列获取所述推理请求并进行推理处理，包括：根据自身负载从所述消息队列中读取若干所述推理请求，并同时批量处理各所述推理处理器，用于执行所述计算机程序时实现如权利要求1或3所述推理服务方法的步骤。5.一种推理服务系统，其特征在于，包括：客户端、消息总线以及若干具有不同服务类型的服务实例；其中，所述客户端，用于接收用户发起的推理请求，并将所述推理去请求发送至所述消息总线；所述消息总线中包含若干消息队列，所述消息总线用于接收到所述推理请求后，确定所述推理请求的服务类型；将所述推理请求添加至主题与所述服务类型相对应的消息队列中；向订阅所述消息队列的服务实例发送新请求通知；所述服务实例，用于接收所述新请求通知；根据自身负载以及服务可用性判断是否可以承接所述推理请求；若可以承接，从所述消息队列获取所述推理请求并进行推理处理；其中，在所述向订阅所述消息队列的服务实例发送新请求通知之后，所述方法还包括：在接收到服务实例发送的请求处理通知后，确定处理的请求，作为目标请求；向所述目标请求添加文件锁；在接收到请求处理完成通知后，将所述目标请求删除；在所述向所述目标请求添加文若所述目标请求的处理异常，解开所述目标请求的文件锁；其中，各所述服务实例根据自身负载从消息队列中读取若干推理请求，并同时批量处理各推理请求。6.根据权利要求5所述的推理服务系统，其特征在于，还包括：与所述消息队列连接的服务管理器；所述服务管理器，用于服务管理器监听所述消息总线中各消息队列的请求处理速度，生成请求处理监听记录，根据所述请求处理监听记录对所述服务实例进行扩缩容处理。7.根据权利要求6所述的推理服务系统，其特征在于，所述服务管理器，具体用于：根据所述请求处理监听记录确定目标消息队列的请求处理速度；若所述请求处理速度低于第一阈值；添加与所述目标消息队列的主题相对应的服务类型的服务实例；若所述请求处理速度高于第二阈值；减少与所述目标消息队列的主题相对应的服务类型的服务实例；其中，所述第一阈值低于所述第二阈值。4技术领域背景技术[0002]模型主要用于对客户端提供的请求数据(比如文本、图片、视频等)进行计算，得出一个结果(比如分类，数值等),包括机器学习模型，深度神经网络模型等不同种类的模型。其中数据准备、特征提取、建模、训练以及部署等过程都需要强大的数据采集能力、数据处理能力以及分析能力、模型结构以及参数知识，专业性要求较强，而且对于部署的设备性能要求也较高，开发成本较高，部分企业或单位难以达到模型开发的条件，但是其仍需要模型自身强大的推理能力来满足自身数据处理的高精度要求，因此模型推理服务应运而生。[0003]模型推理服务指通过某种网络协议(比如http、grpc等),对外提供模型能力的服务，由客户端发起推理请求后，由模型推理服务中对应的服务实例(instance,即模型)响应该推理请求进行推理服务。现有在线模型推理服务为了能够同时提供多种模型服务以及满足高并发要求，通常采用代理结构，由代理服务器负责管理多种模型服务实例，使用路由算法将模型推理请求发送给空闲的服务实例(instance)。但是该种模式下代理服务器无法精准每个推理服务的实际容量和压力，在请求的分发中无法实现请求数量与服务实例自身处理能力的匹配，极易造成服务实例过载或空载的情况，增加了推理请求的平均耗时；同时也无法实时、准确地获得可用的推理服务，极易出现因为使用了错误地址而导致请求失败的情况；而且代理服务在一个请求处理完成后再下发下一个推理请求，整体请求处理效率低，如果网络故障或者推理服务故障，则会导致该推理请求失败，无法进入下一个推理请求的[0004]综上所述，如何保证推理请求分配的均匀合理性，提升推理请求的响应效率以及成功率，是目前本领域技术人员急需解决的技术问题。发明内容[0005]本发明的目的是提供一种推理服务方法、设备及系统，以保证推理请求分配的均匀合理性，提升推理请求的响应效率以及成功率。[0006]为解决上述技术问题，本发明提供如下技术方案：[0008]消息总线接收到客户端发送的推理请求后，确定所述推理请求的服务类型；[0009]将所述推理请求添加至主题与所述服务类型相对应的消息队列中；[0010]向订阅所述消息队列的服务实例发送新请求通知，以便所述服务实例根据自身负载以及服务可用性接收或拒绝所述推理请求的处理。[0011]可选地，在所述向订阅所述消息队列的服务实例发送新请求通知之后，还5[0013]向所述目标请求添加文件锁；[0014]在接收到请求处理完成通知后，将所述目标请求删除。[0016]若所述目标请求的处理异常，解开所述目标请求的文件锁。[0018]所述消息总线用于：接收到客户端发送的推理请求后，确定所述推理请求的服务类型；将所述推理请求添加至主题与所述服务类型相对应的消息队列中；向订阅所述消息队列的服务实例发送新请求通知，以便所述服务实例根据自身负载以及服务可用性接收或拒绝所述推理请求的处理。[0020]服务实例接收订阅的消息总线中的消息队列发送的新请求通知；其中，所述新请求通知为所述消息总线将客户端发送的推理请求添加至所述消息队列后触发；所述消息队列的主题与所述服务实例的推理服务类型相对应；[0021]根据自身负载以及服务可用性判断是否可以承接所述推理请求；[0022]若可以承接，从所述消息队列读取所述推理请求并进行推理处理。[0023]可选地，所述从所述消息队列获取所述推理请求并进行推理处理，包括：[0024]根据自身负载从所述消息队列中读取若干所述推理请求，并同时批量处理各所述推理请求。[0027]处理器，用于执行所述计算机程序时实现基于服务实例的所述推理服务方法的步骤。[0028]一种推理服务系统，包括：客户端、消息总线以及若干具有不同服务类型的服务实[0029]其中，所述客户端，用于接收用户发起的推理请求，并将所述推理去请求发送至所述消息总线；[0030]所述消息总线中包含若干消息队列，所述消息总线用于接收到所述推理请求后，确定所述推理请求的服务类型；将所述推理请求添加至主题与所述服务类型相对应的消息队列中；向订阅所述消息队列的服务实例发送新请求通知；[0031]所述服务实例，用于接收所述新请求通知；根据自身负载以及服务可用性判断是否可以承接所述推理请求；若可以承接，从所述消息队列获取所述推理请求并进行推理处[0033]所述服务管理器，用于服务管理器监听所述消息总线中各消息队列的请求处理速度，生成请求处理监听记录，根据所述请求处理监听记录对所述服务实例进行扩缩容处理。[0034]可选地，所述服务管理器，具体用于：根据所述请求处理监听记录确定目标消息队列的请求处理速度；若所述请求处理速度低于第一阈值；添加与所述目标消息队列的主题相对应的服务类型的服务实例；若所述请求处理速度高于第二阈值；减少与所述目标消息队列的主题相对应的服务类型的服务实例；其中，所述第一阈值低于所述第二阈值。6[0035]本发明实施例所提供的方法，将模型推理服务无状态、请求量波动较大的特点和消息总线易伸缩、高容错的优势相结合，将推理请求的分配由代理服务主动选择，变成由推理服务主动选择，消息总线在接收到客户端发送的推理请求后，将其投入至消息队列中，并向订阅该消息队列的服务实例发送新请求通知，指示存在新请求到达消息队列，服务实例在接收到新请求通知后可以根据自身的实际性能，包括负载情况以及可用性确定是否承接该请求，若可以承接，则从消息总线获取推理请求并处理。这一请求的处理过程中服务实例根据自身实际性能进行请求的承接，不存在由于不了解实际性能造成的过载和空载的问题，保证了负载均衡，同时也不存在不可用但承接请求的问题，请求处理的成功率高；而且当推理请求发送到消息总线后，即使由于网络故障，推理服务无法接收到请求，该请求也可以在网络恢复后继续被处理，容错性高；同时各服务实例可以同时进行请求的承接以及处[0036]相应地，本发明实施例还提供了与上述推理服务方法相对应的推理服务设备和系附图说明[0037]为了更清楚地说明本发明实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。[0038]图1为一种传统的代理结构示意图；[0039]图2为本发明实施例中一种推理服务方法的信令图；[0040]图3为本发明实施例中一种消息总线的结构示意图；[0041]图4为本发明实施例中一种计算机设备的结构示意图；[0042]图5为本发明实施例中一种推理服务系统的结构示意图；[0043]图6为本发明实施例中另一种推理服务系统的结构示意图。具体实施方式[0044]本发明的核心是提供一种推理服务方法，可以保证推理请求分配的均匀合理性，提升推理请求的响应效率以及成功率。[0045]为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。[0046]现有在线模型推理服务为了能够同时提供多种模型服务以及满足高并发要求，通例，以下简称为服务实例)以及服务管理器。[0047]基于上述代理结构的一次推理请求处理过程如下：[0049]2、代理服务器根据推理请求的推理服务类型查询服务管理器，获得该推理服务的7所有服务实例(每种推理服务可能存在多个服务实例);[0050]3、代理服务器根据负载均衡策略(例如随机选择，最少链接数，轮询RoundRobin等)使用路由算法将模型推理请求从所有实例中选择一个空闲的服务实例；[0055]而其中，代理服务器选择空闲服务实例时，代理服务器通常只能通过预先设置的性能规格(如每秒可处理请求数)以及当前正在处理的请求量对服务实例的负载量做大致判断。但是服务实例实际运行过程中，其处理能力是会变化的，可能低于或者高于预先配置的性能规格，因此代理服务器无法准确知道每个服务实例的实际容量和压力，因此无法实现准确地负载均衡，导致请求分配不均。而如果将请求转发给已经满载的服务实例，则会导[0056]而且，代理服务器需要从服务管理器对服务实例进行监控以及创建删除管理中生成服务注册表中获取服务实例的地址，但是由于网络同步延迟或失败、或者推理服务未能及时更新自身信息等因素，导致服务管理器监测生成的服务注册表的信息可能是不准确，或者非实时的。这样的情况下，服务实例就可能会因为使用了代理服务器返回的错误地址而导致请求失败。[0057]另外，代理服务器是以同步的方式处理推理请求的，即将推理请求发送给推理服务后，需要等待服务实例处理完成返回推理结果，将推理结果返回给客户端后才能启动第二个推理请求的响应。这一请求处理机制导致在多个推理请求处理时的处理时长较长；而且如果网络故障或者推理服务故障，则会导致该推理请求失败，无法进入下一个推理请求[0058]为解决传统方法中出现的推理请求分配不均、服务实例信息不准确以及处理耗时长、容错性较差等问题，本发明提出了一种推理服务方法，该方法采用的是基于消息总线的订阅和发布的方式，请参考图1,图1为本发明实施例中一种推理服务方法的信令图，该方法包括以下步骤：[0059]S110、客户端接收用户发起的推理请求，将推理请求发送至消息总线；[0060]推理请求由用户在客户端发起，推理请求中包含用户需要调用模型进行推理计算的数据对象(比如文本、图像、数据)以及需要调用的模型类型，当然，也可以包含其他类型的信息，本实施例中对于推理请求中包含的信息不做限定，足以指示服务实例完成推理服[0061]客户端接收到用户发起的推理请求后，将其发送至消息总线，将模型推理服务的特点(无状态，请求量波动较大)和消息总线的优势(易伸缩，高容错)相结合，可以有效地满足模型推理服务的动态变化，提升模型服务的资源利用率，同时提升模型推理服务的健壮[0062]S120、消息总线接收到客户端发送的推理请求后，确定推理请求的服务类型；[0063]消息总线可以接收来自任意客户端的推理请求，消息总线中包含多个消息队列的服务，每个消息队列对应一个主题(topiic)。生产方(即客户端)将推理请求发布(publish)8到某个主题(topic)的消息队列。消费方(即推理服务)订阅(subscribe)某个主题(topic)的消息队列，当该主题队列中有请求时，则获取请求并进行处理。[0064]具体地，在接收到某个客户端发送的推理请求后，根据推理请求中的信息确定当前推理请求所要请求服务的类型，即模型的类型或服务实例类型。确定推理请求的服务类型可以通过需要调用的模型类型来进一步分析确定，也可以在推理请求中设置响应的服务类型字段，则直接读取该字段内容即可，对于服务类型的确定方式本实施例中不做限定，可以根据实际使用需要进行相应设定。其中，服务类型的配置需与消息总线中消息队列的主题对应设置，以便根据服务类型就可以匹配到与服务类型对应的主题，从而定位到某个消息队列。而需要说明的是，一般来说服务类型与消息队列的主题可以一一对应设置，当然，与服务类型匹配的主题(或消息队列)也可以不止一个，与主题(或消息队列)匹配的服务类型也可以不止一个，具体地服务类型与主题间的匹配关系可以根据实际模型服务调用需求[0065]S121、消息总线将推理请求添加至主题与服务类型相对应的消息队列中；[0066]匹配到可以满足当前推理请求的服务类型后，将推理请求添加至匹配的服务类型相对应的消息队列中，比如匹配的主题为图像特征提取，而以图像特征提取作为主题的消息队列为消息队列1,则将该推理请求添加至消息队列1。一般向消息队列中添加信息是按照先入先出的规则，则将该推理请求添加至消息队列后，如果该消息队列中存储有其他未被处理完成的推理请求，则当前推理请求放置在队尾，在其他请求处理完成后才会处理，这一机制可以保障各个推理请求的处理时长平均化，不会出现等待时间过长的问题。[0067]S122、消息总线向订阅消息队列的服务实例发送新请求通知；[0068]服务实例与主题对应的消息队列建立订阅关系，则在该服务实例订阅的消息队列中存入新请求后，就会向订阅的服务实例发送新请求通知。新请求通知指示消息队列中存在新的推理请求，但可能并非只有新的推理请求，历史未处理的推理请求也可能排列其中，则空闲的各服务实例按照队列中请求的排列顺序依次拿取推理请求进行处理。[0069]S130、服务实例接收订阅的消息总线中的消息队列发送的新请求通知，根据自身负载以及服务可用性判断是否可以承接推理请求；[0070]订阅该主题(topic)的服务实例在接收到新请求通知后，该服务实例会根据自身的实际运行状态判断是否承接该推理请求，具体的运行状态主要是自身负载情况以及服务可用性两方面来判断。[0071]S131、服务实例若可以承[0072]若服务实例自身对于该推理请求的推理服务可用，则指示自身具有承接该服务请求的能力，进一步地，如果该服务实例处于空闲状态(包括无待处理的任务、处理能力超过目前待处理的任务量),即自身负载量较低，则服务实例就可以判定可以承接这个推理请[0073]反之，如果订阅该主题(topic)的服务实例自身对于该推理请求的推理服务不可用，或者，自身负载较大(处理能力已达到超过目前待处理的任务量),则可以不承接当前推理请求。而如果所有的推理服务都处于忙碌的状态无法承接该推理请求，则该主题(topic)的请求数量会堆积，该队列的处理速度变慢。[0074]本方法中对于推理请求的分配将传统方法中代理服务分配转换为由推理服务主9动选择，该种方法下，推理服务可以根据自身的实际性能从消息总线获取推理请求并处理，流量分配均匀，不存在过载和空载的问题。[0075]需要说明的是，在服务实例完成推理处理得到推理结果后，推理结果也会反馈至消息总线，由消息总线返回至客户端。对于结果返回的过程可以参照请求发送的过程，在此不再赘述。[0076]基于上述介绍，本发明实施例所提供的技术方案，将模型推理服务无状态、请求量波动较大的特点和消息总线易伸缩、高容错的优势相结合，将推理请求的分配由代理服务主动选择，变成由推理服务主动选择，消息总线在接收到客户端发送的推理请求后，将其投入至消息队列中，并向订阅该消息队列的服务实例发送新请求通知，指示存在新请求到达消息队列，服务实例在接收到新请求通知后可以根据自身的实际性能，包括负载情况以及可用性确定是否承接该请求，若可以承接，则从消息总线获取推理请求并处理。这一请求的处理过程中服务实例根据自身实际性能进行请求的承接，不存在由于不了解实际性能造成的过载和空载的问题，同时也不存在不可用但承接请求的问题，请求处理的成功率高；而且当推理请求发送到消息总线后，即使由于网络故障，推理服务无法接收到请求，该请求也可以在网络恢复后继续被处理，容错性高；同时各服务实例可以同时进行请求的承接以及处[0077]需要说明的是，基于上述实施例，本发明实施例还提供了相应的改进方案。在优选/改进实施例中涉及与上述实施例中相同步骤或相应步骤之间可相互参考，相应的有益效果也可相互参照，在本文的优选/改进实施例中不再一一赘述。[0078]在上述实施例的基础上，为进一步提升各服务实例从消息队列中承接任务的规范性，避免多个服务实例同时处理一个推理请求对计算资源的浪费等问题，在向订阅消息队列的服务实例发送新请求通知之后，可以进一步执行以下步骤：[0080]若服务实例判定自身可以承接该推理请求，则向消息总线发送请求处理通知，指示服务实例A处理推理请求B,消息总线接收到请求处理通知后，确定请求处理通知发送端要处理的请求(推理请求B),作为目标请求。[0081](2)向目标请求添加文件锁；[0082]为避免多个空闲服务实例同时对一个推理请求进行处理造成的资源浪费等问题，可以在接收到请求处理通知后立即对目标请求添加文件锁，保证第一个发起请求处理通知的服务实例可以独自处理该推理请求，而其他空闲的服务实例无法处理该推理请求，保证推理请求处理的唯一性。[0084]在服务实例完成某一推理请求的处理后，向消息总线发送请求处理完成通知，请求处理完成通知指示服务实例A完成对于目标请求(推理请求B)的处理，此时就可以将该目标请求从消息队列中删除，以避免消息队列中服务请求的堆积。[0085]而进一步地，为避免目标请求的处理陷入死循环，同时为了提升请求的处理效率，避免请求在队列中堆积，在向目标请求添加文件锁之后，可以进一步执行以下步骤：若目标请求的处理异常，解开目标请求的文件锁。[0086]若目标请求的处理异常，可以解开目标请求的文件锁，解开目标请求的文件锁后目标请求可以重新接受其他服务实例的承接处理(其他服务实例承接后也需要对其添加文件锁),以加速目标请求的处理流转。其中，目标请求处理异常的判定方式本实施例中不做限定，可以由服务实例向消息总线发送处理异常通知来确定，也可以由消息总线或其他设备对服务请求的处理过程进行监控，若发生某些异常或处理时间超出最大阈值，则判定异常。本实施例中仅以上述两种异常判定方式为例进行介绍，其他异常判定方式均可参照本[0087]上述实施例中各服务实例间可以同时从消息队列中获取推理请求并同时进行推理处理，各服务实例间推理请求的异步处理可以显著提升推理请求的整体处理速度。而为进一步提升推理请求的处理速度，从消息队列获取推理请求并进行推理处理的过程具体可以为：根据自身负载从消息队列中读取若干推理请求，并同时批量处理各推理请求。[0088]传统方法中代理服务(根据类型)将推理请求发送给对应的推理服务，(使用负载均衡的方法)将请求以均匀的方式发送给推理服务(每种类型的推理服务有多个实例),该种方式导致的结果就是，每个推理服务同时只处理一个请求。但是实际推理服务自身的处理能力是可以同时处理一批(多个)请求，并且耗时和同时处理一个请求的耗时是几乎一样个推理请求同时处理，这样可以充分利用模型服务资源，很好地缓解偶发的，瞬间请求量暴增的问题，显著提升推理服务的处理效率。[0089]相应于上面的方法实施例，本发明实施例还提供了一种消息总线，下文描述的消息总线与上文描述的推理服务方法可相互对应参照。[0090]如图3所示为本实施例提供的一种消息总线示意图，该消息总线中主要包括若干用于存储服务请求的消息队列，每个消息总线具有唯一的主题，主题用于指示存储的推理请求的服务类型。[0091]具体地，在该种设置下的消息总线具体用于：接收到客户端发送的推理请求后，确定推理请求的服务类型；将推理请求添加至主题与服务类型相对应的消息队列中；向订阅消息队列的服务实例发送新请求通知，以便服务实例根据自身负载以及服务可用性接收或拒绝推理请求的处理。该部分内容的介绍可以参照上述方法实施例的介绍，在此不再赘述。[0092]相应于上面的方法实施例，本发明实施例还提供了一种计算机设备，该计算机设备主要用于搭载服务实例，下文描述的一种计算机设备与上文描述的一种推理服务方法可相互对应参照。[0093]该计算机设备具体可以为服务器、计算机等，该计算机[0095]处理器，用于执行计算机程序时实现上述方法实施例的推理服务方法的步骤。[0096]具体的，请参考图4,为本实施例提供的一种计算机设备的具体结构示意图，该计算机设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits,CPU)322(例如，一个或一个以上处理器)和存储器332,存储器332存储有一个或一个以上的计算机应用程序342或数据344。其中，存储器332可以是短暂存储或持久存储。存储在存储器332的程序可以包括一个或一个以上模块(图示没标出),每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储器332通信，在计算机设备301上执行存储器332中的一系列指令操作。11[0097]计算机设备301还可以包括一个或一个以上电源326,一个或一个以上有线或无线网络接口350,一个或一个以上输入输出接口358,和/或，一个或一个以上操作系统341。[0098]上文所描述的推理服务方法中以服务实例作为执行主体的步骤可以由本实施例提供的计算机设备的结构实现。[0099]相应于上面的设备实施例，本发明实施例还提供了一种推理服务系统，下文描述的一种推理服务系统与上文描述的消息总线以及计算机设备可相互对应参照。[0100]一种推理服务系统，具体包括：客户端、消息总线以及若干具有不同服务类型的服务实例，如图5为一种推理服务系统结构示意图。[0101]其中，客户端主要用于与用户交互，接收用户发起的推理请求，并将推理去请求发送至消息总线；[0102]消息总线中包含若干消息队列，消息总线用于接收到推理请求后，确定推理请求的服务类型；将推理请求添加至主题与服务类型相对应的消息队列中；向订阅消息队列的服务实例发送新请求通知；具体的消息总线的结构以及工作过程可以参照上述消息总线实[0103]服务实例，用于接收新请求通知；根据自身负载以及服务可用性判断是否可以承接推理请求；若可以承接，从消息队列获取推理请求并进行推理处理。服务实例搭载于计算机设备中，具体地服务实例的工作过程以及搭载的设备结构也可以参照上述方法实施例以及计算机设备实施例的介绍，在此不再赘述。[0104]本实施例提供的推理服务系统中，通过客户端获取用户的推理请求，并将其发送至消息总线，消息总线在接收到客户端发送的推理请求后，将其投入至与推理请求的服务类型的消息队列中，并向订阅该消息队列的服务实例发送新请求通知，指示存在新请求到达消息队列，服务实例在接收到新请求通知后可以根据自身的实际性能，包括负载情况以及可用性确定是否承接该请求，若可以承接，则从消息总线获取推理请求并处理。这一过程可以与上述方法实施例相互对照。通过设置由客户端、消息总线以及若干具有不同服务类型的服务实例组成的推理服务系统，可以由消息总线实现服务实例主导的推理服务处理，保证请求的负载均衡性以及高效性。[0105]在一种实施例中，推理服务系统中可以进一步包括：与消息队列连接的服务管理器，服务管理器指根据某些外部条件(例如请求量监控数据、队列排队深度等),负责管理推理服务的创建，销毁及信息查询的设备，如图6所示为本实施例中提供的一种推理服务系统结构示意图。[0106]服务管理器连接于消息总线以及各服务实例，可以监听消息总线中各消息队列的请求处理速度，生成请求处理监听记录，根据请求处理监听记录对服务实例进行扩缩容处[0107]目前，传统方法下服务管理器根据代理服务中每个推理服务的请求量和请求处理时间，增加或者减少推理服务数量。而由于代理服务对于推理请求的分配存在不均匀，推理请求的平均耗时偏高，导致服务管理器不能准确地判断请求量的大小，无法准确的、实时的扩缩容(即增加或减少)推理服务数量。而且代理服务需要通过服务注册表才能获取推理服务的地址，但是由于网络同步延迟或失败，或者推理服务未能及时更新自身信息等因素，导致服务注册表的信息可能是不准确、或者非实时的，这样的情况下，推理服务实例的扩缩容周期较长，无法实时响应推理请求量的变化，可能在请求量已经下降之后才完成扩容，这时已经失去意义。[0108]而本实施例提供的服务管理器中根据消息总线上的待处理请求数量的变化趋势，可以准确地、实时地弹性增加或者减少模型服务实例。当请求数量出现堆积的趋势时，增加模型服务的实例数量，提升处理能力。当请求数量处理速度加快时，减少模型服务的实例数量，减少处理能力。由于是根据请求数量的变化趋势，这可以充分真实的反应每个模型