CN109582472A - 一种微服务处理方法及设备 - Google Patents

Abstract

本申请提供一种微服务处理方法及设备，应用于提供微服务的服务器，该方法包括：服务器接收来自消费微服务的终端的调用微服务的消息，其中，消息包括目标微服务的服务标识和接口标识；然后服务器根据所述目标微服务的服务标识和接口标识，确定出对应的目标线程池，最终调用目标线程池中的工作线程执行所述消息，该方法可以把故障影响范围限制在线程池中，避免扩散到整个微服务进程中，该方法硬件和运维成本低。

Description

一种微服务处理方法及设备

技术领域

本申请涉及终端技术领域，尤其涉及一种微服务处理方法及设备。

背景技术

微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模组化的方式组合出复杂的大型应用程序。各小型功能区块使用与语言无关的应用程序编程接口(application programming interface，API)(API也称为操作)相互通讯。

目前业务的服务化已经成为主流趋势，以客户关系管理(customer relationshipmanagement，CRM)开户业务为例，营业厅的一个开户流程会涉及到号卡资源查询、身份验证、套餐查询等数十个微服务的调用。为了保证核心服务的高质量运行，不同的微服务之间需要做故障隔离。当前业界微服务故障隔离的技术：按照核心服务和非核心服务等维度确定各个微服务的优先级，将不同优先级的微服务分别部署在不同的主机(或者虚拟机)上，以达到通过物理资源隔离实现不同服务的故障隔离的目的。

现有微服务故障隔离技术存在的问题是：由于同一个业务的微服务可能包含多个操作，例如订单微服务包括：订单创建、订单查询、订单修改和删除等，不同操作的重要性也可能不同，面临的故障场景也存在差异。虽然从部署上实现了不同微服务之间的故障隔离，同一个微服务的多个不同操作之间依然存在故障相互影响的问题。例如：数据库存在故障会导致订单创建失败，订单微服务所对应的业务的线程被阻塞，导致通过订单查询这一操作在消息队列中排队，得不到执行，最后订单查询这一操作也超时失败。如果再对微服务中的各个操作再按照操作优先级和重要性不同再拆分部署，例如，把订单微服务中的订单创建这一操作单独拆分为一个新的微服务，然后将这一新的微服务单独部署在一个主机上。因一个微服务通常有几十个操作，现有技术的这种部署方式会造成微服务的主机集群规模很大，成本太高而且运维成本(例如部署、升级和监控等)也很大。

发明内容

本申请提供一种微服务处理方法及设备，用以实现把某个操作的故障影响限制在操作对应的微服务所在主机或者虚拟机的线程池中，避免扩散到整个微服务对应的进程中，该方法硬件和运维成本低。

第一方面，本申请实施例提供了一种微服务处理方法，所述方法适用于提供微服务的服务器，该方法包括：服务器接收来自消费微服务的终端的调用微服务的消息，其中，消息包括目标微服务的服务标识和接口标识；然后服务器根据所述目标微服务的服务标识和接口标识，确定出对应的目标线程池，最终调用目标线程池中的工作线程执行所述消息。

本申请实施例中，该方法可以把故障影响范围限制在线程池中，避免扩散到整个微服务进程中，该方法硬件和运维成本低。

在一种可能的设计中，当确定不存在与所述目标微服务的服务标识和接口标识对应的目标线程池时，服务器确定与所述目标微服务的服务标识和接口标识对应的线程池配置参数。然后根据所述线程池配置参数创建所述目标线程池。

其中，线程池配置参数包括如下配置参数中的一个或任意多个：核心工作线程数、最大工作线程数、消息队列的容量上限以及线程池中待处理的消息达到消息队列的容量上限之后的执行策略。

本申请实施例中，线程池的主要作用是将微服务的不同接口调度到不同的线程池中执行，不同线程池的消息队列以及工作线程都是互相隔离的，这样处理比较慢的接口就不会影响其它处理较快的接口，非核心接口的故障也不会影响核心接口的执行，实现同一个微服务进程内部不同接口之间的故障隔离。

在一种可能的设计中，在所述服务器接收来自终端调用微服务的消息之前，还包括：根据所述服务器中微服务和接口的特征，配置与微服务的服务标识和接口标识对应的线程池配置参数；

根据所述线程池配置参数创建与微服务标识和接口标识对应的线程池，并保存微服务标识和接口标识与线程池之间的映射关系；

其中，所述特征包括以下任意一个或任意组合：响应快、响应慢、重要、不重要、管理类、非管理类，对其它微服务的接口有强依赖、对其它微服务的接口没有强依赖。

本申请实施例中，可以利用服务器的线程池，可以把故障接口的影响范围限制在某几个线程池中，避免扩散到整个微服务进程中。

在一种可能的设计中，将与微服务的服务标识和接口标识对应的线程池配置参数同步到注册中心服务器。

本申请实施例中，服务器利用服务的订阅发布机制，在原来的微服务实例信息基础之上增加微服务线程池配置策略信息，将配置策略自动同步到注册中心服务器，注册中心服务器新增线程池配置策略缓存表，将微服务接口对应的微服务线程池信息持久化到存储系统中。

