マイクロサービス間の共有ライブラリが悪いのはなぜですか？
サムニューマンは本の中でBuilding Microservicesと述べています。
サービス間の結合が多すぎることの弊害は、コードの重複によって引き起こされる問題よりもはるかに悪い
サービス間の共有コードがどのように悪かったのか、私には理解できません。作成者はサービス境界自体が共有ライブラリの必要性が生じた場合に設計が不十分であることを意味しますか、または一般的なビジネスロジック依存の場合にコードを複製する必要があることを本当に意味しますか？それが何を解決するのかわかりません。
2つのサービスに共通するエンティティの共有ライブラリがあるとします。 2つのサービスの共通ドメインオブジェクトはにおいがする場合がありますが、別のサービスはそれらのエンティティの状態を調整するためのGUIであり、別のサービスは他のサービスが目的のために状態をポーリングするためのインターフェイスです。同じドメイン、異なる機能。
ここで、共有される知識が変更された場合、共通のコードが外部依存であるか、サービス間で重複しているかに関係なく、両方のサービスを再構築して展開する必要があります。一般に、同じことがビジネスロジックの同じ記事に依存する2つのサービスのすべてのケースに関係します。この場合、コードの重複による害しかなく、システムのまとまりが減少しています。
もちろん、共有知識のdivergingは共有ライブラリの場合に頭痛の種になるかもしれませんが、継承、構成、抽象化の巧妙な使用でこれを解決することもできます。
では、Samは、共有ライブラリを介したカップリングが多すぎるよりも、コードの複製の方が優れていると言うことでどういう意味ですか？
サービス間の結合が多すぎることの弊害は、コードの重複によって引き起こされる問題よりもはるかに悪い
彼が一般的な単語「カップリング」を使うとき、著者は非常に不特定です。特定のタイプのカップリングが厳格な禁止事項であることに同意します（データベースの共有や内部インターフェースの使用など）。ただし、共通ライブラリの使用はそれらの1つではありません。たとえば、golangを使用して2つのマイクロサービスを開発する場合、すでに共有依存関係があります（golangの基本ライブラリに対して）。同じことは、共有目的で自分で開発したライブラリにも当てはまります。次の点に注意してください。
- サードパーティのエンティティへの依存関係と同じように共有されるライブラリを扱います。
- 各コンポーネント/ライブラリ/サービスが異なるビジネス目的を持っていることを確認してください。
- それらを正しくバージョン管理し、どのバージョンのライブラリを使用するかの決定は、対応するマイクロサービスチームに任せます。
- マイクロサービスチームとは別に、共有ライブラリの開発とテストの責任を設定します。
忘れないでください-マイクロサービスのアーキテクチャスタイルは、コードの編成や内部の設計パターンではなく、より大きな組織とプロセスに関連する側面に重点を置いて、アプリケーションアーキテクチャ、組織、およびデプロイメントのスケーリングを可能にします。概要については this answer を参照してください。
複製が許容される密結合の良い例は、サービス間のインターフェース/ DTOを定義する共有ライブラリです。特に、同じクラス/構造体を使用してデータをシリアル化/非シリアル化します。
AとBの2つのサービスがあるとします。どちらのサービスも、わずかに異なりますが、全体的にほとんど同じように見えるJSON入力を受け入れる場合があります。
サービスAとサービスBが共有ライブラリとして使用する非常に少数のキーも含めて、共通のキーを記述する1つのDTOを作成するのは魅力的です。
しばらくの間、システムは正常に動作します。どちらのサービスも共有ライブラリを依存関係として追加し、正しくビルドして実行します。
ただし、時間の経過とともに、サービスAにはJSONの構造を変更する追加のデータがいくつか必要になります。その結果、同じクラス/構造体を使用して、両方のサービスのJSONを同時に逆シリアル化することはできません。サービスAには変更が必要ですが、サービスBはデータを逆シリアル化できません。
共有ライブラリを変更し、サービスAに新しい機能を追加して再構築してから、サービスBを再構築して、ロジックが変更されていなくても新しいバージョンの共有ライブラリに調整する必要があります。
さて、最初から両方のサービスに対して、内部的に別々に定義されたDTOがありますか？その後、それらのコントラクトは、あなたが想像できるあらゆる方向に別々にそして安全に展開できます。確かに、最初は両方のサービスでほぼ同じDTOを維持するのは臭く見えたかもしれませんが、長期的には変更の自由が与えられます。
結局のところ、（マイクロ）サービスはモノリスとそれほど変わりません。懸念の分離と分離は重要です。一部の依存関係（言語、フレームワークなど）は回避できませんが、追加の依存関係を自分で導入する前に、将来の影響について2度考えてください。
私はむしろ与えられた助言に従うべきです-DTOを複製し、避けられない場合を除いて共有コードを避けてください。過去に私を噛んだ。上記のシナリオは取るに足らないものですが、はるかに微妙で、より多くのサービスに影響を与える可能性があります。残念ながら、それはしばらくしてからあなたに当たるので、影響は大きいかもしれません。