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

一、背景

        随着公司的业务倒退，每次稳定性故障带来的影响越来越大，提供稳固的服务，保证系统的高可用曾经变成了整个技术部面对的问题。基于这种背景，公司发展了多云 / 多活的技术我的项目，自己有幸参加了“次日达”我的项目【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  性能优先级

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

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

4.1.2  部署架构

        目前咱们有四个机房（A 洲、B 洲、C 洲、D 洲），建设每个机房所在的地区服务对应的地区用户。机房之间的数据须要 按需复制，每个机房都部署所有的利用以及数据库，使得每个机房都是对等的。当备份好数据之后，就能够让所有的机房互为灾备机房。数据一致性和可伸缩性会在后续介绍。

4.1.3  问题剖析

        以电商场景中的交易、就近拜访以及异地容灾为例。比方买家和卖家别离来自不同的地区，进行交易必定会有局部共享的数据一致性问题；当异地容灾时，也会面临数据一致性问题；当用户迁徙到其余区域时，依然要保障就近拜访，那么又波及到同一个用户的数据一致性问题。

咱们应答的策略如下：

• 就近拜访：用户会路由到固定的机房（失常状况下），并且确保用户的数据都是在同一个机房闭环。
• 异地容灾：因为利用是对等的，那么就要确定数据在备份机房里存在。

<!—->

• 寰球买、卖：将数据按需同步，将商品信息同步到全副机房。
• 数据一致性：确保繁多数据 master 准则，即同一条数据只有一个机房会进行变更。会确保业务的优先级（买家 > 卖家 > 经营）。

4.1.4  解决方案

从应用程序分层的视角来看，解决方案如图；

4.2  路由服务

        区域化部署技术实质就是多层路由，而在每一层路由中，都是基于用户对应的归属机房调用的路由的。路由服务的作用就是通知调用方，这个用户归属于哪个用户。

1. 路由服务构造

-  内存路由表：了解为 HashMap，key 为用户 id，value 为用户归属机房以及用户状态。-  RPC 服务。

2. 路由表如何应用

- 用户申请进入机房第一个应用程序是同一接入层。应用 Nginx 作为对立接入的应用程序，Nginx 内嵌路由表，并且在多过程进行共享。Nginx 承受申请后做的第一件事件就是获取用户 id，而后调用路由表获得用户归属机房以及用户状态。若用户归属于本机房则持续向下透传。-  上游须要路由信息间接获取下层丢下来的路由信息。如下图；

路由透传存在时效限度，当超出肯定时效，透传内容会生效。至于在透传过程中，用户路由扭转怎么办？本文后续解答。

4.2.1  路由表原理

路由表设计规范必须理解以下几点：

• 必须保留在内存。
• 保障性能和吞吐量。

<!—->

• 不能依赖第三方零碎。
• 路由设计应该反对自在降级。

4.2.1.1  计划比拟

        计划比拟包含以下的引入分布式缓存、HashMap、布隆过滤器等，以下的计划各有毛病，具体如下。

4.2.1.1.1 引入分布式缓存

• 缺点

<!—->

• • 所有的零碎都要调用近程缓存，依赖性强。
  • 用户归属变更，客户端缓存要更新，近程的缓存也要更新。
• • 各方零碎都要退出一个强依赖。

4.2.1.1.2  HashMap

• 缺点

<!—->

• • 保留 5000 万条大概须要 2GB 内存。

4.2.1.1.3  布隆过滤器

• 缺点

<!—->

• • 存在 False Positive。

这样看来没有一个现存的计划，须要依据场景来 定制 化路由表。

4.2.1.2  路由表设计

        基于上述启发，抉择应用比特数组进行存储路由信息。咱们能够用 4 个 bit 来表白一个用户。如图所示；

这样存储的话存储一亿的数据只须要 47M 左右的内存空间。

然而如果用户 ID 的散布是分段的呢：

        0~ 80000000

        100000000~ 300000000

        700000000~ 800000000

        2000000000~ 2000100000

        只管实在的用户数量也只有 1 亿左右，然而 id 散布如此宽泛，这样大概要耗费 900 多 M 的内存。