第二方面，本申请实施例提供了一种微服务处理方法，所述方法适用于消费微服务的终端，该方法包括：终端确定与目标微服务的服务标识和接口标识对应的目标线程池；然后终端通过所述目标线程池向提供微服务的服务器发送调用微服务的请求，所述请求包括请求调用的目标微服务的服务标识和接口标识。

在一种可能的设计中，客户端从注册中心服务器获取与目标微服务的服务标识和接口标识对应的线程池配置参数；然后根据所述线程池配置参数创建目标线程池，并保存目标微服务标识和接口标识与目标线程池之间的映射关系。

本申请实施例中，线程池的主要作用是将微服务的不同接口调度到不同的线程池中执行，不同线程池的消息队列以及工作线程都是互相隔离的，这样处理比较慢的接口就不会影响其它处理较快的接口，非核心接口的故障也不会影响核心接口的执行，实现同一个微服务进程内部不同接口之间的故障隔离。

第三方面，本申请实施例提供了一种微服务处理方法，所述方法适用于注册中心服务器，该方法包括：接收来自提供微服务的服务器的注册信息，所述注册信息包括与微服务的服务标识和接口标识对应的线程池配置参数；然后保存所述注册信息。

本申请实施例中，服务器利用服务的订阅发布机制，在原来的微服务实例信息基础之上增加微服务线程池配置策略信息，将配置策略自动同步到注册中心服务器，注册中心服务器新增线程池配置策略缓存表，将微服务接口对应的微服务线程池信息持久化到存储系统中。

在一种可能的设计中，注册中心服务器接收来自消费微服务的终端的订阅注册信息的消息；然后将注册信息同步到所述终端。

本申请实施例中，终端可以从注册中心服务器获取到注册信息之后，在终端也同步创建线程池，将不同微服务的不同接口调用投递到不同的线程池中执行。

在一种可能的设计中，注册中心服务器接收来自所述服务器的注册信息变更的消息；同步所述变更之后的注册信息，并将所述变更之后的注册信息同步到所述终端。

本申请实施例中，由于注册中心服务器都有微服务信息的动态变更和通知机制，利用该机制，把微服务线程池配置参数的变更也加入到消息通知中，这样只要服务器修改了线程池配置参数，例如核心工作线程数，就可以自动同步到所有的终端，由终端刷新路由表，修改本地线程池的配置参数。这种动态变更机制的最大优点就是线程池配置参数变更不需要重启消费微服务的终端。

第四方面，本申请实施例提供一种服务器，包括处理器和存储器。其中，存储器用于存储一个或多个计算机程序；当存储器存储的一个或多个计算机程序被处理器执行时，使得该电子设备能够实现上述第一方面的任意一种可能的设计的方法，或者上述第三方面的任意一种可能的设计的方法。

第五方面，本申请实施例还提供一种装置，该装置包括执行上述第一方面的任意一种可能的设计的方法的模块/单元，或者第三方面的任意一种可能的设计的方法的模块/单元。这些模块/单元可以通过硬件实现，也可以通过硬件执行相应的软件实现。

第六方面，本申请实施例提供一种终端，包括处理器和存储器。其中，存储器用于存储一个或多个计算机程序；当存储器存储的一个或多个计算机程序被处理器执行时，使得该电子设备能够实现上述第二方面的任意一种可能的设计的方法。

第七方面，本申请实施例还提供一种装置，该装置包括执行上述第二方面的任意一种可能的设计的方法的模块/单元。这些模块/单元可以通过硬件实现，也可以通过硬件执行相应的软件实现。

第八方面，本申请实施例中还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得所述电子设备执行上述任一方面的任意一种可能的设计的方法。

第九方面，本申请实施例还提供一种包含计算机程序产品，当所述计算机程序产品在终端上运行时，使得所述电子设备执行上述任一方面的任意一种可能的设计的方法。

本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

图1为现有技术提供的一种故障隔离场景示意图一；

图2为现有技术提供的一种故障隔离场景示意图二；

图3为本申请实施例提供的一种故障隔离场景示意图一；

图4为本申请实施例提供的一种故障隔离场景的网络架构示意图；

图5为本申请实施例提供的一种服务器侧的微服务处理方法流程示意图；

图6为本申请实施例提供的一种终端侧的微服务处理方法流程示意图一；

图7为本申请实施例提供的一种终端侧的微服务处理方法流程示意图二；

图8为本申请实施例提供的一种故障隔离场景示意图二；

图9为本申请实施例提供的一种注册中心服务器侧的微服务处理方法流程示意图；

图10为本申请实施例提供的一种装置结构示意图；

图11为本申请实施例提供的一种服务器结构示意图；

图12为本申请实施例提供的一种装置结构示意图；

图13为本申请实施例提供的一种注册中心服务器结构示意图；

图14为本申请实施例提供的一种装置结构示意图；

图15为本申请实施例提供的一种终端结构示意图。

具体实施方式

下面将结合附图对本申请实施例作进一步地详细描述。本申请实施例中接口和操作是等价的概念，下文中将交替出现的操作和接口，可以作相同理解。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

