architecture - マイクロサービス: スマート エンドポイントとダム パイプとは?

Question

Martin Fowlerの記事「マイクロサービス」を読んだことがありますが、スマートエンドポイントとダム パイプを理解するのは難しいと感じています。これらの用語を説明してください。例を歓迎します。

Answer 1

私はその記事を読んでいなかったので、彼が正確に何を意味しているのかを推測することしかできませんが、マイクロサービスに対する例として ESB を、マイクロサービスに対する例として ZeroMQ を挙げているので、私の推測がかなり正確であることを願っています。

Unix (および Linux) のアイデアの 1 つは、小さな独立したアプリケーションを構築し、それらをパイプ経由で接続することです。私が使用しているおそらく最も一般的な 2 つのコマンドのセットはps、次のgrepようなものps aux | grep PROCESS_NAMEです。psgrep

ZeroMQ などの他のメッセージング システムも同様に機能しますが、ラウンド ロビン分散や信頼性の高い配信など、もう少し複雑になる可能性があります。言語としての Erlang は、互いにメッセージを送信する小さなスマート エンドポイントの上に構築されています。ここでの利点は明らかであり、記事でも言及されています。小さなアプリケーションは保守が容易であり、デカップリングによりスケーリングが容易になります。

一方、マイクロサービスは、前述の Enterprise Service Bus のような大規模なエンタープライズ アプリケーションであることが最も一般的です。具体的な例を示すのに十分なほどそれらを実際に使用したわけではありませんが、通常、これらのバスには、スクリプトまたは構成を介して含まれる多くの機能が含まれています。このような機能には、ほとんどの場合、高度なルーティングを備えた構成可能なワークフローが含まれており、メッセージを変換することもできるため、さまざまなエンドポイントでメッセージを処理できます。

たとえば、すでに実行中のプロジェクトの要件を変更するなど、システムで何らかの事前アクションを実行する必要がある場合、これによりワークフローが開始され、ESB は変更された要件に関連するさまざまなアクターにさまざまな通知を自動的に送信します。この変更が適用される前に、これらのアクターの 1 つ以上が確認するのを待ちます。これは基本的に反対です-ダムエンドポイント（バスとの間でデータを送受信するだけ）と非常にスマートなパイプ（すべての可能なエンタープライズシナリオを処理するように構成またはスクリプト化できるバス）。

私は、同様のシナリオを処理するエンタープライズ サービス バスが存在することを確信しています。これらは、単純な「ばかげた」ZeroMQ のようなメッセージ パッシング フレームワークとは正反対のものです。

基本的に、ロジックは大きな ESB かエンドポイントのいずれかに実装する必要があります。マイクロサービスの考え方は、バスではなくエンドポイントに配置することであり、UNIX アプリケーションと同様の哲学を持っています。

Answer 2

Martin Fowlers の記事は、「ESB」の概念を誤解しているため、ひどく不十分だと思います。この誤解は広まっています。メッセージが流れるパイプとして「バス」を表す図を何回見たことがありますか? 私は確かに数を失いました、そしてそれは私を毎回ひるませます. 「バス」はパイプではありません。これは、分散されたサービス指向の環境全体で「サービスを有効にする」ために簡単にアクセスできるようにするためのメカニズムです。典型的な例えは、工場のバス バーです。電気はバスバーを通って流れますが、それが「バス」である理由ではありません。製造フロア全体を走るので「バス」です。任意の機械 (サービスの実装) は、その機械が配置されている場所に関係なく、簡単にバーを利用して (発電サービスから) 電力を得ることができます。

サービス バス上に存在するのはサービスだけであり、一般的な原則として、可能または望ましい場合はマイクロサービスとして実装するのが最適です。「スマート エンドポイント、ダム パイプ」というスローガンは、マイクロサービスが登場するずっと前にさかのぼります。私が最初に聞いたのは、Microsoft BizTalk チームのメンバーから、何年も前に ESB の主要な支持者との公開討論でした。ESB 担当者は、変換がエンドポイント (スマート エンドポイント) で適用される典型的な BizTalk アプローチではなく、非常に粒度の細かいスタンドアロン変換サービス (マイクロサービス) が望ましいと主張していました。ESB 担当者は BizTalk を批判し、BizTalk は「モノリシック」であり、そのため、このようなきめの細かい個別展開可能なサービスの実装には使用できないと主張しました。

これは、真面目な実務家の間での大人の議論でした。私はこの点で BizTalk の担当者に同意しました。スマート エンドポイント、ダム パイプです。皮肉なことに、ESB 担当者は ESB コンテキストでマイクロサービス アプローチを効果的に推進していました。私にとって、これは、他の哲学と同様に、マイクロサービスのマントラがいかに行き過ぎているかを示す好例です。

Answer 3

Martin Fowler によると、「一般的に使用される 2 番目のアプローチは、軽量のメッセージ バスを介したメッセージングです。選択されるインフラストラクチャは、通常、ダムです (メッセージ ルーターとしてのみ機能するため、ダム)」.

スマート エンド ポイントを使用する理由は、次のように暗示されています。

後者をサポートするには、マイクロサービスはその消費者に対して寛容である必要があります。たとえば、後で必須の入力引数を追加すると、インターフェイスが壊れてしまうため、避ける必要があります。代わりに、デフォルトなどの補償戦略を使用するか、何らかの内部「ルーティング」をサポートして、マイクロサービスが引き続き有効な応答を返すことができるようにする必要があります。これは一種のスマートな「エンドポイント」です。

Answer 4

ダム パイプとは、単にポイント ツー ポイント接続を意味します。エンドポイントがすべての作業を行い、それらを接続するメカニズムから複雑さが取り除かれます。ダム パイプ (ポイント ツー ポイント接続) は、エンタープライズ環境 (および他の多くの環境) ではひどい考えであるため、この会話で人々が ESB について話していると思います。ESB は「ダムパイプ」ではありません。ESB は、非常にインテリジェントなパイプのかなり適切な定義です。また、相互に通信する必要のあるサービスが複数ある場合に、ポイント ツー ポイント接続によって生じる非常に複雑な混乱を制御するのにも役立ちます。

WSO2 は、マイクロサービスに関する一連の優れたウェビナーを作成したばかりで、この概念について語っています。しかし、彼らでさえ、ダムパイプの概念を使用することをためらいます.

サービスが純粋にアドホック ベースで使用される場合、ダム パイプは理にかなっていますが、複雑なエンタープライズ システムを管理しようとする場合には意味がありません。すべてのサービスに対して複数のネットワーク接続を設定することは、少なくともそれです。