服务治理组件参数配置装置及方法与流程

1.本发明涉及云计算技术领域，尤其涉及一种服务治理组件参数配置装置及方法。


背景技术：

2.本部分旨在为权利要求书中陈述的本发明实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.对于现有微服务架构系统而言，服务治理相关的功能往往会包含以下组件：熔断降级、服务限流、负载均衡等；以目前最为主流的微服务治理框架spring cloud举例，服务治理功能和实际使用的组件的关系对应关系见表1。
4.表1
5.功能常用技术实现熔断保护spring cloud hystrix或sentinel负载均衡spring cloud ribbon服务限流google guava或sentinel
6.上述的几个常用服务治理技术实现，基本都需要依赖于一些开源的公共库来实现相应的能力，而开源社区或者技术框架的原始提供者，出于通用性，可维护性等方面考虑，通常都是基于标准的服务模型，或者自定义的数据模型来进行参数的配置。
7.以spring cloud hystrix来实现一个对接口配置超时熔断保护来举例，如果需要针对某个后端服务配置接口在处理超过1秒之后立刻快速返回，按照官方的配置参数如下所示：
8.第一步，添加@hystrixcommand注解到后端接口的实现方法上，并且定义好超时的时间阈值；
[0009][0010][0011]
最后，通过编译构建打包成一个可执行的jar包或者war包，启动应用让配置参数生效；
[0012]
通过类似的工作流程和方法，也可以对负载均衡、服务限流等服务治理相关的参
数进行修改，并且通过重新打包构建发布进行生效；
[0013]
上述技术具有以下缺点：
[0014]
第一，配置参数项复杂，用户学习和使用门槛高。
[0015]
针对不同的服务治理参数配置，不同的治理方式，涉及到的参数配置项都是个性化的，例如熔断降级，如果是基于hystrix来实现该能力的话，则涉及到配置参数多达几十项，并且80％以上的参数项都是使用频率相对较低的，用户在配置的使用过程中对于一些核心参数的学习成本是极高的，相对来说整个服务治理能力也具备较高的使用门槛；而针对路由、负载均衡、限流等组件则是有更多更复杂的参数配置项，每一项参数配置如果配置错误则可能导致应用在调用过程中出现异常，因此开发者需要查阅大量的开发文档，无形之中又增加了整体开发成本；
[0016]
第二，配置方式过于通用，无法在金融场景下直接使用。
[0017]
大多数开源技术框架，例如spring cloud，包括其内部的服务治理组件spring cloud hystrix，spring cloud ribbon等，都是面向通用的场景设计的，因此在服务治理能力上，例如熔断降级，都是针对执行代码的方法为对象，或者是基于一些声明式的注解方式来配置；同样，针对负载均衡能力，原生的配置也是基于spring boot的启动配置，例如application.properties文件的方式进行配置；上述的这种通用配置方式，在多数的业务场景下并没有什么问题，但是在部分金融业务场景下，服务的概念并不是特别明显，反而是围绕着以“交易码”为核心的服务治理需求更加迫切，因此在金融场景下，实现熔断降级的能力，往往需要对开源的服务治理框架进行二次改造，适配成基于“交易码”的熔断降级配置，例如针对交易码a032521dq03配置请求的错误率或者超时时间来设定触发条件，更加符合用户的真实场景。
[0018]
第三，配置修改需要重启应用生效，更新流程过于繁琐。
[0019]
针对服务治理相关的配置参数，基本上可分为两类，第一类是在开发的代码里直接配置的，例如hystrix的基于方法注解形式的配置，可直接修改响应的注解参数即可；第二类是基于spring boot的application.properties文件，或者是jvm的启动参数来配置的，例如ribbon相关的路由及负载均衡的配置。
[0020]
上述的两类配置，第一类代码配置是需要用户重新对业务代码进行编译、构建、发布才能生效，而第二类启动参数的配置方式，则需要在修改后重启应用才能生效；对于一些本地开发的测试应用，该流程相对比较自主可控，但是对于一些线上的环境，配置变更会非常谨慎，在部分的公司内部可能还需要走流程审批等机制，整体的更新流程是非常复杂的，往往代价也是巨大的，稍有不慎，可能还会导致应用业务出现问题等，风险巨大；
[0021]
第四，配置存储分散，无法进行有效的统一管理。
[0022]
原生的微服务治理组件的配置默认都是在每个项目工程的application.properties文件里进行配置的，在分布式系统架构中，拆分后的服务可能会分散在不同物理机、虚拟机甚至是容器里，用户无法对这些配置进行统一的管控和配置，而且组件繁多，每个组件对应都有一份独立的配置，随着业务量增加，配置文件也会越来越长，变得难以维护；对于用户而言，往往需要一个统一的视图对这些资源配置进行统一的查看和修改，包括配置的当前设定值，需要有个集中式的地方可以方便管理，从而可以提升整体的运维效率。
[0023]
综上，目前需要解决金融业务场景下，针对微服务架构中各服务治理组件配置无法进行有效管理的问题，包括可视化的修改和下发，并且实时生效。


