微服务治理方法及装置与流程

1.本技术涉及数据处理技术领域，具体而言，涉及一种微服务治理方法、装置、计算机设备和存储介质。


背景技术：

2.服务治理工作是近两年服务行业尤其是服务侧服务开发工作的一个重要发展方向和趋势，根源在于云服务的兴起和普及，用户规模的扩张，服务大规模容器化后服务调用链路横向长度和纵向深度均提升数倍；在微服务数以千计的容器部署情况下，各个子服务之间的关系变得错综负责，如何理清各个子服务之间的关系，如何快速的定位服务运行过程中的问题并且能够清晰的看到和判断问题，成了服务开发人员必须要面对的严肃问题。
3.目前市场上现有的整体解决方案大多以有中间运行时环境的编程语言为主要治理对象，在服务运行过程中从服务运行时环境中获取相关的信息，汇总后进行存储、处理，可视化以达到服务治理的目的，并且这种方案并不需要开发人员手工添加信息收集埋点。但这种方案方式并不适用于无中间运行时编程语言开发的服务，例如类似golang这种并没有中间运行时，类似java编程语言的注入方式无法实现。
4.针对上述相关技术中的服务治理方案不适用于无中间运行时编程语言开发的服务的问题，目前尚未提出有效的解决方案。


技术实现要素：

