闲鱼异地多活架构设计与实现
背景
首页和搜索一直以来都是闲鱼导购的主阵地，为了保证高可用业务上做了很多保护方案。但是随着原有地域的IDC日渐趋于饱和，一些更深层次的问题开始暴露出来：
a）架构不具备扩展性。当服务量增大，单个IDC由于服务器部署、电力等物理因素无法满足诉求，不能简单的通过IDC部署来应对新增的流量。以算法为例，算法在现有IDC资源饱和的情况下，其上新模型之前不得不等老模型下线，严重制约业务的迭代效率。
b）容灾问题。当现有IDC出现故障时，如何保证导购主链路依然高可用。
常用高可用架构
•同城双活：系统从接入层以下在同城两个机房做部署，这样可以应对断电，断网等单机房故障。由于同城机房距离足够近，可以近似看成一个机房，因此在部署上和单机房相比没有特殊要求。但是遇到同区域灾害时，服务就会受到影响，而且扩展性较差。
•异地灾备：系统从接入层以下除了在同城两个机房做部署之外，在其他区域部署异地备份，底层数据根据实际要求做热备/冷备，但是不承担任何流量。当区域挂掉时，服务切至备份区域保证服务可用性。但异地灾备的问题是：a）另一个区域不跑流量，出了问题不敢切。b）备份全站，资源利用率低。c）存在跨地域访问。
•异地多活：异地多活从接入层开始做多区域多机房部署，各个区域之间没有主备的概念，均承担相应的流量。它的优势在于资源利用率高，扩展性较好。
前面提到闲鱼除了要解决容灾问题之外还需要解决算法同学的资源利用问题，因此异地多活很自然成为我们的不二选择。
多地部署带来的变化
当我们的系统从单地部署升级成多地域部署时，它并不是简单将整个系统搬到各个地域去做部署。当你的系统部署过去之后，需要考虑非常多的因素，比如
流量调度，系统部署过去后流量怎么跟着怎么过去。
流量自闭环。由于距离的原因，跨地域的物理延时是没法避免的，流量过去之后怎么保证所有的操作都在本地完成，如果做不到那怎么将这种延时影响降到最低。
数据一致性，数据如何在多个地域之间保证一致性，针对一些如交易相关等数据时效性敏感的场景，如何解决多地域之间数据同步时延。
容灾切流。当某个机房出现故障时，如何快速把流量无损地切至其他机房。这里并不是说简单把流量切过去就完事，由于数据在多区域同步，流量切过去之后能否保证数据的一致性？
还有很多其他因素，这里不一一列举。可以预想到当我们的系统升级成多地域部署架构之后，给整个系统带来了很大的变化，同时也带来了相当大的挑战。
多地域部署方案
面临的挑战
异地部署最大的特点是网络时延较高：一般来说同地域延时2～3ms，同机房延时小于1ms，而跨地域延时一般大于20ms。所以我们首先要解决的问题便是如何降低跨地域对导购链路的影响，这也是我们做异地容灾的一个大原则，这面临着几个难点
流量如何做到地域内闭环，流量闭环必然有代价，如何平衡这两者之间的关系。
多地域部署带来的系统架构的复杂度。无论是流量调控，服务路由还是数据读写同步，都要在庞大的系统中做好精细化的调控，对系统带来的复杂度可想而知。
如何做流量路由。如何识别流量的来源，控制流量的去向。
系统部署规范。系统在一直不停的演进，如何避免架构快速腐化。
流量如何做管控。流量调控规则需要统一做监控，管控等，一旦需要切流时，流量如何快速完成调整收敛。
用户数据是否做拆分
在介绍部署架构之前先讲一下闲鱼导购链路的一个大前提，后面的很多方案都是基于这个大前提之下做抉择的，那就是存储层的数据是否要做拆分。
异地部署之后数据会存在多个区域中，区域之间的数据同步存在一定的延时，因此数据是否要做拆分取决于对数据一致性的要求。如果可以容忍对数据短时间不一致那么则不需要做数据拆分。但是在电商某些场景下，比如买家加入购物车操作，如果数据写在区域A，购物车列表读的却是区域B，那么很有可能就会导致买家看不到刚加入购物车的商品，这是非常糟糕的体验。因此在这种场景下就需要保证数据的读写都在相同的维度，这种情况下就需要对数据做拆分。
但是前面提到闲鱼导购链路特点是：a）可以容忍短时间的数据不一致。b）不涉及到数据库的写操作。显而易见数据拆分显得并没有那么必要，因此我们决定不做数据拆分。
部署架构
整体部署方案中，物理上各个区域是对等的，不存在主备的概念，但是逻辑上还是区分出了中心区域和其他可用区域，这是因为：a）总有部分长尾依赖没法做多区域部署。b）并不是所有场景(非核心链路)都适合做多地域部署。我们把这些长尾依赖统一放在中心区域，做兜底部署。
流量路由方案
流量路由方案这里面包含了两个问题：
流量分发的原则是什么，解决哪些流量应该到哪个地域。流量分发原则常见的有三种方式：a）完全随机。b）按照地域就近访问。c）按照用户维度切分。
流量在哪一层做分发，解决用户请求从哪里开始分流。
如前面数据拆分部分提到，流量分发理论上需要和数据拆分逻辑保持一致。由于闲鱼底层没有做数据拆分，因此流量分发原则相对较为灵活。
最简单的流量分发原则是完全随机。前面提到数据在多区域之间存在数据同步延时，虽然导购链路可以容忍短时间的数据延时，但是我们需要避免用户连续两次请求看到的数据存在不一致(如果俩次请求分别落在不同地域)。
按照地域就近访问能实现最低的访问延时，但是这种方案最大的问题是地域之间的流量严重不均衡，而且在不停变化(正常时段&节假日)，这会给整个系统的负载均衡带来很高的复杂度。
按照用户进行切分，保证部分用户请求会固定路由到某个区域。
在我们导购场景下1和2都不适合，因为都有可能导致用户两次请求看到的数据不一致，最终我们选择按照用户进行切分，这也是公司内部成熟的路由方案。确定了流量分发原则，接下来需要决定流量在哪一层做分发。这点我们考虑了三个可选的方案
方案一，在域名解析阶段做不同地域的流量分发。a）这种方式成本较高，需要有独立的DNS域名，独立的路由规则。b）当路由规则调整的时候，收敛周期较长(依赖端侧的缓存更新)。c）和运行环境绑定，不支持H5，Web等场景。其优点是经过公司内部验证，相对比较成熟。
方案二，在统一接入层进行不同地域流量分发。这种方式成本低，可以复用现有的逻辑，只需要在统一接入层做规则配置，但是部分流量存在跨地域访问(从接入层到业务集群)。
方案三，搭建边缘网关。通过原生的DNS做域名解析，然后就近选择边缘网关访问。切流等复杂逻辑放在边缘网关中完成。这个方案和运行时无关，支持app&小程序&Web等，而且规则调整收敛速度快，扩展能力强。其缺点是需要从0开始搭基建。
方案一的跨地域问题是我们需要避免的，方案三虽然比较适合，但是成本太高，而且没有成熟的经验借鉴，权衡之下我们最终决定采用方案二。
全链路升级改造
全链路改造的目的在于使我们的系统适应从单地部署到多地域部署的转变，改造涉及到的点非常多，主要包括
应用代码改造。导购链路所有的依赖是否都能做多地部署，如果没法多地部署跨地域时延是否会被放大。
服务之间的流量路由策略。导购链路涉及到很多异构的子系统，这些异构系统之间的流量是否遵循同地域优先，当某个地域服务挂了之后流量是否允许自动切到其余地域。
流量强纠偏。导购的请求链路较为复杂，会依赖众多异构的子系统。虽然域名解析时流量会路由至对应的区域，但是在后续链路仍然有可能发生流量窜到其余地域的情况，这种情况下理论上会对用户体验造成影响，所以在导购链路的每一跳节点都应该有纠偏策略。
外部流量由于分发策略我们没法管控，会导致预期之外的流量流入。为了避免这种情况，我们也需要有一个流量纠偏的策略。
改造点3在数据强一致场景是必不可少的，但是对本次导购链路，由于改造成本和时间的关系，最终我们放弃了改造点3。因为改造点2保证了正常情况下流量路径是符合预期的，只有异常情况才有可能发生流量窜到其他区域，但是这种情况我们认为：a）低频且持续时间不长。b）短时间的不一致对业务影响可控。
应用代码改造主要包括
对于那些没法做多地部署的依赖，评估其对数据一致性的约束，如果是弱一致性，则考虑使用富客户端模式，在富客户端模式中优先读缓存，不命中再走一次RPC，通过缓存降低跨地域请求的频率。
没法做多地部署且要求数据强一致性的依赖，需要避免跨地域访问时延被放大。不存在跨地域延时的时候串行并行的区别并不明显，但是引入跨地域时延之后串行和并行的区别就会非常明显，因此对这部分依赖需要做并发改造。另一方面在改造过程中梳理出核心依赖&非核心依赖，核心依赖强制要求单元化，对于非核心依赖做到并发&可观测&可降级。
缓存改造。由于以前对缓存的使用不够严谨，会导致单地域部署下被掩盖的问题在多地域部署之下暴露出来。比如下面这种场景，在某个场景写入某个key，然后在另一个场景下读取这个key。在单地域部署下不会有问题，但是一旦多地域部署之后就有可能出现读写不同地域的情况导致数据不一致。
这种情况下我们需要：a）强制写中心主节点。b）开通主节点到其他地域的数据同步。总的来说缓存改造两大原则
如果是非持久化缓存，则不用做任何改造。因为这种场景缓存不命中会有数据加载过程。但是很多非持久化缓存场景滥用了持久化缓存，针对这类case需要规范使用，改造成非持久化缓存。
如果是持久化缓存，分为两种情况：a）强一致性，如分布式锁，这种情况强制读写中心主集群。b）非强一致性，则强制写中心主节点，就近读。
导购链路涉及到很多异构系统，包括各个子领域应用构成的微服务集群，以及众多搜索&推荐服务。异构主要体现在：a）编写语言以及部署&运维平台的差异。b）服务注册发现机制不一样，主要包括configserver/vipserver/zookeeper。因此主要改造内容在于规范对这些组件的使用，调整流量路由策略保证流量区域内自闭环。
为了防止外部流量对闲鱼导购流量的影响，我们在统一接入层加了一条流量纠偏策略：对于外部非导购链路的流量，强制切回中心区域。这一点非常重要，因为对于部署范围之外的服务，如果因为这个原因导致流量到了其他可用区域，其返回数据的正确性我们没法做保证。
服务集群部署方案
微服务集群整体采用对等部署。微服务集群按照服务发现&注册机制的不同划分成三类：
采用HSF作为RPC框架的业务服务，采用configserver做服务发现，configserver同时在多地域部署，彼此之间互相隔离，各地域部署的服务只拉取本地域内的configserver数据，通过这种方式实现地域之间的流量隔离。但是中心区域的数据会同步至其他区域(区域挂了流量可以路由到中心区域，保证服务可用)。
采用HTTP调用的算法服务集群由于历史&异构原因，采用了两种服务注册&发现方式
Zookeeper。Zookeeper在中心和区域都做单独部署，客户端请求的时候按照地域拉取对应的Zookeeper。通过这种方式实现流量的同机房访问，地域彼此间数据隔离，当单个地域服务出现问题时，只能通过将其他区域的服务数据挂载到故障地域对应的Zookeeper下面来进行恢复。
vipserver（阿里自研的一套集群路由软件负载均衡系统）。由于vipserver本身是分布式的负载均衡系统，且支持多种路由方式，故只部署一套。
导购链路使用缓存的地方很多，大致分成两种用法
缓解持久层的访问压力。先访问缓存，缓存如果没有数据则请求持久化层并把数据加载至缓存中，缓存本身不做数据一致性保证。这种情况比较好处理，因为不涉及到多区域之间的同步，只需要简单做多地域部署即可。
用作数据持久化。典型的如分布式锁，计数器等。这种场景会有中心和区域的概念，彼此间双向同步，这种场景在单区域部署的时候和上面的用法没有太大区别，但是在多地域部署架构下，就会因为双写导致数据出现不一致，因此需要保证同一个key同一时间不能在多区域同时写。
区域同步至中心。因为数据需要做持久化，所以会在中心有一份完整的数据集，区域保证数据的最终一致性即可。
中心同步至区域。保证区域的数据和中心的数据一致。
数据库部署
按照分布式系统的CAP定理：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。所以严格意义上来说，数据库的异地部署只能三选二。但是在分布式系统中必然是分区的，而且分区之间的网络我们没法控制，也就是说P是一个事实，我们只能从C和A中二选一，这分别对应着数据库的两种数据复制方式。
主从复制模式的MySql：中心写成功即返回，从节点依赖主从之间的数据同步。这种模式下保证了A和P，牺牲了C。
双向复制模式的MySql：没有主从节点之分，节点与节点之间实现数据最终一致性。这种模式下同样保证了A和P，牺牲了C。
采用Paxos协议的分布式数据库如Google的Spanner等，采用Paxos协议来保证数据的强一致性，但是在Master节点挂了之后在新的Master选举出来之前不可用，即保证了C和P，牺牲了A。
一方面根据导购链路的特点(绝大部分都是数据读取操作，可以容忍短时间内的不一致)。另一方面原有的数据存储采用MySql，考虑到成本，最终选择主从复制模式MySql。
总结
异地部署给系统带来的最大挑战是物理距离带来的网络延时，整个系统设计都围绕着这个展开。总的来说在解决跨地域延时过程中我们遵循两个大的原则：a）流量地域内自闭环。b）坚持可用性优先。在这两个大原则之下从接入层，服务层以及数据存储层做了相应的改造&部署。
目前闲鱼部分链路已经实现了两地三机房部署，并且已经承接线上流量，具备了异地容灾的能力。同时经过本次改造，导购链路具备了较好的扩展性，能够以极低的成本快速部署至更多机房。
但是一方面由于导购链路大部分都是只读场景，对数据要求弱一致性即可。对于数据强一致性场景带给系统的挑战会更大。另一方面业务是一个不停演进的过程，如何保证在演进过程中仍然能保证异地多活的部署架构，这是急需解决的问题。