CN116094925A - 一种面向微服务架构的数据分级标识方法、系统和存储介质 - Google Patents

Abstract

本发明公开了一种面向微服务架构的数据分级标识方法。该方法包括对网络服务中的全链路进行监测，根据检测结果为数据添加标识，从而使用灰度发布和标识方法实现压力测试流量和正常业务流量隔离以及热点流量与正常流量的隔离；以平均日流量分布情况为参考控制压力测试或日常访问活动产生的日志数量，并以采样的形式减少高峰时段产生的日志数量，从而达到延迟较低的全链路监控日志记录和查询。

Description

一种面向微服务架构的数据分级标识方法、系统和存储介质

技术领域

本发明涉及网络信息技术，尤其涉及一种面向微服务架构的数据分级标识和隔离方法、系统和存储介质。

背景技术

随着业务量逐步增长，系统间交互及架构日渐复杂，同时伴随着激烈的市场竞争下带来的越来越高频的市场活动、业务模式创新，系统的“响应速度、稳定性、友好体验”正在逐渐成为继功能实现主体以外的又一核心竞争力，因此性能测试效能亟待提升。目前性能测试过程中遇到的各类性能问题无法短时间内进行复现和修复，各类应用的性能表现缺乏相关运维、运营数据，无法对系统容量做出更科学合理的评估。

在生产环境中，由于网络服务需要提供的业务量较大，因此会产生非常大的追踪采集异常的数据量。如果全部盲目进行全链路采集将会对正常业务处理速度造成很大影响，同时对存储系统带来很大压力。所以合理优化全链路采样以及存储的方法变得至关重要。

与此同时，在网络服务提供过程中，需要不断根据用户需求进行优化和维护，在应用升级期间，需要将用于优化或维护的程序包上传到服务器。通常情况下，优化或维护流程为，先停止老版本服务用例的服务，上传新版本，进行融合配置之后运行新的服务用例版本，在这种简单的发布方式下，存在两个问题，一是在新版本升级过程中，服务是中断的，这会造成用户的使用不便和收入流失；而且如果新版本存在缺陷，升级失败，需要经历回滚流程，容易造成更长时间的服务不可用，为服务提供者带来巨大的经济损失。

在对线上服务器应用进行压力测试时，压力测试所占用的流量与正常业务流量并行，压力测试为服务器带来的巨大并发操作压力会影响正常的业务访问处理能力，从而影响业务流程，导致正常服务访问等待时间过长。此外，微服务架构下，每个模块服务都会存在热点流量，比如当某个商品或某个服务访问流量占总访问流量的比重较大时，热点流量的访问增加，将增加整个服务的压力，从而导致服务请求慢。

发明内容

为解决以上问题，本发明提供一种面向微服务架构的数据分级标识方法。从而优化网络服务全链路的跟踪监测、应用升级过程版本发布以及用于压力测试及热点流量的传输，从而实现优化数据处理效能的技术目的。

第一方面，本发明提供的数据分级标记方法包括：对微服务架构中的需要监控的部分或所有的服务组件添加不同的一级标识，根据所述一级标识对被监控的组件产生的日志记录进行分类存储；同时，根据所述一级标识将提供服务的进程与被监控的进程解耦合；对需要进行版本升级或调试的一个或多个组件添加二级标识，从而对升级过程中的具备不同特征的版本进行版本标记从而实现平滑过渡及便捷数据回滚；通过对所述组件动态监控所得的异常比特率获取模块的异常流量，并对产生异常流量相关的组件进行三级数据标记，根据所述三级数据标记将热点数据转发至主服务链路之外的路由。

第二方面，本发明提供的数据分级标识系统，包括：标识设置模块，用于在CMDB（Configuration Management Database）中为同一服务用例的不同参数设置标记版本号的定制化参数标识，在第一页签为不同的服务组件用例设置一级标识、在第二页签为同一服务用例的不同版本设置二级版本标识、在第三页签为链路监控所得日志中获知的异常比特率设置阈值，并为监测到的异常比特率对应的服务设置标识；标识检测模块，用于检测服务请求或提供服务时传输的数据中携带的标识；标识添加模块，用以以不同种类的服务使用特定编码方式添加标识；版本配置下发模块，用于实时更新带数据标识的临时配置参数，用以动态调整服务用例设置，便捷动态用例调试，避免了上线发版的麻烦；日志检索模块，使用标识检索相关日志以便短时间内复现和修复问题。

