[发明专利]一种微服务处理方法及设备

说明书

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

技术领域

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

背景技术

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

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

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

发明内容

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

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

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

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

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

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