需要说明的是，目前业务的服务化甚至是微服务化已经成为主流趋势。当应用程序(Application，APP)越来越多时，应用程序之间的交互不可避免。为此，通过按照功能模块划分，将核心业务抽取出来并作为独立的服务，可以提高系统的稳定性，使前端应用能够更快速的响应多变的市场需求，同时可以共享后端的公共能力，降低重复开发成本。

其中，微服务的主要特征如下：(1)、小且专注于做一件事情：每个微服务都是很小的应用，只关注一个业务功能；(2)、独立部署和管理：微服务独立打包和部署，支持独立的生命周期管理、升级和伸缩，运行在独立的进程中。(3)、异构性：微服务的实现与具体语言无关，微服务间的通信与具体的协议和序列化技术无关，微服务的提供端和微服务的消费端之间通过接口进行通信。这就意味着不同团队、不同业务模块可以基于不同的语言和技术进行构建。(4)、自治性：高内聚、松散耦合，暴露接口而隐藏实现细节，粒度小，独立部署和管理，更容易实现微服务的自治。

为了使本领域的技术人员更容易理解本申请实施例提供的技术方案对现有技术的改进，下面首先对现有技术进行简单的介绍。

现有技术为了实现微服务中的故障隔离，通常是按照各个微服务的重要性、发生故障的概率、微服务的执行速度等维度定义各个微服务的优先级，将不同优先级的微服务部署在不同的主机上，因不同的主机占用的物理资源不同，所以通过物理资源的隔离可以实现不同微服务的故障隔离。例如，如图1所示，微服务的提供端按照各个微服务的重要性、发生故障的概率、微服务的执行速度等维度，定义应用商店中的订单微服务、论坛微服务、评论微服务的优先级，将订单微服务做成可独立部署的微服务软件包，通过运维将该微服务软件包单独部署在一个主机(或者虚拟机)上，将论坛微服务和评论微服务做成可独立部署的微服务软件包，通过运维将该微服务软件包部署在另一个主机(或者虚拟机)上。这样通过物理资源隔离可以实现不同接口之间的故障隔离，即使订单微服务中的创建订单这一操作故障，也不会影响另一个主机(或者VM)上的论坛微服务和评论微服务。

但是现有微服务处理方法存在的问题是：订单微服务中所有操作的调用都是在同一个线程池中执行，若某个操作处理慢会导致后续调用该订单微服务中其它接口的消息在消息队列排队，导致线程池发生消息阻塞。如图2所示，手机侧的游戏中心应用中的订单微服务中可能包含多个操作，例如查询订单、创建订单、删除订单等，如果游戏中心应用的服务器侧的订单微服务的所有接口的调用都是在同一个工作线程池中执行，则当服务器侧创建订单这一操作的执行发生故障后，会导致后续调用其它操作的消息在消息队列排队，发生处理延时，即故障扩散到整个订单微服务的进程中。

另外，现有技术如果再对微服务中的各个操作再按照操作优先级和重要性不同拆分部署，如果拆分部署的粒度过细，则物理资源占用、升级部署和运维成本都会大幅增加，当业务规模比较大时，成本基本不可控。如果拆分部署的粒度过粗，则故障隔离效果比较差，微服务的可靠性还是无法得到有效的保障。

总结来说，现有技术存在如下几个缺点：(1)、部署成本高：为了提升故障隔离效果，需要对业务拆分的很细，以应用市场为例，需要将运营类、管理门户、应用分发、病毒检测、内容管理等业务进行细化拆分，微服务种类将达到300+个，如果每个微服务再根据操作的维度至少部署20个实例，采用双云+容灾部署之后，部署的微服务实例数将达到18000个，后续的升级和运维工作量都比较大。(2)、硬件资源利用率低：有些微服务平时流量比较小，例如运营类的评论管理微服务，但是为了实现故障隔离，还是把它们拆分出来独立部署，由于业务量不大，这些微服务所在主机资源占用率一直很低，导致资源利用率不高。(3)、拆分粒度很难均衡：同一个微服务的不同接口，发生故障的概率差别也很大，例如批量数据库操作相比于单条操作，更容易发生故障。查询类微服务接口相比于更新类接口，由于通过缓存而不是直接查询数据库，因此查询类接口可靠性会更高一些。当故障发生率高的接口和稳定的接口部署在一起时，故障也会互相影响，导致本来稳定的接口变得不稳定。如果把数据库批量和单条操作接口再做拆分，再加上查询和更新等维度，微服务的数量将与接口的数量级接近，成本太高。