进一步地，还可在标识设置模块的所述第二页签中，针对同一二级版本标识下的不同参数组的四级参数组标识，用于保存测试过程中不同侧重的参数组，便于后续参数回滚、定位问题和复现缺陷。

进一步地，还可在标识设置模块中设置集群配置页签，为新建的临时服务用例集群设置标记，从而实现对临时集群的监测。

进一步地，可在标识设置模块设置标识的添加位置，可选择将标识设置为添加在请求数据中作为一个字段，也可选择将标识设置在请求头上。

进一步地，可将标识检测模块设置在网关上，用于仅检测请求头上携带的标识，而不用在解码请求数据后在请求数据中检索标识字段；也可将标识检测模块嵌入在请求数据处理时，用于从请求数据中检索标识字段。

进一步地，可将标识添加模块设置在网关上，用于对到达网关的请求数据外部添加含有标识的请求头；也可将标识添加模块嵌入在请求数据生成时，作为请求数据的一个标识字段。

第三方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被计算机处理器执行时实现本发明任意实施例所述的数据标识方法。

本发明实施例通过为服务用例调用或产生的数据添加标识使数据得到分类存储或优化处理及传输；通过设置不同的数据标识，可以在网络服务的全链路进行优化监测及日志存储；通过链路监控所得日志得到异常数据的比特率，可以实时标识异常流量，让异常流量与正常业务流量区分开，提高系统的处理效率和稳定性；通过为版本配置数据添加数据标识，可以便于用例版本的用例回滚或动态调试。本发明所述实施例应用在实际生产中，可以提升性能测试效能，带有标识的日志文件能够帮助研发及运维人员在短时间内复现和修复性能问题，并对系统容量做出评估。通过分析大业务量下产生的大量追踪异常的日志数据可以更好地供运维人员优化系统性能。此外，还可以动态监测并调整系统数据的处理策略，提高系统的稳定性及向用户提供的服务质量。

附图说明

图1为本发明实施例基于微服务提供的服务器动态隔离实现过程的示意图；

图2为本发明实施例进行的日志采集的架构图；

图3为本发明实施例通过请求头指定灰度路由时网络层的处理流程；

图4为本发明实施例所述在灰度系统业务中的业务架构图；

图5为本发明实施例所述当使用请求头作为三级数据标识时的数据隔离实现过程示意图；

图6为处理异常流量时的灰度路由架构图；

图7为多区域灰度路由架构图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描写的具体实施例仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分，而并非全部结构。本发明的范围不受以下实施例的说明所限，仅由权利要求书的范围所示，而且包括与权利要求范围具有同样意思及权利要求范围内的所有变形。

进入云原生时代后，依托于容器技术与分布式技术的发展，为适应高并发，高压力，快速迭代场景，微服务架构成为了更多企业的必然选择。

系统服务链路是指从用户或是机器发起服务请求到结束，按顺序记录整个请求链路的相关数据，以备后续查询分析、定位系统故障或错误及性能优化所用。微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见。

因此，业界对服务链路追踪进行了广泛而深入的研究。在微服务系统中，一个来自用户的请求的处理流程为：请求先达到前端A（如前端界面），然后通过远程调用，达到系统的中间件B、C（如负载均衡、网关等），最后达到后端服务D、E，后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样的请求，服务链路追踪技术就可以记录请求处理过程中经历的大量服务的数据。

如图1所示，本发明实施例使用声明式pipeline对微服务的模块组件进行服务链路追踪，图示的服务链路可以视为本发明所述的主服务链路，并对pipeline重构结构用以支持便捷扩展迭代及添加一级标识。需要注意的是，本发明所述的主服务链路可以由用户自主选择由哪些服务用例构成，并不拘泥与本发明实施例实例的这样。

pipeline又称为管道，是一种在计算机领域普遍使用的技术。举个最普遍的例子，我们可以将pipeline类比为一个流水线，一个流水线分为四部分，每个部分可以独立工作，于是可以处理多个数据流。一个管道中包含多个通道句柄（channelhandler）、每个句柄（handler）用于调用实现具体操作的处理方法，每个句柄都唯一对应了一个会话（context），在pipeline中，所有的会话是构成一个链式结构的，链式结构是有序的，于是会话发生的先后顺序决定了处理的先后顺序，pipeline可以通过会话与句柄的对应关系来调用句柄。每个句柄实际上只是一个接口，可以根据需要自行定义。同时，将原有多个Java应用工程的各种各样的pipeline，标准化为一个pipeline，如此可以串联相关的服务用例，便于简化数据标识环节，只需要在开始位置的服务用例上标记一次一级标识，便可在所有其他关联的服务用例中体现所述一级标识。在分布式处理中，由于管道模式是数据驱动，因此可以在数据上添加不同的数据标识（例如用以标记服务用例版本的二级版本标识），从而对数据进行管理。

