哪个网站可以做优惠券,最有效的网站推广费用,哪家网站设计好,做图模板网站来源#xff1a;水滴与银弹作者#xff1a;Kaito阅读本文大约需要 20 分钟。你好#xff0c;我是 Kaito。在软件开发领域#xff0c;「异地多活」是分布式系统架构设计的一座高峰#xff0c;很多人经常听过它#xff0c;但很少人理解其中的原理。异地多活到底是什么… 来源水滴与银弹作者Kaito阅读本文大约需要 20 分钟。你好我是 Kaito。在软件开发领域「异地多活」是分布式系统架构设计的一座高峰很多人经常听过它但很少人理解其中的原理。异地多活到底是什么为什么需要异地多活它到底解决了什么问题究竟是怎么解决的这些疑问想必是每个程序看到异地多活这个名词时都想要搞明白的问题。有幸我曾经深度参与过一个中等互联网公司建设异地多活系统的设计与实施过程。所以今天我就来和你聊一聊异地多活背后的的实现原理。这篇文章干货很多希望你可以耐心读完。01 系统可用性要想理解异地多活我们需要从架构设计的原则说起。现如今我们开发一个软件系统对其要求越来越高如果你了解一些「架构设计」的要求就知道一个好的软件架构应该遵循以下 3 个原则高性能高可用易扩展其中高性能意味着系统拥有更大流量的处理能力更低的响应延迟。例如 1 秒可处理 10W 并发请求接口响应时间 5 ms 等等。易扩展表示系统在迭代新功能时能以最小的代价去扩展系统遇到流量压力时可以在不改动代码的前提下去扩容系统。而「高可用」这个概念看起来很抽象怎么理解它呢通常用 2 个指标来衡量平均故障间隔 MTBFMean Time Between Failure表示两次故障的间隔时间也就是系统「正常运行」的平均时间这个时间越长说明系统稳定性越高故障恢复时间 MTTRMean Time To Repair表示系统发生故障后「恢复的时间」这个值越小故障对用户的影响越小可用性与这两者的关系可用性Availability MTBF / (MTBF MTTR) * 100%这个公式得出的结果是一个「比例」通常我们会用「N 个 9」来描述一个系统的可用性。从这张图你可以看到要想达到 4 个 9 以上的可用性平均每天故障时间必须控制在 10 秒以内。也就是说只有故障的时间「越短」整个系统的可用性才会越高每提升 1 个 9都会对系统提出更高的要求。我们都知道系统发生故障其实是不可避免的尤其是规模越大的系统发生问题的概率也越大。这些故障一般体现在 3 个方面硬件故障CPU、内存、磁盘、网卡、交换机、路由器软件问题代码 Bug、版本迭代不可抗力地震、水灾、火灾、战争这些风险随时都有可能发生。所以在面对故障时我们的系统能否以「最快」的速度恢复就成为了可用性的关键。可如何做到快速恢复呢这篇文章要讲的「异地多活」架构就是为了解决这个问题而提出的高效解决方案。下面我会从一个最简单的系统出发带你一步步演化出一个支持「异地多活」的系统架构。在这个过程中你会看到一个系统会遇到哪些可用性问题以及为什么架构要这样演进从而理解异地多活架构的意义。02 单机架构我们从最简单的开始讲起。假设你的业务处于起步阶段体量非常小那你的架构是这样的这个架构模型非常简单客户端请求进来业务应用读写数据库返回结果非常好理解。但需要注意的是这里的数据库是「单机」部署的所以它有一个致命的缺点一旦遭遇意外例如磁盘损坏、操作系统异常、误删数据那这意味着所有数据就全部「丢失」了这个损失是巨大的。如何避免这个问题呢我们很容易想到一个方案备份。你可以对数据做备份把数据库文件「定期」cp 到另一台机器上这样即使原机器丢失数据你依旧可以通过备份把数据「恢复」回来以此保证数据安全。这个方案实施起来虽然比较简单但存在 2 个问题恢复需要时间业务需先停机再恢复数据停机时间取决于恢复的速度恢复期间服务「不可用」数据不完整因为是定期备份数据肯定不是「最新」的数据完整程度取决于备份的周期很明显你的数据库越大意味故障恢复时间越久。那按照前面我们提到的「高可用」标准这个方案可能连 1 个 9 都达不到远远无法满足我们对可用性的要求。那有什么更好的方案既可以快速恢复业务还能尽可能保证数据完整性呢这时你可以采用这个方案主从副本。03 主从副本你可以在另一台机器上再部署一个数据库实例让这个新实例成为原实例的「副本」让两者保持「实时同步」就像这样我们一般把原实例叫作主库master新实例叫作从库slave。这个方案的优点在于数据完整性高主从副本实时同步数据「差异」很小抗故障能力提升主库有任何异常从库可随时「切换」为主库继续提供服务读性能提升业务应用可直接读从库分担主库「压力」读压力这个方案不错不仅大大提高了数据库的可用性还提升了系统的读性能。同样的思路你的「业务应用」也可以在其它机器部署一份避免单点。因为业务应用通常是「无状态」的不像数据库那样存储数据所以直接部署即可非常简单。因为业务应用部署了多个所以你现在还需要部署一个「接入层」来做请求的「负载均衡」一般会使用 nginx 或 LVS这样当一台机器宕机后另一台机器也可以「接管」所有流量持续提供服务。从这个方案你可以看出提升可用性的关键思路就是冗余。没错担心一个实例故障那就部署多个实例担心一个机器宕机那就部署多台机器。到这里你的架构基本已演变成主流方案了之后开发新的业务应用都可以按照这种模式去部署。但这种方案还有什么风险吗04 风险不可控现在让我们把视角下放把焦点放到具体的「部署细节」上来。按照前面的分析为了避免单点故障你的应用虽然部署了多台机器但这些机器的分布情况我们并没有去深究。而一个机房有很多服务器这些服务器通常会分布在一个个「机柜」上如果你使用的这些机器刚好在一个机柜还是存在风险。如果恰好连接这个机柜的交换机 / 路由器发生故障那么你的应用依旧有「不可用」的风险。虽然交换机 / 路由器也做了路线冗余但不能保证一定不出问题。部署在一个机柜有风险那把这些机器打散分散到不同机柜上是不是就没问题了这样确实会大大降低出问题的概率。但我们依旧不能掉以轻心因为无论怎么分散它们总归还是在一个相同的环境下机房。那继续追问机房会不会发生故障呢一般来讲建设一个机房的要求其实是很高的地理位置、温湿度控制、备用电源等等机房厂商会在各方面做好防护。但即使这样我们每隔一段时间还会看到这样的新闻2015 年 5 月 27 日杭州市某地光纤被挖断近 3 亿用户长达 5 小时无法访问支付宝2021 年 7 月 13 日B 站部分服务器机房发生故障造成整站持续 3 个小时无法访问2021 年 10 月 9 日富途证券服务器机房发生电力闪断故障造成用户 2 个小时无法登陆、交易...可见即使机房级别的防护已经做得足够好但只要有「概率」出问题那现实情况就有可能发生。虽然概率很小但一旦真的发生影响之大可见一斑。看到这里你可能会想机房出现问题的概率也太小了吧工作了这么多年也没让我碰上一次有必要考虑得这么复杂吗但你有没有思考这样一个问题不同体量的系统它们各自关注的重点是什么体量很小的系统它会重点关注「用户」规模、增长这个阶段获取用户是一切。等用户体量上来了这个阶段会重点关注「性能」优化接口响应时间、页面打开速度等等这个阶段更多是关注用户体验。等体量再大到一定规模后你会发现「可用性」就变得尤为重要。像微信、支付宝这种全民级的应用如果机房发生一次故障那整个影响范围可以说是非常巨大的。所以再小概率的风险我们在提高系统可用性时也不能忽视。分析了风险再说回我们的架构。那到底该怎么应对机房级别的故障呢没错还是冗余。05 同城灾备想要抵御「机房」级别的风险那应对方案就不能局限在一个机房内了。现在你需要做机房级别的冗余方案也就是说你需要再搭建一个机房来部署你的服务。简单起见你可以在「同一个城市」再搭建一个机房原机房我们叫作 A 机房新机房叫 B 机房这两个机房的网络用一条「专线」连通。有了新机房怎么把它用起来呢这里还是要优先考虑「数据」风险。为了避免 A 机房故障导致数据丢失所以我们需要把数据在 B 机房也存一份。最简单的方案还是和前面提到的一样备份。A 机房的数据定时在 B 机房做备份拷贝数据文件这样即使整个 A 机房遭到严重的损坏B 机房的数据不会丢通过备份可以把数据「恢复」回来重启服务。这种方案我们称之为「冷备」。为什么叫冷备呢因为 B 机房只做备份不提供实时服务它是冷的只会在 A 机房故障时才会启用。但备份的问题依旧和之前描述的一样数据不完整、恢复数据期间业务不可用整个系统的可用性还是无法得到保证。所以我们还是需要用「主从副本」的方式在 B 机房部署 A 机房的数据副本架构就变成了这样这样就算整个 A 机房挂掉我们在 B 机房也有比较「完整」的数据。数据是保住了但这时你需要考虑另外一个问题如果 A 机房真挂掉了要想保证服务不中断你还需要在 B 机房「紧急」做这些事情B 机房所有从库提升为主库在 B 机房部署应用启动服务部署接入层配置转发规则DNS 指向 B 机房接入流量业务恢复看到了么A 机房故障后B 机房需要做这么多工作你的业务才能完全「恢复」过来。你看整个过程需要人为介入且需花费大量时间来操作恢复之前整个服务还是不可用的这个方案还是不太爽如果能做到故障后立即「切换」那就好了。因此要想缩短业务恢复的时间你必须把这些工作在 B 机房「提前」做好也就是说你需要在 B 机房提前部署好接入层、业务应用等待随时切换。架构就变成了这样这样的话A 机房整个挂掉我们只需要做 2 件事即可B 机房所有从库提升为主库DNS 指向 B 机房接入流量业务恢复这样一来恢复速度快了很多。到这里你会发现B 机房从最开始的「空空如也」演变到现在几乎是「镜像」了一份 A 机房的所有东西从最上层的接入层到中间的业务应用到最下层的存储。两个机房唯一的区别是A 机房的存储都是主库而 B 机房都是从库。这种方案我们把它叫做「热备」。热的意思是指B 机房处于「待命」状态A 故障后 B 可以随时「接管」流量继续提供服务。热备相比于冷备最大的优点是随时可切换。无论是冷备还是热备因为它们都处于「备用」状态所以我们把这两个方案统称为同城灾备。同城灾备的最大优势在于我们再也不用担心「机房」级别的故障了一个机房发生风险我们只需把流量切换到另一个机房即可可用性再次提高是不是很爽后面还有更爽的06 同城双活我们继续来看这个架构。虽然我们有了应对机房故障的解决方案但这里有个问题是我们不能忽视的A 机房挂掉全部流量切到 B 机房B 机房能否真的如我们所愿正常提供服务这是个值得思考的问题。这就好比有两支军队 A 和 BA 军队历经沙场作战经验丰富而 B 军队只是后备军除了有军人的基本素养之外并没有实战经验战斗经验基本为 0。如果 A 军队丧失战斗能力需要 B 军队立即顶上时作为指挥官的你肯定也会担心 B 军队能否真的担此重任吧我们的架构也是如此此时的 B 机房虽然是随时「待命」状态但 A 机房真的发生故障我们要把全部流量切到 B 机房其实是不敢百分百保证它可以「如期」工作的。你想我们在一个机房内部署服务还总是发生各种各样的问题例如发布应用的版本不一致、系统资源不足、操作系统参数不一样等等。现在多部署一个机房这些问题只会增多不会减少。另外从「成本」的角度来看我们新部署一个机房需要购买服务器、内存、硬盘、带宽资源花费成本也是非常高昂的只让它当一个后备军未免也太「大材小用」了因此我们需要让 B 机房也接入流量实时提供服务这样做的好处一是可以实时训练这支后备军让它达到与 A 机房相同的作战水平随时可切换二是 B 机房接入流量后可以分担 A 机房的流量压力。这才是把 B 机房资源优势发挥最大化的最好方案那怎么让 B 机房也接入流量呢很简单就是把 B 机房的接入层 IP 地址加入到 DNS 中这样B 机房从上层就可以有流量进来了。但这里有一个问题别忘了B 机房的存储现在可都是 A 机房的「从库」从库默认可都是「不可写」的B 机房的写请求打到本机房存储上肯定会报错这还是不符合我们预期。怎么办这时你就需要在「业务应用」层做改造了。你的业务应用在操作数据库时需要区分「读写分离」一般用中间件实现即两个机房的「读」流量可以读任意机房的存储但「写」流量只允许写 A 机房因为主库在 A 机房。这会涉及到你用的所有存储例如项目中用到了 MySQL、Redis、MongoDB 等等操作这些数据库都需要区分读写请求所以这块需要一定的业务「改造」成本。因为 A 机房的存储都是主库所以我们把 A 机房叫做「主机房」B 机房叫「从机房」。两个机房部署在「同城」物理距离比较近而且两个机房用「专线」网络连接虽然跨机房访问的延迟比单个机房内要大一些但整体的延迟还是可以接受的。业务改造完成后B 机房可以慢慢接入流量从 10%、30%、50% 逐渐覆盖到 100%你可以持续观察 B 机房的业务是否存在问题有问题及时修复逐渐让 B 机房的工作能力达到和 A 机房相同水平。现在因为 B 机房实时接入了流量此时如果 A 机房挂了那我们就可以「大胆」地把 A 的流量全部切换到 B 机房完成快速切换到这里你可以看到我们部署的 B 机房在物理上虽然与 A 有一定距离但整个系统从「逻辑」上来看我们是把这两个机房看做一个「整体」来规划的也就是说相当于把 2 个机房当作 1 个机房来用。这种架构方案比前面的同城灾备更「进了一步」B 机房实时接入了流量还能应对随时的故障切换这种方案我们把它叫做「同城双活」。因为两个机房都能处理业务请求这对我们系统的内部维护、改造、升级提供了更多的可实施空间流量随时切换现在整个系统的弹性也变大了是不是更爽了那这种架构有什么问题呢07 两地三中心还是回到风险上来说。虽然我们把 2 个机房当做一个整体来规划但这 2 个机房在物理层面上还是处于「一个城市」内如果是整个城市发生自然灾害例如地震、水灾河南水灾刚过去不久那 2 个机房依旧存在「全局覆没」的风险。真是防不胜防啊怎么办没办法继续冗余。但这次冗余机房就不能部署在同一个城市了你需要把它放到距离更远的地方部署在「异地」。通常建议两个机房的距离要在 1000 公里以上这样才能应对城市级别的灾难。假设之前的 A、B 机房在北京那这次新部署的 C 机房可以放在上海。按照前面的思路把 C 机房用起来最简单粗暴的方案还就是做「冷备」即定时把 A、B 机房的数据在 C 机房做备份防止数据丢失。这种方案就是我们经常听到的「两地三中心」。两地是指 2 个城市三中心是指有 3 个机房其中 2 个机房在同一个城市并且同时提供服务第 3 个机房部署在异地只做数据灾备。这种架构方案通常用在银行、金融、政企相关的项目中。它的问题还是前面所说的启用灾备机房需要时间而且启用后的服务不确定能否如期工作。所以要想真正的抵御城市级别的故障越来越多的互联网公司开始实施「异地双活」。08 伪异地双活这里我们还是分析 2 个机房的架构情况。我们不再把 A、B 机房部署在同一个城市而是分开部署例如 A 机房放在北京B 机房放在上海。前面我们讲了同城双活那异地双活是不是直接「照搬」同城双活的模式去部署就可以了呢事情没你想的那么简单。如果还是按照同城双活的架构来部署那异地双活的架构就是这样的注意看两个机房的网络是通过「跨城专线」连通的。此时两个机房都接入流量那上海机房的请求可能要去读写北京机房的存储这里存在一个很大的问题网络延迟。因为两个机房距离较远受到物理距离的限制现在两地之间的网络延迟就变成了「不可忽视」的因素了。北京到上海的距离大约 1300 公里即使架设一条高速的「网络专线」光纤以光速传输一个来回也需要近 10ms 的延迟。况且网络线路之间还会经历各种路由器、交换机等网络设备实际延迟可能会达到 30ms ~ 100ms如果网络发生抖动延迟甚至会达到 1 秒。不止是延迟远距离的网络专线质量是远远达不到机房内网络质量的专线网络经常会发生延迟、丢包、甚至中断的情况。总之不能过度信任和依赖「跨城专线」。你可能会问这点延迟对业务影响很大吗影响非常大试想一个客户端请求打到上海机房上海机房要去读写北京机房的存储一次跨机房访问延迟就达到了 30ms这大致是机房内网网络0.5 ms访问速度的 60 倍30ms / 0.5ms一次请求慢 60 倍来回往返就要慢 100 倍以上。而我们在 App 打开一个页面可能会访问后端几十个 API每次都跨机房访问整个页面的响应延迟有可能就达到了秒级这个性能简直惨不忍睹难以接受。看到了么虽然我们只是简单的把机房部署在了「异地」但「同城双活」的架构模型在这里就不适用了还是按照这种方式部署这是「伪异地双活」那如何做到真正的异地双活呢09 真正的异地双活既然「跨机房」调用延迟是不容忽视的因素那我们只能尽量避免跨机房「调用」规避这个延迟问题。也就是说上海机房的应用不能再「跨机房」去读写北京机房的存储只允许读写上海本地的存储实现「就近访问」这样才能避免延迟问题。还是之前提到的问题上海机房存储都是从库不允许写入啊除非我们只允许上海机房接入「读流量」不接收「写流量」否则无法满足不再跨机房的要求。很显然只让上海机房接收读流量的方案不现实因为很少有项目是只有读流量没有写流量的。所以这种方案还是不行这怎么办此时你就必须在「存储层」做改造了。要想上海机房读写本机房的存储那上海机房的存储不能再是北京机房的从库而是也要变为「主库」。你没看错两个机房的存储必须都是「主库」而且两个机房的数据还要「互相同步」数据即客户端无论写哪一个机房都能把这条数据同步到另一个机房。因为只有两个机房都拥有「全量数据」才能支持任意切换机房持续提供服务。怎么实现这种「双主」架构呢它们之间如何互相同步数据如果你对 MySQL 有所了解MySQL 本身就提供了双主架构它支持双向复制数据但平时用的并不多。而且 Redis、MongoDB 等数据库并没有提供这个功能所以你必须开发对应的「数据同步中间件」来实现双向同步的功能。此外除了数据库这种有状态的软件之外你的项目通常还会使用到消息队列例如 RabbitMQ、Kafka这些也是有状态的服务所以它们也需要开发双向同步的中间件支持任意机房写入数据同步至另一个机房。看到了么这一下子复杂度就上来了单单针对每个数据库、队列开发同步中间件就需要投入很大精力了。业界也开源出了很多数据同步中间件例如阿里的 Canal、RedisShake、MongoShake可分别在两个机房同步 MySQL、Redis、MongoDB 数据。很多有能力的公司也会采用自研同步中间件的方式来做例如饿了么、协程、美团都开发了自己的同步中间件。我也有幸参与设计开发了 MySQL、Redis/Codis、MongoDB 的同步中间件有时间写一篇文章详细聊聊实现细节欢迎持续关注。:)现在整个架构就变成了这样注意看两个机房的存储层都互相同步数据的。有了数据同步中间件就可以达到这样的效果北京机房写入 X 1上海机房写入 Y 2数据通过中间件双向同步北京、上海机房都有 X 1、Y 2 的数据这里我们用中间件双向同步数据就不用再担心专线问题专线出问题我们的中间件可以自动重试直到成功达到数据最终一致。但这里还会遇到一个问题两个机房都可以写操作的不是同一条数据那还好如果修改的是同一条的数据发生冲突怎么办用户短时间内发了 2 个修改请求都是修改同一条数据一个请求落在北京机房修改 X 1还未同步到上海机房另一个请求落在上海机房修改 X 2还未同步到北京机房两个机房以哪个为准也就是说在很短的时间内同一个用户修改同一条数据两个机房无法确认谁先谁后数据发生「冲突」。这是一个很严重的问题系统发生故障并不可怕可怕的是数据发生「错误」因为修正数据的成本太高了。我们一定要避免这种情况的发生。解决这个问题有 2 个方案。第一个方案数据同步中间件要有自动「合并」数据、解决「冲突」的能力。这个方案实现起来比较复杂要想合并数据就必须要区分出「先后」顺序。我们很容易想到的方案就是以「时间」为标尺以「后到达」的请求为准。但这种方案需要两个机房的「时钟」严格保持一致才行否则很容易出现问题。例如第 1 个请求落到北京机房北京机房时钟是 10:01修改 X 1第 2 个请求落到上海机房上海机房时钟是 10:00修改 X 2因为北京机房的时间「更晚」那最终结果就会是 X 1。但这里其实应该以第 2 个请求为准X 2 才对。可见完全「依赖」时钟的冲突解决方案不太严谨。所以通常会采用第二种方案从「源头」就避免数据冲突的发生。10 如何实施异地双活既然自动合并数据的方案实现成本高那我们就要想能否从源头就「避免」数据冲突呢这个思路非常棒从源头避免数据冲突的思路是在最上层接入流量时就不要让冲突的情况发生。具体来讲就是要在最上层就把用户「区分」开部分用户请求固定打到北京机房其它用户请求固定打到上海 机房进入某个机房的用户请求之后的所有业务操作都在这一个机房内完成从根源上避免「跨机房」。所以这时你需要在接入层之上再部署一个「路由层」通常部署在云服务器上自己可以配置路由规则把用户「分流」到不同的机房内。但这个路由规则具体怎么定呢有很多种实现方式最常见的我总结了 3 类按业务类型分片直接哈希分片按地理位置分片1、按业务类型分片这种方案是指按应用的「业务类型」来划分。举例假设我们一共有 4 个应用北京和上海机房都部署这些应用。但应用 1、2 只在北京机房接入流量在上海机房只是热备。应用 3、4 只在上海机房接入流量在北京机房是热备。这样一来应用 1、2 的所有业务请求只读写北京机房存储应用 3、4 的所有请求只会读写上海机房存储。这样按业务类型分片也可以避免同一个用户修改同一条数据。这里按业务类型在不同机房接入流量还需要考虑多个应用之间的依赖关系要尽可能的把完成「相关」业务的应用部署在同一个机房避免跨机房调用。例如订单、支付服务有依赖关系会产生互相调用那这 2 个服务在 A 机房接入流量。社区、发帖服务有依赖关系那这 2 个服务在 B 机房接入流量。2、直接哈希分片这种方案就是最上层的路由层会根据用户 ID 计算「哈希」取模然后从路由表中找到对应的机房之后把请求转发到指定机房内。举例一共 200 个用户根据用户 ID 计算哈希值然后根据路由规则把用户 1 - 100 路由到北京机房101 - 200 用户路由到上海机房这样就避免了同一个用户修改同一条数据的情况发生。3、按地理位置分片这种方案非常适合与地理位置密切相关的业务例如打车、外卖服务就非常适合这种方案。拿外卖服务举例你要点外卖肯定是「就近」点餐整个业务范围相关的有商家、用户、骑手它们都是在相同的地理位置内的。针对这种特征就可以在最上层按用户的「地理位置」来做分片分散到不同的机房。举例北京、河北地区的用户点餐请求只会打到北京机房而上海、浙江地区的用户请求则只会打到上海机房。这样的分片规则也能避免数据冲突。提醒这 3 种常见的分片规则第一次看不太好理解建议配合图多理解几遍。搞懂这 3 个分片规则你才能真正明白怎么做异地多活。总之分片的核心思路在于让同一个用户的相关请求只在一个机房内完成所有业务「闭环」不再出现「跨机房」访问。阿里在实施这种方案时给它起了个名字叫做「单元化」。当然最上层的路由层把用户分片后理论来说同一个用户只会落在同一个机房内但不排除程序 Bug 导致用户会在两个机房「漂移」。安全起见每个机房在写存储时还需要有一套机制能够检测「数据归属」应用层操作存储时需要通过中间件来做「兜底」避免不该写本机房的情况发生。篇幅限制这里不展开讲理解思路即可现在两个机房就可以都接收「读写」流量做好分片的请求底层存储保持「双向」同步两个机房都拥有全量数据当任意机房故障时另一个机房就可以「接管」全部流量实现快速切换简直不要太爽。不仅如此因为机房部署在异地我们还可以更细化地「优化」路由规则让用户访问就近的机房这样整个系统的性能也会大大提升。这里还有一种情况是无法做数据分片的全局数据。例如系统配置、商品库存这类需要强一致的数据这类服务依旧只能采用写主机房读从机房的方案不做双活。双活的重点是要优先保证「核心」业务先实现双活并不是「全部」业务实现双活。至此我们才算实现了真正的「异地双活」到这里你可以看出完成这样一套架构需要投入的成本是巨大的。路由规则、路由转发、数据同步中间件、数据校验兜底策略不仅需要开发强大的中间件同时还要业务配合改造业务边界划分、依赖拆分等一些列工作没有足够的人力物力这套架构很难实施。11 异地多活理解了异地双活那「异地多活」顾名思义就是在异地双活的基础上部署多个机房即可。架构变成了这样这些服务按照「单元化」的部署方式可以让每个机房部署在任意地区随时扩展新机房你只需要在最上层定义好分片规则就好了。但这里还有一个小问题随着扩展的机房越来越多当一个机房写入数据后需要同步的机房也越来越多这个实现复杂度会比较高。所以业界又把这一架构又做了进一步优化把「网状」架构升级为「星状」这种方案必须设立一个「中心机房」任意机房写入数据后都只同步到中心机房再由中心机房同步至其它机房。这样做的好处是一个机房写入数据只需要同步数据到中心机房即可不需要再关心一共部署了多少个机房实现复杂度大大「简化」。但与此同时这个中心机房的「稳定性」要求会比较高。不过也还好即使中心机房发生故障我们也可以把任意一个机房提升为中心机房继续按照之前的架构提供服务。至此我们的系统彻底实现了「异地多活」多活的优势在于可以任意扩展机房「就近」部署。任意机房发生故障可以完成快速「切换」大大提高了系统的可用性。同时我们也再也不用担心系统规模的增长因为这套架构具有极强的「扩展能力」。怎么样我们从一个最简单的应用一路优化下来到最终的架构方案有没有帮你彻底理解异地多活呢总结好了总结一下这篇文章的重点。1、一个好的软件架构应该遵循高性能、高可用、易扩展 3 大原则其中「高可用」在系统规模变得越来越大时变得尤为重要2、系统发生故障并不可怕能以「最快」的速度恢复才是高可用追求的目标异地多活是实现高可用的有效手段3、提升高可用的核心是「冗余」备份、主从副本、同城灾备、同城双活、两地三中心、异地双活异地多活都是在做冗余4、同城灾备分为「冷备」和「热备」冷备只备份数据不提供服务热备实时同步数据并做好随时切换的准备5、同城双活比灾备的优势在于两个机房都可以接入「读写」流量提高可用性的同时还提升了系统性能。虽然物理上是两个机房但「逻辑」上还是当做一个机房来用6、两地三中心是在同城双活的基础上额外部署一个异地机房做「灾备」用来抵御「城市」级别的灾害但启用灾备机房需要时间7、异地双活才是抵御「城市」级别灾害的更好方案两个机房同时提供服务故障随时可切换可用性高。但实现也最复杂理解了异地双活才能彻底理解异地多活8、异地多活是在异地双活的基础上任意扩展多个机房不仅又提高了可用性还能应对更大规模的流量的压力扩展性最强是实现高可用的最终方案后记这篇文章我从「宏观」层面向你介绍了异地多活架构的「核心」思路整篇文章的信息量还是很大的如果不太好理解我建议你多读几遍。因为篇幅限制很多细节我并没有展开来讲。这篇文章更像是讲异地多活的架构之「道」而真正实施的「术」要考虑的点其实也非常繁多因为它需要开发强大的「基础设施」才可以完成实施。不仅如此要想真正实现异地多活还需要遵循一些原则例如业务梳理、业务分级、数据分类、数据最终一致性保障、机房切换一致性保障、异常处理等等。同时相关的运维设施、监控体系也要能跟得上才行。宏观上需要考虑业务微服务部署、依赖、拆分、SDK、Web 框架、基础设施服务发现、流量调度、持续集成、同步中间件、自研存储微观上要开发各种中间件还要关注中间件的高性能、高可用、容错能力其复杂度之高只有亲身参与过之后才知道。我曾经有幸参与过存储层同步中间件的设计与开发实现过「跨机房」同步 MySQL、Redis、MongoDB 的中间件踩过的坑也非常多。当然这些中间件的设计思路也非常有意思有时间单独分享一下这些中间件的设计思路。值得提醒你的是只有真正理解了「异地双活」才能彻底理解「异地多活」。在我看来从同城双活演变为异地双活的过程是最为复杂的最核心的东西包括业务单元化划分、存储层数据双向同步、最上层的分片逻辑这些是实现异地多活的重中之重。往期推荐阿里云投入 20 亿发力操作系统数学在左人生在右Redis很厉害使用规范来啦低代码会让程序员更加内卷吗点分享点收藏点点赞点在看
