从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

28 | 业务高可用的保障:异地多活架构

李运华 2018-06-30
无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,而且即使有其他地区的备份,把备份业务系统全部恢复到能够正常提供业务,花费的时间也比较长,可能是半小时,也可能是 12 小时。因为备份系统平时不对外提供服务,可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。
今天我来聊聊异地多活架构,接下来还会再讲异地多活架构的设计技巧和流程。

应用场景

顾名思义,异地多活架构的关键点就是异地、多活,其中异地就是指地理位置上不同的地方,类似于“不要把鸡蛋都放在同一篮子里”;多活就是指不同地理位置上的系统都能够提供业务服务,这里的“活”是活动、活跃的意思。判断一个系统是否符合异地多活,需要满足两个标准:
正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务。
某个地方业务异常的时候,用户访问其他地方正常的业务系统,能够得到正确的业务服务。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(46)

  • 空档滑行
    备份系统平常没有流量,如果直接上线可能触发平常测试不到的故障。
    再实时的系统也会有数据延时,如果涉及到金融这种系统,仍然是不敢直接切换的。
    系统运行过程中会有很多中间数据,缓存数据等。系统不经过预热直接把流量倒过来,大流量会直接把系统拖垮

    作者回复: 分析全面,赞👍

    2018-06-30
    64
  • 王磊
    文章提到异地多活的代价时,说到复杂的架构,但通篇没有一个架构图,从文字看,也没完全理解架构的细节,例如异地之间如何同步,一地出现问题,如何切换,例如北京的业务系统出问题了,怎么用广州的业务系统来抗过去。

    作者回复: 后面还有两篇

    2018-06-30
    11
  • 康文
    现在流行云服务,对于企业做异地多活、灾备会不会很省事?

    作者回复: 不会,云服务一样宕机

    2018-06-30
    9
  • 微风
    李老师,像文中提到的不同的异地多活架构产生的不同成本,没有直观印象,您能否系统性的给个具体的分析~

    作者回复: 支付宝为了底层支持异地多活,自己写了Oceanbase,Oceanbase写了7~8年了还没有完全代替MySQL😄

    2018-10-06
    4
  • 彡工鸟
    支付宝多活也不是正在意义上的多活吧。我记得之前支付宝故障影响部分用户,感觉更多像是分区提供服务
    2018-07-02
    4
  • 武坤
    这得看这1分钟对业务的影响,如果影响不大就没必要做,如果影响较大,还是得做异地多活

    作者回复: 就算是现在异地多活的系统,也做不到实时异地多活的,分钟级的影响都是存在的

    2018-06-30
    4
  • CYH
    请教个问题:文章说支付宝类的金融服务一般采用的是同城异区架构.那假如真的发生了类似奥尔良水灾问题,支付宝如何保证业务正常?要解决这问题的话是多地部署(多地间服务状态不同步),存储高可用?

    作者回复: 支付宝也没法100%保障,不然蓝翔挖掘机就不会导致支付宝故障了

    2018-07-02
    3
  • 孙振超
    假设我们做了前面提到的高可用存储架构中的数据分区备份,又通过自动化运维能够保证 1 分钟就能将全部系统正常启动,那是否意味着没有必要做异地多活了?

    数据分区备份意味着分区中的数据和当前提供服务的机房数据可能存在这延迟,同时备份系统启动后能否按照期望的sla提供服务是无法保证的。

    但不同类型的系统对于数据和可用性的要求也是不同的,对于新闻、网络小说、论坛、政府学校等以阅读资讯为主的系统来说如果可以做到分钟级正常重启,是没有必要做异地多活的;对于电商、银行和钱相关的系统还是需要做异地多活的。

    作者回复: 分析正确

    2018-08-27
    2
  • 今夕是何年
    还是要考虑异地多活的。数据备份和存储高可用没法应对大规模停电 地震这种极端灾难。

    作者回复: 异地多活也是需要数据备份和存储高可用的

    2018-07-01
    2
  • 浪子恒心
    这期讲的有点浅,希望能更深入的谈谈异地多活怎么实现,有没有什么模式。

    作者回复: 后面还有两章

    2018-06-30
    2
  • 王磊
    有个问题,不太清楚。异地多活,即使同城异区,他们都有对用户不同的访问ip吗,当一地出现问题的时候,用户自己尝试访问另一地?如果是自动切换,是什么机制,dns全部解析到另一地的ip?

    作者回复: 每个机房都对外提供服务,都有不同出口ip,由DNS等负载均衡设备切换(适应web),或者端自己切换(适应app)

    2018-06-30
    2
  • Geek_88604f
    首先第一点业务会中断一分钟,这对于微信或支付宝这样的系统来说是不可接受的,特别是像春节这样的关键时刻,万万不可掉链子。
            第二点数据不一致,如果在主分区故障前还没有将数据同步到备分区,那么在主分区恢复前数据一直不一致。对于像新闻或微博之类的应用还好说,对于电商或微信等系统就不可接受。
            第三点备用分区的可用性,发生故障往往是在业务高峰期,这个时候备份区能否抗住是值得怀疑的。一个从来没有锻炼过的人,突然让他跑马拉松估计扛不住。
            最后一点缓存,如果系统中存在缓存,缓存的数据在备分区是没有的,缓存需要预热,一下子切到备出现缓存击穿导致存储扛不住

    作者回复: 分析到位

    2019-09-17
    1
  • 目的不同吧,即使做了前面提到的高可用存储架构中的数据分区备份,又通过自动化运维能够保证 1 分钟就能将全部系统正常启动,那还是不能解决不可抗力(自然灾害等)带来的不可用,因此,对于需要做异地多活的业务还是有必要做异地多活的。

    作者回复: 赞同

    2019-05-31
    1
  • 大宝
    最近看CIPS(人民币跨境支付系统)的相关信息,官网中有这么一条新闻:  
    “本次CIPS主备中心切换用时67秒,较上一次切换运行用时缩短了19秒,进一步提高了切换效率及系统连续运行能力。此次切换运行充分验证了CIPS二期全面投产后备份中心系统配置的正确性和可用性。后续,CIPS运营机构将进一步提高业务连续性保障能力,完善系统服务功能,提升用户使用体验。”
    结合老师讲的最近几章,推断CIPS是主备系统架构,不是异地多活,使用的是数据分区备份,并且官网之前也提到主系统在上海,备份系统在无锡。
    但是我感觉有两个奇怪的地方:一个是:主备在上海和无锡,这两个地方觉得不远也不近,看了下地图约150公里吧,感觉既不是“同城异区”,也算不上“跨城异地”。另一个他作为金融系统使用主备架构,而没有使用异地多活架构,是不是有点业余?

    作者回复: 1. 距离这么近确实有问题,例如台风或者地震,很可能两个机房都受影响
    2. 金融系统大部分使用主备架构,不算业余但也算不上先进,金融系统对数据一致性要求很高,异地多活很多业务做不了

    2018-10-22
    1
  • 碧海蓝天
    余额数据同城异区对比跨城异地在数据一致性上同样存在时间差,只是时间窗口更小而己,如果两地都支持写的话,存在被双花攻击的可能,风险还是很大,有什么方法避免吗

    作者回复: 没有,余额和库存一般不做双写,目前Oceanbase通过paxos算法支持多机房写入,但实际性能我不太了解

    2018-10-17
    1
  • 尼古拉斯·俊杰
    多活不是同时运行的吗

    作者回复: 多活是主要同时运行并且对外提供服务

    2018-08-29
    1
  • J
    老师,我对文章中提到的支付宝不采用跨城异地,而采用同城异区的多活存在疑问,从逻辑上来讲同城异区即便网络延迟很小,但总归是有延迟的,也会从某种程度上影响一致性,架构也必须引入方案解决一致性问题,两者不存在一致性上的复杂度差异,而同城和异地的差异是不是应该是在用户体验上来区别?比如,同样是转账业务,一个转账请求需要在多个活动机房都同步后才向用户返回成功,这样的话,同城的优势就在于响应时间很快,而异地可能就会很慢。

    作者回复: 同城异区也是有延迟的,但是延迟小,故障切换时快,但总是有可能有用户数据不一致,这种数量小就可以容忍,人工修复和事后补偿的代价都可以接受,不存在所有用户都没任何问题的方案。

    转账请求一般不做同步,做好备份就可以了,因为对实时性要求不高

    2018-08-26
    1
  • xderam
    以前微博做过异地机房 但是因为种种原因 还是回到了同城多机房的架构

    作者回复: 微博很多业务应该可以做异地多活呀

    2018-07-23
    1
  • freebird4ever
    文章中支付宝转账的例子不对。支付宝通过分布式事务保证转账交易的原子性。oceanbase保证异地多个节点中大部分节点写成功。未写成功的节点异步恢复。未恢复前不可发生新的交易。

    作者回复: 文中的例子是多地都可以同时写,oceanbase底层基于paxos算法,从业务的角度看起来是多地都可以写,但本质上是通过一致性算法避免同时写,paxos同时写会出现冲突,冲突就要重新发起写操作

    2018-07-11
    1
  • Alan
    能不能给一个系分的案例呢,全面一点的

    作者回复: 案例很多,后面两章会讲具体怎么做

    2018-07-02
    1
收起评论
46
返回
顶部