然后，对链式结构中的不同用例的定制化参数统一在CMDB（ConfigurationManagement Database，配置管理数据库）中管理，即使用不同服务用例的一级标识作为查询关键词在CMDB中查询服务用例对应的定制化参数。pipeline过程中会动态获取CMDB配置信息。其中，CMDB可以为不同版本的同一用例的不同参数添加标记版本号的二级版本标识，甚至可以为同一服务用例版本下的不同参数组设置四级参数组标识，以便于出现配置问题时的快速版本配置回滚。此时，使用CMDB中动态获取的带有二级版本标识的定制化参数所得的日志记录也携带相应的一级标识和二级版本标识甚至四级参数组标识。此外，本发明所述系统的版本配置下发模块支持架构师通过CMDB页面调整JVM（Java Virtual Machine）启动参数、实例数量、启动策略、实例资源配额等。同样，如果开发者在配置中心手动指定服务策略，或修改策略中的某一项或几项参数，在为策略参数添加二级版本标识之后下发至各接口，就可以在运行的项目中实时生效，免于上线发版的麻烦。

接着，为被监控的调用链上的组件创建Span（全链路监控中的基本单元），并由Span携带监控数据标识。一个Span中记录了包括名称、调用时间、键值对形式的标签数据、父调用ID等信息。在全链路监控中，为被监控的一个或多个组件设置一定数量的Span，微服务组件及相应监控线程之间每次调用创建一个Span，这个Span可以监控RPC（RemoteProcedure Call，远程过程调用）调用或数据库的访问。所述Span由一个64位ID标识。由于UUID（Universally Unique Identifier，通用唯一识别码）的生成过程较为方便，是生成Span ID（可以作为一个监控数据标识）的首选。UUID的目的是让分布式系统中的所有元素都能有唯一的识别信息。如此一来，每个请求都可以创建不与其它请求冲突的UUID，就不需考虑数据库创建时的名称重复问题。本发明所述UUID在实际使用过程中，采用与时间戳和MAC地址相关的方法1和与伪随机数（pseudo random-number）相关的方法2生成标识符。因为时间戳和随机数的唯一性，使用以上两种方法之一生成的标识符理论上两两难以重合。

特别的，若使用方法2，为了避免长时间多请求使用下的随机数被用尽，本发明融合了密码学上的强伪随机数产生器来生成值。具体来说，可以根据服务器此时传感器收集的热量、声音的变化等事实上无法预测和重现的自然现象信息来生成随机数，从而获得独特的UUID。

此外，为调用链上的服务用例设置一级标识。在服务链路中，Span称为一个基本工作单元，例如，在一个新建的Span中发送一个RPC等同于发送一个回应请求给RPC，Span通过一个64位ID唯一标识（例如前文所述的UUID），用于监听的进程调用到的Span以另一个64位ID表示（例如前文所述的UUID），Span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、Span的ID、以及进度ID(通常是IP地址)。在使用时Span在不断的启动和停止，同时记录了时间信息。因此，在使用中可以将所述一级标识作为查询服务进程和监听进程间的标识，通过一级标识将服务进程和监听进程区分开，从而实现监听进程与正常服务进程二者通过相应的Span上的监控数据标识并联，实现服务进程与监控进程的同步。因此一级标识可以令监控线程与正常服务线程的多参数紧耦合变为单参数的稀松耦合或解耦合，从而释放正常调用链上的系统资源，规避因为全链路监控对正常服务性能产生的过大影响，维持正常服务整体的抗压能力。

此外，通过为调用链上的服务用例设置一级标识，可以通过采集到的带有一级标识的日志信息完整绘制系统及服务间的调用关系，以帮助运维人员评判服务上下游依赖关系，确定故障影响的范围。也可以用于展示服务中某些环节对应的关键性能指标，可以为开发人员提供性能优化的方向，也可以帮助运维人员合理分配系统资源。

