全球异地多活架构设计(一): Why and How

很多全球化的产品, 比如facebook、twitter, 它们的用户遍布世界各地。 工程师们往往会在全球设立多个数据中心(DC)供用户访问, 我们可以称之为异地多活。在后续一段时间里, 我会写一系列的博客,和大家一起探索异地多活架构。

这篇文章主要是讨论我们为什么需要异地多活, 以及实现这种架构所需要解决的问题。

一、异地多活的好处

1. 提升用户体验

一个产品最重要的是提供良好的用户体验,这对后端服务提出了几个要求:

服务的高可用

对于一些服务而言, 需要提供6个9甚至以上的可用性。 高可用的原则就是避免单点+自动故障转移。 为了避免机房粒度的单点, 我们需要提供多个DC, 彼此做灾备。

良好的响应速度

如果全球只有一个DC,那么所有的用户都只能访问这一个。 这种情况下,跨洲级别的RTT(一般来说>200ms),对于用户体验而言是个灾难。 所以全球级的产品需要在世界各地部署DC,供用户就近访问。

2. 降低成本

廉价的机器

我们都知道, 很多商品在不同地方的价格是不一样的,服务器也不例外。  如果能让非洲用户访问本地廉价的后端服务, 为什么要让他们的流量跑到美东去呢?

流量的分摊

一般而言,我们需要控制机器资源大于峰值流量的某个百分比, 比如为1w日活备好2w日活的机器。

如果你的DC已经遍布世界各地, 那么如果某地的流量疯涨时,你不需要担心机器资源不能及时到位、为高峰期扩容后的资源浪费这种问题。 比如过万圣节、圣诞节时,facebook美国流量疯长, 这时候我们可以选择把一部分流量切到亚洲地区的DC。 

二、如何做到异地多活

要做到异地多活, 有几个问题我们必须解决:

接入层流量控制

用户默认访问哪个DC? 什么时候做切换? 如何控制这个切换过程?

DC业务逻辑一致

对于用户来说, 他的流量被调度前后,业务逻辑是一致的。 比如facebook上有一些内容对于亚洲用户是不可见的,不能因为亚洲用户的流量被迁移到了美洲机房,这个限制就失效了。

DC的实时数据同步与冲突处理

还是以fb为例, 如果访问非洲机房的用户A给访问南美洲机房的用户B的一个帖子点了赞, 那么B应该能及时收到相关的通知。这背后就依赖数据的实时同步。

在多活情况下, DC的数据写入势必会引入数据的冲突, 比如facebook位于美东的的审核系统和位于东南亚的用户同时操作了一条帖子, 就会产生数据的冲突。

提供全球级别的强一致性

对于大多数业务而言, 我们只需要最终一致性即可(比如点赞之类的计数)。 但是某些业务,需要全球的强一致保障(比如下单、支付之类的操作)。

https://mp.weixin.qq.com/s/vkvYJnKfQyuUeD_BDQy_1g

获取更多学习资料,可以加群:473984645或扫描下方二维码

猜你喜欢

转载自www.cnblogs.com/lemonrel/p/11794042.html