保险运营平台的灰度发布方法、系统、装置与流程

1.本技术涉及保险金融科技领域，具体而言，涉及一种保险运营平台的灰度发布方法、灰度发布系统、灰度发布装置及计算机可读存储介质。


背景技术：

2.随着软件技术的迅速发展，软件产品的迭代开发速度越来越快，尤其是互联网金融科技领域，对于开发产品的要求也越来越高，在高要求的情况下对于产品的运维也越来越难，企业需要保证开发系统的7*24 小时不间断的稳定运行，并且保持高速稳定的迭代能力，特别是保险行业领域。
3.具体而言，在保险新产品版本更新时， 企业往往选择凌晨更新，以避免对业务产生影响。而为了防止更新的时候出现各种问题，常常需要开发人员、测试人员、运维人员、业务人员同时在场，涉及面较广，对于产品的维护团队带来的工作压力是巨大的。而当版本出现不可控的问题时，版本回滚的成本也是非常之高的。
4.灰度发布是指在新版本发布时不直接覆盖旧的版本，而是有一段新旧版本的共存时间，通过逐渐增加新版本承担的负载权重，直到完全替代旧的版本。在现有的灰度发布中，如果发布过程中出现问题，回滚耗时长、对业务影响较大。
5.随着保险业务产品的用户量和使用量的增加，单点的技术架构已经无法满足用户对于保险产品的要求，而目前比较流行的基于分布式的产品架构则因为涉及的服务过多，往往造成机器占用资源过高的问题，常规的灰度发布已经无法满足保险金融科技的需求。


技术实现要素：