为了解决上述问题，本申请提供一种微服务处理的方法，该方法是基于线程池来实现对微服务中的不同操作进行故障隔离。具体来说，提供微服务的服务器针对服务器上的每个微服务，对该微服务不同接口进行分类，主要是按照快、慢不同、重要性不同、管理类和非管理类、对其它微服务的接口是否有强依赖等维度进行分类，继而将该微服务的各个接口划分到不同的类型的接口集合中。服务器通过本地配置文件的方式配置不同接口集合所对应的线程池配置参数，其中线程池配置参数主要包括：线程池的核心工作线程数、最大线程数等。这样，当服务器启动时，就可以根据线程池配置参数创建与该微服务标识和接口标识对应的线程池，并缓存该微服务的服务标识和接口标识与线程池之间的映射关系。当服务器接收到消费微服务的终端调用微服务的消息之后，就根据需要消息中的目标微服务的服务标识和接口标识，从映射关系中查询到与目标微服务的服务标识和接口标识对应的目标线程池，最终调用目标线程池中的工作线程执行该消息，在服务器侧实现对微服务接口的故障隔离。示例性地，如图3所示，游戏中心应用的服务器侧把订单微服务的查询订单、创建订单、删除订单等接口分别划分成不同的类型的接口集合，查询订单对应线程池1，创建订单对应线程池2、删除订单对应线程池3。当线程池2中的创建订单的执行发生故障时，并不会影响到线程池1中的查询订单的执行和线程池3中的删除订单的执行。

本申请实施例所提供的微服务处理方法可以应用于如图4所示的网络架构。该网络架构主要涉及三侧设备：服务器、终端、注册中心服务器。

其中，服务器用于向终端提供微服务，终端用于消费服务器上的微服务，注册中心服务器用于负责微服务的订阅发布、微服务状态和版本变更通知等，除了保存微服务地址信息(例如服务器的IP地址和端口)，同时还保存了微服务的线程池配置参数，可以将微服务提供端的线程池配置参数同步到终端。

服务器包括线程池配置参数配置模块101、线程池创建模块102、线程池配置参数注册模块103、微服务执行模块104，具体功能如下：

1)线程池配置参数配置模块：通过微服务本地配置文件(例如YAML格式的文件)，以微服务接口的维度按照规划的线程池策略配置线程池参数，主要包括线程池的核心工作线程数、最大工作线程数、消息队列的容量上限以及线程池消息队列达到上限之后微服务接口的执行策略，具体策略包括：丢弃新的消息、丢弃排队最久的消息、同步阻塞等待有可用的工作线程等。

2)线程池创建模块：微服务启动时，加载并读取本地微服务线程池配置策略文件，按照线程池的参数配置创建微服务提供端线程池，同时缓存微服务接口与线程池的映射关系。

3)线程池配置参数注册模块：微服务启动之后，连接注册中心服务器，除了将微服务地址信息(IP地址和端口)写入到注册中心，同时将微服务接口与线程池的信息之间的映射关系也同步到注册中心，注册中心将微服务实例地址信息和映射关系持久化到线程池配置策略缓存表中。

4)微服务执行模块：微服务提供端接收到终端服务调用之后，根据调用的目标微服务的接口标识，从缓存中查询该接口对应的目标线程池，将消息投递到目标线程池中由工作线程执行。

注册中心服务器包括注册信息保存模块201，具体功能如下：在获取到服务器的注册信息之后，以微服务的服务标识和接口标识为Key(关键字)，线程池的配置参数为Value(结果)，将其保存到线程池配置参数缓存表中。

终端包括订阅模块301、线程池配置参数缓存模块302、线程池创建模块303，具体功能如下：

1)订阅模块：终端启动之后，根据需要调用的目标微服务，通过注册中心服务器的软件开发工具包(software development kit，SDK)连接到注册中心服务器，以目标微服务的服务标识查询目标微服务的地址信息、以及与目标微服务的服务标识和接口标识对应的线程池配置参数。

2)线程池配置参数缓存模块：终端的订阅模块从注册中心服务器获取到注册信息之后，以目标微服务的服务标识和接口标识作为Key，以线程池配置参数为Value，将映射关系缓存到本地的线程池配置参数缓存表中。

3)线程池创建模块：当终端调用进行微服务的接口时，根据需要调用的目标微服务的服务标识和接口标识从本地的线程池配置参数缓存表中查询对应的线程池配置参数。在微服务的接口首次调用时，终端根据线程池配置参数，在终端创建线程池，通过将不同接口的调用放在对应的线程池中发送至服务器，实现终端的故障隔离。

以下实施例均分别从服务器、终端、注册中心服务器这三侧，对本申请实施例所提供的微服务处理方法进行说明。

实施例一

本申请实施例提供一种微服务处理方法，该方法由提供微服务的服务器执行，该微服务处理方法具体过程参阅图5所示，包括：

步骤501，终端向服务器发送调用微服务的消息。

其中，所述消息包括请求调用的目标微服务的服务标识和对该目标微服务的操作类型对应的操作类型标识。例如手机侧安装有游戏中心应用，手机检测到用户作用于游戏中心应用中的炫舞手游(是一种收费应用)的下载购买这一控件的操作时，生成创建订单(订单是下载购买炫舞手游)的消息，该消息中目标微服务的服务标识则为订单微服务的名称，接口标识是创建订单这一名称。

步骤502，服务器确定与所述目标微服务的服务标识和接口标识对应的目标线程池。

其中，目标线程池包括N个工作线程，N为大于等于1的正整数。例如服务器确定与订单微服务和创建订单对应的目标线程池，其中，目标线程池中包括10个工作线程。

