CN111611089B - 一种基于异步的声明式的微服务调度方法 - Google Patents

Abstract

本发明公开了一种基于异步的声明式的微服务调度方法，旨在解决组合型微服务中所包含的各微服务间的过度依赖问题，避免因程序编译、重新发布造成的微服务暂停、下线的现象。该方法具体包括：以编写配置文件的方式构建组合型微服务，在配置文件中定义构成所述组合型微服务所需的所有微服务之间的调用关系；在访问者请求访问所述组合型微服务时，利用调度中心加载所述组合型微服务所对应的配置文件；通过调度中心解析所述组合型微服务的构成，生成具有包含关系的组合型微服务结构树；对结构树中所包含的微服务进行异步调用；将满足调用条件的微服务送入流水线执行；汇总流水线中的微服务执行完毕后产生的返回结果，写回缓存。

Description

一种基于异步的声明式的微服务调度方法

技术领域

本发明属于信息处理技术领域，具体地说，是涉及一种组合型微服务的构建及调度方法。

背景技术

为解决企业内部的网络融合、系统融合、业务融合以及企业之间的网络融合、系统融合、业务融合等问题，企业的系统架构模式逐步从传统的单体架构转换为微服务架构。微服务架构的主要作用是将应用的不同业务功能分散到离散的各个服务中，各个微服务可被独立部署，每个微服务只关注自身业务，从而降低系统的耦合性。

以包含有产品服务、订单服务、用户服务这三个业务模块的应用为例进行说明。在单体架构下，如图1所示，产品服务、订单服务、用户服务共同组成一个应用，各业务模块处于同一个应用中，使用同一个数据库。在微服务架构下，如图2所示，各业务模块相互分离，数据资源互相隔离、互不相同，产品服务、订单服务、用户服务通过http协议等通讯方式互相调用，向外提供服务。

企业业务初生阶段，业务简单，商业模式单一，使用单体架构开发应用更加简单，且能提高应用效率。然而，随着企业业务的发展，业务逐渐积累，业务复杂性逐渐凸显，单体架构的应用开发将显得过于臃肿。此时使用微服务拆分业务，可加速应用的开发、部署和维护。

对企业来说，传统的单体应用开发模式，使用单一的技术栈，由一个大的团队进行开发，无法在合适的领域使用合适的技术，同时大规模的团队也不利于管理以及团队间的沟通。而微服务架构可以使得每一个微服务由一个小团队进行维护，每一个团队可以有着各自的技术栈/代码风格。团队人员只需关注这一个微服务所对应的业务，选择合适的框架/技术进行开发，团队间的技术交流和沟通也更加便捷。

但是，在微服务架构下，服务呈网状分布，服务多且杂，服务数量可达数万个，由此导致服务间的调用关系变得复杂，往往存在以下问题：

①依赖问题：微服务架构下的服务间存在依赖关系，这种依赖关系可以概括为横向依赖关系和纵向依赖关系。其中，横向依赖关系是组合同一级别的服务，同一级别的服务互相依赖，例如若A业务同时调用B服务、C服务，D服务，则对于A服务来说，B服务、C服务、D服务构成A服务的横向依赖关系；纵向依赖关系是服务自身由多级不同服务构成，例如若A服务调用B服务，B服务又调用C服务，C服务再次调用D服务，构成一个服务调用链，则对于A服务来说，B服务、C服务、D服务构成A服务的纵向依赖关系。不同的依赖关系使得微服务间的调度变得十分复杂。对于由其他微服务组合形成的微服务，我们称之为组合型微服务。

②重复调用问题：当使用相同参数调用同一个微服务时，由于微服务是幂等的，因此所返回的结果是相同的。重复使用相同的参数调用同一个微服务将造成微服务资源的浪费。

③硬编码微服务的调用问题：当前组合型微服务大都是由程序代码实现，将调用逻辑直接写入源代码中，当更改业务需求后，需要重新编译源代码、重新测试、重新发布，在此过程中会造成微服务的停机，影响客户使用。

④性能问题：当组合型微服务横向依赖过多、纵向依赖过深，必然会造成整体系统的性能下降，程序结构复杂，对系统的使用和维护造成影响。

发明内容

