全球异地多活架构设计(一): 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://blog.csdn.net/u012422829/
<https://blog.csdn.net/u012422829/> 。

热门工具换一换