[转]亿级流量架构系列专栏总结[2]架构可扩展性

在《亿级流量系统架构》系列第一阶段中，我们从零开始，讲述了一个大型数据平台的几个方面的构建，包括：

• 如何承载百亿级数据的存储挑战
• 如何承载设计高容错的分布式架构
• 如何设计高性能架构，使之能承载百亿级流量
• 如何设计高并发架构，能够支撑住每秒数十万的并发查询
• 如何设计全链路99.99%的高可用架构

好！架构演进到这个时候，系统是否无懈可击了呢？

当然不是！

自古以来，能够瓦解一个军队战斗力的，不仅有外力冲击，还有内部因素。

同样，对于咱们的亿级流量系统，外部的冲击我们抗住了，现在的考验，来自于系统自身。而首当其冲的，就是系统的可扩展性带来的严重挑战。。。

因此在第二阶段，咱们用了大量的篇幅，分为上中下三篇，详细的讨论了该架构在可扩展性方面的痛点和改进。

跨过了2018年，你是否还记得这些痛点以及针对的技术方案呢？

如果忘了，没关系，跟着本文，温故知新。笔者希望各位在重拾记忆的同时，能有新的收获，并且能把文中的某些技术方案在自己公司中实际落地实践。

同样，对于可扩展性方案的复习，也是为后面系统在其他方面的改进打下基础，这样大伙儿读后面的文章时，不至于因为中间知识的断层而一脸懵逼。。。

 

一

对亿级流量架构可扩展性的讨论，咱们分成了上中下三篇。其中上篇，开门见山，发现问题：实时计算平台与数据查询平台之间耦合严重，并造成了诸多痛点：

• 数据查询团队被动承担了本不该他们承担的高并发写入压力

• 数据库运维操作导致的线上系统性能剧烈抖动

• 实时计算平台团队因为自身写入机制的bug导致数据丢失，结果让数据查询团队来进行排查，典型的甩锅！

• 实时计算平台团队，竟然需要自己来实现双写一致性的保障机制，直接导致代码里混合了大量不属于自己团队业务逻辑的代码

• 数据查询平台做了分库分表的操作，需要实时计算平台team一起修改配置，一起测试部署上线

总之，这些痛点，导致的结果是两个团队的同学天天腻在一起，而且是被迫的。。。

对于上面这些系统痛点的成因，你还有印象吗？如果忘了，猛戳下面链接，先赶紧去复习一波吧，知道了病症，才好对症下药！

猛戳下方链接：

• 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？

 

二

好，通过了上篇文章，我们已经知道了系统耦合造成的各种痛点，真的很痛！

那么现在，就该针对这些痛点，对症下药。看看下面的内容，你还能记起吗？

• 类似于中医的“望闻问切”，解决问题的第一步，就是找到病因。而到咱们这里，解决耦合的第一步，则是清晰的划分出系统边界。

• 划分出边界之后，第二件事，当然就是解耦。如何解耦：利用消息中间件

• 好！现在我们引入了消息中间件解耦，你是否还记得上篇文章中的一个痛点：实时计算平台高并发写入时，数据查询平台要无辜承受高并发的写入压力

• 那我们引入了中间件之后，通过消息中间件进行削峰填谷，就能解决这个问题了，关于什么是削峰填谷，以及如何实行，还记得吗？

• 解耦过后，我们通过手动流量开关来配合数据库运维，直接自己团队的同学在某个低锋时段关闭流量开关，迅速完成数据库运维操作。这不又解决了一大痛点吗！

• 好处还不止这些，比如，我们引入中间件解耦之后，其他系统不也可以按需去MQ里，订阅实时计算平台计算好的数据吗！再不用看其他平台的脸色了

总体来讲，解耦之后，各个团队各司其职，不用天天被迫腻在一起。而没有了人为的各种干预，系统也运转的更加流畅高效。

关于这些针对性的解决方案，笔者建议大家再仔细看看，这都是真实线上生产总结出的经验，也许里面的某些方案能够帮到你！

猛戳下方链接：

• 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？

 

三

讲完了实际的落地方案，我们来到了亿级流量架构可扩展性的下篇。

在可扩展性中篇的讨论中，我们提到了解耦的好处之一，是可以实现消息的“Pub/Sub”模型，即不同平台都可以根据自身需要去订阅同一份数据。

那么下篇，我们讨论的主题就是基于消息中间件的“Pub/Sub”模型，并以RabbitMQ为例，详细阐述了其在代码层面的落地实践。

什么是exchange？默认的exchange是啥？如何绑定自己的队列到exchange上去消费？这些还记得吗？如果忘了，猛戳下面的链接，赶紧的回顾一下！

猛戳下方链接：

• 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？

以上就是关于亿级流量可扩展性做的一个阶段性小结，重构之路漫无止境，且环环相扣。笔者希望通过这个总结，在咱们继续上路之前，打牢基础，加深理解，磨刀不误砍柴工。

 

 

[source]亿级流量架构系列专栏总结[二]