基于银行系统的服务发布方法、系统、设备及存储介质与流程

1.本发明涉及银行分布式系统技术领域，尤其涉及一种基于银行系统的服务发布方法、系统、设备及存储介质。


背景技术：

2.分布式系统是建立在网络之上的软件系统，其具有高度的内聚性和透明性，使用分布式系统能够带来性能和效率上的提升，但目前分布式系统的稳定性还有待进一步提高。双活指两个数据中心可同时对外提供服务，在保障容灾的同时，起到来访用户流量负载均衡的作用，能够保证分布式系统特别是银行业务系统在防范地震和海啸等不可抗力因素下的稳定性和可靠性，避免银行业务系统出现数据丢失甚至核心业务瘫痪等问题，但采用双活的方式还不能够在面对银行服务升级或服务版本迭代过程中保障银行业务系统的稳定性。


技术实现要素：

3.有鉴于此，本技术的目的之一在于提供一种基于银行系统的服务发布方法、系统、设备及存储介质，能够至少解决上述部分技术问题。
4.第一方面，本技术实施例提供了一种基于银行系统的服务发布方法，所述方法包括：
5.接收银行用户的访问请求，所述访问请求用于访问银行应用的微服务；
6.在检测所述访问请求符合第一预设条件的情况下，将所述访问请求灰度路由至第一目标pod，其中，所述第一目标pod位于第一数据中心；
7.在检测所述访问请求符合第二预设条件的情况下，将所述访问请求灰度路由至第二目标pod，其中，所述第一目标pod和所述第二目标pod均用于提供更新后的所述微服务，所述第二目标pod位于第二数据中心，所述第一数据中心和所述第二数据中心组成双活数据中心。
8.在一种可能的实施方式中，在所述接收银行用户的访问请求之后，所述方法还包括：
9.根据所述访问请求确定所述银行用户的地址；
10.计算所述银行用户的地址和全部目标地址之间的目标距离，得到目标距离数据集，其中，每个所述目标地址对应一个所述第一数据中心，所述目标距离数据集中的全部目标距离按升序排列；
11.所述第一预设条件包括：
12.检测到所述银行用户的地址对应的目标地址在所述目标距离数据集中排首位；
13.所述第一预设条件还包括：
14.检测到响应码为异常响应码的数量小于或等于第一预设数量，所述响应码为所述访问请求对应的响应状态码，和/或，
15.未检测到切换指令，所述切换指令用于切换所述访问请求所请求访问的数据中心。
16.在一种可能的实施方式中，所述第二预设条件包括：
17.检测到所述响应码为异常响应码的数量大于所述第一预设数量，和/或，检测到所述切换指令。
18.在一种可能的实施方式中，所述方法还包括：
19.在检测到所述访问请求的数量大于或等于第二预设数量的情形下，增加所述第一数据中心和/或所述第二数据中心中的pod总数；
20.在检测到所述访问请求的数量小于所述第二预设数量的情形下，保持所述第一数据中心和/或所述第二数据中心中的pod总数不变，或，减少所述第一数据中心和/或所述第二数据中心中的pod总数。
21.在一种可能的实施方式中，增加或减少所述第一数据中心和/或所述第二数据中心中的pod总数的方式，包括：
22.按预设时间间隔检测所述第一数据中心和/或所述第二数据中心中的pod度量；
23.根据所述pod度量计算满足pod水平自动伸缩资源所配置的目标数值所需的pod副本数量，得到目标pod副本数量；
24.将所述第一数据中心和/或所述第二数据中心中的pod总数对应的pod副本数量更新为所述目标pod副本数量。
25.在一种可能的实施方式中，所述将所述访问请求灰度路由至第一目标pod，包括：
26.将所述访问请求发送至所述第一数据中心中的网关；
27.通过所述网关将所述访问请求灰度路由至所述第一目标pod。
28.在一种可能的实施方式中，所述第一数据中心包括第一数据库和第一中间件，所述第二数据中心包括第二数据库和第二中间件，其中，所述第一中间件和所述第二中间件之间服务同步；
29.在所述将所述访问请求发送至第一目标pod之后，所述方法还包括：
30.检测所述访问请求在访问所述微服务的过程中产生的银行业务信息；
31.将所述银行业务信息通过所述第一中间件存储至第一数据库；
32.将所述银行业务信息从所述第一数据库同步至所述第二数据库。
33.第二方面，本技术实施例提供了一种基于银行系统的服务发布系统，所述系统包括：
34.接收模块，用于接收银行用户的访问请求，所述访问请求用于访问银行应用的微服务；
35.第一检测模块，用于在检测所述访问请求符合第一预设条件的情况下，将所述访问请求灰度路由至第一目标pod，其中，所述第一目标pod位于第一数据中心；
36.第二检测模块，用于在检测所述访问请求符合第二预设条件的情况下，将所述访问请求灰度路由至第二目标pod，其中，所述第一目标pod和所述第二目标pod均用于提供更新后的所述微服务，所述第二目标pod位于第二数据中心，所述第一数据中心和所述第二数据中心组成双活数据中心。
37.第三方面，本技术实施例提供了一种计算机设备，所述计算机设备包括存储器及
处理器，所述存储器上存储有计算机程序，所述计算机程序在被所述处理器执行时，实现第一方面提供的基于银行系统的服务发布方法。
38.第四方面，本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序在被一个或多个处理器执行时，实现第一方面提供的基于银行系统的服务发布方法。
39.本技术提供的基于银行系统的服务发布方法，通过接收银行用户用于访问银行应用的微服务的访问请求，并在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心，在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心，能够在重大灾难事件发生时保证银行业务系统不间断运行，并且以灰度路由的方式可以保证在银行服务升级的过程中保障银行业务系统的稳定性。
附图说明
40.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，应当理解，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
41.图1为本技术实施例提供的一种基于银行系统的服务发布方法的方法流程图；
42.图2为本技术实施例所提供的的一种基于银行系统的服务发布方法所涉及的总体框架逻辑图；
43.图3为本技术实施例提供的一种基于银行系统的服务发布系统的功能模块示意图；
44.图4为本技术实施例提供的一种计算机设备内部结构图。
45.附图标记说明：
46.基于银行系统的服务发布系统300，接收模块310，第一检测模块320，第二检测模块330。
具体实施方式
47.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
48.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本技术实施例的组件可以以各种不同的配置来布置和设计。
49.因此，以下对在附图中提供的本技术的实施例的详细描述并非旨在限制要求保护的本技术的范围，而是仅仅表示本技术的选定实施例。基于本技术中的实施例，本领域普通
技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
50.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
51.在本技术的各种实施例汇中，表述“或”或“a或/和b中的至少一个”包括同时列出的文字的任何组合或所有组合。例如，表述“a或b”或“a或/和b中的至少一个”可包括a、可包括b或可包括a和b二者。
52.在本技术的描述中，需要说明的是，若出现术语“上”、“下”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本技术和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本技术的限制。
53.此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
54.需要说明的是，在不冲突的情况下，本技术的实施例中的特征可以相互结合。
55.请参见图1，图1为本技术实施例提供的一种基于银行系统的服务发布方法的方法流程图，以下将对该方法的各个步骤进行详细阐述。
56.s110，接收银行用户的访问请求，访问请求用于访问银行应用的微服务。
57.在本实施例中，银行系统可以包括银行的核心系统、综合前置系统、ic卡系统中的至少一种，其中，银行的核心系统可以包括共用信息、凭证管理、现金出纳、柜员支持、总账会计、内部账管理、客户信息、活期存款、定期存款、外壁兑换、往来业务、资金清算和股金管理中的至少一种，可视实际需求进行设定，此处不做限定。
58.银行用户的访问请求可以用于访问银行应用的微服务，也可以理解为用于访问上述中提到的具体的银行系统，或者访问上述提到的具体的银行系统中的某一个功能。其中，微服务可以理解为面向服务的进一步发展，是一个独立的职责单一的服务应用程序，可以指服务中一个模块提供的服务，也可以指应用中一个模块提供的服务。
59.在本实施例中，银行用户的访问请求所访问的银行应用或银行服务的微服务部署在kuberbetes容器中或者说部署在k8s容器中，其中，kubernetes简称k8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，其目标是让部署容器化的应用简单并且高效，可以理解为一个容器集群管理系统，另外，k8s将集群中的所有机器都视为单个资源池的一部分，也是一个架构良好的分布式系统。
60.s120，在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心。
61.具体的，pod是k8s应用程序的基本执行单元，表示处于运行状态的一组容器，并非进程而是容器运行的环境，其中，一个pod可以运行一个容器或多个容器，由于pod内的ip地址是不固定的，集群外的请求是不能直接访问pod的。访问请求可以通过灰度路由的形式访问第一数据中心中的第一目标pod，可以理解本实施例能够实现通过k8s实现灰度发布。具体的，可以创建k8s部署和k8s服务，k8s部署将在生产环境中逐步替换旧版本的应用程序，k8s服务可以负责将流量或者说访问请求路由到新版本的应用程序和旧版本的应用程序之间，保证在部署新版本器件不会中断现有的流量或访问请求。
62.其中，灰度发布的原理是将新版本的应用程序逐步引入生产环境，以便在部署新版本之前进行测试和验证，能够减少生产环境中出现问题的风险，并确保新版本的稳定性和可靠性。本实施例中的第一目标pod包括多个pod，一部分pod位于标准集群中，一部分pod位于灰度集群中，其中，标准集群和灰度集群组成灰度发布的一部分。
63.可选的，在接收银行用户的访问请求之后，方法还包括：
64.根据访问请求确定银行用户的地址；
65.计算银行用户的地址和全部目标地址之间的目标距离，得到目标距离数据集，其中，每个目标地址对应一个第一数据中心，目标距离数据集中的全部目标距离按升序排列；
66.第一预设条件包括：
67.检测到银行用户的地址对应的目标地址在目标距离数据集中排首位；
68.第一预设条件还包括：
69.检测到响应码为异常响应码的数量小于或等于第一预设数量，响应码为访问请求对应的响应状态码，和/或，
70.未检测到切换指令，切换指令用于切换访问请求所请求访问的数据中心。
71.在本实施例中，访问请求可以包括访问时间、访问地址、使用的设备、系统、手机和用户ip地址等，其中，根据访问请求确定银行用户的地址，可以理解为对银行用户的访问请求进行解析得到银行用户的ip地址。
72.目标地址可以理解为第一数据中心的ip地址，通过各自ip地址所在无线局域网可以粗略估计目标地址和银行用户的地址之间的距离，本实施例中检测到银行用户的地址对应的目标地址在目标距离数据集中排首位，可以理解为排首位对应的目标地址和银行用户的地址最近，也可以理解为排首位对应的目标地址处的第一数据中心和银行用户的地址最近，确定距离之后，能够进一步实现银行用户的请求就近访问功能。
73.其中，响应码为银行用户的访问请求对应的响应状态码，响应码为异常表示访问失败或当前访问请求不被允许，其中，访问失败也可能是网络出现故障导致的。当异常响应码的数量小于或等于第一预设数量，表示银行用户当前访问的数据中心仍处于正常工作状态，当异常响应码的数量大于第一预设数量，表示银行用户当前访问的数据中心无法正常工作或无法被正常访问。切换指令可以理解为主动切换，表示银行用户当前访问的数据中心不允许被访问，银行用户的访问请求被切换至备用数据中心，其中，若银行用户当前访问的数据中心为第一数据中心，备用数据中心为第二数据中心，能够保证银行业务的不间断，保障银行用户的正常访问。
74.s130，在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心。
75.在本实施例中，第二数据中心是相对第一数据中心而言的，第一数据中心和第二数据中心可组成双活数据中心，若将第一数据中心看作热备份数据中心，则第二数据中心为冷备份数据中心，可以理解的是，在热备份的情况下，只有主数据中心或第一数据中心承担银行用户的业务，与主数据中心相对的备数据中心或第二数据中心可以对主数据中心或第一数据中心进行实时备份，备数据中心可以自动接管主数据中心的业务，避免银行用户的业务终端，同时，银行用户也感受不到数据中心的切换。在冷备份的情况下，可以理解主
数据中心损坏，银行用户的业务被迫中断。
76.可选的，第二预设条件包括：
77.检测到响应码为异常响应码的数量大于第一预设数量，和/或，检测到切换指令。
78.具体的，第二预设条件的介绍可参照上述实施例中针对第一预设条件的介绍，此处不再赘述。
79.由上述分析可知，通过接收银行用户用于访问银行应用的微服务的访问请求，并在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心，在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心，能够在重大灾难事件发生时保证银行业务系统不间断运行，并且以灰度路由的方式可以保证在银行服务升级的过程中保障银行业务系统的稳定性。
80.在一种可能的实施方式中，在检测到访问请求的数量大于或等于第二预设数量的情形下，增加第一数据中心和/或第二数据中心中的pod总数；
81.在检测到访问请求的数量小于第二预设数量的情形下，保持第一数据中心和/或第二数据中心中的pod总数不变，或，减少第一数据中心和/或第二数据中心中的pod总数。
82.在本实施例中，考虑到服务请求的负载突然增加，第一数据中心和/或第二数据中心中的服务资源紧张，pod数量不够，如在银行在购物节优惠或促销惠民便利将吸引大量银行用户访问，第一数据中心和/第二数据中心中的pod数量不足以支撑银行用户的访问服务，这种情形下，可以适当地增加pod数量。相反的，在非购物节且凌晨时期，银行用户的访问请求较少，用不到较多的pod，这种情形下，可以适当次减少pod数量，已实现k8s容器化部署的弹性伸缩，在访问请求多的时候充分利用资源，在访问请求少的时候也能实现对资源的合理使用，不浪费资源开销。
83.访问量激增不仅仅体现在银行在购物节实现优惠促销中，在身份证实名激活赠福利、甚至在银行内部金融业务的自查，也会导致访问量激增，还比如中国银行业监督管理委员会对银行的业务进行审查，均会导致银行业务的访问量激增，可以适当地增减第一数据中心和/或第二数据中心的中的pod。
84.可选的，增加或减少第一数据中心和/或第二数据中心中的pod总数的方式，包括：
85.按预设时间间隔检测第一数据中心和/或第二数据中心中的pod度量；
86.根据pod度量计算满足pod水平自动伸缩资源所配置的目标数值所需的pod副本数量，得到目标pod副本数量；
87.将第一数据中心和/或第二数据中心中的pod总数对应的pod副本数量更新为目标pod副本数量。
88.具体的，实现第一数据中心和/或第二数据中心中的pod的增减可以通过本实施例中改变pod副本数量而实现。
89.在一种可能的实施方式中，将访问请求灰度路由至第一目标pod，包括：
90.将访问请求发送至第一数据中心中的网关；
91.通过网关将访问请求灰度路由至第一目标pod。
92.具体的，本实施例中用到的网关为k8s集群中部署的ingress网关，是k8s中的一个
api对象，可以用来定义请求如何转发到服务的规则，可以理解为配置模板，充当一个反向代理的角色，并且是通过控制器对ingress定义的规则进行解析并根据配置的规则实现请求转发。
93.在一种可能的实施方式中，第一数据中心包括第一数据库和第一中间件，第二数据中心包括第二数据库和第二中间件，其中，第一中间件和第二中间件之间服务同步；
94.在将访问请求发送至第一目标pod之后，方法还包括：
95.检测访问请求在访问微服务的过程中产生的银行业务信息；
96.将银行业务信息通过第一中间件存储至第一数据库；
97.将银行业务信息从第一数据库同步至第二数据库。
98.在本实施例中，中间件指的是一种独立的系统软件或服务程序，分布式应用借助这种软件在不同的技术之间共享资源，是系统软件和用户应用软件之间连接的软件，可为处于上层的应用软件提供运行与开发环境。第一中间件和第二中间件为相同中间件，包括zookeeper中间件和mq中间件中的至少一种，第一中间和第二中间件之间的服务实现同步，具体的服务同步方式视选用不同类型的中间件不同而不同，此处不作限定。第一数据库和第二数据库为相同数据库，包括redis和mysql数据库中的至少一种，第一数据库向第二数据库进行数据同步。
99.为进一步说明书本技术的方案，请参见图2，图2为本技术实施例所提供的的一种基于银行系统的服务发布方法所涉及的总体框架逻辑图，其中，
100.全局负载均衡(global server load balance，简称gslb)，用于实现银行用户的访问请求的就近访问功能，如将银行用户的访问请求发送至第一数据中心。
101.f5负载均衡设备，是k8s的负载均衡设备，可以提供服务器负载均衡、多链路的负载均衡和冗余、防火墙负载均衡、系统高可用性，并且具有很高的安全性。当银行用户发起访问请求时，k8s内部的dns服务器会先对访问请求进行域名解析，然后通过内网的gslb设备按找配置或比例或根据本地优先的方式返回容器f5地址，上述实施例中的第一预设条件综合了gslb设备和f5设备的工作过程，第二预设条件可以理解为对应f5设备的工作条件。
102.银行用户的访问请求从f5设备流入k8s容器，再经过服务映射到ngnix ingress网关，决策访问请求的灰度分发。
103.canary是灰度发布，指定的灰度分发逻辑包括header、cookie、weight和header value中的至少一种。其中的standard cluster为上述实施例中提及的标准集群，gray cluster为上述实施例中提及的灰度集群。
104.loadbalancer也属于负载均衡设备，node port是节点端口，和上述实施例提到的ingress一样，都是集群外部流量导入到集群内的方式，只是各自实现的方式不同。
105.关于中间件和数据库请参见上述实施例中的介绍，此处不再赘述，需要注意的是，第一数据中心和第二数据中心形成了应用级双活，指的是系统在双中心为双活部署，而数据库在双中心为主备部署，本示例中的应用级双活不依赖存储设备厂商，在数据库层面通过主备模式降低了双中心部署难度。第一数据中心的中间件为上述实施例中的第一中间件，第二数据中心的中间件为上述实施例中的第二中间件，第一数据中心中的数据库为上述实施例中的第一数据库，第二数据中心中的数据库为第二数据库。
106.综上，本技术实施例提供的一种基于银行系统的服务发布方法，通过接收银行用
户用于访问银行应用的微服务的访问请求，并在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心，在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心，能够在重大灾难事件发生时保证银行业务系统不间断运行，并且以灰度路由的方式可以保证在银行服务升级的过程中保障银行业务系统的稳定性。
107.与上述方法实施例相对应，本技术还提供一种基于银行系统的服务发布系统300，请参见图3，图3为本技术实施例提供的一种基于银行系统的服务发布系统的功能模块示意图，其中，所述系统包括：
108.接收模块310，用于接收银行用户的访问请求，访问请求用于访问银行应用的微服务；
109.第一检测模块320，用于在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心；
110.第二检测模块330，用于在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心。
111.本技术实施例提供的一种基于银行系统的服务发布方法，根据接收模块接收银行用户用于访问银行应用的微服务的访问请求，并根据第一检测模块在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心，根据第二检测模块在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心，能够在重大灾难事件发生时保证银行业务系统不间断运行，并且以灰度路由的方式可以保证在银行服务升级的过程中保障银行业务系统的稳定性。
112.本技术还提供一种计算机设备，请参见图4，图4为本技术实施例提供的一种计算机设备内部结构图。其中，计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现上述实施例中应用于计算机设备的基于银行系统的服务发布方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行基于银行系统的服务发布方法。本领域技术人员可以理解，图4中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
113.本技术实施例还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现如方法实施例中的基于银行系统的服务发布方法。
114.本技术提供的计算机设备及计算机可读存储介质，可通过接收银行用户用于访问银行应用的微服务的访问请求，并在检测访问请求符合第一预设条件的情况下，将访问请
求灰度路由至第一目标pod，其中，第一目标pod位于第一数据中心，在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，其中，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心，能够在重大灾难事件发生时保证银行业务系统不间断运行，并且以灰度路由的方式可以保证在银行服务升级的过程中保障银行业务系统的稳定性。
115.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldra m)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drd ram)、以及存储器总线动态ram(rdram)等。
116.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

