邱 芳

（上海浦东发展银行股份有限公司，上海 200002）

0 引 言

目前互联网主流的路由分发方式主要是通过负载均衡设备或网关层等预设好分区标示进行分发，标示类型大致分用户的ID、手机和浏览器类型以及某一地区用户和同一运营商用户等。饿了么和滴滴就是按照地域信息进行流量切分，将用户下单和商户接单等核心流程放在一台服务器中处理。以业内银行的互联网应用系统群为例，互联网应用系统群在异地双中心部署，两地双活，使用DNS、LTM、WAF及Gateway等网络设备和中间件控制请求分发路由，但这样的方式存在一些弊端，如分发策略较为固定、无法对用户请求精准分发以及稳定性易受运营商影响等。

此外，互联网应用的一大特点是高频版本迭代，应用变更存在一定风险，部分集群变更产生的异常需要有迅速应急机制。系统架构日趋复杂，对系统、设备及机房提出更高的要求，在单个机房出现故障时要做到迅速响应。通过精准路由分发可以实现机房或集群级别的请求分发控制，同时也提高了系统对机房级别故障的容错性[1-10]。

1 总体设计

1.1 需求目标

互联网系统群路由分发体系需要客户端或App同步改造，该体系最重要的部分是一个对客户端每次启动时的首次请求进行处理的微服务模块，即智能路由分发微服务，借助该服务可以实现路由分发控制。该微服务可根据系统的业务和架构特性定制化部署在多个系统上，下面以手机银行为例。

1.2 总体设计思想

1.2.1 同一会话中控制同一用户访问同一地域

智能路由分发微服务部署在手机银行App原有的域名下，App每次启动时的第一个请求会触发该微服务。智能路由分发微服务会识别请求所在的地域返回其域名信息给客户端，客户端获取到域名信息后，此次会话的后续请求都会通过该域名访问。该用户本次会话都会访问固定地域机房，再结合手机银行应用的原有会话保持机制，尽量保证该用户某业务场景一直由固定的服务器提供服务，减少网络延迟，优化用户体验。

1.2.2 根据规则选定特定用户

在某些需要调整机房用户比例或改变原有分发方式业务场景的情况下，智能路由分发微服务可以根据地域和用户等信息选定特定用户访问特定地区。如手机银行系统设置用户白名单,也可以根据手机设备号和客户标示等信息进行Hash处理，使得满足该条件的用户请求都进入同一地区。

1.2.3 应急措施

为提高应急响应速度，适应业务需求，可通过管理端配置更换域名。原有Wap域名所属架构依然保留。当某一地区域名出现问题时，原生App可切换至Wap域名下。需要选定特定用户的情况下，可根据业务场景和实际情况更换域名。

2 传统系统架构

2.1 传统系统架构存在的问题

传统系统架构存在3个方面的问题。一是依靠域名系统（Domain Name System，DNS）、Web应用防护系统（Web Application Firewall，WAF）以及网络负载均衡与网关等进行请求分发，但无法控制用户请求精准分发。二是会话漂移现象，同一用户请求会在上海或合肥漂移，导致用户会话中断，出现闪退等现象。三是机房层面和集群层面的故障应急响应仅依靠域名系统，当某一分中心出现问题时响应速度较慢，系统容错性有待提高。传统系统架构如图1所示。

图1 传统系统架构图

2.2 传统系统运行情况

互联网系统群主要包括个人网银、个人手机、公司网银以及电子商务支付平台等。其中，个人手机银行系统异地双中心与多集群部署（K1、K2)需要通过域名系统解析该域名，若解析为其中一个地区机房公网地址，则分发到该地区机房，再通过网络负载均衡设备分发进入某一后台服务。

2.3 急需解决问题

2.3.1 路由分发机制

传统互联网系统群依赖于域名系统、网络安全防护系统以及负载均衡等路由分发机制，分发策略固定，无法精准控制请求分发，系统的应急响应机制和容错性有待提升。