本发明的目的在于提供一种基于异步的声明式的微服务调度方法，采用配置的方式创建组合型微服务，并以异步调度和流水线机制执行各微服务的功能，从而解决了组合型微服务中所包含的各微服务间的过度依赖问题，避免了因程序编译、重新发布造成的微服务暂停、下线的现象。

为解决上述技术问题，本发明采用以下技术方案予以实现：

一种基于异步的声明式的微服务调度方法，包括：以编写配置文件的方式构建组合型微服务，在配置文件中定义构成所述组合型微服务所需的所有微服务之间的调用关系；在访问者请求访问所述组合型微服务时，利用调度中心加载所述组合型微服务所对应的配置文件；通过调度中心解析所述组合型微服务的构成，生成具有包含关系的组合型微服务结构树；对结构树中所包含的微服务进行异步调用；将满足调用条件的微服务送入流水线执行；汇总流水线中的微服务执行完毕后产生的返回结果，写回缓存。

优选的，所述配置文件优选按照DSL语言规则编写，在所述配置文件中采用以下逻辑结构描述各微服务之间的调用关系：

name：命名，用于为组合型微服务命名；

serial：串行，用于上级微服务调用下级微服务；

parallel：并行，用于同级微服务间的调用；

condition：分支，用于对符合条件的微服务进行调用；

jump：循环，用于在条件成立的情况下跳转到指定的微服务循环执行；

break：跳出，用于跳出循环；

start：开始，用于在指定端口和hostname下发布组合型微服务；hostname为域名、ip或者主机名；

wait：等待，用于等待某一条件满足后进行下一步微服务调用；

end：结束，用于结束微服务的执行。

进一步的，在所述组合型微服务结构树中，父节点表示组合型微服务，叶子节点表示单一型微服务；在所述对结构树中所包含的微服务进行异步调用的过程中，包括：解析叶子节点；从作为叶子节点的微服务中解析出运行参数齐全的微服务，形成独立无依赖的微服务，直接调用；将需要其他微服务提供参数或者需要条件判断的微服务，形成有依赖的微服务，在其调用条件满足时再行调用。

又进一步的，在所述将满足调用条件的微服务送入流水线执行的过程中，包括：将独立无依赖的微服务直接送入流水线执行；对于有依赖的微服务，在等待其所依赖的微服务执行完毕后，通知调度中心，由调度中心传递参数，并在参数满足判断条件后，送入流水线执行。

优选的，所述调度中心优选利用多条流水线分别执行微服务，每一个微服务流水线操作是一个独立的的进程。

其中，所述多条流水线部署到不同的主机中，负责相关逻辑业务操作；或者在同一主机部署多条不同的流水线操作；多条流水线操作异步执行，微服务在空闲的流水线操作中执行，使多个微服务并行执行。

为了解决微服务的重复加载问题，本发明设计所述调用中心在将某一微服务送入流水线执行时，在此微服务中增加一个引用计数参数；所述引用计数参数在此微服务每次被调用时自动加1，在此微服务每次执行完毕后自动减1；当所述引用计数参数等于零时，调度中心将此微服务退出流水线。

为了解决微服务的重复调用问题，本发明设计所述调度中心在调用某一微服务时，对传入此微服务的参数是否已使用过进行判断，若使用过所述参数，则将所述参数在首次传入此微服务时此微服务所生成的返回结果直接反馈给调用者；若未使用过所述参数，则将所述参数传入此微服务执行，并将此微服务的返回结果与所述参数一起写回缓存。

优选的，所述调度中心在调用某一微服务时，优选对每次传入此微服务的参数均进行哈希运算，并将不同参数的哈希值写入缓存；同时，将此微服务在传入该参数时的返回结果写回缓存，使一个哈希值对应一个返回结果；所述调度中心在对传入此微服务的参数进行哈希运算后，首先将计算出的哈希值与缓存中已存储的哈希值进行对比；若存在相等的哈希值，则从缓存中直接调用该哈希值所对应的返回结果，无需再次调用此微服务。

优选的，所述调度中心在调度各微服务的过程中，微服务之间传递的参数或环境变量优选通过HTTP Header指定的格式进行传递。

与现有技术相比，本发明的优点和积极效果是：