技术特征：
1.一种基于银行系统的服务发布方法，其特征在于，所述方法包括：接收银行用户的访问请求，所述访问请求用于访问银行应用的微服务；在检测所述访问请求符合第一预设条件的情况下，将所述访问请求灰度路由至第一目标pod，其中，所述第一目标pod位于第一数据中心；在检测所述访问请求符合第二预设条件的情况下，将所述访问请求灰度路由至第二目标pod，其中，所述第一目标pod和所述第二目标pod均用于提供更新后的所述微服务，所述第二目标pod位于第二数据中心，所述第一数据中心和所述第二数据中心组成双活数据中心。2.如权利要求1所述的基于银行系统的服务发布方法，其特征在于，在所述接收银行用户的访问请求之后，所述方法还包括：根据所述访问请求确定所述银行用户的地址；计算所述银行用户的地址和全部目标地址之间的目标距离，得到目标距离数据集，其中，每个所述目标地址对应一个所述第一数据中心，所述目标距离数据集中的全部目标距离按升序排列；所述第一预设条件包括：检测到所述银行用户的地址对应的目标地址在所述目标距离数据集中排首位；所述第一预设条件还包括：检测到响应码为异常响应码的数量小于或等于第一预设数量，所述响应码为所述访问请求对应的响应状态码，和/或，未检测到切换指令，所述切换指令用于切换所述访问请求所请求访问的数据中心。3.如权利要求2所述的基于银行系统的服务发布方法，其特征在于，所述第二预设条件包括：检测到所述响应码为异常响应码的数量大于所述第一预设数量，和/或，检测到所述切换指令。4.如权利要求1所述的基于银行系统的服务发布方法，其特征在于，所述方法还包括：在检测到所述访问请求的数量大于或等于第二预设数量的情形下，增加所述第一数据中心和/或所述第二数据中心中的pod总数；在检测到所述访问请求的数量小于所述第二预设数量的情形下，保持所述第一数据中心和/或所述第二数据中心中的pod总数不变，或，减少所述第一数据中心和/或所述第二数据中心中的pod总数。5.如权利要求4所述的基于银行系统的服务发布方法，其特征在于，增加或减少所述第一数据中心和/或所述第二数据中心中的pod总数的方式，包括：按预设时间间隔检测所述第一数据中心和/或所述第二数据中心中的pod度量；根据所述pod度量计算满足pod水平自动伸缩资源所配置的目标数值所需的pod副本数量，得到目标pod副本数量；将所述第一数据中心和/或所述第二数据中心中的pod总数对应的pod副本数量更新为所述目标pod副本数量。6.如权利要求1所述的基于银行系统的服务发布方法，其特征在于，所述将所述访问请求灰度路由至第一目标pod，包括：
将所述访问请求发送至所述第一数据中心中的网关；通过所述网关将所述访问请求灰度路由至所述第一目标pod。7.如权利要求1所述的基于银行系统的服务发布方法，其特征在于，所述第一数据中心包括第一数据库和第一中间件，所述第二数据中心包括第二数据库和第二中间件，其中，所述第一中间件和所述第二中间件之间服务同步；在所述将所述访问请求发送至第一目标pod之后，所述方法还包括：检测所述访问请求在访问所述微服务的过程中产生的银行业务信息；将所述银行业务信息通过所述第一中间件存储至第一数据库；将所述银行业务信息从所述第一数据库同步至所述第二数据库。8.一种基于银行系统的服务发布系统，其特征在于，所述系统包括：接收模块，用于接收银行用户的访问请求，所述访问请求用于访问银行应用的微服务；第一检测模块，用于在检测所述访问请求符合第一预设条件的情况下，将所述访问请求灰度路由至第一目标pod，其中，所述第一目标pod位于第一数据中心；第二检测模块，用于在检测所述访问请求符合第二预设条件的情况下，将所述访问请求灰度路由至第二目标pod，其中，所述第一目标pod和所述第二目标pod均用于提供更新后的所述微服务，所述第二目标pod位于第二数据中心，所述第一数据中心和所述第二数据中心组成双活数据中心。9.一种计算机设备，其特征在于，所述计算机设备包括存储器及处理器，所述存储器上存储有计算机程序，所述计算机程序在被所述处理器执行时实现权利要求1-7中任一项所述的基于银行系统的服务发布方法。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该计算机程序在被一个或多个处理器执行时，实现权利要求1-7中任一项所述的基于银行系统的服务发布方法。

技术总结
本发明实施例公开了一种基于银行系统的服务发布方法、系统、设备及存储介质，涉及银行分布式系统技术领域，包括接收银行用户的访问请求，访问请求用于访问银行应用的微服务；在检测访问请求符合第一预设条件的情况下，将访问请求灰度路由至第一目标pod，第一目标pod位于第一数据中心；在检测访问请求符合第二预设条件的情况下，将访问请求灰度路由至第二目标pod，第一目标pod和第二目标pod均用于提供更新后的微服务，第二目标pod位于第二数据中心，第一数据中心和第二数据中心组成双活数据中心。本发明双活数据中心能够在重大灾难事件发生时保证银行业务系统不间断运行，且以灰度路由的方式在银行服务升级的过程中保障银行业务系统的稳定性。务系统的稳定性。务系统的稳定性。


技术研发人员：叶云娴
受保护的技术使用者：平安银行股份有限公司
技术研发日：2023.06.02
技术公布日：2023/8/23