本发明公开了一种多版本共存应用服务系统，包括配置服务器、反向代理服务器以及多个应用服务器。反向代理服务器根据所述配置服务器对下单请求进行灰度染色分组，并对符合灰度染色分组特性的下单请求按照灰度链路进行转发；对没有进行灰度染色分组的下单请求，按照常规链路转发给相应的应用服务器；应用服务器对于灰度链路的下单请求根据灰度染色分组编号向配置服务器查询当前应用服务是否存在灰度版本，若是，则运行调用灰度版本，否则，运行调用默认常规版本。另外，公开了相应的数据传输方法、设备和存储介质。采用本发明实现了应用服务多版本共存于同一系统架构下，不需要进行物理隔离，节省了物理设备，节约了成本。
1.一种多版本共存应用服务系统，其特征在于，所述系统包括：配置服务器，用于为多版本共存的应用服务配置灰度染色分组决策，所述决策包括：灰度染色分组特性和灰度染色分组编号，所述多版本包括灰度版本和常规版本；
反向代理服务器，用于根据所述配置服务器的灰度染色分组特性检测来自客户终端的下单请求，对符合灰度染色分组特性的下单请求进行灰度染色分组，并将灰度染色分组编号写入下单请求的消息头中后，按照灰度链路转发给与灰度染色分组编号对应的应用服务器；对没有进行灰度染色分组的下单请求，则按照常规链路转发给相应的应用服务器；
多个应用服务器，用于接收下单请求并调用相应的应用服务，对于灰度链路的下单请求根据灰度染色分组编号运行调用灰度版本，没有相应的灰度版本则运行调用默认常规版本，对于常规链路的订单请求则运行调用应用服务的常规版本；其中，反向代理服务器在下单请求的入口处对订单请求进行灰度染色分组，在数据链路传输过程中根据灰度染色分组编号调用指定的灰度版本，后端的应用服务不需要再次添加灰度染色分组。
2.根据权利要求1所述的多版本共存的应用服务系统，其特征在于，所述配置服务器具体用于：
设置匹配规则，所述匹配规则包括行灰度染色分组特性；
3.根据权利要求1所述的多版本共存的应用服务系统，其特征在于，所述反向代理服务器具体用于：
根据配置服务器配置的灰度染色分组特性判断当前下单请求是否需要进行灰度染色分组，若是，则获取灰度染色分组编号，并将所述灰度染色分组编号写入所述订单请求的http header信息头中，否则，判定当前的订单请求不需要进行灰度染色分组；
将http header信息头中携带有染色分组编号的订单请求按照灰度链路发送给相应的服务器；
将不需要进行灰度染色分组的订单请求按照常规链路发送给相应的应用服务器。
4.根据权利要求1‑3中任一项所述的多版本共存的应用服务系统，其特征在于，所述应用服务器在接收到灰度链路的订单请求时具体用于：解析订单请求的消息头，获取订单请求的灰度分组编号和应用服务名称；
根据所述灰度分组编号向配置服务器查询与所述应用服务名称对应的版本是否存在灰度版本，若是，则运行调运灰度版本，否则，运行调用默认常规版本。
5.一种多版本共存的应用服务系统的数据传输方法，所述应用服务系统包括配置服务器、反向代理服务器以及多个应用服务器；所述配置服务器配置有灰度染色分组决策，所述决策包括：灰度染色分组特性和灰度染色分组编号，所述多版本包括灰度版本和常规版本，其特征在于，所述方法包括步骤：S1，反向代理服务器根据所述配置服务器的灰度染色分组特性检测来自客户终端的下单请求，对符合灰度染色分组特性的下单请求进行灰度染色分组，并将灰度染色分组编号写入下单请求的消息头中后，按照灰度链路转发给与灰度染色分组编号对应的应用服务器；对没有进行灰度染色分组的下单请求，则按照常规链路转发给相应的应用服务器；
S2，多个应用服务器接收下单请求并调用相应的应用服务，对于灰度链路的下单请求根据灰度染色分组编号运行调用灰度版本，没有相应的灰度版本则运行调用默认常规版本，对于常规链路的订单请求则运行调用应用服务的常规版本；其中，反向代理服务器在下单请求的入口处对订单请求进行灰度染色分组，在数据链路传输过程中根据灰度染色分组编号调用指定的灰度版本，后端的应用服务不需要再次添加灰度染色分组。
6.根据权利要求5所述的多版本共存的应用服务系统的数据传输方法，其特征在于，所述步骤S1之前还包括：
设置匹配规则，所述匹配规则包括行灰度染色分组特性；
7.根据权利要求5所述的多版本共存的应用服务系统的数据传输方法，其特征在于，所述步骤S1具体包括：
根据配置服务器配置的灰度染色分组特性判断当前下单请求是否需要进行灰度染色分组，若是，则获取灰度染色分组编号，并将所述灰度染色分组编号写入所述订单请求的http header信息头中，否则，判定当前的订单请求不需要进行灰度染色分组；
将http header信息头中携带有染色分组编号的订单请求按照灰度链路发送给相应的应用服务器；
将不需要进行灰度染色分组的订单请求按照常规链路发送给相应的应用服务器。
8.根据权利要求5‑7中任一项所述的多版本共存的应用服务系统的数据传输方法，其特征在于，所述步骤S2具体包括：解析订单请求的消息头，获取所述订单请求的灰度分组编号和应用服务名称；
根据所述灰度分组编号向配置服务器查询与所述应用服务名称对应的版本是否存在灰度版本，若是，则运行调用灰度版本，否则，运行调用默认常规版本。
9.一种多版本共存的应用服务系统的设备，其特征在于，包括：存储器和至少一个处理器，所述存储器中存储有指令；
所述至少一个处理器调用权利要求5‑8中任一项所述的多版本共存的应用服务系统的数据传输方法的步骤。
10.一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令处理器执行权利要求5‑8中任一项所述的多版本共存的应用服务系统的数据传输方法的步骤。
多版本共存的应用服务系统、传输方法、设备及存储介质
技术领域
[0001] 本发明涉及应用服务系统，特别是一种多版本共存的应用服务系统、传输方法、设备及存储介质。
背景技术
[0002] 在互联网云原生服务架构下，一个下单请求依赖后端多个应用服务，例如购物车、商品中心、库存中心、试算中心、订单中心、支付中心等协作完成流程。同一个应用服务有时
会多个版本同时在线，这些版本既包括稳定的常规版本又包括测试版本。对于测试版本来
说每个功能都要上线进行测试，但是平台又依赖订单中心的稳定的常规版本进行运行。另
外，有时为了检测新上线版本是否受欢迎也需要对新版本进行测试，这样同一个应用服务
就会有新版本和稳定的常规版本同时存在的情况。
[0003] 目前，对于同一应用服务多个版本共存的情况，通常采用硬件隔离的方式，这样的运营架构下就包括两套系统，相应的就需要两套物理设备来支撑，大大增加了运营成本。
发明内容
[0004] 本发明的目的是提供一种多版本共存的应用服务系统、传输方法、设备及存储介质，通过在订单请求的入口处进行灰度染色分组，减少了物理设备，节省了成本。
[0005] 为解决现有技术存在的问题，本发明提供一种多版本共存的应用服务系统，该系统包括：
[0006] 配置服务器，用于为多版本共存的应用服务配置灰度染色分组决策，所述决策包括：灰度染色分组特性和灰度染色分组编号，所述多版本包括灰度版本和常规版本；
[0007] 反向代理服务器，用于根据所述配置服务器的灰度染色分组特性检测来自客户终端的下单请求，对符合灰度染色分组特性的下单请求进行灰度染色分组，并将灰度染色分
组编号写入下单请求的消息头中后，按照灰度链路转发给与灰度染色分组编号对应的应用
服务器；对没有进行灰度染色分组的下单请求，则按照常规链路转发给相应的应用服务器；
[0008] 多个应用服务器，用于接收下单请求并调用相应的应用服务，对于灰度链路的下单请求根据灰度染色分组编号运行调用灰度版本，没有相应的灰度版本则运行调用默认常
规版本，对于常规链路的订单请求则运行调用应用服务的常规版本。
[0009] 另外，所述配置服务器具体用于：
[0010] 新建灰度染色分组以及分组编号；
[0011] 设置匹配规则，所述匹配规则包括行灰度染色分组特性；
[0012] 配置需灰度染色的应用服务及其版本号。
[0013] 另外，所述反向代理服务器具体用于：
[0014] 拦截来自客户终端的下单请求；
[0015] 根据配置服务器配置的灰度染色分组特性判断当前下单请求是否需要进行灰度染色分组，若是，则获取灰度染色分组编号，并将所述灰度染色分组编号写入所述订单请求
的http header信息头中，否则，判定当前的订单请求不需要进行灰度染色分组；
[0016] 将http header信息头中携带有染色分组编号的订单请求按照灰度链路发送给相应的服务器；
[0017] 将不需要进行灰度染色分组的订单请求按照常规链路发送给相应的应用服务器。
[0018] 另外，所述应用服务器在接收到灰度链路的订单请求时具体用于：
[0019] 解析订单请求的消息头，获取订单请求的灰度分组编号和应用服务名称；
[0020] 根据所述灰度分组编号向配置服务器查询与所述应用服务名称对应的版本是否存在灰度版本，若是，则运行调运灰度版本，否则，运行调用默认常规版本。
[0021] 相应的，本发明还提供一种多版本共存的应用服务系统的数据传输方法，所述应用服务系统包括配置服务器、反向代理服务器以及多个应用服务器；所述配置服务器配置
有灰度染色分组决策，所述决策包括：灰度染色分组特性和灰度染色分组编号，所述多版本
包括灰度版本和常规版本，其特征在于，所述方法包括步骤：
[0022] S1，反向代理服务器根据所述配置服务器的灰度染色分组特性检测来自客户终端的下单请求，对符合灰度染色分组特性的下单请求进行灰度染色分组，并将灰度染色分组
编号写入下单请求的消息头中后，按照灰度链路转发给与灰度染色分组编号对应的应用服
务器；对没有进行灰度染色分组的下单请求，则按照常规链路转发给相应的应用服务器；
[0023] S2，多个应用服务器接收下单请求并调用相应的应用服务，对于灰度链路的下单请求根据灰度染色分组编号运行调用灰度版本，没有相应的灰度版本则运行调用默认常规
版本，对于常规链路的订单请求则运行调用应用服务的常规版本。
[0024] 另外，所述步骤S1之前还包括：
[0025] 新建灰度染色分组以及分组编号；
[0026] 设置匹配规则，所述匹配规则包括行灰度染色分组特性；
[0027] 配置需灰度染色的应用服务及其版本号。
[0028] 另外，所述步骤S1具体包括：
[0029] 拦截来自客户终端的下单请求；
[0030] 根据配置服务器配置的灰度染色分组特性判断当前下单请求是否需要进行灰度染色分组，若是，则获取灰度染色分组编号，并将所述灰度染色分组编号写入所述订单请求
的http header信息头中，否则，判定当前的订单请求不需要进行灰度染色分组；
[0031] 将http header信息头中携带有染色分组编号的订单请求按照灰度链路发送给相应的应用服务器；
[0032] 将不需要进行灰度染色分组的订单请求按照常规链路发送给相应的应用服务器。
[0033] 另外，所述步骤S2具体包括：
[0034] 解析订单请求的消息头，获取所述订单请求的灰度分组编号和应用服务名称；
[0035] 根据所述灰度分组编号向配置服务器查询与所述应用服务名称对应的版本是否存在灰度版本，若是，则运行调用灰度版本，否则，运行调用默认常规版本。
[0036] 相应的，本发明还提供了一种多版本共存的应用服务系统的设备，该设备包括：存储器和至少一个处理器，所述存储器中存储有指令；
[0037] 所述至少一个处理器调用所述的多版本共存的应用服务系统的数据传输方法的步骤。
[0038] 相应的，本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，该指令处理器执行时实现了上面所述的多版本共存的应用服务系统的数据传
输方法的步骤。
[0039] 与现有技术相比，本发明的有益效果是：
[0040] 本发明实施例在配置服务器中将应用服务的多个版本区分为常规版本和灰度版本，并对灰度版本建立灰度染色分组决策系统；因此反向代理服务器在下单请求的入口处
就可以根据配置服务器的灰度染色分组决策系统，对下单请求进行灰度染色分组，并将灰
度染色分组编号写入下单请求的消息头后按照灰度链路传输指定的应用服务器，该指定的
服务器接收到订单请求时根据灰度染色分组编号进行查询版本号，从而实现了多版本同时
共存，节省了物理设备，节约了成本。
附图说明
[0041] 图1是本发明一种多版本共存的应用服务系统的一种实施例的示意图；
[0042] 图2是本发明一种多版本共存的应用服务系统的具体实现示意图；
[0043] 图3是本发明一种多版本共存的应用服务系统的数据传输方法的第一种实施例的流程示意图；
[0044] 图4是本发明一种多版本共存的应用服务系统的数据传输方法中配置服务器配置建立灰度染色分组决策系统的流程步骤示意图；
[0045] 图5是本发明一种多版本共存的应用服务系统的数据传输方法的第二种实施例的示意图；
[0046] 图6是本发明一种多版本共存的应用服务系统的数据传输方法中灰度链路传输示意图。
[0047] 其中：
[0048] 10.配置服务器, 11.反向代理服务器, 12.应用服务器; 20.客户终端, 21.PC终端,22.手机终端，23.互联网网页端,30.API网关,40.常规链路,50.灰度链路。
具体实施方式
[0049] 下面结合实施例对本发明进行详细说明。
[0050] 参考图1，该图是本发明一种多版本共存的应用服务系统的一种实施例的示意图，该系统包括配置服务器10、反向代理服务器11、应用服务器12，其中，配置服务器10分别与
反向代理服务器11、多个应用服务器12连接，反向代理服务器、各应用服务器均可以与配置
服务器进行通讯来获取灰度染色分组决策信息。
[0051] 配置服务器10，建立有灰度染色分组决策系统，具体实现时，该决策系统包括灰度染色分组、灰度染色分组编号、匹配规则、灰度染色分组依赖的应用服务及其版本号。具体
实现时，该配置服务器可以表现为consul注册中心（分布式服务发现和配置管理系统）或运
管平台。
[0052] 其中，该匹配规则可为灰度染色分组特性，例如订单请求的入口地址特性，订单请求的来源特性，该订单请求的来源特性可为IP信息（\省\市\区信息）。
[0053] 该灰度染色分组特性也可以是用户标签特性、用户机型或用户手机系统等特性。
[0054] 该灰度染色分组依赖的应用服务以及版本号，例如配置灰度链路的下单流程(商品v2.1, 促销v3.1, 订单v6.1), 常规链路的下单流程(商品v2.0, 促销v3.0, 订单
v6.0)；最后刷新缓存， 推送至键值对数据库（Redis ，Remote Dictionary Server）配置中
心。
[0055] 反向代理服务器11，具体实现时可以用网关来代替，也可以反向代理服务器和网关结合来代替，例如nginx+lua服务器。反向代理服务器在整个系统中处于下单请求的入口
处，它会拦截所有客户终端的下单请求。因此，可以在入口处对下单请求进行灰度染色分组
并将灰度染色分组编号写入消息头中，使同一应用服务的多个版本可以在同一套应用服务
中交替运行，即灰度版本和常规版本并行， 实现了开发和测试两套隔离环境集成在1套环
境中互调，减少了开发测试成本。基于灰度染色分组，可实现多个灰度调用测试，隔离不同
业务链路调用。
[0056] 另外，反向代理服务器11内可以自带反向代理服务负载，该反向代理服务负载设置于应用服务器之前，对灰度染色分组的订单请求按照灰度链路转发给相应的应用服务器
（灰度服务器），对没有进行灰度染色分组的订单请求按照常规链路转发给相应的应用服务
器。
[0057] 多个应用服务器12，应用服务器之间在相互调用的过程中，都会基于下单请求中的信息头判断是否进行了灰度染色分组，若是，则会根据信息头中的灰度染色分组编号到
配置服务器上查询对应绑定的版本是什么样的版本，如果是灰度版本则执行灰度版本，如
果没有灰度版本则运行调用默认的常规版本。
[0058] 需要说明的，整个应用服务系统中设置有几多个应用服务器，构成数据传输的路径，在本实施例中可以在现有的网络架构的基础上将灰度链路的订单请求指定在几个服务
器上，这些服务器可以称为灰度服务器，服务器之间进行应用调用的时候，也是先判断订单
请求的信息头是否有灰度染色分组信息，如果有的话就根据信息头中的灰度染色分组编号
查询是否具有灰度版本，如果有，则运行调用灰度版本，没有，则运行调用默认的常规版本；
如果订单请求的头信息中没有灰度染色分组信息，则按照常规链路进行传输，具体传输过
程在此不再进行赘述。
[0059] 下面以反向代理服务器被API网关取代为例，对本发明实施例进行说明，本实施例中配置服务器预设用户流量按照95%和5%的比例分配给常规链路和灰度链路，并且，为了说
明应用服务系统对数据的传输路径，省略了配置服务器部分。参考图2，该图是本发明一种
多版本共存的应用服务系统的具体实现示意图，该系统包括：客户终端20、API网关30、常规
链路40和灰度链路50。客户终端20发送订单请求，5%的订单请求按照配置服务器的配置经
过API网关灰度染色分组后按照灰度链路进行传输，95%的订单请求不需要进行灰度分组，
则按照常规链路进行传输。
[0060] 客户终端20，用于发送订单请求，具体实现时，可以为PC终端21、手机终端22，互联网网页端23等客户终端设备。
[0061] API网关30，可包括路由、路由插件、分流、流量镜像、维护开关、API监控、认证授权、治理和文档报表，便于客户终端的所有请求路由到合适的微服务，且可以调用多个微服
务并合结果来处理一个请求，减少了客户终端与应用程序间的交互次数，还简化了客户终
端代码。
[0062] 灰度链路50，将灰度请求流量流转到前端服务的业务层服务化节点（灰度服务器）后，后端服务的后续流量由服务框架代管，通过 RPC（Dubbo）协议流转，服务框架的标签路
由层会自动识别本次丁订单请求是否携带灰度流量标识（灰度染色分组编号），并筛选特定
的灰度环境并转发请求，基于RPC的服务框架能远程调用，可以在任何环境下运行，该框架
提供了负载均衡，跟踪，智能监控，身份验证等功能，可以实现系统间的高效连接。
[0063] 下面对本发明的一种多版本共存的应用服务系统的数据传输方法进行说明，参考图3，该图是本发明一种多版本共存的应用服务系统的数据传输方法的第一种实施例的流
程示意图，该流程包括如下步骤：
[0064] 步骤s1, 反向代理服务器根据所述配置服务器的灰度染色分组特性检测来自客户终端的下单请求，对符合灰度染色分组特性的下单请求进行灰度染色分组，并将灰度染
色分组编号写入下单请求的消息头中后，按照灰度链路转发给与灰度染色分组编号对应的
应用服务器；对没有进行灰度染色分组的下单请求，则按照常规链路转发给相应的应用服
务器；
[0065] 步骤s2，多个应用服务器接收下单请求并调用相应的应用服务，对于灰度链路的下单请求根据灰度染色分组编号运行调用灰度版本，没有相应的灰度版本则运行调用默认
常规版本，对于常规链路的订单请求则运行调用应用服务的常规版本。
[0066] 本实施例在入口处对订单请求的进行灰度染色分组，然后在数据链路传输过程中根据灰度染色分组编号运行调用指定的灰度版本。后端的应用服务不需要再次添加灰度染
色分组，不必对现有程序进行侵入式改动。实现了同一应用多版本交叉混合测试，将开发系
统和测试系统融为一个系统，不需要增加额外的服务器进行物理隔离，节约了成本，提高了
效率。
[0067] 参考图4，该图是本发明一种多版本共存的应用服务系统的数据传输方法中配置服务器建立灰度染色分组决策系统的流程步骤示意图，具体包括：
[0068] 步骤s11, 新建灰度染色分组以及分组编号；
[0069] 步骤s12,设置匹配规则，所述匹配规则包括灰度染色分组特性；具体实现时，该灰度染色分组特性可为：请求入口地址, 订单请求来源[IP\省\市\区]、用户标签、用户机型、
用户手机系统，因此系统可以根据需要进行灰度染色分组，例如要测试某个区域的流量，则
可设置订单请求来源作为灰度染色分组的特性；
[0070] 步骤s13,配置需灰度染色的应用服务及其版本号；具体实现时，例如配置下单请求的灰度链路流程为：商品v2.1, 促销v3.1, 订单v6.1, 下单请求的常规链路流程为：商
品v2.0, 促销v3.0, 订单v6.0等；
[0071] 步骤s14, 刷新缓存并将建立的灰度染色分组决策推送至redis配置中心。
[0072] 参考图5，该图是本发明一种多版本共存的应用服务系统的数据传输方法的第二种实施例的示意图，该流程包括如下步骤：
[0073] 步骤s201,反向代理服务器拦截所有客户的订单请求；
[0074] 步骤s202, 反向代理服务器通过配置服务器进行检测和规则引擎计算，具体的，通过lua+redis脚本进行检测并根据配置服务器的灰度染色分组特性做规则引擎计算；
[0075] 步骤s203, 反向代理服务器判断当前调用是否需灰度染色分组，若是，则执行步骤s204，否则，执行步骤s205；
[0076] 步骤s204, 反向代理服务器获取灰度染色分组编号，并将灰度染色分组编号写入http header头信息中；
[0077] 步骤s205, 反向代理服务器判定不需要染色分组，按照常规链路传输当前的订单请求；
[0078] 步骤s206, 反向代理服务器负载在应用服务器前，判断当前订单请求的信息头是否包含灰度染色分组编号，若是，步骤s207,否则，执行步骤s205；
[0079] 步骤s207，则获取当前订单请求的灰度染色分组编号；
[0080] 步骤s208, 根据灰度染色分组编号和应用服务名称获取灰度服务器信息，具体实现时, 通过配置服务器获取灰度服务器信息，此处的灰度服务器为指定的灰度染色分组的
应用服务器；
[0081] 步骤s209,将订单请求发送给灰度服务器；
[0082] 步骤s210,灰度服务器接收订单请求并获取灰度染色分组编号；
[0083] 步骤s211,灰度服务器根据灰度染色分组编号向配置服务器查询是否存在与该灰度染色分组编号对应的灰度版本，若是，则执行s212,,否则，执行s213,；
[0084] 步骤s212,运行调用灰度版本；
[0085] 步骤s213,运行调用默认常规版本。
[0086] 需要说明的，本发明实施例中的灰度流量标识（携带有灰度染色分组的订单请求）可借助全局trace组件向下传输，参考图6，该图是本发明一种多版本共存的应用服务系统
的数据传输方法中灰度链路传输示意图，该实施例中有三条灰度链路，分别是A‑B1‑C2‑D、
A1‑B1‑C‑D、A2‑B‑C3‑D4。从图中可见，在传播的过程中不同的灰度链路可以相互交叉存在，
从而不需要进行物理隔离，就实现了多版本的共存，节省了物理设备，节约了成本，提高了
应用服务系统的工作效率。
[0087] 以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为
本发明的保护范围。