本发明所述实施例在服务用例层级还支持在集群配置页签中快速配置临时集群信息。具体来说，集群是被选取的多个服务用例组成的集合。用于标记属于同一集群的多个服务用例的标识即为临时集群信息。优选的，可以选取不同服务用例组成新建的临时集群，新建临时集群的集群标识可以由被选择的服务用例对应的一级标识通过哈希计算得出。通常，CMDB侧重于信息的管理(采集、整合、记录、维护、检验、更新等)，传统数据库侧重于信息的物理存储，两者是密切联系的。但是，CMDB的功能需要专门的CMDB管理软件，很难在传统数据库上直接完成。因为对配置信息的管理是CMDB的核心功能，而这一部分功能很难由数据库软件实现。

因此，本发明为CMDB编写了一个系统页签，实现了用户对于CMDB的简便交互。具体来说，用户可以在获得新建临时集群的版本标识后，将版本标识输入到CMDB页签和用于设置一级标识的第一子页签并提交，以标记临时集群中使用的服务用例和获取用例使用的配置参数。在集群配置页签中可以直接并发应用新建的临时集群用例，并发版至多个关联的子集群，从而实现支持对同一个工程同时进行多个发版任务同时进行。

在升级或优化调用链上的某一服务用例时，本领域技术人员常常用到灰度发布这一技术手段。在灰度发布中，最重要的就是对不同版本的服务用例进行管理，本发明实施例在使用灰度发布方法升级或优化调用链上的服务用例时的具体方法如下：

从计算机网络的网络层来说，当开发人员制定某些服务关联的接口使用灰度发布时，在本发明实施例中，对于某一服务用例不同版本设置的二级版本标识则可以作为识别标识。在Zuul(Spring Cloud网关组件)网络层中的Filter（过滤器）识别所述二级版本标识，根据二级版本标识路由到服务端的对应版本的服务用例上，二级版本标识可以在标识设置模块的第二页签对某一服务用例的不同版本分别设置。被指定二级版本标识的服务用例在实际工作过程中的被网关路由时，会首先识别所述服务用例产生的数据包或请求头中是否携带二级版本标识，如果数据包或请求头中不携带二级版本标识，或者二级版本标识指向不存在服务用例，则路由到正在调用链路中使用的对应服务用例版本上。

服务对应的接口的调用通常是服务请求方按照某种负载均衡策略去选择服务实例。本发明实施例中为不影响正常调用链为用户提供的服务，带有二级版本标识的服务用例将使用负载均衡策略。所述负载均衡策略是指：路由识别到二级版本标识后，将带有二级版本标识的数据包或请求头转发至基于正常调用链克隆的克隆链路上。搭载克隆调用链的服务器可以为在正常调用链所使用的服务器中搭建的虚拟服务器，也可以为不同于正常服务器的另一个物理服务器实体。

当用户或机器向服务器发起请求时，服务器中的Zuul拦截器将对请求进行拦截，在请求真正的接口前获取请求头（Headers）中传递的参数（trace-id），并存储在ThreadLocal<T>字段中，作为请求的线程共享局部变量。在请求结束时需要手动调用remove()方法移除变量副本，防止内存泄漏。所述ThreadLocal<T>字段在多线程中，为保证多个线程对共享变量的安全访问，通常会使用synchronize来保证同一时刻只有一个线程对共享变量进行操作。这种情况下可以将类变量放到ThreadLocal类型的对象中，使变量在每个线程中都有独立拷贝，不会出现一个线程读取变量时而被另一个线程修改的现象。接下来，由自定义Ribbon（自定义负载均衡器，Spring Cloud负载均衡组件）的ZoneAviodanceRule路由规则（拦截器路由规则）来实现带有二级版本标识的数据包或请求头的转发，在转发的详细过程中，在首次运行负载均衡策略时或在Ribbon中获取所有的被添加一级标识的服务实例中的二级版本标识列表，在后续检测到数据包或请求头中带有二级版本标识时，只需要在带有二级版本标识清单范围内检索识别到的带有二级版本标识既可，若是存在于清单里的带有二级版本标识便可以快速按照路由规则转发服务用例涉及的请求或数据，从而大大提高了路由识别效率。在数据包或请求数据到达网关时，网关会将二级版本标识记录下来，并传递给接收转发的二级版本标识对应服务用例相关联的接口，则后续调用的相关接口也会按照同样的逻辑将二级版本标识传递下去，从而保证所有数据请求在该添加了一级标识的服用用例的后续微服务调用链中均包含该服务用例的二级版本标识。

