拆解交易系统--异地多活

点击上方蓝色字体,选择“设为星标”

优质文章,及时送达

很多产品发展到一定规模之后,可能会走出国门,技术架构要做到国际化。或者基于高可用 / 高性能的需求,需要做异地多活。

多数据中心架构

两者在是实现上有一定类似之处,比如都可以建立独立的数据中心,数据中心内部做一套自治系统,也就是说独立数据中心内需要具备完备的功能,做到链路内聚,内聚服务可以独立在数据中心内运行。

系统自治对于服务层来说比较简单,服务扩容时无状态服务只要做到可以水平扩展就可以了。所以统一部署到数据中心内即可。

但存储服务就比较复杂一些,需要保证数据中心内服务可以独立运行,还需要做好多数据中心之间的数据同步,因为需要保证多个数据中心之间的数据一致。

可能是Master-Master架构,就是两个数据中心都是可写的,或者是Master-Slave架构,一个写另一个读,具体使用哪种,需要依业务场景来设计。

Master-Master存储架构

Master-Master架构,处理数据一致性是个很大的挑战,两个数据中心之间因地理位置较远,存在较大的延迟。

如果是国际化系统的独立部署,延迟会更高一些,比如国内用户写到上海Master,所有写操作需要回到国内数据中心完成。国外用户数据写到国外数据中心Master,写操作在国外数据中心进行。

架构层次上看是Master-Master,在用户数据纬度看是Master-Slave模式,每条数据只能在用户归属的数据中心写入,再通过异步复制方式写到其他数据中心中。

多数据中心通过数据复制方式实现了数据最终一致性。如何在业务逻辑纬度处理这种数据弱一致性带来的问题呢?

需求一:用户访问数据问题

想象一个场景,如果用户可以根据自己的位置就近接入数据中心,那么所有的读写数据处理一致性的场景就会收到影响,业务逻辑需要对数据一致性做到实时改变,需要做好数据一致性处理和用户请求依照数据实时性做路由。

整体设计上会带来高昂的实现成本和维护成本,很大一定程度上限制了系统的无状态扩容的能力。

所以我们可以限制用户访问哪个数据,通过路由服务将用户路由到常用的数据中心,那里有其已归属的数据。这样用户数据读写的一致性问题就迎刃而解了。数据可以做到一定程度的强一致,也不需要在数据之间做数据的实时同步,也降低了数据同步带来的宽带需求。

需求二:用户访问其他用户数据

上面解决了用户自己数据读写的需求,但是当用户想访问其他用户的其他数据中心数据时应该怎么处理呢?

这种场景下我们从业务角度考虑下,其实大部分场景对数据一致性要求并不高。需求场景下可以支持一定的数据延迟,也并不会带来太大的问题。

如果对于数据一致性要求比较高的场景,比如支付金融场景,可以提供全局的分布式事务或是分布式锁的方式解决。当然场景很少,所以也不会带来太大问题。

数据同步的可靠性实现

数据中心之间需要做大量的数据同步,数据是否达到最终一致,取决于数据同步服务是否可靠。

这种情况一般借助于消息队列实现,依靠消息队列的顺序写,一个备份同步成功即算作成功,如果失败则重试。这样可以让消息队列有更好的可用性和写入性能。

每个数据中心将需要同步的数据写入本数据中心的消息队列,由其他数据中心对数据进行拉取与重放,达到数据同步的目的。

异地多活容灾

很多巨型互联网产品发展到一定规模之后,其可用性往往造成很大经济损失,比如微信,支付宝这些用户规模巨大的产品,如果可用性有一点的降级,都会对大规模的用户影响,所以微信,支付宝这些产品早已做了异地多活。

比如某个数据中心园区主光纤被挖断,可能造成几千台服务器不可用,引发整个数据中心服务瘫痪。

以前我曾遇到一次这样的事故,当时某个数据中心服务不可用,我们尝试修改接入服务,将故障中心的流量迁走,但是收效甚微。

数据中心内的上百个服务虽然做了容灾和冗余设计,每个模块看起来都没有单点故障问题。但整体上无数个服务实例分散在数据中心多个机房几千台服务器上,服务之间通过RPC调用,调用链路复杂,呈网状结构。

同时虽然服务做了冗余和可用性设计,但是没有做过对应的容灾等级规划和容灾验证与故障演练,没人知道切走流量是否可以保证整个服务多个数据中心是否可用,是否会出现什么不可控情况造成雪崩。

所以针对于类似问题,可以做多个园区的容灾设计,每个数据中心服务部署到物理隔离的多个园区,单个园区整体故障时,也不会造成整个数据中心的不可用。

传统灾备方案

传统数据中心的灾备方案,一般是同城两个互备数据中心,异地建设一个灾备中心,三个数据中心平时只能一个提供在线服务,故障时将业务流量切到其他数据中心。一份数据在多个园区之间保留至少2个以上副本,这样在一个园区故障后,可以无损对外提供服务。

这种方案的问题在于,灾备中心平时无实际流量,在主数据中心故障时,切换到灾备数据中心可能还会造成大量服务不可用情况,同时造成资源浪费。

所以优化方案是,三个数据中心可以同时提供服务,某个数据中心故障时,另外两个园区业务流量只会各增加50%。每个园区资源跑在容量的2/3,保留1/3容量,提供无损容灾能力。

因为三个园区同时提供在线服务,所以服务故障时,要解决的是怎样把服务流量切到其他园区,方案也就更简单了。

有了迁移容灾方案,是否可以做到故障时自动迁移流量,对业务透明呢?

这就需要我们对服务模块可以准确识别出某些服务可用性问题,然后自动切换到其他服务实例,而避免被拖死。

同时还需要建立一套手工操作对全局对业务透明的系统,可以在大型网络故障时,由人工介入,实现业务流量快速迁移或分散到其他园区或数据中心。

设计并部署了整体技术方案之后,很重要的一点就是需要做故障演练,看看迁移效果是否符合预期。

发布了15 篇原创文章 · 获赞 0 · 访问量 68
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 游动-白 设计师: 上身试试

分享到微信朋友圈

×

扫一扫,手机浏览