微服务单元化路由的实现方法与流程

1.本技术涉及云服务技术领域，具体涉及一种微服务单元化路由的实现方法。


背景技术：

2.springcloud微服务架构体系内，微服务a调用微服务b时一般是通过客户端负载均衡器ribbon，从注册中心eureka中获取到的微服务b的可用实例列表中选择一个目标实例来转发请求的，不能基于用户标识等业务参数定向选择。如图1所示，来自用户甲、用户乙和其它用户的请求到达servicea后，被无差别的转发到后端serviceb实例上，不能按照用户选择不同的实例。服务servicea可以是一个边界服务也可以是一个服务网关。现在亟待解决的问题是如何面向不同用户选择不同的目标微服务实例实现微服务单元化路由。


技术实现要素：

3.本技术的目的是提供一种。为了对披露的实施例的一些方面有一个基本的理解，下面给出了简单的概括。该概括部分不是泛泛评述，也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念，以此作为后面的详细说明的序言。
4.根据本技术实施例的一个方面，提供一种1.一种微服务单元化路由的实现方法，其特征在于，包括：
5.部署微服务实例，为所述微服务实例打上路由元数据；
6.根据业务需要将对应于各用户的单元化路由规则配置到统一业务配置中心中；
7.从用户请求中获取用户标识，根据所述用户标识从所述统一业务配置中心查询对应于所述用户请求的单元化路由规则，将对应于所述用户请求的单元化路由规则加入到所述用户请求中，得到加入所述单元化路由规则的用户请求信息；
8.根据所述加入所述单元化路由规则的用户请求信息选择目标微服务实例。
9.进一步地，所述部署微服务实例，为所述微服务实例打上路由元数据，包括：
10.微服务发版时，将路由元数据打标到微服务实例上；其中，打标的方法设置在应用配置文件中，或者由运维发版平台在服务启动时加上元数据参数来进行设置。
11.进一步地，所述路由元数据的格式是routeunit＝gray，其中routeunit是所述路由元数据的key，gray是所述路由元数据的值。
12.进一步地，所述根据业务需要将对应于各用户的单元化路由规则配置到统一业务配置中心中，包括：
13.使用用户id或者开发者账号作为用户唯一标识，使用路由元数据为用户期望的微服务单元化路由目标。
14.进一步地，所述根据所述加入所述单元化路由规则的用户请求信息选择目标微服务实例，包括：
15.从eureka注册中心获得服务实例列表信息；所述服务实例列表信息中包含对应服
务实例上的路由元数据信息；
16.根据单元化路由规则，将满足单元化路由要求的服务实例过滤出来，形成可用实例列表；
17.选择一个实例作为目标微服务实例用于转发api请求；
18.转发api请求到目标微服务实例的同时，在所述api请求中加入路由元数据信息。
19.根据本技术实施例的另一个方面，提供一种微服务单元化路由的实现装置，包括：
20.部署模块，用于部署微服务实例，为所述微服务实例打上路由元数据；
21.配置模块，用于根据业务需要将对应于各用户的单元化路由规则配置到统一业务配置中心中；
22.查询加入模块，用于从用户请求中获取用户标识，根据所述用户标识从所述统一业务配置中心查询对应于所述用户请求的单元化路由规则，将对应于所述用户请求的单元化路由规则加入到所述用户请求中，得到加入所述单元化路由规则的用户请求信息；
23.选择模块，用于根据所述加入所述单元化路由规则的用户请求信息选择目标微服务实例。。
24.根据本技术实施例的另一个方面，提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的微服务单元化路由的实现方法。
25.根据本技术实施例的另一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述的微服务单元化路由的实现方法。
26.本技术实施例的其中一个方面提供的技术方案可以包括以下有益效果：
27.本技术实施例提供的微服务单元化路由的实现方法，能够面向不同用户选择不同的目标微服务实例实现微服务单元化路由，伸缩时无需启停现有微服务；路由规则的配置项能做到简单、动态、集中配置并能可视化管理；动态增减微服务实例个数无须修改或启停运行中的微服务系统；路由标记能够动态增减，能够很好地满足实际应用的需要。
28.本技术的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者，部分特征和优点可以从说明书中推知或毫无疑义地确定，或者通过实施本技术实施例了解。本技术的目的和其他优点可通过在所写的说明书、以及附图中所特别指出的结构来实现和获得。
附图说明
29.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
30.图1示出了现有技术的非单元化路由情况下微服务实例间在被选择时无差别的示意图；
31.图2示出了单元化路由情况下按照用户身份选择合适的微服务实例的示意图；
32.图3示出了本技术一个实施例的微服务单元化路由的实现系统的结构示意图；
33.图4示出了本技术一个实施例的微服务单元化路由的实现方法流程图；
34.图5示出了本技术一个实施例中的服务治理薄层的功能实现示意图；
35.图6示出了本技术一个实施例中的单元化路由规则和路由标识串起了用户和微服务实例的示意图。
具体实施方式
36.为了使本技术的目的、技术方案及优点更加清楚明白，下面结合附图和具体实施例对本技术做进一步说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
37.本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本技术所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。
38.微服务架构下，用户在直观可见的各种云服务上发起的一个操作，背后往往会触发数以百计的微服务实例间的相互调用。tob领域云服务一般要面对多用户场景。有些用户购买了很高的服务保障协议要求独享某些服务能力，有些用户的某类请求并发量大会挤占平台服务于其它用户的资源。云服务同时服务于大量用户，新研发的云服务新特性需要小范围验证后再逐步推广，这时需要选择一些用户试用新特性。这些场景都需要云服务背后的微服务实例集群具有单元化路由能力。
39.为了实现图2所示的按用户标识选择服务实例的目标，需要执行：
40.(1)在每个微服务实例打上某种标记从而把各微服务实例集群再细分成若干逻辑单元；
41.(2)通过将请求中包含的用户信息与微服务实例上的标记信息进行某种关联比较进而选择出合适的微服务实例进行路由。
42.目前存在一些基于在配置文件中配置路由mapping表的方式实现粗粒度用户单元化路由的方案。
43.例如：
44.vip标识 配置文件路由mapping表：
45.为不同的微服务实例单元分配不同的vip或域名来标识；
46.配置文件中为不同用户选择不同的vip地址或域名。
47.slb地址标识 配置文件路由mapping表：
48.上云后使用不同的slb来标识不同的微服务实例单元；
49.配置文件中为不同用户选择不同的vip地址或域名。
50.整体独立部署 nginx配置文件：
51.整套服务进行全复制的独立部署，方便识别最外侧边界服务；
52.nginx配置文件中为不同用户指定不同的边界服务入口。
53.发明人发现，基于配置文件路由mapping表的单元化路由技术方案，在伸缩时需要启停读部分重要微服务。微服务实例的标识信息没有在微服务实例运行时上，是通过ip：
port来标识不同微服务的。微服务实例发生增减时，首先要增减部署服务实例得到ip：port标识，然后通过修改vip或域名所指向的ip：port集合，最后为了生效需要重启读取路由mapping表的上游重要微服务。
54.服务间细粒度单元化路由难以实现无法做到一处配置处处生效。微服务架构下，微服务间相互调用是多层次的。针对每一个服务都设置vip或域名标识并针对用户配置路由mapping表是繁杂庞大的工作量，是不现实的。
55.路由单元动态增减不便，增减路由单元需要修改mapping表。集中可视化管理程度不高；从无到右接入单元化路由能力具有某种程度的代码侵入性。
56.如上这些缺点，导致基于配置文件的单元化解决方案实施成本高运维不便。
57.springcloud微服务架构体系的技术栈中，将微服务实例注册到eureka注册中心时可以为该实例提供附加metadata元数据；使用ribbon进行客户端负载均衡选择出目标微服务实例时是根据断言和过滤规则进行的，断言和过滤规则是可以定制扩展的。
58.本技术实施例的技术方案的目的是克服现有技术方案的诸多缺点，简单便捷地实现由不同微服务实例为不同用户的请求提供服务。
59.本技术实施例的技术方案的数据模型的基石正是eureka注册中心的实例metadata元数据，使用eureka metadata元数据进行微服务实例的标记；同时通过增加自定义断言和过滤规则来扩展ribbon负载均衡器功能使其具备单元化路由能力。
60.如图3所示，本技术一个实施例的微服务单元化路由的实现系统主要由统一业务配置中心、微服务治理控制中心、微服务治理薄层sdk和微服务注册中心eureka等组件组成。微服务治理控制中心组件用于对微服务治理薄层sdk下发控制信息。
61.如图4所示，本技术的一个实施例提供了一种微服务单元化路由的实现方法，包括步骤s1-步骤s4。
62.s1.部署微服务实例，为所述微服务实例打上路由元数据。
63.微服务发版时，将路由元数据，打标到微服务实例上。打标方法是多元的，可以在应用配置文件中设置，也可以也可以由运维发版平台在服务启动时加上元数据参数来进行设置。
64.路由元数据取值范围根据业务需要来统一规定，如：xiaomi，gray等。
65.路由元数据的格式是：routeunit＝gray，其中routeunit是元数据的key；gray等是元数据的值。
66.s2.根据业务需要将对应于各用户的单元化路由规则配置到统一业务配置中心中。
67.使用用户id(tenantid)或者开发者账号(appkey)作为用户唯一标识，使用路由元数据为用户期望的微服务单元化路由目标。
68.单元化路由规则的数据格式是：1000049822：gray，其中1000049821232是用户id，gray是选定的路由单元。
69.s3.从用户请求中获取用户标识，根据所述用户标识从所述统一业务配置中心查询对应于所述用户请求的单元化路由规则，将对应于所述用户请求的单元化路由规则加入到所述用户请求中，得到加入所述单元化路由规则的用户请求信息。
70.网关层从用户请求中获取用户标识，根据用户标识从配置中心查询该用户的单元
化路由规则，将这些路由规则以http header的方式加入到请求中。
71.如果查询到已配置的单元化路由规则，则记为routeuniit＝xxx，比如routeunit＝gray。
72.如果没有查询到则记为routeunit＝
“”
。
73.s4.根据所述加入所述单元化路由规则的用户请求信息选择目标微服务实例。
74.服务治理薄层选择目标微服务实例。如图5所示，服务治理薄层的功能实现示意图。
75.具体地，步骤s4包括以下步骤s401-步骤s406。
76.s401、从eureka注册中心获得服务实例列表信息。服务实例列表信息中包含对应服务实例上的路由元数据信息。比如routeunit＝gray。
77.s402、根据步骤s3确定的单元化路由规则，将满足单元化路由要求的服务实例过滤出来，形成可用实例列表。
78.本功能通过新建单元化路由专用断言器
79.microservicegraypredicate、microservicecompositepredicate实现。
80.s403、如果步骤s402选择出的可用实例列表为空，则重新对服务实例列表进行过滤。选择出没有设置路由信息或者路由信息是default的所有服务实例，形成可用实例列表，
81.s404、按照loadbanlanc规则选择1个实例作为目标微服务实例用于转发api请求。
82.s405、转发api请求到目标微服务实例的同时，在header中种入routeunit＝xxx信息，用于后续微服a调用微服务b时，依照相同规则选择微服务b的实例。本功能通过requestfactoryinterceptor拦截器实现，对发往服务实例的每一个clienthttprequest增加标识header。
83.s406、微服务b调用微服务c时，由于微服务b没有引入服务治理薄层sdk，虽然从微服务a处得到了routeunit＝xxx路由信息，微服务b在调用微服务c时是使用eureka客户端的默认方式选择微服务c的实例。
84.如图6所示，单元化路由规则和路由标识串起了用户和微服务实例的示意图，其中，租户即用户。
85.本技术实施例的方法支持从网关到微服务以及从微服务到微服务的全链路单元化路由。服务治理薄层是单元化路由寻址能力的具体担当者。基于服务治理薄层进行微服务单元化路由有如下特点：
86.代码非侵入，便于微服务接入，依赖一个jar包即可。不接入服务治理薄层，不影响api转发和处理的既有逻辑。接入服务治理薄层后，则在请求下游服务时，可以进行单元化路由。除单元化路由功能外，服务治理薄层可以支持各种服务治理功能。比如：微服务之间的受控访问功能，微服务之间的访问限流功能。一般来说api网关层可以统一对流入网关的请求进行鉴权限流等处理，但请求流经网关后，微服务之间的相互调用则比较随意。引入服务治理薄层，很好地补齐了网关后面的微服务间的治理短板。微服务治理薄层从微服务治理控制中心处读取控制信息并上报心跳和监控信息。
87.统一业务配置中心承担路由规则的统一配置和存储，系统内各服务均可读取。路由规则配置在用户维度上，是全系统统一的。使用eureka metadata(eureka元数据)作为微
服务实例上的单元化标记信息。
88.本发明的技术方案具有如下优点：能够面向不同用户选择不同的目标微服务实例实现微服务单元化路由，伸缩时无需启停现有微服务；路由规则的配置项能做到简单、动态、集中配置并能可视化管理；动态增减微服务实例个数无须修改或启停运行中的微服务系统；路由标记能够动态增减；服务实例接入单元化路由能力是非代码侵入的。应用本方法后，基于springccloud微服务架构体系构建起的业务处理系统可以感受到以下改变：能够根据用户标识将api请求路由到该用户专用的微服务实例上；能够通过单元化路由规则的配置，可进行动态线上流量调度。用于故障隔离或重点用户服务能力保障。
89.本技术的另一个实施例提供了一种微服务单元化路由的实现装置，包括：
90.部署模块，用于部署微服务实例，为所述微服务实例打上路由元数据；
91.配置模块，用于根据业务需要将对应于各用户的单元化路由规则配置到统一业务配置中心中；
92.查询加入模块，用于从用户请求中获取用户标识，根据所述用户标识从所述统一业务配置中心查询对应于所述用户请求的单元化路由规则，将对应于所述用户请求的单元化路由规则加入到所述用户请求中，得到加入所述单元化路由规则的用户请求信息；
93.选择模块，用于根据所述加入所述单元化路由规则的用户请求信息选择目标微服务实例。
94.在某些实施方式中，所述部署微服务实例，为所述微服务实例打上路由元数据，包括：
95.微服务发版时，将路由元数据打标到微服务实例上；其中，打标的方法设置在应用配置文件中，或者由运维发版平台在服务启动时加上元数据参数来进行设置。
96.在某些实施方式中，所述路由元数据的格式是routeunit＝gray，其中routeunit是所述路由元数据的key，gray是所述路由元数据的值。
97.在某些实施方式中，所述根据业务需要将对应于各用户的单元化路由规则配置到统一业务配置中心中，包括：
98.使用用户id或者开发者账号作为用户唯一标识，使用路由元数据为用户期望的微服务单元化路由目标。
99.在某些实施方式中，所述根据所述加入所述单元化路由规则的用户请求信息选择目标微服务实例，包括：
100.从eureka注册中心获得服务实例列表信息；所述服务实例列表信息中包含对应服务实例上的路由元数据信息；
101.根据单元化路由规则，将满足单元化路由要求的服务实例过滤出来，形成可用实例列表；
102.选择一个实例作为目标微服务实例用于转发api请求；
103.转发api请求到目标微服务实例的同时，在所述api请求中加入路由元数据信息。
104.本技术的另一个实施例提供了一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述任一实施方式所述的微服务单元化路由的实现方法。
105.本技术的另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程
序，该程序被处理器执行，以实现上述任一实施方式所述的微服务单元化路由的实现方法。
106.本技术的另一个实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机程序代码，该计算机程序代码存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序代码，处理器执行该计算机程序代码，使得计算机设备实现上述实施例的图像处理方法中所执行的操作。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
107.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。
108.需要说明的是：
109.术语“模块”并非意图受限于特定物理形式。取决于具体应用，模块可以实现为硬件、固件、软件和/或其组合。此外，不同的模块可以共享公共组件或甚至由相同组件实现。不同模块之间可以存在或不存在清楚的界限。
110.在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本技术也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本技术的内容，并且上面对特定语言所做的描述是为了披露本技术的最佳实施方式。
111.类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本技术的示例性实施例的描述中，本技术的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本技术要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本技术的单独实施例。
112.应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
113.以上所述实施例仅表达了本技术的实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术的保护范围应以所附权利要求为准。