当二级版本标识位于请求的请求头时，且二级版本标识被用户指定为例如参数version时，参见图3、4，处理流程如下：

步骤1.来自前端的前端请求11首先到达网关3，此时网关拦截器会根据配置中心2的灰度路由规则处理请求，即配置中心2的灰度配置策略21，针对某类接口或接口的参数来进行配置相应的规则，比如一个接口当它的请求参数为规则中配置的值时命中规则，命中规则后就添加灰度标识，若没有，则不做任何处理放行。例如，客户端通过域名访问项目，通过请求灰度规则，命中灰度规则后，并给客户端设置cookie作为标识，并将用户标识存放到redis，将用户重定向到指定的版本。在灰度规则中使用的接口发出请求的时候，如果已经带有cookie则直接返回对应版本，不存在cookie则去查找redis，redis中存在对应信息则直接返回，如果不存在则进入灰度规则识别流。

步骤2.在Zuul拦截器执行完毕后，Zuul在进行转发请求时会通过负载均衡器Ribbon（Spring Cloud负载均衡组件）。

步骤3.负载均衡策略Ribbon被重写。当请求到达时，Ribbon会取出网关3存入线程的参数，例如version，version为约定的请求头参数，version参数从客户端传递到后端，然后存储到线程变量中。与此同时，Ribbon还会取出所有服务列表（定期从eureka注册中心刷新获取最新列表）及其该服务的元数据信息。然后取出服务元数据的version信息与线程变量version进行判断对比，若值一致则选择该服务作为返回。若所有服务列表的version信息与之不匹配，则返回null，此时Ribbon选取不到对应的服务用例则会报错。

步骤4.当请求为正常服务的请求，没有灰度标识的请求头，例如version信息时，此时Ribbon会收集所有正常服务用例列表，然后利用Ribbon默认的规则从这些正常服务用例列表中返回下一个将被调用的服务。当请求为灰度服务的请求，包含version信息时，Ribbon会根据记录的灰度服务路由规则，将其路由至下一个将被调用的灰度服务，并将灰度标识通过线程变量传递。

步骤5.Zuul通过Ribbon将请求转发至链路中的下一个服务。若下一个被调用的服务为正常服务用例列表中的服务，则路由至正常实例6；若下一个被调用的服务为灰度服务，则路由至灰度实例5。

步骤6.在调用另外一个服务的时候需要设置一个拦截器，假设我们在请求头中添加二级版本标识来决定是否转发至用于带有处理二级版本标识请求的克隆链路，就需要在接口处添加请求头version=beta，其中version=beta为当前请求接口的二级版本标识，然后存入线程变量。在经过RPC调用拦截器后最后回到Ribbon，Ribbon会从线程变量里面取出二级版本标识信息。然后重复步骤（4）和（5）。

本发明实施例所述网关通过负载均衡器Ribbon将带有二级版本标识的请求或数据转发到克隆链路，此外，可能还会通过RPC远程过程调用9来调用处于克隆链路外的其他服务。Zuul通过Ribbon将请求转发后，可能还会通过RPC调用其他服务。但是无论是通过什么方式调用，他们最后在选取目标路由转发的时候都会通过负载均衡器Ribbon。

在本发明所述技术方案中，数据标识有三个来源：一是用户请求直接指定带有数据标识的请求头，例如当客户端请求方法为GET时，请求用于专门接收含有请求头请求的服务器；二是在配置中心针对某些接口通过配置来指定带有数据标识的请求头，如果接口配置的请求头不满足请求对应的服务的请求头需求，就需要扩展实现自定义请求头与现有服务的映射表；三是在配置中心配置动态策略，通过判断请求接口的参数值、URL路径或其他值是否符合某个条件时，自动给请求添加带有数据标识的请求头，也就达到了动态比特率隔离的目的。其中数据标识中的第三个来源所述通过判断请求接口的参数值、URL路径为本领域技术人员常用的技术手段，在此就不做过多说明。