基于这点，要引入分段模式：

• 分段模式

分段模式如图所示，外围思路就是建设一个段索引表，每个索引表上指定了一段比特序列，用来保留用户信息。（例如咱们以 100 万用户为一段）。针对这些索引项中一个用户都没有的，咱们执行一个 NULL 段。其对应的比特序列也不会调配存储空间。这样大大的节俭了内存空间。这样还是同样的用户注销才须要耗费 58 M 左右的存储空间。

4.2.1.3  路由表相干设计

        上阶段解决了路由表的根底存储计划，然而有一些场景还是须要咱们继续设计改良的。当初咱们思考两个问题：

• 当某个机房呈现故障须要容灾切换时，如果基于现有的路由表实现计划，则须要变更对应机房所有用户的路由归属信息，可能波及到几千万或者是上亿的用户变更，老本十分高。

• 在双十一的场景内，尽管能够通过大数据布局用户的行为散布，然而双十一一年才一次，学习样本少，很容易就会呈现用户行为和预期不统一的景象，那就有可能会造成 A 洲机房的容量有余，然而美国的机房容量却很空余。此时就须要局部的 A 洲用户分流到美国机房，如果通过当初的路由表怎么反对呢？基于以上场景咱们提出了一个叫做“逻辑机房”的概念。

<!—->

• • • 当一切正常时，逻辑机房间接映射到一个原机房。
    • 当产生容灾切换时，间接将逻辑机房映射到灾备机房。
• • • 当须要对局部用户进行分流时，依照用户 ID 进行 Hash 取模，将 Hash 后果不同的用户映射到不同的物理机房内。

具体的配置逻辑能够基于各个公司应用的配置零碎来进行集中配置。

4.2.2  路由表更新机制

路由表更新机制的确立须要有以下设计束缚；

• 数据一致性：在路由表变更的过程中，会呈现一个用户的归属信息在不同的机房或者机器节点不统一的可能性。

• 可复原、可回滚：无论零碎处于什么状态，都能够确定性的复原到一个冀望状态。
• 疾速变更：在一致性的保障过程，或者复原、回滚的过程中，都会影响用户体验，甚至无奈应用零碎。所以在变更过程中须要在极短的工夫内实现。

4.2.2.1  数据一致性思路

        很多时候分布式系统都在解决一个问题，那就是如何让任何一条记录批改在所有机房或者多机房上同时失效。解决思路并不简单，并且有通用性。尽管咱们无奈保障变更在所有机房或者多机房同时失效，但咱们能够晓得变更在多机房中是否曾经失效，在此基础上咱们设置一个中间状态，这个状态与变更前的状态和变更后的状态都兼容，就解决了这个问题。

        如图所示，状态 A 是变更之前的状态，状态 C 是变更后的指标状态，状态 A 与状态 C 是不能同时呈现的，然而状态 A 变更为状态 B，在期待直到所有机房的所有相干机器全副都变更为状态 B，那么再从 B 到状态 C，这样就不会呈现状态 A 和状态 C 同时呈现的状况。

        为了解决路由更新过程中业务数据全局一致性问题，咱们引入了一个“禁写”过渡版本。在切换到指标路由机房之前，咱们先将路由置为以后机房的“禁写”过渡版本，在这个状态下，用户不能持续在以后机房以及其余任何机房中进行任何会批改相干业务数据的动作。在“禁写”过渡版本变更到新版本之前，必须确保所有路由解析的本地版本曾经降级到“禁写”过渡版本。“禁写”过渡版本将新旧路由版本的失效工夫严格的隔离开来，不存在某个时刻新旧版本的路由都失效的状况，从而确保了业务数据的全局一致性

（正文：处在“禁写”过渡版本中的用户在“禁写”过程中的其余业务的可用性会受到肯定水平的影响。这种影响该当被业务所承受，将其了解为一种业务可用性的部分长期降级。这种降级会安顿在用户不沉闷的时段，往往不会对用户的体验造成太大的影响。回归到路由表的眼帘中，用户 Id 是不须要被存储的，归属机房对应用户 bit 的前三位，可写标记对应的第 4 位，为 0 时示意用户可写，为 1 时示意用户禁写。）

