1。初步提示上一篇文章《第一次当架构师，我设计高并发架构发现了N个痛点。。。》给大家初步介绍了大型复杂系统中两个核心子系统耦合后会发生什么。场景。如果您还没有阅读上一篇文章，我建议您先阅读一下。在本文中，我们将告诉您如何通过使用MQ消息中间件重构系统之间的耦合，使系统具有高度的可扩展性。首先，来回看一下前面绘制的两个系统之间耦合的大图。从这张图中我们可以看出，两个系统是通过一套共享存储（数据库集群+缓存集群）完全耦合的。2、明确划分系统的边界只要存在耦合，一旦要解决耦合，首先要做的就是明确系统之间的边界。比如上面两个系统共享一套存储集群，那么大家可以先想想两个系统的边界怎么划分？也就是说，中间的缓存集群和数据库集群应该属于哪个系统呢？首先我们来看一下，缓存集群和数据库集群主要是给谁用的？很明显，是针对数据查询平台的。说白了，两组集群就是数据查询平台所依赖的核心底层数据存储，存储在这里的数据也属于数据查询平台的核心数据。对于实时计算平台，他只是将自己的计算结果写入到缓存集群和数据库集群中。实时计算平台只要写好了，以后就不管数据了，所以这两套集群显然不属于实时计算平台。好了，那么系统之间的界限就划清了。看看下图。首先，从系统的整体架构来看，两个系统之间的关系应该是这样的。3.引入消息中间件解耦只要明确了系统之间的界限，接下来就是引入消息中间件进行解耦。我们只需要引入一个消息中间件，然后让实时计算平台将计算出的数据按照预设的格式直接写入消息中间件即可。同时，数据查询平台需要增加数据访问服务。这个数据访问服务负责消费消息中间件中的数据，然后写入本地缓存集群和数据库集群。如上图所示，此时两个系统不再基于共享数据存储直接耦合，中间加入了MQ消息中间件。该消息中间件仅用于两个系统之间的数据交互和传输，职责简单明了。这样做最大的好处是，数据查询平台本身可以根据自己的需要，对涌入自己平台的数据进行自定义管控，不会像以前那样被动。事实上，在上述结构下，所有涌入数据查询平台的数据都需要经过数据访问服务。在数据访问服务中，您可以根据自己的情况随意管理。4.使用消息中间件削峰填谷。还记得我们在上一篇文章中提到过，两个系统之间的第一个大痛点是实时计算平台会高并发写入数据查询平台，之前没有任何控制，导致各种事故。例如，快速增加的写库压力导致数据查询平台优先覆盖分库分表的架构，打破了自身的架构演进节奏；差点一下子把数据库服务器搞垮。所以，一旦用消息中间件在中间挡了一层，我们就可以削峰填谷了。那么什么是削峰填谷呢？其实很简单。我们先来看看。如果不做任何控制，实时计算平台写入数据库集群的写入并发曲线大致如下图所示。在高峰时段，写入量会急剧上升。比如平时每秒500个并发写，但是高峰期5000个并发写请求，那么你会看到上图，高峰期突然出现一个尖峰，一下子涌入5000个并发请求，在这个时候数据查询平台的数据库集群可能就承受不住了。但是如果我们在数据访问服务中做一个限流控制呢？也就是说，在数据访问服务中，按照当前数据查询平台的数据库集群所能承载的并发上限，比如每秒最多可以承载3000个。好的！那么数据访问服务可以自己控制，每秒最多可以向本地数据库集群写入3000个请求。这时候就会出现削峰填谷的效果。请看下图。因为高峰期瞬时写入压力最大为5000条/s，但是数据访问服务进行了流量控制，最多3000条/s写入本地数据库集群，那么会出现每秒2000条数据的情况消息中间件做一个积压。不过一时的积压也无所谓，至少可以保证在高峰期，把这个向上的高峰拉平，也就是所谓的削峰填谷。那么在高峰期之后，写入压力可能是每秒100/s，但是此时数据访问服务会不断的从消息中间件中取数据，并继续以最大3000/s的压力写入本地数据库簇。然后在非高峰期，可以看到3000/s的写入速度会持续写入本地数据库一段时间。原图中，低峰时期山谷处于底部，现在山谷已经被填满，也就是所谓的填谷。通过这种削峰填谷的机制，可以保证数据查询平台能够将MQ中的数据以自己可以接受的速率均匀的取出并写入到自己本地的数据库集群中。这样一来，不管实时计算平台的并发请求压力有多大，哪怕是异常的热点数据，瞬间上万个并发请求过来也无所谓。因为MQ中间件可以承受瞬时高并发写入，但是数据查询平台会始终以稳定统一的速度写入其本地数据库。这样一来，数据查询平台就不需要从care的实时计算平台承受太大的压力，可以根据自己的节奏来规划整体架构的演进策略，根据自己的节奏来迭代架构脚本。说了这么多，老规矩！给大家一张图，此时的结构图如下。大家可以直观的感受到，数据访问服务中多了一个限流模块。5、手动流量开关配合数据库运维操作。现在基于消息中间件实现了两个系统的隔离，还有一个很大的优势就是数据查询平台可以进行任何数据运维操作，比如DDL、分库分表、扩容、数据迁移等操作，等与实时计算平台无关。实时计算平台主要是简单的写入消息中间件，其他忽略。然后，如果数据查询平台需要做一些数据库运维操作，可以通过在数据访问服务中增加手动流量开关，暂时关闭流量开关。比如选择下午大家工作或午睡的相对低峰时段，在半小时内关闭流量开关。那么这个时候数据访问服务就不会继续往本地数据库写数据了，写操作也会在这个时候停止，然后数据库运维操作会在半小时内快速完成。相关操作完成后，再次开启流量开关，继续从MQ消费数据并快速写入本地数据库。这样就可以完全避免同时写入数据和进行数据库运维操作的困境。否则在早期耦合的状态下，每次进行数据库运维操作时，实时计算平台组的同学都要配合进行各种复杂的操作，避免上线失败。现在不需要其他人参与。就是这样。整个过程中，我们还是用一张图来给大家展示一下：6.支持多系统同时订阅数据。引入消息中间件后还有一个好处，就是其他一些系统也可以根据自己的需要在MQ中进行订阅。实时计算平台计算的数据。例如，在这个平台中，还有一个数据质量监控系统，需要获取计算数据来监控数据结果的准确性和质量。此外，还有数据链路监控系统，也需要采集MQ中的数据作为数据计算链路中的核心点数据，对整个数据链路进行监控和自动跟踪。如果不引入MQ消息中间件的概念，实时计算平台是不是不仅要向数据库集群写入一份数据，还需要通过接口发送给数据质量监控系统？还需要发送到数据链监控系统吗？这简直就是作弊，N个系统都是耦合在一起的。这样，每有一点变化，各个系统的负责人就会聚在一起讨论，修改代码，修改接口，考虑各种调用细节等等。但是现在有了消息中间件，完全可以使用MQ支持的“Pub/Sub”消息订阅模型。不同的系统可以订阅相同的数据。大家按需消费，按需加工，各种系统彻底解决。夫妻。整个系统的扩展性瞬间提升了很多，因为每个系统都在迭代演进自己的架构，不需要过多依赖其他系统。7.系统解耦后的感觉一清二楚！各队的同学终于不用天天吵架了。今天他们说你的系统影响了我，明天就是我的系统影响了你。同时，完全不需要关注其他系统。只要有一个总架构师来把控整体架构，各个团队就可以按照这个分工合作去做。消息中间件的引入，消除了系统的耦合性，大大提高了系统的可扩展性。每个团队都可以快速独立地迭代扩展自己的架构和系统。PS：最重要的是，不同团队的同学再也不用为了一些琐碎的事情加班到深夜，让女朋友以为他们要在一起了。