在微服务架构下，每个模块服务都会存在异常比特率，比如某个商品某个服务访问比特率占总访问比特率的比重较大，此类比特率就可称为异常比特率。一般情况下，异常比特率的访问增加，会增加整个服务的压力，从而导致服务请求慢。在一些极端情况下，异常比特率还会造成服务器的宕机，极大影响我们的日常生活。在某个服务访问的高峰期内，比如电商活动期间或对某一服务进行压力测试时，针对异常比特率的扩容与保护就需要与正常服务比特率隔离开来，此时只需要将异常比特率访问参数添加三级数据标记，就可以根据三级数据标记将异常比特率路由至处理正常调用服务的服务器之外的服务器，从而实现异常比特率与正常服务比特率的隔离。因此，本发明实施例在此主要说明一种根据链路监测得到异常比特率与预设的比特率阈值对比，从而调整数据使用正常服务通道还是带数据标识的隔离服务通道的标记方法。

具体来说，根据业务实际比特率动态添加三级数据标记并采用对应隔离服务策略，就是当某个接口在某个时间段内的请求比特率达到阈值时，或者是在某个时间内的某个业务的请求并发数量达到阈值时将其视为异常业务，使用三级数据标记来标记异常比特率，使之路由至与正常服务用例不同的隔离服务用例。可选的，可以将异常比特率使用隔离服务通道进行传输，从而实现异常业务比特率与正常业务比特率的隔离，处理异常比特率的隔离服务用例与正常服务用例的隔离，以达到项目稳定。所述阈值则通过实施例中的全链路监测中对业务的总请求量来确定。根据业务实际比特率动态对热点数据进行三级数据标记的添加与删除或对热点数据来源的服务用例进行三级数据标记的添加与删除。即，当某个接口比特率达到一定阈值时，利用三级数据标记在路由转发时就转发到与正常业务不同的路由，实现与其他业务比特率隔离，以达到项目稳定（例如：指定key标识）。在指定数据于正常服务切换至隔离服务的阈值时，所述阈值可由配置中心指定，修改后所有隔离环境中的实例都会同步更新为专门用于应对隔离服务的架构，在处理数据的方法和限度发生了相应变化，并且由于配置中心的存在，会在配置中心调取相应的参数值，并由配置下发模块同步至所有相关的服务实例，而不需要逐个指定，保持了服务实例调用链的参数一致性。

同时，为了防止短暂而突发的请求高并发或热点比特率扰动，本申请额外添加了一个三级数据标记锁。所述锁在服务内部对采样队列数据进行周期性监听，异常的服务请求并发数或异常比特率被提取出来放入异常队列中，当异常队列长度满足配置中心设置的预警值后，将自动为处于异常队列中的数据或请求添加三级数据标记，后续路由及接口会根据三级数据标记，将数据或将异常请求转发至用于处置异常情况的服务用例或服务器。当异常比特率长时间小于设定的异常比特率下限时，将自动删除为数据或请求添加的三级数据标记，使之恢复路由至正常服务调用链中的下一用例接口上。所述短暂例如异常的持续时间小于切换锁的监听周期。所述突发情况指的是某个模块调用的服务用例状态异常，例如提示TIMEOUT、EXCEPTION、HTTP_4XX、HTTP_5XX标志位，当发生异常情况的时候将会强制采集日志，无论是否处于周期性监听节点上。且所述强制采集只对下游调用链生效，除下游调用链之外的其他兄弟子树可能已经上报完毕，强制采集不保证整条链路会被全部采集。

例如，服务提供者可以在配置中心增加用于识别异常比特率的阈值，当在某段时间内多次检测到的比特率均值均大于设定的阈值的时候，服务提供者可以通过配置中心增加网关异常比特率的灰度路由策略。特别地，本发明还可以自动为通过前端传入的异常比特率自动添加三级数据标记，以实现将前端传入的高并发异常请求造成的异常比特率传入灰度策略，并进一步与灰度策略中包含的灰度服务匹配。用于响应造成异常比特率的请求的灰度服务与三级数据标记之间的映射关系可以是：

1)三级数据标记与灰度服务版本之间的匹配

如图6所示，例如，多个灰度服务版本之间承受的峰值比特率不同，而通常来说，能够长时间承受较高峰值比特率的服务用例所消耗的服务器资源也越多。若选用了峰值比特率过高的服务用例处理一个比特率较高的请求，则会造成资源浪费。因此，本发明将多个灰度服务版本的峰值比特率和最高峰值比特率持续时间作为标记参数，并生成一个数据表。在检测到异常比特率时，网关将会在判别逻辑中将异常比特率值与数据表相比较，再向上取整得到最适合的灰度服务版本。

2)三级数据标记与版本权重之间的匹配