（1）本发明以配置的方式创建组合型微服务，通过特定的DSL语义，将组合型微服务以配置文件的形式呈现，通过调度中心解析该配置文件，并执行该配置文件，从而实现了组合型微服务的热部署、热更新，方便了组合型微服务的发布、升级，解决了现有技术中采用编程语言硬编码构建组合型微服务时，因程序编译、重新发布造成的微服务暂停、下线的问题；

（2）本发明采用异步调度执行微服务功能配合基于配置的组合型微服务，实现了对组合型微服务的指令预分析和预加载，依赖调度中心的流水线执行能力，实现了对构成组合型微服务的各项服务的乱序执行能力，提升微服务系统的性能，解决了传统微服务架构中的组合型服务因横向依赖过多、纵向依赖过深所导致的系统性能下降的问题；

（3）本发明基于微服务接口的幂等特性（微服务传入的参数一致，则返回的结果一致），通过判断传入微服务接口的参数是否存在于缓存中，对于存在于缓存中的参数，采用直接从缓存中提取返回结果，不再对微服务进行再次调用的处理方式，从而解决了微服务架构中的服务被多次重复调用的问题，提升了微服务系统的性能。

结合附图阅读本发明实施方式的详细描述后，本发明的其他特点和优点将变得更加清楚。

附图说明

图1为单体架构下的应用构建图；

图2为微服务架构下的应用构建图；

图3为组合型微服务CMS01的逻辑结构示意图；

图4为组合型微服务CMS02的逻辑结构示意图；

图5为组合型微服务CMS03的逻辑结构示意图；

图6为组合型微服务CMS04的逻辑结构示意图；

图7为本发明所提出的基于异步的声明式的微服务调度方法的一种实施例的调度流程图；

图8为解析组合型微服务CMS01-CMS04的构成所生成的树状结构图；

图9为避免微服务二次调用所提出的调度流程图。

实施方式

下面结合附图对本发明的具体实施方式进行详细地描述。

微服务一般在公司业务发展到一定规模下、需求变化频繁的时候使用。例如电商平台业务量多、用户基数大、需要迭代速度快，当业务量上升时，微服务数量也将相应地增长，将会出现数万个微服务，微服务间的调用关系将会变得极其复杂。

为解决上述问题，本实施例设计调度中心并配合调度语音，以配置的方式创建组合型微服务，通过对组合型微服务中所包含的所有微服务采用异步调用，并基于流水线机制实现对各个微服务的乱序执行，从而有效地解决了微服务间的复杂调用关系，提升了微服务系统的性能。

下面结合图3-图8，对本实施例的基于异步的声明式的微服务调度方法进行具体阐述。

首先，以编写配置文件的方式构建组合型微服务。

在本实施例中，优选以领域专家语言DSL（Domain Special Language）作为调度语言，编写配置文件。

领域专家语言DSL的语法大多是自定义的，通过文本解析技术对编写的DSL进行解析。常见的DSL语言包括正则表达式、SQL语句、HTML、CSS等。它是根据某一特定领域的特点塑造的，为了解决抽象的问题，使用时，只需要声明规则、元素之间的层级和关系，没有计算和执行的概念。

本实施例在使用DSL进行配置时，优选定义以下逻辑结构描述各微服务之间的调用关系：

命名（name）：为组合型微服务命名；

串行（serial）：上级微服务调用下级微服务；

并行（parallel）：同级微服务间的调用；

分支（condition）：符合条件则进行微服务调用，yes()用于条件判断；

循环（jump）：在条件成立的情况下跳转到指定的微服务循环执行；

跳出（break）：跳出循环；

开始（start）：在指定端口和hostname下发布组合型微服务；hostname可以是域名，或者是ip，亦或者是主机名，可以使用正则表达式进行匹配；例如：域名：www.ouc.edu.cn，*.ouc.*；ip：192.168.137.2*；主机名：*ouc*，*newstar*；调度中心在hostname上部署组合型微服务，这些组合型微服务在接收到配置文件后，通过开放指定端口，提供可供访问的组合型微服务；

结束（end）：结束微服务的执行；

等待（wait）：等待某一条件满足后进行下一步微服务调用；over()监控某一微服务是否完成，微服务完成后通知调度中心，结束下一微服务的等待，调用下一微服务。

本实施例以MS作为组合型微服务的开头，用以上名称作为函数节点名称，进行链式调用。

