1. EDITORIAL
システムは、高度にスケーラブルを含み、再構成システム間の結合、のは、MQメッセージング・ミドルウェアを利用することにより本明細書にする方法についてお話しましょう。
カップリングシステム間の図ではまず見て、我々は最初の具体的なデータクエリプラットフォームでの計画の詳細やリアルタイム・コンピューティング・プラットフォームに焦点を当てていません。
ただ、どこのデータクエリのプラットフォームとリアルタイム・コンピューティング・プラットフォーム2つのシステムを知っている必要があり、共有メモリ（キャッシュクラスタ・データベース・クラスタ+）を介して結合させました。
2.パーティショニングシステム境界
限りが結合されるように、一度結合を解決するために、その後に行われる最初は明らかにシステム間の境界を定義することです。
例えば、ストレージクラスタのセットを共有する上記2つのシステムは、最初の2つのシステム間の境界線を分割すべきかを考えますか？
言い換えれば、システムはこの質問に答えるために？属すべきキャッシュ・クラスタおよびデータベースクラスタの中央のセットは、主な考慮事項は、主に誰に使わキャッシュ・クラスタとクラスタデータベースのですか？
明白な答えは、当然のことながら、データのクエリのプラットフォームを使用することです。
端的に言えば、キャッシュデータベースクラスタは、データストレージの基礎となるコアの生存、データストレージは、彼らはまた、コアデータのクエリプラットフォームの一部であり、その上にクラスタとデータクエリプラットフォームです。
リアルタイムコンピューティングプラットフォームのために、彼は、キャッシュ・データベース・クラスタとクラスタベールに書き込まれ、自分のコンピューティングの唯一の結果です。
クラスタの二組が明らかにリアルタイムコンピューティングプラットフォームの一部ではないので、リアルタイムコンピューティングプラットフォーム後に限り書き込まれるように、これらのデータパイプを追従しないであろう。
システム間の国境画定が、ビューの全体的なアーキテクチャから、明らかになった後、2つのシステム間の関係は、次のようになります。
3.デカップリング導入のメッセージミドルウェア
今、私たちは明らかにシステム間の境界を定義して、次のステップは、メッセージングミドルウェアの導入を切り離すことがあります。
メッセージングミドルウェアのシーンはまだ馴染みの友人ではない場合、あなたは前の記事を見てみることができます：「おい、あなたのアーキテクチャはなぜメッセージングミドルウェアを導入？」、メッセージングミドルウェア、さまざまなシナリオを使用して、どの手の込んだがあります。
今、私たちは、メッセージングミドルウェアを導入し、その後、プリセットデータのフォーマットに従って計算リアルタイムコンピューティングプラットフォームは、メッセージングミドルウェアに直接書き込むことができましょう。
データへのアクセスを追加するために、ここでデータクエリプラットフォームが、データ内のメッセージング・ミドルウェア責任消費は、ローカル・キャッシュ・クラスタおよびデータベース・クラスタに書き込ま着陸、出てきました。
全体のプロセスを以下に示します。
通过上图可以清晰的看到，两个系统之间已经不再直接基于共享数据存储进行耦合了，中间加入了MQ消息中间件，它仅仅是用于两个系统之间的数据交互和传输，职责简单，清晰明了。
这样做最大的好处：数据查询平台可以对涌入自身平台的数据，按照自己的需求进行定制化的管控，不会像之前那样的被动。
因为涌入数据查询平台的所有数据，都需要经过数据接入服务那一关，在数据接入服务那里就可以随意根据自己的情况进行管理。
4. 利用消息中间件削峰填谷
好，我们继续，现在把目光集中到两个系统上，进行痛点分析。
两个系统间第一大痛点：实时计算平台会高并发写入数据查询平台，之前不做任何管控的时候，导致各种意外发生。
比如快速增长的写库压力导致数据查询平台必须优先cover住分库分表那块的架构，打破自己的架构演进节奏。
比如突然意外出现的热数据因为不做任何写入管控，一下子可能把数据库服务器击垮。
因此一旦用消息中间件在中间挡了一层之后，就可以进行削峰填谷了。那什么叫削峰填谷呢?
很简单，如果不做任何管控，实时计算平台并发写入数据库集群，在高峰期会有一个陡然上升的尖峰。
打个比方：平时每秒写入并发就500，但是高峰期写入并发请求有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”消息订阅模型，不同的系统都可以订阅同一份数据，大家按需消费，按需处理，各个系统之间完全解耦。
这样一来，整个系统可扩展性瞬间提升了很多，因为各个系统各自迭代和演进，都不需要强依赖其他的系统了。
最后我们来看看，两个系统解耦后的架构图：