4.2.2.2  解决方案

4.2.2.2.1  数据筹备与失效过程拆散

“禁写”状态会对用户产生影响，如果用户被禁写，则意味着用户无奈下单，尽管在用户不沉闷时段进行变更能够升高对用户产生影响的概率，然而变更能够在此基础上进一步升高这个概率。咱们能够采纳数据筹备与失效过程拆散的形式实现。

• 数据筹备过程就是将用户归属的信息写入分布式长久数据库中。
• 因为要求疾速回滚，因为必须是多版本的写入。这就要求咱们长久层数据库的数据是多版本的。筹备好数据后，对版本的失效过程采纳 Zookeeper 的 watch 机制进行交互，过程如下：

<!—->

• • 当须要进行路由变更时，会由路由变更控制程序将数据写入数据库中，并且定义版本号。
  • 数据筹备好之后，将版本号写入 Zookeeper 的监听节点中，所有 watch 都会受到推送。
• • 须要加载路由表的机器读取数据库内的数据，并进行新版的路由表加载。

4.2. 2.2.2  一致性具体计划

        Zookeeper 是一种高性能的分布式协调工具，用于节点之间的通信，常被应用分布式的配置管理中，各个厂商在路由表的数据一致性的建设中，大部分应用的也是这种解决方案。

        在分布式协调场景中，经常会用到短暂节点，这个节点与创立他的 session 同在，当 session 隐没，节点也会隐没。这个机制罕用于做心跳查看。而在路由节点的建设中，所有须要监听路由表的节点都会创立一个短暂节点，用于路由表加载节点的心跳查看。单次变更的流程如下：

• 所有的节点都会与 Zk 的 currentVersion 节点建设 watcher，用于获取最新版本的推送。
• 所有的节点都会创立一个短暂节点，以机器名称命名，示意此节点正在监听变更，建设在 SessionList 目录下；当 session 隐没时，示意这个节点不会在监听变更。
• 当节点被推送有新版本的变更后，它会应用这一个版本号去分布式数据库内查问数据（4.2.2.2.1 之前曾经筹备好数据了）
• 当获取实现，并在本地内存中初始化路由表，会将机器名字作为节点写入 AckList 目录下的 currentVersion 子目录，示意此节点曾经对于以后版本更新实现。
• 变更程序会比拟 AckList 目录下的 currentVersion 子目录中的所有机器节点是否笼罩了 SessionList 目录下的所有机器节点，如果是则证实所有节点更新到最新版本。
• 因为咱们晓得所有节点是否曾经更新实现，并且有与前后兼容的“禁写”状态，所以能够在所有节点都更新到“禁写”状态后，再进行新版本的路由信息变更，这样就能够确保呈现的状态都是互相兼容的，从而保障了数据一致性问题。

上述步骤阐明的 ZK 的目录节点构造如下：

4.2.2.3  整体架构

        后面对要害的技术细节进行了介绍，上面介绍整体的架构。后面介绍过，管控零碎会负责所有机房的区域化治理，蕴含路由表的变更流程。在每个机房中都会有一个管控的 Agent，管控零碎会调用 Agent 对所有的机房进行治理。在路由变更过程中，对每个 Agent 会把机房中的路由数据写入对应的分布式数据库中，Zk 再推送信息写入，这里不再赘述。

4.2.2.3  变更流程

当路由表变更时，残缺的流程变更如下：

1. 保留以后版本号 V1，用于解决回滚的计划。
2. 获取以后机房列表，失去所有机房，循环调用每个机房的 Agent，顺次向下执行。

<!—->

3. 每个机房的 Agent 调用咱们上述说的解决方案，将数据写入分布式数据库内。
4. 如果失败，则间接调用第 8 步。

<!—->

5. 获取以后机房列表，失去所有机房，并且循环调用每个机房的 Agent，将用户状态批改。
6. 之后利用一致性的具体计划（4.2.2.2.2），并将所有用户状态改成最终状态。
7. 如果失败，则间接调用第 8 步。如果胜利，则流程完结。
8. 循环调用每个机房的 Agent，将版本回退。如果失败，则进行人工干预。

