|
|
一、写在后面
以前更新过一个“亿级流量零碎架构”系列，次要讲述了一个大范围商家数据平台的如下几个方面：
如何承载百亿级数据存储如何设计高容错的散布式架构如何设计承载百亿流量的高机能架构如何设计每秒数十万并发查问的高并发架构如何设计全链路99.99%高可用架构。接上去，咱们将会持续经过几篇文章，对这套零碎的可扩展架构、数据统一性保障等方面进行讨论。
假如没看过本系列文章的同窗能够先回过头看看以前写的几篇文章：
亿级流量零碎架构
别光看NB的Github开源名目，你得参考他们去设计本人的架构！
为何有些看起来很厉害的技术高手，设计的架构都很渣滓？
为何每个顺序员都必需坚持写博客？这篇文章教你怎么写！
共事总是吐槽我的接口机能差，原来真凶就在这里！
2022阅历裁员之后，我总结了顺序员必备的架构才能！
二、配景回顾
假如大家看过以前的一系列文章，应该依稀还记得上一篇文章最初，全部零碎架构大抵演进到了如下图的一个形态。
假如没看过以前的系列文章，下去猛一看上面这个图，绝对一脸懵逼，就看到一片“花花绿绿”。这个也没方法，繁杂的零碎架构都是特别的庞杂的。
三、实时计算平台与数据查问平台之间的耦合
好，我们正式开始！这篇文章我们来聊聊这套零碎里的不同子零碎之间通讯进程的一个可扩展性的架构处置。
这外面蕴含了线上繁杂零碎之间交互的实在场景和痛点，置信对大家可以有所启示。
咱们就关注一下下面的架构图里左边的部份，处于两头地位的阿谁实时计算平台在实现了每一个个数据分片的计算当时，都会将计算后果写入到最左边的数据查问平台中。
出于种种考量，由于计算后果的数据量比拟于原始数据的数据量，实际上曾经少了一个数量级了。
所以，咱们选择的是实时计算平台间接将数据写入到数据查问平台的MySQL数据库集群中，而后数据查问平台基于MySQL数据库集群来对外提供查问申请。
另外，为了包管当天的实时计算后果可以高并发的被用户查问，因此过后采用的是实时计算平台的计算后果同时双写缓存集群和数据库集群。
这样，数据查问平台能够优先走缓存集群，假如找不到缓存才会从数据库集群里回查数据。
所以上述就是实时计算平台与数据查问平台之间在某一个时代的一个典型的零碎耦合架构。
两个不同的零碎之间，经过同一套数据存储（数据库集群+缓存集群）进行了耦合。
大家看看上面的图，再来明晰的感触一下零碎之间耦合的觉得。
零碎耦合痛点1：主动承当的高并发写入压力
大家假如子细看过以前的系列文章，大略就该知道，在初期次要是集中精神对实时计算平台的架构做了少量的演进，以便于让他能够撑持超高并发写入、海量数据的超高机能计算，最初就能抗住每秒数万乃至数十万的数据涌入的存储和计算。
然而由于初期采取了上图的这类最简略、最高效、最实用的耦合交互形式，实时计算平台间接把每个数据分片计算完的后果写入同享存储中，就致使了一个很大的问题。
实时计算平台能抗住超高并发写入没问题了，并且还能疾速的高机能计算也没问题。
然而，他同时会跟着数据量的增长，愈来愈高并发的将计算后果写入到一个数据库集群中。而这个数据库集群在团队划分的时分，其实是交给数据查问平台团队来担任保护的。
也就是说，对实时计算平台团队来讲，他们是不care阿谁数据库集群是甚么形态的，而就是不断的把数据写入到阿谁集群里去。
然而，关于数据查问平台团队来讲，他们就会主动的承当实时计算平台愈来愈高并发压力写入的数据。
这个时分数据查问平台团队的同窗极可能处于这样的一种烦躁中：原本本人这块零碎也有得多架构上的改进点要做，好比说以前提到的冷数据查问引擎的自研。
然而呢，他们却要不断的被线上数据库办事器的报警搞的焦头烂额，疲于奔命。
由于数据库办事器单机写入压力可能跟着业务增长，迅速变为每秒5000~6000的写入压力，天天到了顶峰期，线上办事器的CPU、磁盘、IO、网络等压力微小，报警频繁。
此时数据查问平台团队的架构演进节拍就会被打乱，由于必需主动的去按照实时计算平台的写入压力来进行调剂，必需立马停下手中的任务，而后去斟酌如何对数据库集群做分库分表的计划，如何对表进行扩容，如何对库进行扩容。
同时结合分库分表的计划，数据查问平台本身的查问机制又要随着一同改动，少量的革新任务，调研任务，数据迁徙任务，上线部署任务，代码革新任务。
实际上，下面说的这类状况，绝对是分歧理的。
由于全部这套数据平台是一个大互联网公司里中心业务部门的一个中心零碎，他是数十个Java工程师与大数据工程师通力协作一同开发，并且外面划分为了多个team。
好比说数据接入零碎是一个团队担任，实时计算平台是一个团队担任，数据查问平台是一个团队担任，离线数据仓库是一个团队担任，等等。
所以只有分工协作了当前，那末就不该该让一个团队主动的去承当此外一个团队猛然增长的写入压力，这样会打破每个团队本人的任务节拍。
致使这个问题的基本缘故，就是由于两个零碎间，没有做任何解耦的处置。
这就致使数据查问平台团队基本无奈对实时计算平台涌入过去的数据做任何无效的管制和办理，这也致使了“主动承当高并发写入压力”问题的产生。
这类零碎耦合致使的主动高并发写入压力还不仅是下面那末简略，实际在上述场景中，线上出产环境还产生过各种奇葩的事件：
某一次线上忽然发生少量的热数据，热数据计算后果涌入数据查问平台，由于没做任何管控，简直一瞬间致使某台数据库办事器写入并兴旺到1万+，DBA着急的耽心数据库快宕机了，一切人也都被搞的焦头烂额，心思解体。
零碎耦合痛点2：数据库运维操作致使的线上零碎机能激烈颤动
在这类零碎耦合的场景下，反过去实时计算平台团队的同窗其实心里也会呼吁：咱们心里也苦啊！
由于反过去大家能够思考一下，线上数据库中的表构造改动，那简直能够说是再正常不外了，尤为是高速迭代开展中的业务。
需要评审会上，要是不谨慎碰上某个产品经理，明天改需要，今天改需要。工程师估量会怒火冲天的想要砍人。然而没方法，最初仍是得为五斗米折腰，该改的需要仍是得改。该改的表构造也仍是要改，改加的索引也仍是要加。
然而大家斟酌一个点，假如说对上述这类强耦合的零碎架构，单表根本都是在千万级别的数据量，同时还有单台数据库办事器每秒几千的写入压力。
在这类场景下，在线上走一个MySQL的DDL语句试一试？规劝大家千万别胡乱尝试，由于数据查问团队里的年老同窗，干过这个事儿。
实际的后果就是，DDL咔嚓一履行，对线上表构造进行修正，间接致使实时计算平台的写入数据库的机能急剧降落10倍以上。。。
而后连带致使实时计算平台的数据分片计算工作少量的提早。再而后，由于实时计算之后的数据无奈尽快反馈到存储中，无奈被用户查问到，致使了少量的线上投诉。
而且，DDL语句履行的还特别的慢，耗时数非常钟才履行终了，这就致使数非常钟里，整套零碎泛起了大范围的计算提早，数据提早。
始终到数非常钟之后DDL语句履行终了，实时计算平台才经过本身的自动提早调度恢复机制缓缓恢复了正常的计算。
orz......因而从此之后，数据查问平台的攻城狮，必需得谨慎翼翼的在天天早晨2点~3点之间进行相干的数据库运维操作，防止影响线上零碎的机能不乱性。
然而，莫非人家年老工程师没有女敌人？莫非年短工程师没有老婆孩子？常常在早晨3点看看窗外的景色，而后打个滴滴回家，估量没任何人违心。
其实上述问题，说白了，仍是由于两套零碎间接经过存储耦合在了一同，致使了任何一个零碎只有有点异动，间接就会影响此外一个零碎。耦合！耦合！仍是耦合！
零碎耦合痛点N。。。
其实下面只不外是挑了其中两个零碎耦合痛点来讲明罢了，文章篇幅无限，很难把上述长达数月的耦合形态下的各种痛点一一阐明，实际线上出产环境的痛点还包罗不限于：
实时计算平台本身写入机制有bug致使的数据丧失，后果让数据查问平台的同窗去排查；实时计算平台对缓存集群和数据库集群进行双写的时分，双写统一性的包管机制，竟然还需求本人来完成，间接致使本人的代码里混合了少量不属于本人的业务逻辑；数据查问平台有时分做了分库分表运维操作之后，好比扩容库和表，竟然还得让实时计算平台的同窗配合着一同修正代码配置，一同测试和部署上线数据查问平台和实时计算平台两个team的同窗在上述少量耦合场景下，常常每天一同加班到早晨深夜，各自的女敌人都认为他们打算在一同了，但实际状况是一堆大老爷儿们每天被搞的焦头烂额，苦不胜言，都不肯意多看对方一眼由于零碎耦合致使的各种问题，两个team都要抽时间精神来解决，影响了本人那套零碎的架构演进进度，没法集中人力和时间做真正有价值和意义的事件四、下集预报
下一篇文章，咱们就来聊一聊针对这些痛点，如何灵敏的应用MQ动静两头件技术来进行繁杂零碎之间的解耦，同时解耦当时如何来自行对流量数据进行管控，解决各种零碎耦合的问题。 |
|
注册会员