Java资源分享网 - 专业的Java学习网站 学Java,上Java资源分享网
行业案例:饿了么异地多活架构演进 PDF 下载
匿名网友发布于:2024-11-10 10:10:14
(侵权举报)
(假如点击没反应,多刷新两次就OK!)

行业案例:饿了么异地多活架构演进 PDF 下载 图1

 

 

资料内容:

 

背景:为什么要做异地多活?

饿了么要做多活,是受业务发展的驱动,经过几年的高速发展,我们的业务已经扩大到单个数据中心撑 不住了,主要机房已经不能再加机器,业务却不断的要求加扩容,所以我们需要一个方案能够把服务器 部署到多个机房。

 

另外一个更重要的原因是,整个机房级别的故障时有发生,每次都会带来严重的后果,我们需要在发生 故障时,能够把一个机房的业务全部迁移到别的机房,保证服务可用。 异地多活面临的主要挑战是网络延迟,以北京到上海 1468 公里,即使是光速传输,一个来回也需要接 近10ms,我们在实际测试的过程中,发现上海到北京的网络延迟,一般是 30 ms。

 

这 30 ms可以和运算系统中其他的延迟时间做个比较:

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
Round trip within same datacenter ...... 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms

北京上海两地的网络延迟时间,大致是内网网络访问速度的 60 倍(30ms/0.5ms).

如果不做任何改造,一方直接访问另外一方的服务,那么我们的APP的反应会比原来慢 60 倍,其实考 虑上多次往返,可能会慢600倍。

 

如果机房都在上海,那么网络延迟只有内网速度的2倍,可以当成一个机房使用。 所有有些公司的多活方案,会选择同城机房,把同城的几个机房当成一个机房部署,可以在不影响服务 架构的情况下扩展出多个机房,不失为一个快速见效的方法。

L1 cache reference ......................... 0.5 ns Branch mispredict ............................ 5 ns L2 cache reference ........................... 7 ns Mutex lock/unlock ........................... 25 ns Main memory reference ...................... 100 ns Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs SSD random read ........................ 150,000 ns = 150 µs Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs Round trip within same datacenter ...... 500,000 ns = 0.5 ms Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms

我们在做多活的初期也讨论过同城方案,比如在北京周边建设一个新机房,迁移部分服务到新机房,两 个机房专线连接,服务间做跨机房调用。 虽然这个方案比较容易,也解决了机房的扩展问题,但是对高可用却没有好处,相反还带来了更高的风 险。

异地多活的关键

与同城多活的方案不同,异地多活的关键—— 限制机房间的相互调用,需要对业务 进行单元化改造 —— 定义清晰的服务边界,减少相互依赖,让每个机房都成为独立的单元,不依赖于其他机房。