Spring Boot Applicationのマイクロサービス間でリポジトリを共有することは良い考えですか？
デスクトップアプリケーションをWebベースのSpring Bootマイクロサービスアプリケーションに移行します。クライアントは既存のMySQLデータベースの使用を義務付けられているため、すべてのマイクロサービスが共通のデータベースを共有します。
そのSQLデータベース以来、Spring JPA（Hibernate）を選択しました。
プロジェクトのセットアップ中に、アーキテクチャチームはHibernateツールを介してエンティティを「db-commons」プロジェクトに生成し、再利用可能なコードを引用してこの共有ライブラリにSpring JPAリポジトリも追加しました。
共有エンティティは無害に聞こえますが、次のように、リポジトリを共有するという考えに激しく反対しました-
- SOLIDのSに違反しています。マイクロサービスは、自分が所有するデータのみを表示して操作する必要があります。
- プレッシャーのある開発者は、他のサービスでこれらのリポジトリを直接使用して、他のマイクロサービスが所有するデータを変更します。
- コードが重複し、検証が失敗する可能性があります。
- 大規模な同時実行性とデータの問題につながる可能性があります。
私の懸念は間違っていますか？
正しい場合、考えられる悪影響（現在/将来）を見逃していませんか？
私は激しく反対しました
Vehemenceは、他の人に聞き取りを停止させると同時に、問題とその解決策に対する私たちの認識を制限します。
私の経験では、私たちは完全に理解していないアイデアを擁護したり反対したりすることに激怒します。
共有エンティティは無害に聞こえますが、リポジトリを共有するという考えに反対しました
MSアーキテクチャーは些細なことではありません。永続化を分割することは、最も難しいことの1つです。これはやるより言うのが簡単なことなので、なぜ多くの「教祖」が「どうあるべきか」について書いているのに、正確に「それを行う方法」については誰も言いません。この主題についてインターネットで読むとき、著者がそのような結論に至った原因を私たちは知らないことを思い出さなければなりません。または、私たちはそうしますが、同じ問題点を共有しません。
他の誰かの意見に基づいて意思決定を行うと、平凡な意思決定につながるだけなので、独断的ではありません。見知らぬ人の猛烈な意見を擁護しないでください。実用的である。主題について知っているすべてのものをプロジェクトのコンテキストに入れ、テストして、自分に合ったものを選択します。最終的には複雑になるため、可能な限り単純なソリューションから始めます。
SOLIDのSに違反しています。マイクロサービスは、それが所有するデータのみを参照して操作する必要があります。
MSごとに1つのデータソースが理想的ですが、それは石で書かれたルールではありません。私たちがそのようにしないと、マーティン・ファウラーが現れて私たちの魂を食べてしまうようなものではありません。正当な理由がある場合は、データソースを分離します。
MSアーキテクチャは、大規模なモノリシックシステムを使用している企業によって推進されてきました。メンテナンスが非常に難しくて高価になり、市場での競争力が低下しました。これらの企業は、製品化までの時間を短縮し、開発を並列化し、新しい機能を展開し、いつでも離陸できるように、さまざまなSDLCを明確にする方法を必要としていました。ある時点で、単一のデータベースが目標を達成する能力を制限するため、データソースも分割することにしました。それらはビジネスから派生した決定でした。アーキテクチャ上の決定は、会社のいくつかの目標を満たすために対処されるビジネスニーズによって課されます。これらの目標の中には明白なものもあれば、そうでないものもあります。
プレッシャーのある開発者は、他のサービスのこれらのリポジトリを直接使用して、他のマイクロサービスが所有するデータを変更します。
必ずしもそうとは限りませんが、リポジトリをいくつかのライブラリに分離し、各サービスに必要と思われるものだけを選択することができます。
次に、サービスを異なるプロファイルを使用してデータソースに接続できます。プロファイルはそれぞれ異なるACLを使用します。データベースの多くはRBACをサポートしています。それを活用してください。
コードが重複し、検証が失敗する可能性があります
コードの再利用につながり、それは良いことです。ライブラリは、適切に「抽象化」されていれば、具体的なデータモデルを提供する必要はありません。場合によっては、実装するインターフェースまたは適応する抽象クラスのみが必要になることがあります。リポジトリでのコードの再利用はデータモデルではなく、永続化に関するロジックです。不足しているコードに関しては、そのコードを再利用する価値がある場合は、リポジトリとともにライブラリにカプセル化されます。
大規模な同時実行性とデータの問題につながる可能性があります。
か否か。時期尚早の最適化は悪の種です。理由があるまで、システムのサイズを大きくしないでください。
複数のサービスがデータソースに過負荷をかけ、システムの残りの部分が影響を受ける場合、同時実行性に問題が生じる可能性があります。これは、データソースを分離するための良い議論ですが、これが成り立つまで待つ必要があります。データの競合状態については、処理がさらに困難な高度に分離されたMSアーキテクチャでも発生します。
私の懸念は間違っていますか？
理論的には正しいですが、実用的ではありません。最先端のアーキテクチャを実装するための報酬は得られず、手元にあるものに関する問題を解決するための報酬が得られます。
考えられるマイナスの影響を見逃しましたか（現在/将来）？
はい、しかし、それらは重要な場合にのみ重要です。
共有ライブラリは、コードの再利用を利用するために、他のサービスを同じプログラミング言語で実装する必要があることを意味します。それはMSの哲学とは全く逆です1。しかし、すべての開発者がそのプログラミング言語しか知らない場合でも、必ずしも悪いことではありません。
共通のソースコードを変更すると、配信戦略にペナルティが課せられる可能性があるため、コードの再利用はSDLCも結合します。しかし、どのサービスが互いに密接に関連しているのかを見つけるのに役立ちます。それらが将来単一のサービスになる可能性があるという合図。
現実vs知覚
現実はすべて知覚です。 「本物」が1つしかない場合でも、さまざまなデータソースがあるという「知覚」を提供できます。それを作る本当の理由があるときそれを現実にしてください。
1-MSアーキテクチャは、実装と回復力の自由がすべて
まず最初に、マイクロサービスは独自のDBで動作する必要があります...そうではありませんが、これを可能にする方法でアプリケーションを構築することは、一般的には良い考えです。 dbは共有されています。
私は、リポジトリを個々のMSにとって可能な限り有効に保ち、MS間でリポジトリを共有できないようにすることを強くお勧めします。このようにして、システム内で誰が何を所有しているかは非常に明確であり、アプリケーションの他のレイヤーから共有データベースのアイデアを遠ざけます。
移行の最中なので、この共有ライブラリはしばらく存在する可能性がありますが、このライブラリをできるだけ早く消滅させる計画が必要です。
共有ライブラリでマイクロサービスを使用することは 悪臭一部の場合 と見なされますが、モノリスアプリケーションを小さな平和（サービス）で壊そうとしている場合は理解できます。デスクトップアプリケーションをモノリスアプリケーションと見なすことができると思います。
エンティティとリポジトリを含む共有ライブラリを扱うことは、私には悪臭のケースのようです。あなたはこの人たちの多くの変更に対処する必要があるでしょう、そしておそらく、あなたは時々アップグレードすることを強制されるでしょうすべてのこの共有ライブラリのバージョンマイクロサービス。しかし、私が言ったように、各データベースの適切なサービス所有者を特定し、将来この共有ライブラリを削除するまで、この状況が一時的である場合は、私にとっては許容できる一時的な解決策。
覚えておいてください。一般に、マイクロサービスは非常に独立している場合に適しています。作成したこれらのマイクロサービスが本当に必要かどうか、モノリスの場合は、マイクロサービスを中断する前に、必要なマイクロサービスを理解するまで、これは適切な選択ではありません。