在多个灰度服务版本之间能够承受的峰值比特率步长不够完备时，会出现监测到的比特率处于两个灰度版本之间的情况。针对这一情况，本发明可以通过给两个灰度版本之间分配权重的方式，得到适于处于当前异常比特率的灰度服务版本配置。例如，当监测到的异常比特率为540bps，若灰度服务版本1的峰值比特率为400bps，灰度服务版本2的峰值比特率为800bps。此时则可以对灰度服务版本1和灰度服务版本2进行权重分配，为灰度服务版本1分配60%的权重，为灰度服务版本2分配40%的权重，既可得到一个重组的峰值比特率为560bps的灰度服务。从而实现较为可靠的且资源浪费较少的用于服务的比特率。

3)三级数据标记与服务区域之间的匹配

如图7所示，还可通过三级数据标记将区域1的服务A1路由至区域2的服务B2，从而实现服务的跨区调用，从而减轻区域1的服务压力。例如在遭遇高并发阻塞攻击时，大量请求多来自于同一服务区域。因此在检测到异常比特峰值时，可以针对出现异常的区域标记三级数据标记，然后分流至灰度服务或服务于其他区域的未受到异常请求攻击的服务区域。进一步的，可以将三级数据标记与请求发出者的IP地址或路由端口之间匹配。即，可以根据技术手段推定发出异常请求的请求发出者的IP，针对这一情况，可以仅对异常的IP添加三级数据标记，从而实现对异常攻击的隔离。最终，在服务器层面令区域1与区域2的服务数据同步，从而保证服务提供的一致性。

在全链路监控过程中，对于pipeline过程中的用例，针对各阶段状态反馈及失败原因反馈作为日志。日志将记录：增加检测实例启动状态时，打印检测结果、收集job字数、pipeline各阶段用时等信息。所有日志记录将通过grafana的“服务治理-发版统计”页展示。pipeline检查实例启动状态过程中，当检测到日志上报“Application startupfailed”时，pipeline快速失败，并发生弹窗和推送，提示运维人员排查问题。

日志采集架构如图2所示。若在测试过程中开启日志采集，则执行上述添加数据标识的方法，同时对整个服务携带is_export标识，并将这一标识流转于系统之间，控制此条调用链经过的所有用例都需要进行日志采样。在每个用例根据日志统计的QPS（Query PerSecond）到达设定阈值后，对下个请求进行采样。同时，每个用例的阈值配置在Apollo中，并支持实时修改。在http端的日志采样，需要拦截用户或服务器提出的请求，查看是否存在追踪器并获取当前的采样策略，从而决定在提供服务时决定此条调用是否进行采样。在获取返回值时，根据采样策略的返回结果设置is_export标识，追踪器中的sleuth trace会将is_export标识携带到此条调用链的任何地方。根据一级标识对全链路监听采集到的日志记录进行分类存储。最终采集到的日志将通过ops编写的日志拦截将已被标识采样的日志收集到kafka中，带新系统运行闲暇时将其同步到服务器，从而实现微服务架构的某一调用链的全链路监测。

值得注意的是，服务端发布的灰度分支，在发布完成后不会自动合并到主服务链路中，只有经过开发人员确认完成后才会合并至主服务链路中，从而替代主服务链路中具有相同功能的正常服务用例。同时，灰度配置的文件也与正常配置文件相互独立设置，经过开发人员确认后才会局部覆盖正常配置文件中相同的配置。

本发明实施例还提出一种数据标识系统。其中，系统中的标识设置模块，用于在CMDB中为同一服务用例的不同参数设置标记版本号的四级参数组标识、为调用链中的各服务用例设置一级标识、为临时集群中添加集群标识以标识临时集群中使用的服务用例和用例使用的配置参数、为正在优化或升级的服务用例设置二级版本标识从而实现版本管理，并在版本间便捷地完成数据回滚、为链路监测到的异常比特率对应的服务设置三级数据标记。系统中的标识检测模块，用于检测服务请求或提供服务时传输的数据包中携带的标识头；标识添加模块，用以以不同种类的服务使用特定编码方式进行标识头的添加；版本配置下发模块，用于实时下发带数据标识的临时配置参数，用以动态调整服务用例设置，便捷动态用例调试；日志检索模块，按各标识对日志进行优化采集和存储，从而实现对全链路的服务用例的监控，便于运维人员定位故障以及开发人员优化用例及系统。此外还可便捷对服务用例版本更新的版本控制和调试，便于在新版本发生故障的时候快速进行数据回滚，降低因版本故障带来的损失的同时降低测试优化版本时对用户正常使用网络服务的影响。此外，在用户使用过程中，由于可根据链路监控中取得的异常比特率并自动为异常比特率关联的服务用例添加标识，从而实现对服务产生的比特率的动态监测并灵活调整服务策略，提高了系统的处理效率和稳定性，也提高了向用户提供的服务质量。

