マイクロサービス アーキテクチャ ( http://martinfowler.com/articles/microservices.html )に準拠した全体的なサービスを構築する際に、Enterprise Service Bus の機能を使用しない (または使用する) 理由は何ですか? よりスマートなパイプを使用してよりシンプルなサービスを開発できるのではなく、ダム パイプとスマート エンドポイントを使用する必要があるのはなぜですか?
4 に答える
これは非常に大きな問題であり、おそらく SO の Q&A 形式では効果的に答えることはできません。
それはあなたがそれで何をしているかによって異なります。
独立していると考えることができる多くの小さな機能で構成される単一の製品を構築している場合は、マイクロサービスが最適な方法です。
あなたが大規模な企業組織であり、IT が取締役会の競争上の優位性としての主な考慮事項ではなく、独自の IT 部門を持つグローバルに分散したプロジェクト全体に新しい標準を適用する必要がある規制の厳しい業界で働いている場合。組織内のすべてのエンドポイントとアプリケーションを一元的に制御できない場合は、ESB が必要になる可能性があります。
両方のアプローチのすべての利点をここにリストしようとしていると非難されたくありません。それらは完全ではなく、すぐに時代遅れになる可能性があるからです。
そうは言っても、OPに役立つようにするために:
Spotify と Netflix がマイクロサービスをどのように行っているかを調べると、個々のサービスの Blue/Green デプロイの容易さ、分離されたチーム構造、障害の分離など、アプローチについて彼らが気に入っている多くの点を見つけることができます。
ESB を使用すると、法的要件などのポリシーを一元的に管理および実施し、各チームがすべてをログに記録することに関するメモを取得することを期待するのではなく、1 か所ですべてを監査し、負荷と稼働時間に関するグローバルな統計情報を提供したり、その他多くのことを行うことができます。ESB は、Web サイトでの顧客の応答時間やイノベーションの速度などではなく、サービス レベル アグリーメント、費用対効果、および規制 (その他) が原動力である大企業から成長しました。
どちらのアプローチにも多くの価値があります。ESB が 10 ~ 15 年前にそうであったように、現在、マイクロサービスについて多くのことが書かれています。それは進歩かもしれないし、ただの変化かもしれないし、単に消費財企業が自らを売り込む必要があり、大企業が詳細を非公開にしたいだけかもしれない. あと10年もすればわかるかもしれません。今のところ、それはあなたが何をしているかに大きく依存しています。プログラミングのほとんどの場合と同様に、単純なものから始めて、必要に応じてより複雑なソリューションに移行するだけです。