步骤503，服务器调用所述目标线程池中的N个工作线程执行所述调用微服务的消息。

也就是说，服务器执行创建订单这一操作是在目标线程池中执行的，即使创建订单这一操作处理较慢，也不会对服务器执行该目标线程池之外的查询订单或者删除订单的服务。

在执行步骤501之前，针对服务器中的每个微服务，服务器预先对该微服务的接口分类，根据所述服务器中微服务和接口的特征，配置与微服务的服务标识和接口标识对应的线程池配置参数；然后根据所述线程池配置参数创建与微服务标识和接口标识对应的线程池，并保存微服务标识和接口标识与线程池之间的映射关系。服务器启动成功之后，将与微服务的地址信息(例如主机的IP地址和端口)，以及微服务的服务标识和接口标识对应的线程池配置参数作为注册信息同步到注册中心服务器。

其中，特征包括以下任意一个或任意组合：响应快、响应慢、重要、不重要、管理类、非管理类，对其它微服务的接口有强依赖、对其它微服务的接口没有强依赖。例如，服务器按照响应快慢对订单微服务的查询订单、创建订单和删除订单进行分类，其中创建订单响应慢，查询订单和删除订单相对较快，因此服务器配置与订单微服务的创建订单对应的线程池配置参数，根据该线程池配置参数创建与订单微服务的创建订单对应的线程池。其中线程池配置参数包括如下配置参数中的一个或任意多个：核心工作线程数、最大工作线程数、消息队列的容量上限以及线程池中待处理的消息达到消息队列的容量上限之后的执行策略。

当服务器首次接收包括目标微服务的服务标识和接口标识的消息时，也就是当确定不存在与所述目标微服务的服务标识和接口标识对应的目标线程池时，先确定与所述目标微服务的服务标识和接口标识对应的线程池配置参数；然后根据所述线程池配置参数创建所述目标线程池。例如，服务器首次接收到来自终端调用订单微服务的消息，该消息中包括订单微服务的创建订单，因此服务器首先确定与订单微服务的创建订单对应的线程池配置参数，然后根据该线程池配置参数创建出来目标线程池。

进一步地，当服务器创建成功目标线程池之后，服务器缓存目标微服务的服务标识和接口标识与目标线程池的映射关系，并保存在目标微服务进程的本地内存中。

其中，线程池具体开发实现的配置策略示例如下：

executors:

Provider:

appgallery.showAppDetail:appGallery.ThreadPool

其中，executors表示采用线程池实现，Provider代表是提供微服务的服务器，appgallery.showAppDetail的格式是微服务名.接口名，冒号后面配置的是线程池名称。线程池线程池的具体配置示例如下(以Java语言为例)：

<bean id＝"appGallery.ThreadPool"

class＝"java.util.concurrent.ThreadPoolExecutor">

<property name＝"corePoolSize"value＝"3"/>

<property name＝"maxPoolSize"value＝"5"/>

<property name＝"queueCapacity"value＝"1000"/>

<property name＝"keepAliveSeconds"value＝"300"/>

<property name＝"rejectedExecutionHandler">

<bean class＝"java.util.concurrent.ThreadPoolExecutor$AbortPolicy"/>

</property>

</bean>

参数的具体含义说明如下：

corePoolSize：线程池的核心工作线程数，即使消息队列中没有任务需要处理，仍然维持这么多个工作线程保持存活状态。

maxPoolSize：最大工作线程数，当任务队列积压满之后，线程池会动态创建新的工作线程，直到线程数达到该值。

queueCapacity：消息队列的容量上限，超过容量上限的消息将不能被加入到任务队列中。

keepAliveSeconds：空闲线程的存活时间，如果达到最大工作线程数之后，积压的任务处理完，此时大于核心工作线程的工作线程会等待keepAliveSeconds秒，然后被销毁掉，以降低系统空闲时的资源开销。

rejectedExecutionHandler：任务队列满之后的执行策略，采用AbortPolicy为丢弃新的消息，并抛出任务执行拒绝异常RejectedExecutionException。

值得说明的是，线程池的主要作用是将微服务的不同接口调度到不同的线程池中执行，不同线程池的消息队列以及工作线程都是互相隔离的，这样处理比较慢的接口就不会影响其它处理较快的接口，非核心接口的故障也不会影响核心接口的执行，实现同一个微服务进程内部不同接口之间的故障隔离。另外线程池可以在用完之后释放，或者在需要用到的时候再次创建，也就是说内存资源可以重复使用，相比现有技术利用物理资源进行故障隔离，可以大大节约硬件成本。在实际业务中，微服务调用时延大、响应慢是最致命的问题，因为资源是有限的，当有限的工作线程资源都被阻塞在执行比较耗时的接口中时，其它耗时较短，本可以快速执行并返回结果的接口消息被阻塞在消息队列中，等待前面处理慢的接口执行完才有空闲的工作线程可用，这样就会发生慢接口阻塞快接口，故障接口影响正常接口。利用服务器的线程池，可以把故障接口的影响范围限制在某几个线程池中，避免扩散到整个微服务进程中。

实施例二

