得物多活架构设计之路由服务设计

一 、背景

 

随着公司的业务发展，每次稳定性故障带来的影响越来越大，提供稳定的服务，保证系统的高可用已经变成了整个技术部面对的问题。基于这种背景，公司开展了多云/多活的技术项目，本人有幸参与了 “次日达” 项目【1】的异地双活改造方案的设计。想以此来浅谈一下我对多活乃至全球化的一些技术方案的认知。

多活架构系列的文章我会按照总体技术方案、双活/全球区域化部署技术、网络调度技术、性能优化以及SRE五大部分来展开。本篇毒家Blog会着重讨论总体技术方案以及双活/全球区域化部署技术中的路由服务设计模块，并会在后续的毒家Blog中逐步完善多活架构的完整技术方案。

二、多活/全球化的技术要求

网络服务除了要满足用户对性能、可用性等的基础要求外，多活/全球化的背景下还增加了合规、数据隔离性等要求。而这方方面面的要求都遇到了全新的挑战。

1. 性能

用户从发起请求到接收、响应的时效越短，代表性能越好。但是在双活/全球化的背景下，用户可能在日本，机房可能在中国，物理的距离变得更长了，对应服务的响应时效也会成正比。有测试数据显示，跨国家或者大范围的跨机房调用，网络的RTT会增加1s左右，而这1s可能会造成交易达成的“转化率”下降，甚至用户流失。

2. 可用性

多活\全球化的业务会跨越时区，这就要求我们的服务要7✖️24小时可用。这不仅是对系统的挑战，也是对人力的挑战。

3. 互联互通

互通互联指的是电信网络之间的物理连接。为了使一个电信运营商企业的用户可以和另一个电信运营商企业的用户进行相互通讯，在国内，这种跨越运营商的网络通讯已经不是什么大的问题。但是在国外，很多国家的网络互通互联的质量仍然不够理想。

4. 数据一致性

当数据被全球用户共享时，多地用户都可进行读写操作，如何确保数据的一致性？

5. 隐私保护

全球化的业务必须遵守GDRP（General Data Protection Regulation,通用数据保护条例）。

6. 可伸缩性

维基百科的解释：当系统、网络或者进程在任务量增减时，有能力进行应对。

三、多活/全球化的总体架构

3.1 领域建模

系统的核心就是处理领域模型的关系，从领域模型出发让整个系统满足现状和未来的需求。同时让项目团队更好地协作，以下是系统的核心对象。

User：网站平台上的用户。

UserGroup：用户组、具有相同特征的用户一般会采用同样的网络链路和机房调度策略，因此会被归属到同一个用户组之中。实际上，多活系统是以用户组为基础调度单位的。用户是用户组的一员，我们既可以以用户组为单位调度，也可以针对某个具体用户调度。

EdgeNode：边缘节点。可以理解为静态资源的提供节点。比如图片、js文件、css等。一般的边缘节点指的是CDN。

NetLink：网络链路。

NetNode：网络节点。

• PoP：网络服务接入点。（路由器、交换机等节点）
• DSA：动态站点加速，是访问由CDN厂商提供动态内容的加速器。

IDC：机房。

DNS：DNS服务器。

HTTP-DNS：理解成APP端的DNS服务器。

DomainName：域名。

VIP：虚拟「偶像」。

以上领域模型的关系如下；

3.2 总体架构

按照以上的描述，其实是可以看到，从用户出发一直到机房，会存在边缘节点调度、网络调度以及机房调度。还有调度的执行（路由的使用）以及调度的控制（路由的产生）。路由即每个用户或者每个用户组隶属于那个机房。 结构图如下；

• 全球用户：我们的系统会把全球用户分成不同的用户组，并且按照区域分为四组，即A洲、B洲、C洲和D洲。在调度执行时，常规的流程是把调度信息推送到每个用户组的 App 上。
• Edge 调度：静态信息的调度，决定了每个用户组应该使用哪个边缘节点。
• 网络调度：基于大数据实时统计每一条可行的链路并且由决策模型确定走哪一条路线。（跟路由没关系）
• 机房：提供解决方案的源头。
• 调度执行：PC 使用 DNS 技术进行调度，App 使用 HTTP-DNS 以及 PUSH 技术调度。（路由的使用）
• 调度控制：通过实时数据计算，确定具体的调度。（路由的产生以及配置）

四、多活/全球化区域化部署技术

4.1 整体架构

4.1.1 功能优先级

调度的编排具体策略由业务需求决定，通常来讲就是会考虑合规、数据一致性、可伸缩性、成本、容量、性能和稳定性来考虑。通常重要顺序是

合规 > 数据一致性 > 可伸缩性 >