6.为了解决上述问题，本发明的目的是提供一种保险运营平台的灰度发布方法，所述保险运营平台包括正式版本和晚于正式版本发布的灰度版本，所述灰度发布用于在测试所述灰度版本的同时，保证正式版本的正常运行，在测试所述灰度版本前，使用所述保险运营平台的用户群体使用所述正式版本，所述正式版本运行于所述保险运营平台的整体环境，其特征在于：将所述保险运营平台的整体环境按指定比例划分为正式发布环境和灰度发布环境，所述正式发布环境用于运行所述正式版本，所述灰度发布环境用于测试所述灰度版本；在所述正式发布环境和所述灰度发布环境中部署相同的服务；将所述正式发布环境和所述灰度发布环境隔离；完成所述隔离后，对所述服务进行分流，使得在所述正式发布环境内，只能调用所述正式发布环境内部的服务，在所述灰度发布环境内，只能调用所述灰度发布环境内部的服务；使所述灰度版本与所述正式版本使用相同的数据源；将所述用户群体进行用户分流，使所述用户群体中的部分用户进入所述灰度发布环境，以测试所述灰度版本，使所述用户群体中未进入所述灰度发布环境的用户进入所述
正式发布环境，以继续使用所述正式版本。
7.根据前述的方法，其特征在于：采用动态ip配置的方法进行所述划分。
8.根据前述的方法，其特征在于：划分出所述正式发布环境和所述灰度发布环境的所述指定比例介于7:3~9:1之间。
9.根据前述的方法，其特征在于：所述服务包括：前端页面，所述前端页面对应的后台服务，微服务，数据源，消息传输中间件。
10.根据前述的方法，其特征在于：通过apollo或nacos技术，使所述正式发布环境和所述灰度发布环境获取不同的系统配置，进行所述隔离。
11.根据前述的方法，其特征在于：通过dubbo或spring-cloud技术，对所述服务进行分流。
12.根据前述的方法，其特征在于：通过设置规约以使所述灰度版本与所述正式版本使用相同的数据源，所述规约是一种对开发人员设定的规范标准。
13.根据前述的方法，其特征在于：所述规约包括数据库规约，所述数据库规约为：当需要对数据库字段进行变更时，只能对字段进行增加而不能进行删除，不能进行有损变更。
14.根据前述的方法，其特征在于：所述规约包括缓存规约，所述缓存规约为：当需要对缓存集合实际存储的对象或者数据结构进行变更时，只能开启新的缓存集合以进行所述变更，而不能直接对所述缓存集合进行变更。
15.根据前述的方法，其特征在于：所述规约包括数据结构规约，所述数据结构规约为：当需要对数据结构进行变更时，对于原有字段只能进行废弃和无损更改；并且当需要进行反序列化时，忽略新增字段。
16.根据前述的方法，其特征在于：通过lua或javaagent技术控制网关，根据用户实际请求路径、访问请求携带的标识、ip、访问参数或用户信息，进行所述用户分流。
17.根据前述的方法，其特征在于：所述用户群体中进入所述灰度发布环境的用户数量少于进入所述正式发布环境的用户数量。
18.一种用于保险运营平台的灰度发布的装置，其特征在于：该装置是计算机或服务器，其可以实现前述的保险运营平台的灰度发布方法；该装置可以包括一个或者一个以上处理核心的处理器、一个或一个以上计算机可读存储介质，该装置还可以包括电源、输入输出单元。
19.一种用于保险运营平台的灰度发布的计算机可读存储介质，其特征在于，所述可
读存储介质上存储有灰度发布程序，其可以实现前述的保险运营平台的灰度发布方法。
20.本发明提供的一种保险运营平台的灰度发布方法、灰度发布系统、灰度发布装置及计算机可读存储介质，具有以下有益效果：一、代码入侵少：传统的灰度发布：在从用户操作到数据库访问整个流程，从代码的角度对访问增加用户标识，用于区分是否执行灰度环境，在访问过程中所经历微服务，网关，多线程，都需要对代码进行梳理以保证用户标识的可持续性传输。代码入侵度很高。
21.本发明的灰度发布：在配置文件的角度对整个环境进行灰度隔离，相比于传统的灰度发布，对代码入侵很少，只需要在关键代码位置改为动态配置参数，即可保证服务之间进行灰度隔离。
22.二、资源占用少：传统的灰度发布：在原本的正式环境之上，而外部署一套灰度资源用于灰度环境的部署，往往在部署过程中，为了保证因灰度环境的错误数据不会影响到正式环境，需要对数据库，缓存等中间件进行隔离区分，非常耗费额外资源。
23.本发明的灰度发布：从数据库规约的上，在灰度环境使数据库格式变更时不会影响到正式环境。在中间件层面上是可以共用一套资源，避免资源浪费，在产品运行的服务上，采用一套环境，以7：3的角度对当前环境资源进行切割，让30%的资源成为灰度资源，70%的资源成为正式环境，当灰度验证成功后，正式环境占比将达到百分之百，资源得到了充分的利用，资源占用少。
24.三、方便迭代：传统的灰度发布：代码入侵度高，在日常迭代的过程中，为了保证代码的一致性，经常采用暂停或者延长迭代周期的方法，大大的降低了产品的迭代速度，会影响到业务的正常需求。
25.本发明的灰度发布：不需要大量更新代码，只需要在关键性位置采用动态配置的方式即可，可以在日常迭代的过程中进行更改，只要配置不存在变更，会保证正常的迭代流程，当灰度上线时，只需要将配件进行变更，即可完成灰度环境切换。
附图说明
26.通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚。此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
27.显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：图1为本发明实施例中的保险运营平台的灰度发布方法原理；
图2为本发明实施例中的保险运营平台灰度发布方法的流程示意图。
具体实施方式
28.现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本发明将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。
29.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。
30.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
31.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
32.参照图1与图2所示，本技术的一种保险运营平台的灰度发布方法的具体实施例1具体包括以下步骤：s1.1: 将系统所需资源按p1：p2的比例划分，形成 a,b 两个集群。
33.整体环境分为正式环境a和灰度环境b，在 a,b 集群中，需要部署完全一致的服务。在大多数系统中，为了保证项目持续不断的稳定运行，多服务节点十分普通，此方法不会再部署难度上造成很大的困难。
34.s1.2: 运用 ip 动态配件技术方法，使 a,b 集群所属服务，在代码一致的情况下，分别使用不同的系统配置，从而达到集群内服务只能互相调用， 不可以集群之外调用的效果。此时可以将p1比例的集群作为正常节点使用，将p2比例的集群作为灰度发布应用。
35.s1.3: 设定开发规约，为了让产品使用统一数据源的前提，我们需要定义三大规约t1，t2，t3并在开发过程中严格遵循。
36.s1.4:通过网关控制，通过用户实际请求路径，访问请求携带的标识， 通过ip,访问参数,用户信息等指标进行用户分流，使小部分用户或测试用户使用灰度版本，不影响绝大用户对于正常版本的使用。
37.s1.5:在正式的运行环境中，隔离出灰度环境，实现灰度环境的系统发布，灰度环境验证失败的回滚操作，灰度环境验证成功后的上线操作，从而避免人为操作失误带来的影响。
38.参见图2，本发明实施例1的核心流程具体包括：服务分流、动态配置、灰度规约、网关控制。其中：服务分流s1.1：本发明采用dubbo技术阐明，也可以用spring-cloud技术进行代替，在spring-cloud技术中，微服务通过feign技术互相调用，feign可以指定调用的节点，
可以达到服务分流的最终结果。
39.动态配置s1.2：本发明采用apollo技术阐明，也可以用nacos进行动态配置，在项目打包的时候，分为不同的项目名，从nacos获取不同的配置，可以达到动态配置的最终结果。
40.灰度规约s1.3：本发明是对数据库、缓存、数据结构的规约，规约是一种对于开发人员设定的规范标准，为保证产品不会因为开发细节而让灰度环境影响到正式环境，从而建立的一套灰度规约。
41.网关控制s1.4：本发明采用lua技术阐明，也可以用javaagent代理的方式，进行网关限流，权限控制。可以达到网关控制的最终结果。
42.进一步的，上述s1.3步骤中的规约t1，t2，t3分别可以包括：数据库规约t1：本规约约定,当对于数据库字段进行操作时，只能对字段进行增加而不能删除，不支持有损变更，比如从 bigint 变为int，或者从varchar(255)变为varchar(10)。同时要求在代码中的查询语句不允许出现 select * 和 insert into value 等无指定的字段的全量字段查询和全量字段插入语句。本规约主要解决在使用同一数据库的前提下灰度发布的过程中不会因为数据库的变更而产生灰度版本和正常版本的不兼容的问题。
43.缓存规约t2：本规约约定，当对于缓存实际存储的对象或者数据结构发生变更时，需要开启新的缓存集合进行保存，而不能对原缓存集合进行更改，如缓存集合 car 的实际存储对象-车辆信息。增加车辆结构字段。则需要在新的版本中新建缓存集合 car-v2，将增加车辆结构的信息保存在 car-v2 中。本规约主要解决在使用同一缓存的前提下灰度发布的过程中不会因为缓存内容的变更而产生灰度版本和正常版本的不兼容的问题。
44.数据结构规约t3：在产品的处理过程中，会涉及到对于数据结构的序列化和反序列化的操作。要求对于数据结构的变更时，对于原有字段只能进行废弃和无损更改，并且对于新增字段在进行反序列化时需要忽略新增字段。本规约主要解决在使用同一数据源的前提下灰度发布的过程中不会因为数据结构的变更而产生灰度版本和正常版本的不兼容的问题。
45.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例2，其中，s1.1步骤中的比例p1：p2可为70%：30%。
46.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例3，其中，s1.1步骤中的比例p1：p2可为80%：20%。
47.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例4，其中，s1.1步骤中的比例p1：p2可为90%：10%。
48.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例5，其中，s1.3步骤中仅包括规约t1的应用。
49.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例6，其中，s1.3步骤中仅包括规约t2的应用。
50.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例7，其中，s1.3步骤中仅包括规约t3的应用。
51.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出
本技术的具体实施例8，其中，s1.3步骤中仅包括规约t1+t2的应用。
52.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例9，其中，s1.3步骤中仅包括规约t1+t3的应用。
53.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例10，其中，s1.3步骤中仅包括规约t2+t3的应用。
54.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例11，其中，s1.3步骤中包括规约t1+t2+t3的应用。
55.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例12，其中,web包括: 整个产品服务清单中分为前端页面，前端页面对应的后台服务，许多微服务，数据源，消息传输中间件，其中前端页面对应的后台服务是web，代表的是前端页面访问后端服务的第一个接触的服务。
56.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例13，其中,soa包括: 整个产品服务清单中分为前端页面，前端页面对应的后台服务，微服务，数据源，消息传输中间件。其中微服务是soa，代表的是信息传输过程中，出现物理隔离的传输操作时，由一个服务向另一个服务传递消息时，包括但不限于：http，tcp，rpc的传输方式时的下一个服务。
57.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例14，其中，db包括：整个产品服务清单中分为 前端页面，前端页面对应的后台服务，微服务，数据源，消息传输中间件。其中数据源是db，代表的是数据储存，包括但不限于：mysql，mongo，redis。
58.进一步的，基于本技术的一种保险运营平台的灰度发布方法的具体实施例1，提出本技术的具体实施例15，其中,mq包括：整个产品服务清单中分为 前端页面，前端页面对应的后台服务，微服务，数据源，消息传输中间件。其中消息传输中间件时mq，代表的是非正常服务传输，而是通过其他中间件传输的手段，包含但不限于：rabbitmq。
59.特别地，根据本发明的实施例，上文描述的方法可以被实现为计算机软件程序系统。例如，本发明的实施例包括一种计算机软件系统，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理单元(cpu)执行时，执行本技术的系统中限定的上述功能。
60.本技术实施例还提供一种电子设备，可以是计算机或服务器，其中可以实现本技术实施例提供的任一种灰度发布方法。
61.该电子设备可以包括一个或者一个以上处理核心的处理器、一个或一个以上计算机可读存储介质。该电子设备还可以包括电源、输入输出单元。本领域技术人员可以理解，以上描述并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：处理器是该电子设备的控制部分，利用各种接口和线路连接各个部分，通过运行或执行存储在计算机可读存储介质中的软件程序，执行本技术实施例提供的任一种灰度发布方法的步骤。
62.计算机可读存储介质可用于存储软件程序，即本技术实施例提供的任一种灰度发
布方法中涉及的程序。
63.处理器通过运行存储在计算机可读存储介质的软件程序，从而执行各种功能应用以及数据处理。计算机可读存储介质可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据电子设备需要使用的数据等。此外，计算机可读存储介质可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，计算机可读存储介质还可以包括存储器控制器，以提供处理器对计算机可读存储介质的访问。
64.电子设备还包括给各个部件供电的电源，优选的，电源可以通过电源管理系统与处理器逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
65.该服务器还可包括输入输出单元，比如可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入；比如可用于显示由用户输入的信息或提供给用户的信息以及服务器的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。
66.本技术实施例提供的任一种保险运营平台的灰度发布方法、系统、装置及计算机可读存储介质均基于相同的设计构思，并且本技术任一个实施例中的技术手段可以进行自由组合，组合得到的技术手段仍在本技术的保护范围之内。
67.本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。