2.3.2 两地IP漂移

同一个会话中客户端请求进入其中一个地区后台服务，接下来请求可能会漂移到异地中心的集群，导致之前的会话消失。

2.3.3 复杂的用户数据验证以及系统并发性能稳定

目前大型互联网类系统普遍部署超过500个微服务，当上线一个新系统或服务模块时都面临复杂的用户数据验证及系统并发性能稳定的考验，测试环境中的案例不能完全涵盖实际情况，通过路由分发进行版本控制，可以有效验证应用的稳定性。

3 实现过程

3.1 应用功能实现

在不改变业务逻辑的情况下，建设互联网系统群路由分发体系，提升路由分发能力，提高系统容错性，进一步实现互联网系统群特有的分布式架构，支撑未来业务发展。基于域名实现分流，同一个系统分流到不同域名，从而实现客户的分流。此外，该方案可以提升系统的容错性，有利于数据库切分和上云多区域分发，方案总体架构如图2所示。

图2 总体架构图

3.2 主要业务流程

改造后，用户访问业务流程如下。

3.2.1 基于多域名分发

客户打开手机银行App，App启动时会触发请求该域名下的智能路由分发微服务，通过域名系统解析获取公网IP后通过硬件负载均衡设备分发至微服务系统群网关，网关通过Eureka Client获取服务列表后根据客户端负载均衡策略将客户请求分发至对应微服务地址，通过该请求得到集群地域返回对应地区域名，从而实现多域名分发服务。另外，当需要选定部分用户分发到特定地区A时，则在请求到达对应智能路由分发微服务之后，首先判断请求的集群地域，再根据设备号等判断该客户是否命中参与规则。若命中，则返回地区A域名（wapabst.a.com.cn）；若不命中，则返回地区B域名（wapcdst.b.com.cn）。

3.2.2 异常处理流程

（1）若单个集群出现问题，如地区A的K1集群。第一种情况，智能路由分发微服务服务正常，K1集群智能路由分发微服务返回了地区A：wapabst.a.com.cn域名，则停掉转发给K1的流量，此时上海K2集群对外服务。第二种情况，智能路由分发微服务异常，K1 的智能路由分发微服务将不会返回上海域名：客户端在拿不到返回域名的情况下，默认走wap域名，这时地区A还有K2对外服务。

（2）某一分中心机房出现问题，如地区B。第一种情况，地区B的智能路由分发微服务服务还正常，对外返回地区B域名：将地区B的集群DNS域名解析的地址改为地区A域名的公网IP；.及时调整地区B的智能路由分发微服务返回域名，调整成返回地区A域名；第二种情况，地区B的智能路由分发微服务异常，将不会返回地区B域名：则客户端在拿不到返回域名的情况下，默认走wap域名，地区A还有K1、K2对外服务，此时，wap域名DNS解析改为地区A机房的公网IP，从而保证对外正常服务。

3.3 微服务设计实现

以常规手机银行为例，该微服务部署在Caas集群上，物理架构如图3所示。

图3 物理架构图

3.4 客户端设计实现

客户端/APP配合改造，每次启动时首次访问会触发智能路由分发微服务。智能路由分发微服务管理端可以配置参数，更换域名。客户端根据智能路由分发微服务返回值更换域名。

3.5 负载均衡实现

根据域名分发，用WAF和Gateway混合实现LB，WAF使用最小连接数负载均衡策略，不进行源地址会话保持。

4 结 论

基于大型互联网系统群路由分发技术的应用，参考互联网路由模式，互联网系统群路由分发体系的目标是通过智能路由分发微服务识别请求中用户标识，配合域名规则，将指定范围内的用户请求精确分发到指定逻辑机房。分发策略灵活精确，能更好地满足多地多逻辑机房分发需求，不仅有利于互联网系统群分布式架构建设，而且也适用于数据库及对应的微服务分片解耦、多中心分发以及上云后的多区域分发。