同城双活-流量分流
作者：互联网
-
引言
现阶段，在同城带宽时延问题没有经过大规模的生产实践、验证的情况下，我们只导入“白名单或1%“的小比例请求流量，进入双活环境，确保环境有效的（活的），同时能支持“容灾切换“。那么，请求流量如何导入双活环境？有哪些分流方法？存在什么样的问题和挑战，需要注意些什么？本文将从这些角度进行剖析。 -
流量分流方法
流量分流的主要方法有：1、HTTP-DNS
2、公网GSLB（公网DNS+公网F5出口）
3、SLB（F5+Nginx）
4、内网GSLB （内网DNS+内网F5）
5、点对点软路由（Dubbo/SpringCloud）
2.1 HTTP-DNS
在口袋App渠道终端，通过HttpDNS模块，以“域名”为单位，按白名单或比例进行分流。
说明：
1. HTTP-DNS服务的IP地址列表，内置到APP中。App启动时，异步基于IP发送请求，获取各域名的映射IP。
2. 前端App发送业务请求时，HTTP-DNS模块进行拦截，获得域名映射IP，替代默认的DNS服务。
3. HTTP-DNS服务通过设备ID返回不同的映射IP，实现白名单或比例分流
4. HTTP-DNS服务双活，前端侦测模块定时侦测，当默认环境IP不可用时，切换使用双活环境IP，进行域名映射IP获取。
局限性：
1. 依赖App的native能力，不适用于微信公众号/小程序、PC、纯H5等类型的终端渠道
2. 分流策略为全局策略：以“域名”为单位，后端多个应用系统共享域名，分流策略也就多个应用系统共用，需要协同。
优点：
1. 相对于GSLB(公网DNS）方式，切换速度快，更改策略准实时生效
2. 基于设备ID分流，也就是“用户”请求只会进入到同一IDC，不会随机进入不同的IDC。长远来看，对于后端应用系统处理跨IDC延时和数据一致性是有利的。
2.2 公网GSLB
通过公网域名解析服务（DNS）进行分流，公网渠道端入口的分流方法：
说明：
1. GSLB服务在域名解析时，按照预先配置的分流规则（按比例或根据客户端IP按地域），返回不同的域名映射IP，实现请求流量分流
2. GSLB服务本身双活
局限性：
1. 公网DNS服务提供方的DNS缓存策略的不确定性，会影响分流策略的准确度，以及策略变更生效的时效性
2. 分流策略为全局策略：以“域名”为单位，后端多个应用系统共享域名，分流策略也就多个应用系统共用，需要协同。
2.3 SLB（F5+Nginx）
SLB（F5+Nginx）通过Nginx配置动态变更，实现流量分流。内网动态分流方法。
说明：
1. 公网接入SLB双活，实现互联网出口双活。上图示例中，假设域名M由应用A和应用B共用，应用B尚未双活，则域名M双活流量中，请求应用B的部分，需要回到观澜IDC。
应用B虽未做双活，但互联网出口是双活的，也是有价值的。
2. 内网SLB，上图示例中，假设应用C通过内网SLB调用应用A，需要通过分流策略，将部分流量分流到应用A的双活集群。这种情况下，需要在SLB治理平台上，设定分流策略。
3. 内网SLB，Nginx跨IDC连接双活集群所有节点，心跳侦测机制确保及时排除故障节点
4. SLB治理平台，自身双活，支持随时在线变更分流策略
局限性：
1. 内网系统间调用，大部分应用未使用SLB做负载均衡，大部分是直接使用F5。应用使用需要F5后面加Nginx，进行改造接入SLB
优点：
1. 可以按应用系统维度，设置不同的分流策略，且变更实时生效
2. 公网基于域名分流，域名下没有做双活的应用，可以通过SLB把双活环境（福田IDC）流量导回观澜IDC，起到一个很好的补充作用
3. 对比内网GSLB(DNS域名解析），内网SLB（Nginx）策略变更实时生效，也不依赖调用方，调用方无需重启或策略变更。
2.4 内网GSLB
通过内网DNS域名解析，结合内网F5，实现流量分流
说明：
1. 通过GSLB管理工具，进行分流策略管理。应用调用时，进行域名解析时，根据分流策略（按比例）返回不同IP，实现分流。
2. 目前已实现应用双活的系统，基本上是基于此方案实现。
应用A-->F5-->ESB-->F5(DNS分流)-->应用B
局限性：
1. 当调用方启用连接池时，将受到调用方连接池策略的影响。分流策略可能得不到有效执行，同时策略变更时，策略可能不能生效。
2. 为了保证策略生效，调用方有可能需要重启。
2.5 点对点软路由
Pafa5(Dubbo)，Halo(SpringCloud)，是通过点对点软路由方式进行流量分流的。本章节通过Dubbo来描述这块的解决方案。
说明：
1. 两套环境，通过服务提供者工具，将对方环境所有服务提供者（IP列表）同步到当前环境的注册中心，保证当前环境的注册中心中，有服务提供者的全集。
2. 当应用间进行点对点调用时，根据提供者权重或同IDC优先原则，筛选（路由选择）提供者，获得可用提供者列表，再进行负载均衡，点对点调用。
3. 当某应用没有做双活时，双活环境将获得默认环境的提供者列表，调用回到观澜IDC（默认环境），比如：示例图中的应用C。
4. 当其中某一环境不可用时，对方环境的服务同步者工具侦测到，自动删除对方环境的提供者。
局限性：
1. 需要升级Pafa5或Halo的新版本才能支持
- 分流存在挑战
流量分流，是双活建设最为重要的课题之一。
3.1 同IDC优先 VS IDC权重
如果从公网渠道入口分流（如：HTTP-DNS），内网执行“同IDC优先原则“，则内网系统间，是不需要设置“分流策略”，
但这前提条件是：主要渠道或调用方已完成双活，业务场景比较全，能有效验证双活环境，通过“同IDC优先“方式实现全链路双活。
同IDC优先的优点：双活环境独立，流量分流由渠道入口统一控制，内部应用系统不需要单独做“分流策略”。
如果应用系统的调用方或主要接入渠道，都没有实现双活，那只能自己在应用系统维度设定分流策略（IDC权重），导入部分流量来验证自己的双活环境和双活能力。例如：
那我们到底选用哪一种方案呢？现阶段，D+等核心业务系统，接入渠道较多，且多没有完成双活，
可以以应用系统为维度，自已独立验证双活能力，建议先使用“IDC权重“方案，后续主要渠道及调用方完成双活后，再切换到“同IDC优先“的方案上来。
以口袋APP为主要渠道的渠道系统，则建议以“同IDC优先“的方案，协同进行全链路的双活建设和验证。
3.2跨IDC时延和带宽问题
跨IDC时延和带宽问题，问题影响有多大，应用系统能否接受，终端用户体验能否接受，目前还没有大规模生产实践、论证过，暂时是没有答案的。
现阶段，我们只导入极小部分流量（白名单，百分之一，甚至万分之一），进入双活环境，能验证双活环境可用，保证它是活的即可。
长期手段，我们慢慢增加导入的流量，持续监控观察，持续改进，在实践过程中，逐步把这个问题解决掉或规避掉。
所以，短期我们可以忽略这个问题。
3.3 白名单分流的支持
白名单分流，是比较安全的双活环境验证方式。
目前支持白名单分流的方式，只有HTTP-DNS，且口袋APP是行内的主要C端渠道，场景也比较全。所以要充分利用这个渠道和HTTP-DNS这个方法做双活分流。
3.4 变更实时生效
公网GSLB、内网GSLB，存在实时生效问题，如果有替代方式，尽量用替代方式。
比如：HTTP-DNS替代公网GSLB，SLB替代内网GSLB。
3.5 B端如何分流
B端合作方渠道，一般通过专线或公网，服务端对服务端连接进行交互，分流方式需要合作方商定。
4.总结
前面，我们分析了各分流方法，及各自优劣，也分析了现阶段存在的挑战和问题，并给出了解决办法，有以下观点，我们再阐述一下：
1. 现阶段，应该尽快把双活环境搭建起来。大家都搭建起来了，才能执行”同IDC优先“原则，保证双活环境独立性，并全链路双活验证。
2. 现阶段，只要导入极小部分流量，进入双活环境，保证它是可用的，是活的，就可以了。当容灾切换时，存储手工切换，确保所有流量能即时切入双活环境。
3. 现阶段，只导入极小部分流量进入双活环境，先忽略掉跨IDC时延和带宽问题。容灾切换后，双活环境确保没有跨IDC流量。
4. 推荐使用：HTTP-DNS、SLB、点对点软路由（Dubbo/SpringCloud）这三种分流方法。GSLB尽量不使用。
5. "同IDC优先“的策略下，在渠道入口端进行分流，后端应用系统无需设定自己的分流策略，由运维统一变更和协同。
6. “同IDC优先“与”IDC权重“二选一，应用系统可以根据自身情况选择”IDC权重“，自己设置自身的分流策略，导入一定比例的流量进入自己的双活环境。
7. 所有分流方法都需要同时支持这二种策略：“同IDC优先“与”IDC权重“。
8. 现阶段，在达到目的的前提下，尽量保持架构简单，谨防过度设计
本文转载至：https://www.modb.pro/db/52907
标签：应用,同城,IDC,分流,DNS,双活,SLB 来源： https://www.cnblogs.com/zbzSH/p/15916922.html