技术实现要素：

[0024]
本发明实施例提供一种服务治理组件参数配置装置，用以在金融业务场景下，实现对微服务架构中各服务治理组件进行可视化配置管理，且能够实时生效，该装置包括：
[0025]
配置管理可视化前端，用于在接收到参数配置请求后，输出基于交易码的服务目录；接收用于从所述基于交易码的服务目录中选中的交易码，输出所述交易码对应的参数配置界面；接收用户在所述参数配置界面输入的所述交易码对应的配置参数；
[0026]
配置管理服务端，用于将所述交易码对应的配置参数封装为请求，推送至业务应用端；
[0027]
业务应用端，用于在接收到请求后，对所述请求进行解析，获得交易码对应的配置参数；根据所述配置参数更新业务应用端的服务治理组件。
[0028]
本发明实施例还提供一种服务治理组件参数配置方法，用以在金融业务场景下，实现对微服务架构中各服务治理组件进行可视化配置管理，且能够实时生效，该方法包括：
[0029]
在接收到参数配置请求后，输出基于交易码的服务目录；
[0030]
接收用于从所述基于交易码的服务目录中选中的交易码，输出所述交易码对应的参数配置界面；
[0031]
接收用户在所述参数配置界面输入的所述交易码对应的配置参数；
[0032]
其中，所述交易码对应的配置参数被封装为请求，推送至业务应用端，所述业务应用端在接收到请求后，对所述请求进行解析，获得交易码对应的配置参数；根据所述配置参数更新业务应用端的服务治理组件。
[0033]
本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述服务治理组件参数配置方法。
[0034]
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述服务治理组件参数配置方法。
[0035]
本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述服务治理组件参数配置方法。
[0036]
本发明实施例中，配置管理可视化前端，用于在接收到参数配置请求后，输出基于交易码的服务目录；接收用于从所述基于交易码的服务目录中选中的交易码，输出所述交易码对应的参数配置界面；接收用户在所述参数配置界面输入的所述交易码对应的配置参数；配置管理服务端，用于将所述交易码对应的配置参数封装为请求，推送至业务应用端；业务应用端，用于在接收到请求后，对所述请求进行解析，获得交易码对应的配置参数；根据所述配置参数更新业务应用端的服务治理组件。与现有技术中依赖于一些开源的公共库来实现服务治理组件的参数配置的技术方案相比，通过配置管理可视化前端接收用户在所述参数配置界面输入的所述交易码对应的配置参数，避免了以往用户需要先学习不同的开发框架的配置定义，大大提高了研发效率，节省开发成本；配置管理服务端将所述交易码对应的配置参数封装为请求，推送至业务应用端，最后业务应用端根据所述配置参数更新业
务应用端的服务治理组件，具备实时下发生效的能力，避免了传统方式修改配置后至少需要重启应用才能更新的弊端，有效提升了整体的运维效率。
附图说明
[0037]
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
[0038]
图1为本发明实施例中服务治理组件参数配置装置的示意图；
[0039]
图2为本发明实施例中基于交易码的服务目录的结构示意图；
[0040]
图3为本发明实施例中交易码对应的参数配置界面的示意图；
[0041]
图4为本发明实施例中配置参数封装的示意图；
[0042]
图5为本发明实施例中服务治理组件参数配置方法的流程图；
[0043]
图6为本发明实施例中计算机设备的示意图。
具体实施方式
[0044]
为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。
[0045]
首先，对本发明实施例涉及的术语进行解释。
[0046]
服务治理：服务治理主要是针对分布式系统架构中，当一个单点应用按照不同的业务职责被拆分为多个独立的微服务应用之后，各个服务之间的远程调用需要有独立的机制来保证服务和服务之间请求调用的可靠性和稳定性，常用的治理包括熔断降级、服务限流、负载均衡等措施；
[0047]
熔断降级：为了防止服务调用链上由于某个服务或节点异常导致整个业务服务不可用的情况，也称之为雪崩效应，需要在调用链上的服务里加入一种保护逻辑，当发现后端的服务提供时间超时后，直接返回一些特定异常信息或者是默认的降级数据，这种机制称之为熔断降级；
[0048]
服务请求限流：当正常运行的业务系统由于一些促销活动等原因，导致服务提供方在短时间内收到大量的业务请求，由于服务资源的前期规划不合理性，或者是资源调度问题、扩容的不及时等原因，当流量集中汇聚之后存在将服务资源耗尽的风险，针对此类问题，通过在提供方的流量处理逻辑的最前端增加流量控制能力，通过削峰，整型等方式对流量进行控制，从而保护后端服务。
[0049]
图1为本发明实施例中服务治理组件参数配置装置的示意图，包括：
[0050]
配置管理可视化前端101，用于在接收到参数配置请求后，输出基于交易码的服务目录；接收用于从所述基于交易码的服务目录中选中的交易码，输出所述交易码对应的参数配置界面；接收用户在所述参数配置界面输入的所述交易码对应的配置参数；
[0051]
配置管理服务端102，用于将所述交易码对应的配置参数封装为请求，推送至业务应用端；
[0052]
业务应用端103，用于在接收到请求后，对所述请求进行解析，获得交易码对应的配置参数；根据所述配置参数更新业务应用端的服务治理组件。
[0053]
在本发明实施例中，与现有技术中依赖于一些开源的公共库来实现服务治理组件的参数配置的技术方案相比，通过配置管理可视化前端接收用户在所述参数配置界面输入的所述交易码对应的配置参数，避免了以往用户需要先学习不同的开发框架的配置定义，大大提高了研发效率，节省开发成本；配置管理服务端将所述交易码对应的配置参数封装为请求，推送至业务应用端，最后业务应用端根据所述配置参数更新业务应用端的服务治理组件，具备实时下发生效的能力，避免了传统方式修改配置后至少需要重启应用才能更新的弊端，有效提升了整体的运维效率。
[0054]
在金融行业的部分业务场景里，交易码是一个非常核心的概念，大部分的交易类的请求报文，都会在请求的数据中携带交易码的字段，用于指明当前的请求需要被后端哪个业务应用去处理；
[0055]
针对交易码去实现服务治理组件配置，首先需要有一个配置管理可视化前端，通过用户手工录入或者是文件导入的方式将交易码的参数配置元数据存放至配置管理可视化前端上，形成基于交易码的服务目录，从而用户可以在后续的配置过程中直接选择目标交易码进行参数配置。
[0056]
在一实施例中，所述基于交易码的服务目录为层级树状结构。
[0057]
图2为本发明实施例中基于交易码的服务目录的结构示意图，所述服务目录的层级树状结构中，一个服务对应有一个或者多个交易码，代表该服务支持处理这些特定的交易码报文；通过层级树状结构，更加符合人脑的理解认知，也方便记忆和快速查找，从而有效提高了用户在服务治理过程中对服务和交易码的管理效率。
[0058]
前述提到，大多数开发过程中，服务治理组件相关的参数都是通过编码形式，或者是通过启动配置文件的形式设置的，其中一个最大的问题就是用户在开发过程中，对于这些参数的学习和理解成本很高；
[0059]
随着信息化系统的普及，以及产品可视化交互的快速发展，在实际的服务治理产品化落地过程中，如果降低用户的服务治理使用难度成了必不可少需要思考的问题。
[0060]
以限流的能力举例说明，在金融场景下，限流的资源控制粒度往往是基于交易码的，而不是服务或者其它的维度，因此在实际编码的时候，大致的处理逻辑如下所示：
[0061]
list《flowrule》rules＝new arraylist《flowrule》()；
[0062]
flowrule rule＝new flowrule()；
[0063]
rule.setresource("a032521dq01")；
[0064]
//set limit qps to 100
[0065]
rule.setcount(100)；
[0066]
rule.setgrade(ruleconstant.flow_grade_qps)；
[0067]
rules.add(rule)；
[0068]
flowrulemanager.loadrules(rules)；
[0069]
上述设计基本上需要考虑两部分，首先是对于限流的资源控制粒度范围进行设定，其次是针对限流的详细阈值参数进行控制，最终需要调用框架的设置接口来让规则生效，用户需要对第三方的框架sdk使用非常熟悉，并且了解内部的各个相关参数的含义，才
能进行有效的编码；
[0070]
而基于交易码的可视化服务治理配置，则是基于一个图形化的页面进行操作的。
[0071]
配置管理可视化前端接收用于从所述基于交易码的服务目录中选中的交易码，输出所述交易码对应的参数配置界面，图3为本发明实施例中交易码对应的参数配置界面的示意图，通过设计可视化的参数配置界面，用户无需理解hystrix或者sentinel等限流能力的服务治理组件的具体参数配置定制，也无需在服务层面考虑具体的请求流量匹配方式，只需要针对交易码维度配置好参数，就能够实现相关的限流能力。
[0072]
主流的服务治理相关开发框架，都是基于一些通用的java方法或者是api接口来进行设置，而交易码是在金融行业特定的元信息，无法直接通过开发框架来实现基于交易码的规则配置，因此需要对配置的参数进行封装，并且暴露基于交易码的配置接口，从而提供特色化的使用方式，用于降低用户的使用门槛。
[0073]
图4为本发明实施例中配置参数封装的示意图。如图4所示，在第三方服务治理组件的上层进行二次封装，在一实施例中，配置管理服务端具体用于：将所述交易码对应的配置参数封装到请求的header里；或将所述交易码对应的配置参数封装到请求的body字段里。
[0074]
封装时，具体的数据格式是json还是xml，最终只要能通过请求解析获取到交易码的原始数据即可。
[0075]
在一实施例中，所述配置参数包括规则名称、服务名称、限流方式、限流阈值和限流返回方式中的其中一种或任意组合。
[0076]
在一实施例中，配置管理服务端具体用于：
[0077]
采用长连接机制将请求推送至业务应用端，所述长连接机制基于grpc实现或基于tcp方式实现。
[0078]
在上述实施例中，基于grpc实现的长连接机制实现的成本更低，只需要定义好相互之间的通信协议，即可通过grpc原生的代码生成工具生成不同开发语言的sdk实现，快速就能够实现跨语言能力。
[0079]
业务应用端在接收到请求后，对所述请求进行解析，获得交易码对应的配置参数；根据所述配置参数更新业务应用端的服务治理组件。
[0080]
在一实施例中，配置管理服务端具体用于：
[0081]
将请求加密后推送至业务应用端；
[0082]
业务应用端具体用于：在对所述请求进行解析之前，对请求进行解密。
[0083]
另外，涉及到比较大的配置参数，配置管理服务端可以对请求进行压缩，业务应用端收到请求后，进行解压。
[0084]
其中，对所述请求进行解析的可以通过配置解析器进行，获得交易码对应的配置参数之后，最终可由独立的配置更新器，将其更新到特定的业务应用，例如服务治理组件的熔断、限流、负载均衡或者分流等等，从而实现了配置的可视化编辑到实时推送，并且实时更新的全流程控制。
[0085]
综上所述，本发明实施例提出的装置具有以下有益效果：
[0086]
(1)基于交易码的服务目录，大大降低了用户进行参数配置元数据的管理成本；
[0087]
(2)通过所述交易码对应的参数配置界面可直接设置参数，避免了以往用户需要
先学习不同的开发框架的配置定义，大大提高了研发效率，节省开发成本；
[0088]
(3)业务应用端根据所述配置参数更新业务应用端的服务治理组件，具备实时下发生效的能力，避免了传统方式修改配置后至少需要重启应用才能更新的弊端，有效提升了整体的运维效率。
[0089]
本发明实施例中还提供了一种服务治理组件参数配置方法，如下面的实施例所述。由于该装置解决问题的原理与服务治理组件参数配置装置相似，因此该方法的实施可以参见服务治理组件参数配置装置的实施，重复之处不再赘述。
[0090]
图5为本发明实施例中服务治理组件参数配置方法的流程图，包括：
[0091]
步骤501，在接收到参数配置请求后，输出基于交易码的服务目录；
[0092]
步骤502，接收用于从所述基于交易码的服务目录中选中的交易码，输出所述交易码对应的参数配置界面；
[0093]
步骤503，接收用户在所述参数配置界面输入的所述交易码对应的配置参数；
[0094]
其中，所述交易码对应的配置参数被封装为请求，推送至业务应用端，所述业务应用端在接收到请求后，对所述请求进行解析，获得交易码对应的配置参数；根据所述配置参数更新业务应用端的服务治理组件。
[0095]
在一实施例中，所述基于交易码的服务目录为层级树状结构。
[0096]
在一实施例中，将所述交易码对应的配置参数封装为请求，包括：
[0097]
将所述交易码对应的配置参数封装到请求的header里；
[0098]
或将所述交易码对应的配置参数封装到请求的body字段里。
[0099]
在一实施例中，所述配置参数包括规则名称、服务名称、限流方式、限流阈值和限流返回方式中的其中一种或任意组合。
[0100]
在一实施例中，采用长连接机制将请求推送至业务应用端，所述长连接机制基于grpc实现或基于tcp方式实现。
[0101]
在一实施例中，所述方法还包括：
[0102]
将请求加密后推送至业务应用端；
[0103]
在对所述请求进行解析之前，对请求进行解密。
[0104]
综上所述，本发明实施例提出的方法的有益效果如下：
[0105]
(1)基于交易码的服务目录，大大降低了用户进行参数配置元数据的管理成本；
[0106]
(2)通过所述交易码对应的参数配置界面可直接设置参数，避免了以往用户需要先学习不同的开发框架的配置定义，大大提高了研发效率，节省开发成本；
[0107]
(3)业务应用端根据所述配置参数更新业务应用端的服务治理组件，具备实时下发生效的能力，避免了传统方式修改配置后至少需要重启应用才能更新的弊端，有效提升了整体的运维效率。
[0108]
本发明实施例还提供一种计算机设备，图6为本发明实施例中计算机设备的示意图，所述计算机设备600包括存储器610、处理器620及存储在存储器610上并可在处理器620上运行的计算机程序630，所述处理器620执行所述计算机程序630时实现上述服务治理组件参数配置方法。
[0109]
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述服务治理组件参数配置方法。
[0110]
本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述服务治理组件参数配置方法。
[0111]
综上所述，本发明实施例提出的计算机设备、计算机可读存储介质、计算机程序产品的有益效果如下：
[0112]
(1)基于交易码的服务目录，大大降低了用户进行参数配置元数据的管理成本；
[0113]
(2)通过所述交易码对应的参数配置界面可直接设置参数，避免了以往用户需要先学习不同的开发框架的配置定义，大大提高了研发效率，节省开发成本；
[0114]
(3)业务应用端根据所述配置参数更新业务应用端的服务治理组件，具备实时下发生效的能力，避免了传统方式修改配置后至少需要重启应用才能更新的弊端，有效提升了整体的运维效率。
[0115]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0116]
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0117]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0118]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0119]
以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。