本申请实施例还提供一种微服务调度方法，该方法由消费微服务的终端执行，该微服务处理方法具体过程参阅图6所示，包括：

步骤601，终端确定与目标微服务的服务标识和接口标识对应的目标线程池。

步骤602，终端通过所述目标线程池向提供微服务的服务器发送调用微服务的请求。

其中，请求包括请求调用的目标微服务的服务标识和接口标识。

如图7所示，在执行步骤601之前，终端可以先执行步骤701，订阅注册中心服务器中的注册信息，再执行步骤702，从注册信息中查询与微服务的服务标识和接口标识对应的线程池配置参数和服务器地址信息。然后将目标微服务的服务标识和接口标识，以及对应的线程池配置参数缓存到本地路由表中，其中Key为目标微服务标识和接口标识，Value为微服务的实例信息，例如包含主机地址信息、线程池配置策略参数等。在微服务调用时，终端根据需要调用的微服务标识和接口标识，从本地路由表中查询线程池参数信息，然后根据线程池参数信息，创建与微服务标识和接口标识对应的线程池，生成微服务标识和接口标识与线程池的对应关系。这样，在执行步骤601时，终端可以从该映射关系中查询与目标微服务的服务标识和接口标识对应的目标线程池。

需要说明的是，终端也可以不通过注册中心服务器，而是直接从服务器获取与微服务的服务标识和接口标识对应的线程池配置参数和服务器地址信息。

在执行步骤601时，若终端判断是首次调用微服务标识和接口标识对应的接口，则需要创建目标线程池。也就是说终端从本地路由表中查询与之对应的线程池配置参数，然后根据线程池配置参数，创建目标线程池。

其中，终端的线程池的主要作用是：在终端创建线程池，将不同接口的微服务调用调度到不同的线程池中，这样当终端的某个微服务接口调用响应慢，或者发生故障时，不会影响对微服务其它接口的正常调用。

退一步来说，假设只有服务器创建了线程池，在服务器可以将不同接口的执行进行故障隔离，但是对于终端，由于可以调用服务器接口的工作线程资源有限，即便服务器已经将某个处理比较慢的接口隔离到了指定的线程池运行，但是慢的接口响应依然会慢，当终端调用到响应比较慢的接口时，线程资源就会被长时间的占用，直到服务器返回响应或者微服务调用超时。响应慢的接口调用会挤占终端工作线程资源，导致其它接口调用在队列排队等待，这样会导致终端的故障扩散，不同接口调用相互影响。

所以，本申请实施例中服务器侧配置了线程池之后，终端从注册中心服务器获取到注册信息之后，在终端也同步创建线程池，将不同微服务的不同接口调用投递到不同的线程池中执行，效果如图8所示。这样，终端的线程池和服务器的线程池配合工作，一个在服务器侧做故障隔离，对微服务不同接口的执行做隔离；另一个在终端工作，对不同接口的调用做故障隔离，通过二级故障隔离机制，更好的提升微服务的运行质量和可靠性。

实施例三

本申请实施例还提供一种微服务处理方法，该方法由注册中心服务器执行，该微服务处理方法具体过程参阅图9所示，包括：

步骤801，注册中心服务器接收来自服务器的注册信息。

其中，注册信息包括与微服务的服务标识和接口标识对应的线程池配置参数、微服务地址信息等。

步骤802，注册中心服务器保存所述注册信息。

例如，注册中心服务器将所述注册信息持久化到存储系统中(例如磁盘、DB等)，比如保存到线程池配置参数缓存表中。

其中，服务器启动成功后自动将与微服务的地址信息(例如主机的IP地址和端口)，以及微服务的服务标识和接口标识对应的线程池配置参数作为注册信息同步到注册中心服务器。注册中心服务器将提供微服务的服务标识和接口标识对应的线程池配置参数持久化到线程池配置参数缓存表中，以保证注册中心重启后线程池配置参数不丢失。当终端启动成功之后自动从注册中心服务器获取注册信息。

在一种可能的实现中，若服务器修改了线程池配置参数之后，则执行步骤803，将变更之后的线程池配置参数同步到注册中心服务器。注册中心服务器收到来自所述服务器的注册信息变更的消息之后，执行步骤804，更新本地持久化的线程池配置参数缓存表。然后注册中心服务器执行步骤805，向终端发送线程池配置参数变更通知消息，由终端主动获取变更之后的线程池配置参数，或者注册中心服务器将所述变更之后的注册信息同步到所述终端。

也就是说，服务器在本地配置线程池配置参数之后，利用服务的订阅发布机制，在原来的微服务实例信息基础之上增加微服务线程池配置策略信息，将配置策略自动同步到注册中心服务器，注册中心服务器新增线程池配置策略缓存表，将微服务接口对应的微服务线程池信息持久化到存储系统中(例如磁盘、DB等)。终端通过注册中心服务器订阅微服务提供者地址信息时，新增对线程池配置参数的订阅，根据目标微服务标识和接口标识获取到对应的线程池配置参数，然后缓存到本地路由表中。