下面通过一个具体的实例，描述配置文件的编写方式：

MS.name(CMS01).serial(S1).parallel(S2,S5,CMS03).wait(over(s2),serial(CMS02)).start(hostname01,9001)

MS.name(CMS02).serial(S6).serial(S9,name(loop1)).condition(yes(num==1),serial(S3)).condition(yes(num!=1),parallel(CMS03)).jump(yes(var<10),break(yes(time>5)),loop1).start(hostname02,9002)

MS.name(CMS03).parallel(S7,S10).start(hostname03,9003)

MS.name(CMS04).parallel(S4,S8).start(hostname04,9004)。

以上配置文件所描述的配置方式为：

组合型微服务CMS01：串行调用S1；并行调用S2、S5、CMS03；等待S2运行结束后，串行调用CMS02；在9001端口和指定的hostname01下发布组合型微服务CMS01，如图3所示。

组合型微服务CMS02：串行调用S6；串行调用S9并将此调用命名为loop1；判断条件(num==1)是否成立，若成立，则串行调用S3，否则（“num!=1”表示num不等于1），并行调用CMS04；判断条件(var<10)是否成立，若条件成立，则跳转到串行调用loop1的位置循环执行，并在条件(time>5)成立时，跳出循环；在9002端口和指定的hostname02下发布组合型微服务CMS02，如图4所示。

组合型微服务CMS03：并行调用S7、S10；在9003端口和指定的hostname03下发布组合型微服务CMS03，如图5所示。

组合型微服务CMS04：并行调用S4、S8；在9004端口和指定的hostname04下发布组合型微服务CMS04，如图6所示。

其中，S1-S10为在微服务注册中心注册的微服务名称；loop1 为跳转的标签名称；变量num、var、time为环境变量或参数，通过HTTP Header指定的格式进行传递。组合型微服务CMS01中所包含的所有微服务所需的参数全部给出，除CMS02外均可直接执行，CMS02中的微服务必须在S2执行完毕后才可执行；S3需要S9和S6的结果作为参数，CMS04需要S9的结果作为参数，且S3和CMS04均由DSL的配置进行判断。

其次，在微服务注册中心注册组合型微服务，例如在微服务注册中心注册CMS01、CMS02、CMS03、CMS04。

然后，根据访问者的访问请求，异步调用组合型微服务。

本实施例对组合型微服务中所包含的各个微服务采用异步调用、流水线机制乱序执行的调度方式，如图7所示，具体调度方法为：

S701、访问者向微服务注册中心发起访问组合型微服务MS的请求；

在本实施例中，访问者可以是用户，也可以是其他微服务。访问者可以将需要访问的组合型微服务的名称name发送给微服务注册中心，以请求访问在微服务注册中心上注册的该名称的组合型微服务MS。

S702、微服务注册中心将访问者所请求访问的组合型微服务MS的地址发送给访问者；

在本实施例中，所述地址即为发布该组合型微服务MS的hostname。

S703、访问者在指定端口访问hostname。

S704、调度中心加载访问者所请求访问的组合型微服务MS所对应的配置文件。

S705、调度中心根据配置文件解析组合型微服务MS的构成，生成仅具有包含关系的组合型微服务结构树；

图8为解析组合型微服务CMS01、CMS02、CMS03、CMS04所构成的结构树。其中，父节点表示组合型微服务，例如CMS01、CMS02、CMS03、CMS04；叶子节点表示单一型微服务，例如S1-S10。由图8可见，在本实施例的组合型微服务结构树中没有依赖关系，只有包含关系。

S706、解析叶子节点；

在本实施例中，可以将组合型微服务结构树中作为叶子节点的微服务构成一个微服务集合，例如{S1,S2,S3,S4,S5,S6,S7,S8,S9,S10}即为叶子节点的微服务集合。从微服务集合中，解析出运行参数齐全的微服务，形成独立无依赖的微服务，例如{S1,S2,S5,S7,S10}；剩余需要其他微服务提供参数或者需要条件判断的微服务，则形成有依赖的微服务，例如{ S3,S4,S6,S8,S9}。

S707、将满足执行条件的微服务送入流水线执行；

