マイクロサービス：スマートエンドポイントとダムパイプとは何ですか？
Martin Fowlerの記事「 Microservices 」を読んだところ、smart endpointsとダムパイプ。これらの用語について説明してください。例は大歓迎です。
私は記事を読んでいないので、彼が正確に何を意味するのかを推測できるだけですが、マイクロサービスに対する例としてESBを、マイクロサービスの例としてZeroMQを挙げているので、私の推測はかなり正確であることを願っています。
Unix（およびLinux）のアイデアの1つは、小さな独立したアプリケーションを構築し、それらをパイプ経由で接続することです。私が使用しているおそらく最も一般的な2つのコマンドのセットは、psとgrepのようです：ps aux | grep PROCESS_NAME-ここでは、psの出力のみをgrepのstdinに転送するダムパイプを確認できます。
ZeroMQのような他のメッセージングシステムも同様に機能しますが、ラウンドロビン配信や信頼性の高い配信など、少し複雑になる可能性があります。言語としてのErlangは、互いにメッセージを送信する小さなスマートエンドポイントの上に構築されています。ここでの利点は明白であり、記事にも記載されています。小さなアプリケーションは保守が容易であり、分離することで拡張が容易になります。
一方、マイクロサービスのほとんどは、前述のエンタープライズサービスバスのような大規模なエンタープライズアプリケーションです。具体的な例を示すのに十分なものではありませんでしたが、通常、これらのバスにはスクリプトまたは構成を介して組み込まれる多くの機能が含まれています。このような機能には、ほとんどの場合、高度なルーティングを備えた構成可能なワークフローが含まれ、メッセージを変換することもできるため、さまざまなエンドポイントがそれらを処理できます。
たとえば、システムで事前のアクションを実行する場合、たとえば既に実行中のプロジェクトの要件を変更する場合、これによりワークフローが開始され、ESBは変更された要件に関連するさまざまなアクターに異なる通知を自動的に送信します。そして、この変更が適用される前に、それらのアクターの1つ以上が確認するのを待ちます。これは基本的には逆です-ダムエンドポイント（バスとの間でデータを送受信するだけ）と非常にスマートなパイプ（バス。構成またはスクリプト化して、考えられるすべてのエンタープライズシナリオを処理できます）。
同様のシナリオを処理するエンタープライズサービスバスが存在することは間違いありません。これは、単純な「ダム」なZeroMQのようなメッセージパッシングフレームワークの反対です。
基本的に、ロジックは、大きなESBまたはエンドポイントのどこかに実装する必要があります。マイクロサービスのアイデアは、それをバスではなくエンドポイントに配置し、UNIXアプリケーションと同様の哲学を持つことです。
マーティンファウラーズの記事は、「ESB」の概念を誤解させることにより、ひどく不足していると思います。この誤特徴は広範囲に及んでいます。 「バス」をメッセージが流れるパイプとして表す図を何回目にしましたか？私は確かに数を失いました、そしてそれは私を毎回ひるませるのです。 「バス」はパイプではありません。これは、分散型のサービス指向の環境全体で「有効化サービス」に簡単にアクセスできるようにするためのメカニズムです。典型的な例えは、工場のバスバーです。電気はバスバーを通って流れますが、それが「バス」である理由ではありません。製造フロア全体を走る「バス」です。あらゆる機械（サービスの実装）は、機械がどこにあるにせよ、どこでも（発電サービスから）電力を取得するためにバーに簡単にアクセスできます。バスはユビキタスイネーブラーであり、柔軟性と経時変化をサポートします。
サービスバス上に存在する唯一のものはサービスであり、一般的な原則として、それらは可能な場合または望ましい場合は常にマイクロサービスとして実装するのが最適です。 「スマートエンドポイント、ダムパイプ」のスローガンは、マイクロサービスが登場する前にさかのぼります。私は何年も前に、ESBの主要な擁護者との公開討論で、Microsoft BizTalkチームのメンバーから最初にそれを聞きました。 ESBの担当者は、エンドポイント（スマートエンドポイント）で変換が適用される一般的なBizTalkアプローチではなく、非常に細かいスタンドアロンの変換サービス（マイクロサービス）の望ましさを主張していました。 ESBの担当者はBizTalkを批判し、「モノリシック」であり、そのため、このようなきめ細かい、独立して展開可能なサービスの実装には使用できないと主張していました。 BizTalkの担当者は、（BizTalk ESBツールキットで後で示されるように）事実上間違っていると指摘しましたが、主なポイントは、中間サービスのダウンストリームではなく、メッセージのエンドポイントで（統合の観点から）変換を行うことの一般的な望ましさでした。交換で呼び出されます（概念的には「パイプ」のさらに下）。
これは、真面目な実践者の間の大人の議論でした。この点について、BizTalkの担当者（スマートエンドポイント、ダムパイプ）に同意しました。皮肉なことに、ESBの担当者は、ESBのコンテキストでマイクロサービスアプローチを効果的に宣伝していました。私にとって、これは、他の哲学と同様に、マイクロサービスマントラを一歩踏み出すことができないという良い例です。
システム内のコンポーネントは、「パイプ」（HTTP/S、キューなど）を使用して相互に通信します。通常、これらのパイプは、コンポーネント間で渡されるメッセージに対して多くのことを行うESB（Enterprise Service Bus）を通過します。
それはするかもしれません：
- セキュリティチェック
- ルーティング
- 業務フロー/検証
- 変換
これらのタスクが完了すると、メッセージは「エンドポイント」コンポーネントに転送されます。これは、多くのロジックと処理がESB（「パイプ」のシステムの一部）内に存在するため、「スマートパイプ」の例です。 ESBがすべての作業を行ったので、エンドポイントは「ダム」になります。
「スマートエンドポイントとダムパイプ」は反対のシナリオを提唱します。通信のレーンからビジネス処理とロジックを取り除き、文字通りコンポーネント間でメッセージを分散する必要があること。これらのメッセージに対して処理/ロジック/検証などを行うのはコンポーネント自体です。
それは非常に一般的な質問です。そのままにしていきます
スマートエンドポイント
スマートエンドポイントは、実際のビジネスルールを意味するだけであり、他の検証はエンドポイントの背後で発生します。エンドポイントのコンシューマーには誰にも見えませんが、実際のマジックが発生する場所と見なされます。
ダムパイプライン
ダムパイプラインとは、検証などのアクションが実行されない通信手段を意味し、特定のチャネルを介してデータを伝送するだけであり、必要に応じて交換することもできます。
Martin Fowler氏は次のように述べています。
スマートエンドポイントを使用する根拠は、「コンポーネントの重要な特性は、独立した置換とアップグレードの概念です。これは、コラボレーターに影響を与えずにコンポーネントの書き換えを想像できるポイントを探すことを意味します。」.
後者をサポートするには、マイクロサービスがそのコンシューマに対して寛容である必要があります。例えば。後で必須の入力引数を追加するとインターフェイスが壊れるので、避けてください。代わりに、マイクロサービスが有効な応答を提供できるように、デフォルトなどの補償戦略を使用するか、ある種の内部「ルーティング」をサポートする必要があります。これは一種のスマートな「エンドポイント」です。
ダムパイプは、単にポイントツーポイント接続を意味します。エンドポイントはすべての作業を実行し、それらを接続するメカニズムから複雑さが取り除かれます。ダムパイプ（ポイントツーポイント接続）はエンタープライズ環境（および他の多くの環境）ではひどい考えなので、この会話の中で人々はESBについて話していると思います。 ESBは「ダムパイプ」ではありません。 ESBは、非常にインテリジェントなパイプの優れた定義です。また、相互に通信する必要のあるサービスがいくつかある場合に、ポイントツーポイント接続が作成する非常に複雑な混乱を制御するのに役立ちます。
WSO2は、マイクロサービスに関する一連の優れたウェビナーを作成しました。彼らはこの概念について話します。しかし、彼らさえも、ダムパイプの概念を使うことをためらいます。
現在、サービスが純粋にアドホックベースで使用されていて、複雑なエンタープライズシステムを管理しようとしているのではない場合、ダムパイプは理にかなっています。すべてのサービスに対して複数のネットワーク接続を設定することは、その最小です。