マイクロサービス間でコードとスキーマを共有する
組織内でマイクロサービスアーキテクチャを使用する場合は、 zookeeper または同等のものを使用して構成を共有できます。ただし、さまざまなサービスがどのように共通のdbスキーマを共有する必要がありますか？共通定数？および一般的なユーティリティ？
1つの方法は、すべてのマイクロサービスを同じコードリポジトリに配置することですが、それはマイクロサービスに伴う分離と矛盾します...
別の方法は、各マイクロサービスを完全に独立させることですが、それにより、各マイクロサービスが保持しなければならない個別のデータベースでコードの重複とデータの重複が発生します。
さらに別の方法は、コンテキスト\状態のない機能的なマイクロサービスを実装することですが、それは通常現実的ではなく、コンテキスト\状態とそこからの大量のトラフィックを維持する中央ハブを持つようにアーキテクチャをプッシュします。
マイクロサービス間でコードとスキーマを共有するための、スケーラブルで効率的で実用的で、うまくいけば美しい方法は何でしょうか？
一般的なコードに関しては、パッケージシステムを使用するのがベストプラクティスです。したがって、Javaを使用する場合は、mavenを使用し、Rubyを使用する場合はGemsを使用する場合は、python pypiなどを使用します。共通のライブラリ（またはさまざまなトピックのいくつかの共通ライブラリ）の（たとえば、git）リポジトリを持ち、アーティファクトリポジトリ（プライベートMaven/gems/pypiなど）を通じてアーティファクトを公開する場合があります。場合によっては、パッケージングシステムが何らかの摩擦（1つはMaven）を追加するため、すべてに単一のgitリポジトリを使用し、マルチモジュールプロジェクトをセットアップすることを好む場合があります。他のオプションは、単一の「親」リポジトリにソースコードを含めるためにgitサブモジュール（あまり望ましくない）またはgitサブツリー（より良い）を使用することです。
スキーマに関して-あなたが本で遊びたいなら、各マイクロサービスには独自のデータベースがあります。お互いのデータには触れません。これは非常にモジュール式のアプローチであり、最初はプロセスに多少の摩擦を加えるように見えますが、最終的には感謝します。これにより、マイクロサービスの高速反復が可能になります。たとえば、特定のサービスについて、あるデータベース実装を別のデータベース実装に置き換えることができます。すべてのサービスが同じデータベースを使用しているときにこれを行うことを想像してください！幸運です...しかし、各サービスが独自のデータベースを使用する場合、サービスはデータベースを正しく抽象化します（たとえば、API呼び出しとしてSQLクエリを受け入れません;-)）、mysqlをCassandra突然実現可能になります。完全に分離されたデータベースを使用することには、負荷とスケーリング、ボトルネックの発見、管理など、他にも利点があります。
つまり、一般的なコード（ユーティリティ、定数など）-パッケージングシステムまたはgit-treeなどのソースコードリンケージを使用します
データベース-あなたは私のものに触れない、私はあなたのものに触れない。これはこれを回避するより良い方法です。
HTH、蘭。
「最も純粋な」アプローチ、つまり、カップリングの量が最も少ないアプローチは、コードを共有しないです。
2つのサービス（AおよびBと呼ばれる）が同じ機能を必要とする場合、オプションは次のとおりです。
- 別のサービスCとしてオフの場合は分割されるため、AとBはCを使用できます
- 弾丸を噛んでコードを複製する
これは厄介に聞こえるかもしれませんが、誰もが依存する「ユーティリティ」または「共通」または「インフラストラクチャ」ライブラリを作成するという（珍しいことではありません）問題を回避します。サービス）。
実際には、いつものように、トレードオフです。
- 共有機能が充実している場合は、別のサービスを利用します。
- それが単なる定数である場合、共有ライブラリーが最良のソリューションかもしれません。ただし、後方互換性については十分に注意する必要があります。
- 構成データについては、LDAPなどの既存のテクノロジーを使用して、特定のサービスを実装することもできます。
- 最後に、独立して進化する可能性が高い単純なコードの場合、複製するだけが最適なソリューションになる可能性があります。
ただし、最善の方法は特定の状況と問題によって異なります。
私のプロジェクト経験から
SOAP（WSDLから生成されるため、サービスモデルコードではない）を使用する場合、WSDLを共有します。 。2番目または3番目の消費者が登場するとすぐに、問題が発生します。それらを切り離してください。サービスの操作と使用は、データ構造よりも過去に頻繁に変更されました。 2つ目のバージョンを同時に操作する必要があります。
いくつかの追加の考え
共有は、スケーラビリティと部分的に矛盾します。何も共有せず、一部共有/すべて共有することには、長所と短所があります。何も共有しないと、いつでも完全な柔軟性が得られます。マイクロサービスは、特定のドメインサービスを提供する独立したコンポーネントです。
ビジネスドメインデータモデルの共有は、同じ重複を防ぐ一般的なパターン（ http://www.ivarjacobson.com/resources/resources/books/#object%20oriented%20software ）です。マイクロサービスはビジネスパーツを分割して征服するため、ビジネスドメインデータモデルの一部を共有することが難しくなる可能性があります。
マイクロサービスは相互に通信するため、これらの通信データモデル（主にHTTPベース）を共有する必要性を理解しています。サービスプロバイダーとコンシューマーの間に1対1のマッピングがある場合は、これらのデータモデルを共有しても問題ない場合があります。モデル内の異なるモデル/フィールドを必要とする1つのサービスに対して複数のコンシューマーが存在するとすぐに、困難になります。
ISPの原則（インターフェイスセグメンテーションの原則）については、クライアントは実装ではなくインターフェイスに依存する必要があります。この方法で実装ではなくインターフェイスを共有できる場合は、システムを実装から切り離すことをお勧めします。