<blockquote id="pww52"></blockquote>

          <div id="pww52"><tr id="pww52"><object id="pww52"></object></tr></div>
          <div id="pww52"></div>
        1. <div id="pww52"></div>
        2. 首页 > 基础设施 > 正文

          做容灾,双活、多活、同城、异地、多云,到底应该怎么选?

          2019-03-18 14:11:24  来源:Forrest随想录

          摘要:不管怎么选择容灾方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双活和多活,就是特么的扯淡。所以,打算搞双活,先从这里下手,当然牵出来就要涉及到分布式,还有很多大量细节技术问题。
          关键词: 容灾
            结论,可?#28798;?#25509;拖到最后,如果看不明白,可以从头看起。
           
            最近,公有云又出了些大故障,各大群和朋友圈又开始沸沸扬扬,但是整体看下来,声音无非两种:
           
            单站点不?#31185;祝?#35201;有容灾,出现这?#26234;?#20917;就得马上?#26657;?#25152;以回去赶紧建设容灾站点;
           
            鸡蛋不能放在一个篮子里,单云不?#31185;祝?#35201;多云。所以,多云就要选我们?#19994;膞x云,或者我们提供xx多云服务。
           
          \
           
            我在?#19994;?#19968;个讨论群里就提出来,第一种声音是有意识的建设,有这个意识很好,但?#21069;?#36825;个事情想得太简单了。第二种声音,基本就是不动脑子的瞎BB,原因我下面讲。
           
            转回正题来,既然上篇提到主备模式不?#31185;祝?#37027;到底怎么选?而且整天见各类技术文章,不是双活,就是多活,不是同城,就是异地,现在又出来个多云,好复杂。
           
            下面我就谈谈?#19994;?#29702;解:
           
            首先,这么多名词是什么含义,要搞清楚,然后再?#35789;?#19981;适合。
           
            先讲相对简单的双活(简不简单,看后面就明白了),其实就是两个站点,同时承载业务流量,可以根据用户ID、地域或者其他业务属性也决定怎么分担流量,当一个站点故障时,可以快速(分钟级)切换到另一个站点,理想情况下,对业务基本是无损或者非常小的。
           
            这里就跟前面讲的主备不同了,主备的另一个站点完全是不承载任何流量的。
           
            这里再往深里看一眼,同时承载流量,也要看承载到那一层,也就是流量在统一站点内闭环,所有调用都是本机房内完成,还是只有应用层这样的无状态组件双活,但是数据访问、异步消息这些有状态的部件还是回到主站点调用,这两种模式又是不一样的。
           
            其实第二种,就比前面讲的主备模式要好一些,因为这样至少可以保证应用层随时可用,不过真出故障的时候,还是少不了数据层的切换,这个其实是非常耗时的。跟主备模式一样,基本无法演练,因为代价太高,数据会有损。(如果数据层没有这么复杂,只有几个数据库,那是没问题问题的,但是分布式的场景下,上百个,几百个实例切换,这个代价?#32479;?#26412;还是很大的。)
           
            所以,再往下推导,如果想要做到?#34892;?#26524;的双活,就必须保证每个站点,都是独立运行,所有的调用都是本机房调?#20204;?#38381;环,底层做好数据同步即可。
           
            只有做到这个程度,当一个站点发生故障不可用时,就可以从接入层把故障站点的流量切换到另一个站点,双活的效果也就有了。
           
            不过,做到这个程度,就不是说我们想要做就能做到的,如果您做个类似的架构设计,你会知道这里有三个关键的技术点:
           
            第一个,本机房调用
           
            也就是一个分布式请求不能跨机房调来调去,这个是不行的,必须要保证本机房调用闭环。所以从分布式服务的路由策略上,以及服务化框架上,必须得支持这也中调用模式,同理,数据访问层,以及消息组件也要支持这种特性。
           
            第二个,数据分片和一致性
           
            为什么要做这个事情?我们知道一个系统中数据?#26082;沸浴?#23436;整性和一致性是非常关键的,放到双活这个场景下,最关键的就是数据一致性,我们不能?#24066;?#26377;同一个记录两边同时在变更,还要双向同步,比如用户交易和支付类的数据,同时变更的情况下,我们无法确认哪边是?#26082;?#30340;。
           
            前面提到,两个站点是同时承载不同的流量的,这就要根据一些业务属性来分配,比如用户ID、所属地域等等策略,这里为的就是能够在数据层面也要做好隔离,一个站点内只提供固定部分的用户访问。
           
            这样就保证了单站点内同一分片的数据,不会在另外一个站点被变更,后续的同步也可以做到单向。
           
            所以,这里的关键,就是数据要做分片,就要用到分布式的数据中间件,要做数据访问的路由设计,数据要同机房读写,还要做数据拆分这样的工作,技术门槛和工作量也不低。
           
            这两点如果能够做到,其实就是我们经常说的“单元化”架构达成了,理论上,我们可以选择任何一个机房和地域,把系统搭建起来,就可以提供业务访问了。
           
            但现实是更为复杂的,因为用户业务系统产生的数据,有可能会被其它系统用到,比如商?#25151;?#23384;这样的系统,这就要涉及异步消息和数据的同步问题,而数据同步不仅仅是一个技术问题,而是个物理问题,我们接下来讲。
           
            第三个,数据同步。
           
            其实单从同步角度而言,目前很多的同步工具和开源产品已经比较完善,所以这里最大的问题,其实不在技术层面,而是在物理层面。
           
            ?#26082;?#28857;,就是物理距离上的时延问题,这个无论是双活、多活,还是同城、异地,都绕不开的痛苦问题。
           
            既然要双活,必然会选择另一个跟当前机房有一定距离的机房(同城或异地),而且距离必须得拉开才有意义,如果都在一个园区里面,就没有任何容灾意义了。
           
            距离一旦拉开,物理距离?#32479;?#26469;了,?#35789;?#26159;专线相连,中间也要经过很多网络设备,如果是云化的网络架构下,经过的软硬设备就更多,还有可能涉及协议转换,如果?#22411;?#36328;运营商,就更难保障,这样一来时延肯定是几倍、十几倍,甚至是上百倍的上?#29301;?#30452;接从0.x毫秒,上涨到秒级别。
           
            对于同城来?#25285;?#36825;个问题还好,但是一旦跨省就完全不可控,特别是机房如果不是自己的,根本无法控制。所以,想大公司自建机房,一定会在这个层面做大量的优化,尽最大可能降低时延。
           
            就以淘宝、天猫为例,按照之前了解的情况,基本也是杭州和上海这两个城市为主做双活,再远时延这个问题就绕不开了。
           
            数据同步及时性为什么这么重要,一个是业务体验,不能说库存都没了,其他用户看到的还是有货,这个是不会被接受的。
           
            再就是故障时,如果同步不及时,极有可能造成?#35813;?#38047;内的交易数据丢失,或者不一致,像淘宝这样每秒4位数订单量的系统,丢?#35813;?#38047;数据,造成的损失也是巨大的。所以,这里就必须要建设有一整套的数据完整性和一致性保障措施,尽最大程度降低业务损失。
           
            所以,数据同步所依赖的时延问题,其实就已经超出了绝大部分公司所能掌控的范畴,也不是单?#38752;?#33258;身技术能解决的问题,要看天时和地利。
           
            讲到这里,我想多活就不用讲了,时延这个问题解决不了,多活就是扯淡,至于同城和异地,我想看明白的读者,也知道怎么选择了,其实一样,还是取决于时延。
           
            我们可以得出的几个结论:
           
            不管怎么选择容灾方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双活和多活,就是特么的扯淡。所以,打算搞双活,先从这里下手,当然牵出来就要涉及到分布式,还有很多大量细节技术问题。
           
            一个合理的建设节奏应该是,同城双活—异地双活—两地三?#34892;?同城双活+异地多活),因为你要解决的问题的复杂度和难度也是在逐步上升的,不可能一蹴而就。
           
            题目里这些个名词,不是孤立的,而是从不同维度看到的结论,但是如果你偏离自己的业务场景去看,孤立的去看,就一定会被带到沟里去,而且不知道该如何下手,所以,一定别偏离你的业务场景,然后把它们联系起?#30784;?/div>
           
            一切都是ROI,为了保证高可用,就一定会有成本,高可用程度越高,成本就一定越高,所以成?#23601;?#20837;得到的收益到底划不划算,这个只能自家公司自?#31227;瑯小?/div>
           
            现实情况,?#20219;?#20889;的要复杂的多的多,推荐大家看两个成功案例,一个是毕玄的异地多活数据?#34892;模?#19968;个是饿了么异地多活,几个关键字google一下就有了,里面涉及到的场景化的细节对大家理解这件事情的复杂?#28982;?#26377;更帮助。

          第二十八届CIO班招生
          法国布雷斯特商学院MBA班招生
          法国布雷斯特商学院硕士班招生
          法国布雷斯特商学院DBA班招生
          责编:pingxiaoli
          湖北体彩11选5走势图

          <blockquote id="pww52"></blockquote>

                <div id="pww52"><tr id="pww52"><object id="pww52"></object></tr></div>
                <div id="pww52"></div>
              1. <div id="pww52"></div>

                <blockquote id="pww52"></blockquote>

                      <div id="pww52"><tr id="pww52"><object id="pww52"></object></tr></div>
                      <div id="pww52"></div>
                    1. <div id="pww52"></div>