1つのデータベーステーブルの読み書き用の2つのマイクロサービス

Question

マイクロサービスのベストプラクティスアプローチについて少し混乱しています。

次のシナリオ：MQTTデバイスから

大規模な受信メッセージ。顧客がメッセージを読むことができる休憩API（主にその一部のみ）。

私の考えは、メッセージをデータベーステーブルに格納するための1つのマイクロサービスを作成することでした。そして、このメッセージを読むための残りのAPIを備えた2番目のマイクロサービス。 スケーリングの問題が原因でこれをやりたい（入ってくる記憶部は、読書用のAPIよりもはるかに多くの電力を必要とします）

「完全な」マイクロサービスだけがデータベース内の自分のデータにアクセスする必要があります。したがって、他のマイクロサービスは、データベースレベルではなくAPIを介してこのデータを要求する必要があります。 私のアプローチは完璧なものではありません。

• 一つだけmircroservice、格納し、残りのmicroserviceは、データをフェッチすることができ保存microservice、でAPIを作る
• を読み取るための：私はこれを処理するためのいくつかのオプションを参照してください。

しかし、それらのすべては、私のためによく見えません。

あなたの意見は？

よろしく、 マルクス

Answer 1

私は、次の質問への答えに依存するある程度のアプローチをお勧めするつもりです：ときにメッセージ時間から最大許容時間遅れで何

顧客がメッセージを表示できるようになるまでの間にデータベースにコミットされていますか？

この質問に対する回答が10msを超える場合は、read-write separationを使用することを検討することができます。あなたは良いユースケースと思われます。

これは間違いなくあなたのソリューションに多くの複雑さを導入するが、このアプローチの利点があります：

• データベースの間には競合が書き込まれていないと
• 書き込みが独立して拡張することができ読み込みます。
• あなた書き込まれたデータは
• 顧客データはほとんどがretrevalおよびディスプレイの問題を簡素化した方法で読み取ることができるリレーショナル形式で保存することができる（例えばdenormalised、のviewmodelに揃え）

は、あなたのアーキテクチャにこれを適用すると、何らかの種類の耐久性のあるキューイング転送を使用しなくても、読み取りと書き込みの分離を実装することは可能ですが、難しくなります。イベントを利用するのではなく、全体をコマンド駆動にする必要があります。

ここでの主な違いは、メインデータベースの書き込みとその後の読み取りモデルの更新を担当するサービスへの呼び出しで「トランザクション可能性」を適用する必要があることです。

Answer 2

現実的には、読んだり書いたりするのに計算的に集中的なことをしないと、データベースIOがあなたの論点になりそうです。私はあなたのシステムを「完璧」に構築することを強く検討し、容量テストを実行してチョークポイントの位置を確認します。 Donald Knuthの言葉「Premature optimization is the root of all evil」を忘れないでください。

サービスの規模を変更する必要がある場合は、読み込みと書き込みの両方を水平にスケーリングできるかどうかを確認してください（結合サービスのインスタンスを増やす）。

これで必要なパフォーマンスを得ることができない場合は、別の回答者のようにはるかに複雑なスケーリング要件があります。proposedです。