本申请实施例中，由于注册中心服务器都有微服务信息的动态变更和通知机制，利用该机制，把微服务线程池配置参数的变更也加入到消息通知中，这样只要服务器修改了线程池配置参数，例如核心工作线程数，就可以自动同步到所有的终端，由终端刷新路由表，修改本地线程池的配置参数。这种动态变更机制的最大优点就是线程池配置参数变更不需要重启消费微服务的终端。

总结来说，本申请实施例基于线程池机制实现的微服务线程池，以线程粒度对微服务的不同接口做故障隔离，相比于传统采用物理机/虚拟机独立部署微服务做故障隔离方案，占用的硬件资源更少，部署、升级和运维成本更低。另外采用二级故障隔离技术，首先在提供微服务的服务器创建线程池，保证微服务各个接口的执行互相不干扰。其次在消费微服务的终端创建线程池，将不同微服务接口调用投递到指定线程池中执行，即使服务器有部分接口发生了时延大等故障，也不会导致终端其它接口调用受到影响。通过在微服务接口执行端和调用端做二级故障隔离，可以更有效的保障微服务的可靠性。

在本申请的一些实施例中，本申请实施例公开了一种用于提供微服务的装置，如图10所示，该装置用于实现实施例一中记载的方法，其包括：接收单元1001、处理单元1002。其中，接收单元1001用于支持该装置执行图5中的步骤501；处理单元3004用于支持该装置执行图5中的步骤502和步骤503。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

在本申请的另一些实施例中，本申请实施例公开了一种服务器，如图11所示，该服务器可以包括：一个或多个处理器1101；存储器1102、收发器1103，用于存储一个或多个微服务(未示出)；以及一个或多个计算机程序1104，上述各器件可以通过一个或多个通信总线1105连接。其中该一个或多个计算机程序1104被存储在上述存储器1102中并被配置为被该一个或多个处理器1101执行，该一个或多个计算机程序1104包括指令，上述指令可以用于执行如图5及相应实施例中的各个步骤。

在本申请的一些实施例中，本申请实施例公开了一种用于提供微服务注册功能的装置，如图12所示，该装置用于实现实施例三中记载的方法，其包括：接收单元1201、处理单元1202，发送单元1203。其中，接收单元1201用于支持该装置执行图10中的步骤801和步骤803；处理单元1202用于支持该装置执行图10中的步骤802和步骤804，发送单元1203用于支持该装置执行图10中的步骤805。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

在本申请的另一些实施例中，本申请实施例公开了一种注册中心服务器，如图13所示，该服务器可以包括：一个或多个处理器1301；存储器1302、收发器1303，用于存储一个或多个微服务(未示出)；以及一个或多个计算机程序1304，上述各器件可以通过一个或多个通信总线1305连接。其中该一个或多个计算机程序1304被存储在上述存储器1302中并被配置为被该一个或多个处理器1301执行，该一个或多个计算机程序1304包括指令，上述指令可以用于执行如图10及相应实施例中的各个步骤。

在本申请的一些实施例中，本申请实施例公开了一种用于消费微服务的装置，如图14所示，该装置用于实现实施例二中记载的方法，其包括：处理单元1401，发送单元1402。其中，处理单元1401用于支持该装置执行图6中的步骤601；发送单元1402用于支持该装置执行图6中的步骤602，其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

上述终端可以为手机、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digitalassistant，PDA)等终端设备，下面以终端为手机为例进行说明，图15示出的是与本发明各实施例相关的手机800的部分结构的框图。

如图15所示，手机1500包括：RF(radio frequency，射频)电路1501、Wi-Fi系统模块1502、存储器1503、输入单元1504、显示单元1505、处理器1506、音频电路1507以及电源1508等部件。本领域技术人员可以理解，图1500中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1500对手机1500的各个构成部件进行具体的介绍：

Wi-Fi系统模块1502用于扫描手机1500周围环境存在的Wi-Fi接入点，获取相关信息，以便手机1500根据所述相关信息接入所述Wi-Fi接入点。

RF电路1501用于收发信息或通话过程中信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1506处理。另外，将上行的数据发送给基站。在本申请实施例中，所述RF电路1501与Wi-Fi系统模块的Wi-Fi天线相连，控制Wi-Fi天线对Wi-Fi网络的扫描。通常，RF电路1501包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(lownoise amplifier，LNA)、双工器等。此外，RF电路1501还可以通过无线通信与网络和其他设备通信。

该存储器1503用于存储该手机1500的软件程序，例如游戏中心应用。通常，该存储器1503可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器1506是手机1500的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1503内的软件程序，以及调用存储在存储器1503内的数据，例如线程池配置参数，执行手机1500的各种功能和数据处理。

在本申请实施例中，该处理器1506执行存储器1503内的软件程序可实现上述方法实施例中提供的一种故障隔离的方法，具体参照上述方法实施例的描述，此处不再赘述。

其中，上述处理器1506可包括一个或多个处理单元；优选的，处理器1506可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1506中。