在本实施例中，调度中心对微服务集合中的微服务进行异步调用，将独立无依赖的微服务直接送入流水线执行，对于有依赖的微服务，则需要等待其所依赖的微服务执行完毕，通知调度中心，由调度中心传递参数，并在参数满足判断条件后，送入流水线执行。

以组合型微服务CMS01、CMS02、CMS03、CMS04为例进行说明：CMS02需要等待微服务S2执行完毕后执行；在调度中心中，判断DSL配置中的参数num，根据参数num选择执行微服务S3或CMS04。其中，微服务S3等待S6、S9的参数传递，CMS04等待S9的参数传递。在调度过程中，环境变量var、time的共享、参数以及上下文信息等均通过HTTP Header的信息进行传递。

作为一种优选实施例，调度中心优选利用多条流水线分别执行微服务，每一个微服务流水线操作是一个独立的的进程，可以部署到不同的主机中，负责相关逻辑业务操作。不同的主机可以拥有多个不同的流水线操作，多个流水线操作异步执行，微服务在空闲的流水线操作中执行，实现多个微服务的并行执行。

为了解决微服务重复加载的问题，本实施例设计调用中心在将微服务送入流水线执行时，在微服务中增加一个变量——引用计数参数。当一个调用者对此微服务进行调用时，将此微服务中的引用计数参数加1；当第二个调用者对此微服务进行调用时，将此微服务中的引用计数参数再加1；以此类推，由此可以避免此微服务被其他调用者在服务器上二次加载，影响性能。在此微服务执行完一次后，引用计数参数减1；执行完两次后，引用计数参数再减1；以此类推，直到引用计数参数等于零，将此微服务退出流水线。

S708、汇总流水线中的微服务产生的结果，写回缓存；

为了解决微服务重复调用的问题，本实施例设计服务接口采用rest风格的API提供服务调用，根据程序的幂等性，当传入微服务的参数相同时，其返回的结果也是相同的。

基于此，本实施例设计调度中心在调用某个微服务时，对传入此微服务的参数是否使用过进行判断，如果使用过该参数，则将该参数所对应的返回结果直接反馈给调用者，由此可以避免对微服务的多次执行，有利于提升微服务系统的性能。

具体可以采用以下判断及写回过程，结合如图9所示：

当调度中心调用某一微服务（例如微服务S2）时，调用的微服务参数优选以哈希值的形式存储，参数不变，哈希值是不会改变的；对每次的调用参数均进行哈希运算，并将计算出的哈希值写入缓存；同时，将此微服务在传入该参数时的返回结果写回缓存，一个哈希值对应一个返回结果；

在对每次调用的微服务参数进行哈希运算后，首先将计算出的哈希值与缓存中已存储的哈希值进行对比；若存在相等的哈希值，则可以直接从缓存中调用该哈希值所对应的返回结果，无需再次调用此微服务；

若缓存中不存在相等的哈希值，则首先判断此微服务是否在流水线中，若不在，则将此微服务送入流水线中执行，然后将调用参数传递给流水线中的此微服务，并待此微服务返回结果后，将调用参数的哈希值以及此微服务的返回结果一起写回缓存存储；若此微服务在流水线中，则可以直接将调用参数传递给流水线中的此微服务，无需二次加载，然后将调用参数传递给流水线中的此微服务，并待此微服务返回结果后，将调用参数的哈希值以及此微服务的返回结果一起写回缓存存储。

待组合微服务中的所有微服务执行完毕后，访问者可以在指定端口获取hostname的返回结果。例如若访问组合型微服务CMS01，则在可以在9001端口获取hostname01的返回结果。

可以采用本实施例的微服务调度方法形成一个微服务架构下的通用软件组件，负责解析“组合型微服务”的构成，并执行“组合型微服务”（执行过程是调用本“组合型微服务”中所包含的其他微服务）。此组件不直接面向企业的实际业务，面向的是微服务的开发者和微服务的维护者。微服务的开发者和微服务的维护者编写微服务提供面向企业的实际业务的微服务。

使用本实施例所提出的微服务调度方法开发的组合型微服务，可以解决传统微服务架构下组合型微服务中服务调用存在的横向依赖过多、纵向依赖过深、服务重复调用等问题。

当然，以上所述仅是本发明的一种优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种基于异步的声明式的微服务调度方法，其特征在于，包括：