<!—->

4.2.3  用户路由更新计划

        后面介绍过了路由表的更新机制，然而如何确定用户归属的机房？如何变更用户归属机房？如何将网站的存量用户退出到路由表中？以及有了新用户如何退出路由表中？

4.2.3.1  确定 用户归属机房

        在实在利用场景中，绝大部分用户的归属逻辑采纳性能优先准则，根本等同于用户归属于拜访提早最小的机房。当然对于大部分场景下，提早最小的机房就是物理间隔最近的机房。

咱们如何来判断用户的归属机房，计划如下：

1. 每个用户都会在所有机房进行异步拜访，用于确认用户和所有机房的提早。
2. 以用户区域为粒度进行统计，最稳固的机房是哪一个。

<!—->

3. 在路由表中将区域中每个用户与这个区域整体体现最好的机房做关联。

4.2.3.2  变更用户归属机房

        确定了用户归属机房之后，假如新的归属机房与原机房不同，那么就要落实一个用户到机房的归属。后面介绍过，在用户路由归属过程中，须要将表改写成向前向后都兼容的“禁写”状态，这个过程确保了路由表自身变更不会带来数据不统一的状况。然而从“禁写”用户到用户“可写”的过渡中，还须要将用户的数据在原机房复制到指标机房，并且确保复制实现。相干数据复制的技术这里不展开讨论，会在后续章节讲述。

4.2.3.3 变更优化 - 分时变更

        因为禁写可能会对用户产生影响，因而咱们须要在变更的工夫上进行优化，升高对用户生产影响的概率。次要的办法就是找到用户最可能闲时。

（1）以小时为单位，并且赋予时间段标识 id。

（2）为用户的不同行为设置权重，权重代表禁写对用户影响的大小。\

（3）建设用户 abc 在一段时间内操作记录如下，则采纳上面的计算方法计算每个事件的抵触值。

        P(0)=1/(1+2+1)0.2+4/(4+2+2)0.8=0.45 代表标识 id 为 0 的时间段抵触值为 0.45

        P(1)=2/(1+2+1)0.2+4/(4+2+2)0.8=0.3 代表标识 id 为 1 的时间段抵触值为 0.3

        P(2)=1/(1+2+1)0.2+4/(4+2+2)0.8=0.25 代表标识 id 为 0 的时间段抵触值为 0.25

值越大，代表此时间段的避开价值就越大。

4.2.3.4  存量更新计划

存量更新计划是指两种场景

• 计划刚上线
• 机器刚启动

        这两种场景个别都是指从新计算所有目前零碎中存在的用户的归属机房。基于后面介绍的常识，目前采纳的计划就是之前咱们提到的确定用户归属机房（4.2.3.1）计划。

        这里非凡提一下归属的默认优化，咱们将某一个机房作为默认机房，所有归属到此机房的用户无需退出路由表，当调用路由服务查问此用户路由时，路由表返回空值，路由服务间接返回默认机房，从而大大降低路由表的大小。

4.2.3.5  全量更新计划

增量更新计划个别也指的是两个场景

• 用户注册
• 用户迁徙

        对于第一种状况，新机房的用户都会归属到默认机房，不进行任何路由表的变更，之后的过程与第二种状况雷同。

        对于第二种状况，在对新用户进行多机房探测过程，发现用户可能不应该属于本机房，或者发现新注册用户的确拜访默认机房不是最快的。那么就须要做用户迁徙，即进行增量更新。在确认归属之后，增量更新与存量更新计划统一，相比之下，增量更新计划须要变更的用户比拟少。存量更新计划须要运行的次数并不多。

五、小结

        这一篇文章次要介绍了在异地多活 / 全球化革新过程中的基本概念以及领域建模还有路由零碎的存储优化过程。后续还会继续更新异地多活 / 全球化的更多内容，欢送关注「得物技术」公众号。

正文：

【1】次日达（Leadtime、LT）是一款得物推出的履约承诺产品，外围逻辑是通过发货园区、收货城市、商品属性匹配后盾配置的线路，以此给用户承诺商品是否反对商品次日送达。

文|FUGUOFENG

关注得物技术，做最潮技术人！