ESBがマイクロサービスアーキテクチャで悪いと見なされる理由
マイクロサービスアーキテクチャでは、自律型ビジネスサービスは互いに直接通信する必要があります。通信は、同期（オーケストレーション）またはイベントベース（コレオグラフィー）の場合があります。 APIゲートウェイは、クライアント（フロントエンドのバックエンド）のAPIを集約できます。マイクロサービスでは、2つの究極の目標を探しています
- 低結合
- 高い凝集力
当然ながら、継続的な展開、きめの細かいスケーリング、迅速な技術の適応、再利用性、監査性がはるかに高くなりますが、もちろん複雑さが増します。
ただし、ESB（Enterprise Service Bus）またはその他のミドルウェアを使用することは強くお勧めしません。マイクロサービスとESBは、しばしば競合するソリューションと見なされます。 ESBがこんなに悪いのはなぜですか？いくつかの追加の監視および認証レイヤー（ビジネスロジックなし）を備えた瞑想チャネルとして使用されている限り、マイクロサービスアーキテクチャでそれを使用することの問題は何ですか？
さまざまな企業で2つのESBの展開を目撃しました。どちらの場合も、監視と認証を支援するという同じ高貴な目標を持ち、レガシーシステムへの「より良い」アクセスを提供します。どちらの場合も、わずか1〜2年でESBは単一障害点になり、変更のボトルネックになり、一般にすべてのプロジェクトの障害になりました。
ESBは、あまり使用しない便利です。最初に、何らかのシステムに送信したいメッセージに特別なルーティングを追加し、次に、可能であればXMLメッセージを別の形式に変換するだけですぐに解決します。次に、クライアントシステムで修正するにはコストがかかりすぎるバージョン更新をカバーするために、さらにXSLTまたはその他のものを追加します。等々...
やがて、あなたはそこにビジネスロジックを持ちます。すべてのチームは、すべてのロールアウト、新しいメッセージ、またはメッセージ形式の変更についてもESBチームと調整する必要があります。それ独立を殺す（低カップリング）チーム。
先ほど指摘したように、Microservicesアーキテクチャのポイントは、自律動作をサービスだけでなく、そのチームにもを有効にすることです。これにより、迅速な変更が可能になります。理想的には次のことを意味します：
- 他のチームとの同期ポイントは避けてください。テスト、ロールアウト、構成、または操作のために使用してください（つまり、部門を超えてDevOpsを実行する必要があります）。
- ランタイムが他のサービスと同期するのを避けます。これは、テクノロジーに関係なく同期呼び出しを回避することを意味します。後から応答が来たとしても、要求して応答することは絶対に避けてください。
- 他のチームへの依存を避けます。これは、（ビジネスロジックまたはビジネス関連のオブジェクトを持つコードの）コード共有を避けることを意味します
基本的に、会社の他のメンバーがシャットダウンして休暇に出た場合でも、マイクロサービスの運用を継続できます（そして、新しいバージョンを展開します）。
もちろんそれは「理想化された」シナリオですが、ESBは上記のすべての目標に最も確実に反します。これは同期ポイントであり、ランタイムと組織の両方の集中化された依存関係です。