以编写配置文件的方式构建组合型微服务，在配置文件中定义构成所述组合型微服务所需的所有微服务之间的调用关系；

在访问者请求访问所述组合型微服务时，利用调度中心加载所述组合型微服务所对应的配置文件；

通过调度中心解析所述组合型微服务的构成，生成具有包含关系的组合型微服务结构树；

对结构树中所包含的微服务进行异步调用；

将满足调用条件的微服务送入流水线执行；

所述调度中心在将某一微服务送入流水线执行时，在此微服务中增加一个引用计数参数；所述引用计数参数在此微服务每次被调用时自动加1，在此微服务每次执行完毕后自动减1；当所述引用计数参数等于零时，调度中心将此微服务退出流水线；

汇总流水线中的微服务执行完毕后产生的返回结果，写回缓存。

2.根据权利要求1所述的基于异步的声明式的微服务调度方法，其特征在于，所述配置文件按照DSL语言规则编写，在所述配置文件中采用以下逻辑结构描述各微服务之间的调用关系：

name：命名，用于为组合型微服务命名；

serial：串行，用于上级微服务调用下级微服务；

parallel：并行，用于同级微服务间的调用；

condition：分支，用于对符合条件的微服务进行调用；

jump：循环，用于在条件成立的情况下跳转到指定的微服务循环执行；

break：跳出，用于跳出循环；

start：开始，用于在指定端口和hostname下发布组合型微服务；hostname为域名、ip或者主机名；

wait：等待，用于等待某一条件满足后进行下一步微服务调用；

end：结束，用于结束微服务的执行。

3.根据权利要求1所述的基于异步的声明式的微服务调度方法，其特征在于，在所述组合型微服务结构树中，父节点表示组合型微服务，叶子节点表示单一型微服务；在所述对结构树中所包含的微服务进行异步调用的过程中，包括：

解析叶子节点；

从作为叶子节点的微服务中解析出运行参数齐全的微服务，形成独立无依赖的微服务，直接调用；

将需要其他微服务提供参数或者需要条件判断的微服务，形成有依赖的微服务，在其调用条件满足时再行调用。

4.根据权利要求3所述的基于异步的声明式的微服务调度方法，其特征在于，在所述将满足调用条件的微服务送入流水线执行的过程中，包括：

将独立无依赖的微服务直接送入流水线执行；

对于有依赖的微服务，在等待其所依赖的微服务执行完毕后，通知调度中心，由调度中心传递参数，并在参数满足判断条件后，送入流水线执行。

5.根据权利要求4所述的基于异步的声明式的微服务调度方法，其特征在于，所述调度中心利用多条流水线分别执行微服务，每一个微服务流水线操作是一个独立的的进程。

6.根据权利要求5所述的基于异步的声明式的微服务调度方法，其特征在于，所述多条流水线部署到不同的主机中，负责相关逻辑业务操作；或者在同一主机部署多条不同的流水线操作；多条流水线操作异步执行，微服务在空闲的流水线操作中执行，使多个微服务并行执行。

7.根据权利要求1至6中任一项所述的基于异步的声明式的微服务调度方法，其特征在于，所述调度中心在调用某一微服务时，对传入此微服务的参数是否已使用过进行判断，若使用过所述参数，则将所述参数在首次传入此微服务时此微服务所生成的返回结果直接反馈给调用者；若未使用过所述参数，则将所述参数传入此微服务执行，并将此微服务的返回结果与所述参数一起写回缓存。

8.根据权利要求7所述的基于异步的声明式的微服务调度方法，其特征在于，所述调度中心在调用某一微服务时，对每次传入此微服务的参数均进行哈希运算，并将不同参数的哈希值写入缓存；同时，将此微服务在传入该参数时的返回结果写回缓存，使一个哈希值对应一个返回结果；

所述调度中心在对传入此微服务的参数进行哈希运算后，首先将计算出的哈希值与缓存中已存储的哈希值进行对比；若存在相等的哈希值，则从缓存中直接调用该哈希值所对应的返回结果，无需再次调用此微服务。

9.根据权利要求1至6中任一项所述的基于异步的声明式的微服务调度方法，其特征在于，所述调度中心在调度各微服务的过程中，微服务之间传递的参数或环境变量均通过HTTP Header指定的格式进行传递。

Images