シーン記述
マイクロサービスアーキテクチャでは、各サービスは、マイクロ独自のデータベースを担当して、マイクロAサービスはBの直接接続マイクロサービスデータベースに動作許可されていません。
2つのマイクロのサービスがありますが、サービスオーダは、サービス利用者です。
データレポートの需要があります：生成含むユーザ情報をに注文レポート。
これは、2つのデータ取得サービス、接続の要約が必要です。
サービスのレポートデータを構築するには？
スキーム1は、直接データベースに接続します
取得することができます処理した後、必要なデータを取得するためのサービス、顧客サービスデータベースへの直接接続、。
非常にシンプルですが、明らかな問題があります。
まず、上記の原則を破壊しても、直接他の誰かのデータベースへのマイクロサービス、あまりにも失礼なこと。
注文がサービスと顧客サービスになっている場合は、より深刻な問題があり、データベースのテーブル構造を変更しますか？
Reporting Servicesは一緒にそれを変更する必要があり、感度が高すぎます。
シナリオ2のデータの集約
直接データはなく、所望のデータを得るために、これら2つのサービスのRESTのAPIインターフェイスを呼び出しありません。
前のプログラムの問題を解決しますが、この方法の最大の問題はあるパフォーマンスの低下。
サービスは、最新のデータを必要とする報告、多くの場合、データサイズの増加に伴って、3つのサービスのパフォーマンスが低くなってと低くなり、これら2つのサービスを訪問します。
スキーム3バッチプルデータ
独自のデータベースに、2つのデータベース・サービスからタイミングルーチン、バッチプルデータを使用して、自分のサービスを報告して、データベースを確立します。
前のプログラムの問題を解決するため、パフォーマンスが大幅に改善したが、マイクロサービスの原則を損なう、バックプログラムの最初の問題に行くが、また、データテーブル構造の変化に非常に敏感のように。
利点は、より良い性能、なぜなら彼ら自身のデータベースの、より便利ということです。
シナリオ4イベントプッシュモデル
注文サービス、顧客サービス、データテーブル、さらにバックには、トピックに関連するサービスのサブスクリプションを報告イベント、（たとえば、カフカのための）システムに投稿されたメッセージを、生成し、受信したデータは、独自のデータベースに書き込まれます。
利点：
疎結合、ビジネスサービス、レポートサービスは、それがビジネスの界面層やデータベース層であるかどうか、関係を呼び出すことはありません。
データの一貫性、準リアルタイム、ビジネス・サービス・データ・テーブルよりイベントメッセージすぐにレポートサービスの送信後すぐに消費することができます。
性能好，数据吞吐量增加后，报告服务可以增加处理事件的 worker，提供处理能力。
扩展性好，方便以后添加更多的数据处理需求，例如实时分析，而且，以后可能不止是做订单报告，可能会对更多的业务系统数据进行分析，到时，新服务只需把自己的数据变更事件发送到消息系统中即可。
翻译整理自：
https://medium.com/@muneeb.ahmed20/building-a-reporting-service-in-microservice-architecture-8d5bf3b90fb70
推荐阅读
- 图解 Kubernetes
- ZooKeeper 并不适合做注册中心
- kafka 中 zookeeper 具体是做什么的？
- Postman 的替代品来了
- Redis Cluster 会丢数据吗？
- 阿里开源的分布式事务框架 Seata
