2つの「マイクロサービス」間でデータベースを共有する必要がありますか？
ビジネスの特定の部分に関連するデータを公開するサービスを実装しています。さまざまなソースからデータを取得し、ETLを実行してRedisに保存します。 ReSTエンドポイント（および場合によってはGraphQL）を介してこのデータを公開します。
スケーラビリティのため、Redisはロンドンから米国に複製されます。米国にあるサービスは、Redisにある既存のデータを使用するだけなので、ETLを実行する必要はありません。
このサービスには2つの「モード」（ロンドンでの読み取りと書き込み、および米国での読み取りのみ）があるため、2つのサービスに分割する必要があるかどうかについて議論しています。 1つはデータを書き込み、もう1つはデータを読み取ります。
オプション1：
ETLとデータの書き込みを行うサービスと、そのデータを読み取るだけのサービスの2つのサービスを、異なるリポジトリに配置する可能性があります。
これで確認できる問題は、すべてが2つ（リポジトリ、TeamCityプロジェクト、タコデプロイなど）になることです。また、異なる速度で進化する可能性があるため、バージョン管理の問題が発生する可能性もあります。
オプション2：
「読み取り/書き込み」または「読み取り専用」として開始できる1つのサービス。ロンドンでは「読み取り/書き込み」モードで開始し、米国では「読み取り専用」モードで開始します。
これにより、複数のリポジトリ、複数のTeamCityプロジェクトなどの問題が解決されます。
このアプローチで確認できる問題は、特定の「モード」で起動することの複雑さが増すことです。また、基本的に読み取り専用モードで「オフ」になっているコード（ETLコンポーネント）をデプロイします。
私たちはさまざまな記事をオンラインで読んでいます。 「マイクロサービス」間でデータベースを共有すべきではないと言う人もいれば、まったく問題ないと言う人もいます。
ここまで、Wordマイクロサービスの前後にアポストロフィを使用しました。私がこれを行ったのは、これまでのところ、この質問では、「技術的な機能」を説明するために、より詳細ではなくWordを使用しているためです よく定義されています ：
分割に対するマイクロサービスのアプローチは異なり、ビジネス機能を中心に編成されたサービスに分割されます
私はマイクロサービスのその説明が好きであり、それが私の好ましいオプションであるオプション2に重みを与えると思います。
しかし、私は建築の専門家ではないので、他の人の意見を聞いてみようと思いました。
どのオプションを選びますか、それともまったく違うことをしますか？
書き込みと読み取りを分離することが一般的に望ましい理由は、書き込みと読み取りで発生する問題が異なるためです。また、アプリケーションが読み取りまたは書き込みのどちらであるかに応じて、両方のサービスを個別にスケーリングできます。書き込み時のレイテンシ（通常は高い）とデータベースへの接続数の管理がはるかに簡単です。競合を回避するために書き込みを処理する専用のサービスは非常に便利です。
「マイクロサービス」であるかどうかに関係なく、目標は、サービス間を十分に分離して、サービスを個別にスケーリングし、分離に失敗できるようにすることです。
もちろん、分離することで、バージョン管理を念頭に置く必要がありますが、バージョン管理を非常に適切に処理するシリアル化フレームワークがたくさんあります（Protobuf、thriftなど）。
リポジトリを分離する-開発者が対処しなければならないすべての問題の中で、最後のことは、複数のチームが同じリポジトリで作業して、多くの競合を引き起こすことです。
詳細な要件を知らずに、この質問に特定の答えを出すのは本当に簡単ではありません。
推奨事項があります："一緒に変化するものをまとめる"。あなたが書いていない要件がない限り、start small！と言います。すべてを1つのリポジトリに配置します。 1つのビルドジョブがあります。一緒に展開します。あなたがそれを分割する正当な理由があるまで。
米国の顧客が機能の要求やロンドンの要求から完全に独立した変更のためにあなたにやって来る場合、ある時点でプロジェクトを分割すること（コード、ビルド、デプロイメント）は理にかなっているかもしれませんが、最初のときに後で行うことができます機能リクエストが届きます。
100％コードの再利用と構成による分割に問題はありません。 「構成」をデプロイするための初期セットアップコストにあまり重点を置かないでください。おそらく、とにかくプロジェクトを構成する必要があります（たとえば、テスト環境と本番環境で）。 ETLを適用するかどうかの問題は、単に別の構成オプションです。
構成を使用するか、実装を使用して分割するかは、サービスが時間の経過とともにどのように進化するかを予想することによります。
サービスを設計/設計する際に考慮すべき点は次のとおりです。-異なる顧客は常に同じデータに依存しますか？ -顧客は常に同時にデータを更新することを望みますか（タイムゾーン）？ -将来、異なるデータと異なる時間を必要とする新しい顧客はいますか？ -顧客ごとに機能以外の要件（パフォーマンスなど）は異なりますか？ Redisを使用していてロンドンと米国間でデータを複製している場合、おそらくこのデータへの非常に高速なアクセスが必要ですか？ -両方の顧客に異なるまたは同じ開発者がいますか？ -サービスは常に一緒にリリースされますか？リリースにダウンタイムが必要ですか？どのくらいの頻度でリリースする必要がありますか？
アーキテクチャ/設計の観点からは、データの収集、データの変換を評価および変換（読み取り）から切り離す必要があります。書き込みと読み取りの両方に変換部分があるため、ロンドンのお客様は次のことを行います。
- 収集->変換->保存および読み取り->変換->配信
米国のお客様の場合：
- 収集->変換->保存および読み取り-> [変換なし]->配信
いずれの場合でも、ソフトウェア設計では、これらのステップを可能な限り分離することが理にかなっています。ソフトウェアの設計に問題がなければ、後でコードを分割しても問題はありません。その後、「構成」または「実装」を使用して2つの異なるサービスを作成するかどうかは、多少の決定です。
コードベースとビルドのセットアップ方法には、まったく異なる理由があります。特定の理由がない場合、または後で分割の問題が発生する可能性がある場合を除き、しないでください。
理論的には、2つのマイクロサービスが1つの同じデータベースを読み取る場合、モノリスではなくマイクロサービスが必要なのはなぜですか？当然のことながら、同じデータベースを読み取る場合はどうなるでしょうか。しかし、すべてのサービスには独自のテーブルセットがあります。その場合、個別のマイクロサービスを用意する方が受け入れられそうです。
与えられた質問に対して-あなたはRedisが複製されると述べたので、実際には2つの別々のデータベースがあります。次に、2つの別々のサービスを用意することは完全に理にかなっており、それらが共有する唯一のものはデータモデルです。米国ではリーダーのみを展開し、英国ではリーダーとライターの両方を展開します。それでも、英国の読者は最新のデータを米国の読者よりもわずかに早く取得するという問題があります。
マイクロサービスの構成についてよくある誤解があると思います。読み取りと書き込み操作はサービスではなく、マイクロサービスは操作に対して1対1ではありません。読み取り操作と書き込み操作の両方を備えたマイクロサービスを使用できます。それはモノリスにはなりません。 この記事 は、マイクロサービスアーキテクチャの概念とそうでない概念の概要を示しています。
個々のマイクロサービスを確認する良い方法は、関連する関数またはエンドポイントのコレクションまたはエンドポイントをビジネスドメイン内の制限付きコンテキストを構成することです。
強調は私のものです。質問する必要があるのは、読み取りサービスと書き込みサービスが本質的に結合されているかどうかです。これは見た目ほど明白ではありませんが、読み取り操作はデータの書き込み方法に依存するため、多くの場合は明らかです。読み取り側と書き込み側の間にETLを構築することでこれを回避できる可能性がありますが、そうすることの価値は疑わしく、より複雑になります。
1つのリージョンでのみ読み取りを行う必要があるということは、アーキテクチャ上のものよりも認可の問題に似ています。