输入单元1504可用于接收输入的数字或字符信息，以及产生与手机1500的用户设置以及功能控制有关的键信号输入。具体地，输入单元1504可包括触摸屏以及其他输入设备。触摸屏也称为触控面板，可收集用户在其上或附近的触摸操作并根据预先设定的程式驱动相应的连接装置。其他输入设备可以包括但不限于物理键盘、功能键(比如音量控制按键、电源开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1505可用于显示由用户输入的信息或提供给用户的信息以及手机1500的各种菜单。显示单元1505可包括显示面板，可选的，可以采用液晶显示器(LiquidCrystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等形式来配置显示面板。

音频电路1507连接扬声器和麦克风，可提供用户与手机1500之间的音频接口。音频电路1507可将接收到的音频数据转换后的电信号，传输到扬声器，由扬声器转换为声音信号输出；另一方面，麦克风将收集的声音信号转换为电信号，由音频电路接收后转换为音频数据，再将音频数据输出至RF电路1501以发送给比如另一手机，或者将音频数据输出至存储器1503以便进一步处理。

手机1500还包括给各个部件供电的电源1508(比如电池)，优选的，电源可以通过电源管理系统与处理器1506逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机1500还可以包括蓝牙模块，传感器、GPS等，在此不再赘述。

本申请实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的微服务处理方法。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的微服务处理方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的微服务处理方法。

其中，本申请实施例提供的服务器、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

在本申请所提供的几个实施例中，应该理解到，所公开的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储数据的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种微服务处理方法，应用于提供微服务的服务器，其特征在于，所述方法包括：

接收来自终端调用微服务的消息，所述消息包括请求调用的目标微服务的服务标识和接口标识，所述终端用于消费所述服务器中的微服务；

确定与所述目标微服务的服务标识和接口标识对应的目标线程池，所述目标线程池包括N个工作线程，N为大于等于1的正整数；

调用所述目标线程池中的N个工作线程执行所述调用微服务的消息。

2.如权利要求1所述的方法，其特征在于，还包括：

当确定不存在与所述目标微服务的服务标识和接口标识对应的目标线程池时，确定与所述目标微服务的服务标识和接口标识对应的线程池配置参数；

根据所述线程池配置参数创建所述目标线程池；

其中，所述线程池配置参数包括如下配置参数中的一个或任意多个：核心工作线程数、最大工作线程数、消息队列的容量上限以及线程池中待处理的消息达到消息队列的容量上限之后的执行策略。

3.如权利要求1或2所述的方法，其特征在于，在所述服务器接收来自终端调用微服务的消息之前，还包括：

根据所述服务器中微服务和接口的特征，配置与微服务的服务标识和接口标识对应的线程池配置参数；

根据所述线程池配置参数创建与微服务标识和接口标识对应的线程池，并保存微服务标识和接口标识与线程池之间的映射关系；

其中，所述特征包括以下任意一个或任意组合：响应快、响应慢、重要、不重要、管理类、非管理类，对其它微服务的接口有强依赖、对其它微服务的接口没有强依赖。

4.如权利要求1至3任一项所述的方法，其特征在于，还包括：

将与微服务的服务标识和接口标识对应的线程池配置参数同步到注册中心服务器。

5.一种微服务处理方法，其特征在于，应用于消费微服务的终端，所述方法包括：

确定与目标微服务的服务标识和接口标识对应的目标线程池；

通过所述目标线程池向提供微服务的服务器发送调用微服务的请求，所述请求包括请求调用的目标微服务的服务标识和接口标识。

6.如权利要求5所述的方法，其特征在于，所述终端确定与目标微服务的服务标识和接口标识对应的目标线程池之前，还包括：

从注册中心服务器获取与目标微服务的服务标识和接口标识对应的线程池配置参数；

根据所述线程池配置参数创建目标线程池，并保存目标微服务标识和接口标识与目标线程池之间的映射关系。

7.一种微服务处理方法，其特征在于，应用于注册中心服务器，所述方法包括：

接收来自提供微服务的服务器的注册信息，所述注册信息包括与微服务的服务标识和接口标识对应的线程池配置参数；

保存所述注册信息。

8.如权利要求7所述的方法，其特征在于，还包括：

接收来自消费微服务的终端的订阅所述注册信息的消息；

将所述注册信息同步到所述终端。

9.如权利要求8所述的方法，其特征在于，

接收来自所述服务器的注册信息变更的消息；

同步所述变更之后的注册信息，并将所述变更之后的注册信息同步到所述终端。

10.一种提供微服务的服务器，其特征在于，包括一个或多个处理器和一个或多个存储器；

所述一个或多个存储器与所述一个或多个处理器耦合，所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，所述服务器执行如权利要求1至4任一项所述的微服务处理方法。

11.一种终端，其特征在于，包括一个或多个处理器和一个或多个存储器；

所述一个或多个存储器与所述一个或多个处理器耦合，所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，所述终端执行如权利要求5至6任一项所述的微服务处理方法。

12.一种注册中心服务器，其特征在于，包括一个或多个处理器和一个或多个存储器；

所述一个或多个存储器与所述一个或多个处理器耦合，所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，所述注册中心服务器执行如权利要求7至9任一项所述的微服务处理方法。

13.一种计算机存储介质，其特征在于，所述计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至9任一项所述的微服务处理方法。