本发明实施例还提出一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述的数据标识方法。

本领域技术人员可以理解，在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。

计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，可用本领域公知的下列技术中的任一项或它们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。

Claims (12)

1.一种面向微服务架构的数据分级标识方法，对微服务架构中的多个子服务组成的主服务链路进行数据分级标识，其特征在于，包括以下步骤：

对微服务架构中的需要监控的部分或所有的各服务组件用例添加不同的一级标识，根据所述标识对监控所述组件产生的日志文件进行分类存储，并使用所述一级标识将提供服务的进程与监控进程解耦合；

对需要进行版本升级或调试的一个或多个组件分别添加二级版本标识，并使用二级版本标识作为记录用于数据回滚；

通过对所述组件动态监控所得的异常比特率得到异常流量，并对产生异常流量相关的组件进行三级数据标记，根据所述三级数据标记将热点数据转发至在所述主服务链路之外的路由。

2.根据权利要求1所述的数据分级标识方法，其特征在于：

为微服务架构中的组件添加所述一级标识可以由用户在配置中心中指定，也可以由配置中心检测链路中的新增组件，并为所述新增组件自动添加。

3.根据权利要求1所述的数据分级标识方法，其特征在于：

在进行版本升级或调试时添加时，需要在配置中心新增版本管理数据库后才能添加所述二级版本标识，所述二级版本标识会被附加至使用这一版本产生的所有数据及日志中。

4.根据权利要求1所述的数据分级标识方法，其特征在于：

对组件动态监控时，可以在所得的热点比特率对应的组件上添加三级数据标识，所述三级数据标识的添加需要使用的预先约定的标记添加规则，所述标记添加规则需要在配置中心手动指定生成；所述灰度服务策略为客户端在配置中心手动指定生成。

5.根据权利要求3所述的数据分级标识方法，其特征在于：

在服务涉及的某类接口或接口的参数在网关处配置与二级版本标识相应的路由规则，当接口的请求参数为路由规则中规定的目标二级版本标识列表中的标识时，将包含所述参数的请求转发至专门用于处理与所述请求参数对应的服务器或其他路由或接口。

6.根据权利要求4所述的数据分级标识方法，其特征在于：

所述标记添加规则的数据依赖，可以为既往采集的监控日志中的平均比特率，也可为在配置中心手动制定的识别热点比特率的阈值。

7.根据权利要求4所述的数据分级标识方法，其特征在于：

所述热点比特率为指定的某个/些接口/服务组件的在某个/些时间段内的业务实际比特率。

8.根据权利要求1所述的数据分级标识方法，其特征在于：

使用所述一级标识将提供服务的进程与监控进程解耦合包括，将所述一级标识作为查询进程间资源的标识，从而实现服务进程与监控进程的同步且从紧密的多参数耦合变为稀松的单参数耦合。

9.根据权利要求3所述的数据分级标识方法，其特征在于：

在网关处可以识别服务实例某一版本添加的二级版本标识。

10.一种应用权利要求1-9中任一项所述方法的数据分级标识系统，包括：

配置中心；

网关，用于转发服务产生的报文数据或在受配置中心指定时添加标识头；

负载均衡器， 通过其中的路由规则将识别到所述标识的所述报文数据转发到相应目标实例；

其中，配置中心包括：

标识设置模块，用于设置一级标识字符串，设置二级版本标识及添加位置，设置三级数据标记及添加阈值，设置标识编码方式，设置标识添加方式；

标识添加模块，用于在配置中心下发添加标识的指令后在生成报文时添加标识字段，或用于在网关处在报文前添加标识头；

标识检测模块，用于在网管处识别报文前的标识头，或用于在报文中识别标识字段；

版本配置下发模块，用于用户在配置中心新增或修改配置后将配置下发至其他模块。

11.根据权利要求10所述的数据分级标识系统，其特征在于：

所述配置中心可以是位于服务器控制主机上的独立系统，也可以是任何一台具有修改配置的权限认证功能的终端。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时可实现如权利要求1-9中任一项所述数据分级标识方法。

Images