5.本发明实施例提供一种微服务治理方法、装置、计算机设备和存储介质，用以解决相关技术中的服务治理方案不适用于无中间运行时编程语言开发的服务的问题。
6.为了实现上述目的，本发明实施例的第一方面，提供一种微服务治理方法，包括：
7.实时获取服务自身数据和第三方支撑服务质量数据，作为运维基础数据；其中服务自身数据包括服务质量数据和服务运行状态数据；
8.当集群服务中的一个或多个服务出现异常时，服务自身根据所述运维基础数据和本地治理配置进行自我调节；
9.如果所述自我调节无法解决当前服务所出现的异常时，则将所述服务自身数据和关键数据上行报告治理中心，以使治理中心在整合数据后根据不同类型的问题，执行预定的综合处理方案。
10.可选地，在第一方面的一种可能实现方式中，所述实时获取服务自身数据和第三方支撑服务质量数据，包括：
11.在服务启动后对服务自身的运行状态和运行质量进行实时监测；
12.当发生外部调用时，以显式的方式跟随服务执行流程流动，记录关键执行节点和服务自身数据；
13.当对第三方服务进行调用时，以增量的方式添加对第三方服务的质量监测，并将监测得到的第三方支撑服务质量数据反向反馈给服务自身。
14.可选地，在第一方面的一种可能实现方式中，所述方法还包括：
15.根据反馈得到的第三方支撑服务质量数据，调节对第三方软件的调用策略，其中所述第三方支撑服务质量数据包括服务请求响应的耗时和响应质量。
16.可选地，在第一方面的一种可能实现方式中，所述治理中心在整合数据后根据不同类型的问题，执行预定的综合处理方案，包括：
17.在收集服务自身数据和关键数据后，根据配置策略计算服务运行风险，在可控范围内自动下发调整参数，并将所述调整参数反向反馈给服务自身，以使服务自身进行自我调节。
18.可选地，在第一方面的一种可能实现方式中，所述方法还包括：在治理中心无法自动给出处理方案时采取人工介入的方式，将人工处理方案下发至问题服务中，使得所述问题服务根据人工处理方案进行自我调节。
19.本发明实施例的第二方面，提供一种微服务治理装置，包括：
20.数据收集模块，用于实时获取服务集群中各个服务的服务自身数据和第三方支撑服务质量数据，作为运维基础数据，并将所述运维基础数据传输至软件本地治理模块；其中服务自身数据包括服务质量数据和服务运行状态数据；
21.软件本地治理模块，用于根据所述服务自身数据和本地治理配置进行自我调节；根据所述第三方支撑服务质量数据，调节对第三方服务的调用策略；整理所述运维基础数据，将其数据结构进行统一，并将其数据结构统一后的运维基础数据上报至综合治理模块；
22.综合治理模块，用于接收所述运维基础数据；根据所述运维基础数据实时计算各个软件运行质量统计数据，并根据配置策略计算软件运行风险，以及在可控范围内自动下发调整参数，反向反馈给软件本地治理模块，以使软件本地治理模块根据调整参数进行自我调节。
23.可选地，在第二方面的一种可能实现方式中，所述数据收集模块，包括：
24.监测单元，用于在服务启动后对服务自身的运行状态和运行质量进行实时监测；
25.服务自身数据收集单元，用于当发生外部调用时，以显式的方式跟随服务执行流程流动，记录关键执行节点和服务自身数据；
26.第三方支撑服务质量数据收集单元，用于当对第三方服务进行调用时，以增量的方式添加对第三方服务的质量监测，并将监测得到的第三方支撑服务质量数据反向反馈给服务自身。
27.可选地，在第二方面的一种可能实现方式中，所述装置还包括：
28.人工处理模块，用于在治理中心无法自动给出处理方案时采取人工介入的方式，将人工处理方案下发至问题服务中，使得所述问题服务根据人工处理方案进行自我调节。
29.本发明实施例的第三方面，提供一种计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述各个方法实施例中的步骤。
30.本发明实施例的第四方面，提供一种可读存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时用于实现本发明第一方面及第一方面各种可能设计的所述方法的步骤。
31.本发明提供的微服务治理方法、装置、计算机设备和存储介质，通过实时获取服务
自身数据和第三方支撑服务质量数据，作为运维基础数据；其中服务自身数据包括服务质量数据和服务运行状态数据；当集群服务中的一个或多个服务出现异常时，服务自身根据所述运维基础数据和本地治理配置进行自我调节；如果所述自我调节无法解决当前服务所出现的异常时，则将所述服务自身数据和关键数据上行报告治理中心，以使治理中心在整合数据后根据不同类型的问题，执行预定的综合处理方案。本发明能够为多种开发语言提供软件开发治理支撑，使得软件本身具备自我治理能力，治理中心执行战略策动，以此两层治理模式，保障整体集群的高效高质量运行。
附图说明
32.图1为本发明实施例提供的微服务治理方法的流程图；
33.图2为服务异常修复的流程图；
34.图3为本发明实施例提供的微服务治理装置的结构图。
具体实施方式
35.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
36.本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
37.应当理解，在本发明的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
38.应当理解，在本发明中，“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
39.应当理解，在本发明中，“多个”是指两个或两个以上。“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“包含a、b和c”、“包含a、b、c”是指a、b、c三者都包含，“包含a、b或c”是指包含a、b、c三者之一，“包含a、b和/或c”是指包含a、b、c三者中任1个或任2个或3个。
40.应当理解，在本发明中，“与a对应的b”、“与a相对应的b”、“a与b相对应”或者“b与a相对应”，表示b与a相关联，根据a可以确定b。根据a确定b并不意味着仅仅根据a确定b，还可以根据a和/或其他信息确定b。a与b的匹配，是a与b的相似度大于或等于预设的阈值。
41.取决于语境，如在此所使用的“若”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”或“响应于检测”。
42.下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
43.本发明提供一种微服务治理方法，如图1所示其流程图，包括：
44.步骤s110、实时获取服务自身数据和第三方支撑服务质量数据，作为运维基础数据；其中服务自身数据包括服务质量数据和服务运行状态数据。
45.在本步骤中，在软件启动时会针对当前软件注册全局链路追踪功能。在服务启动后对服务自身的运行状态和运行质量进行实时监测；当发生外部调用时，以显式的方式跟随服务执行流程流动，记录关键执行节点(即关键数据)和服务质量数据；当对第三方服务进行调用时，以增量的方式添加对第三方服务的质量监测，并将监测得到的第三方支撑服务质量数据反向反馈给服务自身，为下次调用提供决策参考。通过上述数据获取方法，当有多个软件以集群的方式运行时，每个软件都会实时上报自身质量数据和第三方软件的质量数据到治理中心，为运维提供基基础数据；在各个软件之间形成一张监测网，各个软件都能知道自身的支撑软件的运行状态和质量输出。
46.步骤s120、当集群服务中的一个或多个服务出现异常时，服务自身根据所述运维基础数据和本地治理配置进行自我调节。
47.在步骤s120中，多个软件以集群方式运行时，当其中一个或者多个软件出现异常时，软件自身根据服务自身数据和本地治理配置调节自身运行节奏，以及根据收集到的第三方支撑软件质量数据调节对第三方软件的调用策略。
48.具体地，其中“软件自身根据服务自身数据和本地治理配置调节自身运行节奏”包括：在本地治理中心，根据收集的服务所在物理机器的运行数据(cpu使用率、内存使用率、硬盘使用率、网络延迟等)，以及服务运行数据(每秒请求量、每秒响应量、单次请求响应时长、热点接口、热点数据等)等数据，根据服务设定的承载能力，动态调节请求接受量和响应量，以防止服务自身过载导致无法响应；同时，以上所有数据都会实时同步至综合治理中心，综合治理中心根据子服务反馈数据，动态判断是否需要增减服务物理机器数量和服务容器数量，以及是否需要对某个服务执行降级或者熔断，待服务运行水平稳定下来再进行逐步开放。
49.具体地，其中“根据收集到的第三方支撑软件质量数据调节对第三方软件的调用策略”包括：对于第三方支撑服务，动态记录服务请求响应的耗时和响应质量，如果出现响应不及时或者超时，则根据既定策略进行屏蔽第三方服务；在屏蔽预设时间后再进行测试请求，通过则打开链路，多次测试请求无法通过后，则需要上报综合治理中心，由综合治理中心从上层进行干预(重启或者增加第三方服务容器数量)，或者通知运维人员介入。
50.步骤s130、如果所述自我调节无法解决当前服务所出现的异常时，则将所述服务自身数据和关键数据上行报告治理中心，以使治理中心在整合数据后根据不同类型的问题，执行预定的综合处理方案。
51.在该步骤中，如果软件自身的自我调节无法解决当前软件所出现的异常时，软件自身会对收集到的运维基础数据(包括服务自身数据和第三方支撑服务质量数据)进行数据结构的统一，继而将其上报至治理中心；治理中心通过收集服务自身数据和关键数据后，根据配置策略计算服务运行风险，在可控范围内自动下发调整参数，并将所述调整参数反向反馈给服务自身，以使服务自身进行自我调节。
52.针对上述步骤s120-s130，在实际运行中，当集群服务中某个服务出现运行问题(异常或者错误)时，首先服务自身可以进行一定程度的自我保护和自我修复，并同时上行报告自身运行状态(例如物理机器运行数据和服务自身程序执行成果数据)和关键数据(关键接口响应率、请求质量等)，治理中心在收到问题服务的报告时，可以根据不同类型的问题，执行预定的综合处理方案，例如服务资源耗尽，那么服务自身首先控制访问量，保证最低程度的可响应状态，而治理中心可以同步下发扩容指令，并同时对外部访问进行适当的限制，保证进入流量的正常响应。
53.整个的服务异常/错误修复流程如图2所示，当服务出现异常时，每个服务集群会先进行自检，如果软件自身根据服务自身数据和本地治理配置调节自身运行节奏能够解决问题，则服务集群继续运行；如果无法解决问题则将其运维基础数据(包括服务自身数据和第三方支撑服务质量数据)和关键执行节点信息(即关键信息)发给治理中心，治理中心在整合数据后根据不同类型的问题，下发处理方案给特定服务集群的特定软件进行软件的自我调节；当治理中心无法给出处理方案时会向人工发出告警信息，使得人工介入处理，将人工处理方案输入至治理中心，将通过治理中心将人工方案下发至特定服务集群的特定软件进行软件的自我调节。整个过程的服务集群运行数据和治理中心数据都会在监控大屏上显示。通过图2的服务异常/错误修复流程可知，在该方案下，整个由多个服务集群组成的应用系统，基本可以自治和自理，尤其在高危和高紧急的情况下，有更快和更高效的处理方式，人工干预工作大幅下降，降低人工出错的可能性，提高系统响应能力和恢复能力，降低人力成本，具有极高的可行性和效益。
54.在一个实施例中，所述方法还包括：在治理中心无法自动给出处理方案时采取人工介入的方式，将人工处理方案下发至问题服务中，使得所述问题服务根据人工处理方案进行自我调节。
55.本发明提供的微服务治理方法，通过实时获取服务自身数据和第三方支撑服务质量数据，作为运维基础数据；其中服务自身数据包括服务质量数据和服务运行状态数据；当集群服务中的一个或多个服务出现异常时，服务自身根据所述运维基础数据和本地治理配置进行自我调节；如果所述自我调节无法解决当前服务所出现的异常时，则将所述服务自身数据和关键数据上行报告治理中心，以使治理中心在整合数据后根据不同类型的问题，执行预定的综合处理方案。本发明能够为多种开发语言提供软件开发治理支撑，使得软件本身具备自我治理能力，治理中心执行战略策动，以此两层治理模式，保障整体集群的高效高质量运行。
56.技术效果：
57.1.本技术可以兼容多种开发语言，可为多种开发语言提供软件开发治理支撑；
58.2.本技术自带本地治理中心，让软件自我治理更加迅速高效；
59.3.本技术中的本地治理中心与综合治理中心的联动，为整体策略提供支撑，也为上层策略下行传达提供可执行点。
60.4.本技术为整体的软件治理提供的基本的组件功能支撑，并且在软件内部自建治理中心，让软件本身具备一定的自我治理能力；同时软件自身治理中心与综合治理中心进行联动和交互，让软件集群可控可调。综合来讲，软件自身可以进行战术策动，治理中心可以执行战略策动，以此两层治理模式，保障整体集群的高效高质量运行。
61.本发明的实施例还提供一种微服务治理装置，如图3所示，包括：
62.数据收集模块，用于实时获取服务集群中各个服务的服务自身数据和第三方支撑服务质量数据，作为运维基础数据，并将所述运维基础数据传输至软件本地治理模块；其中服务自身数据包括服务质量数据和服务运行状态数据；
63.软件本地治理模块，用于根据所述服务自身数据和本地治理配置进行自我调节；根据所述第三方支撑服务质量数据，调节对第三方服务的调用策略；以及整理所述运维基础数据，将其数据结构进行统一，并将其数据结构统一后的运维基础数据上报至综合治理模块；
64.综合治理模块，用于接收所述运维基础数据；根据所述运维基础数据实时计算各个软件运行质量统计数据，并显示在数据大屏上；根据配置策略计算软件运行风险；以及在可控范围内自动下发调整参数，反向反馈给软件本地治理模块，以使软件本地治理模块根据调整参数进行自我调节。
65.在一个实施例中，所述数据收集模块，包括：
66.监测单元，用于在服务启动后对服务自身的运行状态和运行质量进行实时监测；
67.服务自身数据收集单元，用于当发生外部调用时，以显式的方式跟随服务执行流程流动，记录关键执行节点和服务自身数据；
68.第三方支撑服务质量数据收集单元，用于当对第三方服务进行调用时，以增量的方式添加对第三方服务的质量监测，并将监测得到的第三方支撑服务质量数据反向反馈给服务自身。
69.在一个实施例中，所述装置还包括：
70.人工处理模块，用于在治理中心无法自动给出处理方案时采取人工介入的方式，将人工处理方案下发至问题服务中，使得所述问题服务根据人工处理方案进行自我调节。
71.其中，可读存储介质可以是计算机存储介质，也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何可用介质。例如，可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(application specific integrated circuits，asic)中。另外，该asic可以位于用户设备中。当然，处理器和可读存储介质也可以作为分立组件存在于通信设备中。可读存储介质可以是只读存储器(rom)、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。
72.本发明还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得设备实施上述的各种实施方式提供的方法。
73.在上述终端或者服务器的实施例中，应理解，处理器可以是中央处理单元(英文：central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(英文：digital signal processor，dsp)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及服务模块组合执行完成。
74.最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽
管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。