MicroservicesVsSOA
Middleware vs. API Layer †
要約 †
メッセージングミドルウェア & API
詳細 †
Middleware vs. API Layer †
前のセクションの図3-5と図3-8を比較すると、どちらのアーキテクチャー・パターンもメディエーションを処理するミドルウェア・コンポーネントを持つように見えます。しかし、そうではありません。マイクロサービスアーキテクチャのパターンは、通常、APIレイヤーとして知られていますが、SOAにはメッセージングミドルウェアコンポーネントがあります。このセクションでは、これらの2つの要素を、果たす役割と提供する機能の点で比較します。
マイクロサービスパターンは、メッセージングミドルウェア（例えば、統合ハブまたはエンタープライズサービスバス）の概念をサポートしていません。むしろ、サービスアクセスファサードとして機能するサービスの前にAPIレイヤの概念をサポートしています。サービスコンシューマとサービスの間にAPIレイヤを配置することは、サービスコンシューマがサービスエンドポイントの実際の位置を知る必要がないように抽象レイヤを形成するため、一般的には良い考えです。また、サービスコンシューマーに影響を与えることなく、サービスの粒度レベルを変更することもできます。サービス粒度を抽象化するには、API層内に少しのインテリジェンスとオーケストレーションレベルが必要ですが、これをリファクタリングしてサービスを対応するサービスコンシューマへの絶え間ない変更なしに進化させることができます。
たとえば、製品の発注に関連したビジネス機能を実行するサービスがあるとします。あなたはそれが粗すぎると判断し、スケーラビリティを向上させ、導入を容易にするためにサービスを2つのより細かいサービスに分割したいとします。実際のサービスエンドポイントを抽象化するAPIレイヤーがなければ、サービスを使用する各サービスコンシューマは、1つではなく2つのサービスを呼び出すように変更する必要があります。 APIレイヤーを使用している場合、サービスコンシューマーは、単一の要求が現在2つの別々のサービスに移行していることを知らない（または注意しません）。
SOAはメッセージングミドルウェアを利用してサービスコールを調整します。メッセージング・ミドルウェア（インテグレーション・ハブと呼んでいます）を使用すると、仲介とルーティング、メッセージ強化、メッセージ変換、プロトコル変換など、マイクロサービス・アーキテクチャ・スタイルにはない追加のアーキテクチャ機能が提供されます。
仲介とルーティングは、アーキテクチャが特定のビジネス要求またはユーザー要求に基づいてサービス（またはサービス）を見つけて呼び出す機能を記述します。この機能を図3-9に示します。サービスレジストリまたはサービスディスカバリコンポーネントの使用、サービスオーケストレーションの使用を図に示します。マイクロサービスとSOAの両方は、特にサービスレジストリやサービスディスカバリコンポーネントに関して、この機能を共有しています。しかし、マイクロサービスでは、サービスのオーケストレーションは通常最小化されるか、まったく使用されませんが、SOAでは頻繁に使用されます。
Figure 3-9. Mediation and routing capability
メッセージ拡張は、要求がサービスに達する前に、要求のデータ部分を変更、削除、または拡張するためのアーキテクチャの機能を記述します。メッセージの強化の例としては、日付形式の変更、要求に派生または計算された追加値の追加、ある値を別の値に変換するデータベースルックアップの実行などがあります（統一セキュリティ識別手順[CUSIP]株価記号、およびその逆）。マイクロサービスパターンはこの機能をサポートしていません。主に、この機能を実装するためのミドルウェアコンポーネントが含まれていないためです。 SOAは、メッセージングミドルウェアを通じてこの機能を完全にサポートしています。図3-10に、この機能を示します。この図では、サービスコンシューマがCUSIP番号（標準取引証書識別子）とMM / DD / YY形式の日付を送信しているのに対して、サービスは株式交換日公認リスト（SEDOL）番号（別のタイプ、YYYY.MM.DD形式の日付、株価指数（株取引の場合）の株価記号が含まれます。この場合、メッセージングミドルウェアは、Apple、Inc.（037833100）のCUSIP番号をApple、Inc.（2046251）のSEDOL番号に変換し、シンボルを検索して追加して、AAPLを変換して、日付は04/23/15から2015.04.23までです。
Figure 3-10. Message enhancement capability
メッセージ変換は、あるタイプから他のタイプへのデータのフォーマットを変更するアーキテクチャの能力を記述します。 たとえば、図3-11に示すように、サービス・コンシューマはサービスをコールしてJSON形式でデータを送信しますが、サービスにはJavaオブジェクトが必要です。 メッセージの拡張は、要求のデータに関係するのではなく、データを含むラッパーの形式に関するものであることに注意してください。 ここでも、マイクロサービスアーキテクチャはこの機能をサポートしていませんが、SOAはメッセージングミドルウェアを使用して行います。
Figure 3-11. Message transformation capability
最後に、プロトコル変換では、サービスコンシューマに、サービスが期待しているものとは異なるプロトコルを使用してサービスを呼び出すようにするアーキテクチャの機能が記述されています。 図3-12にこの機能を示します。 このダイアグラムでは、サービスコンシューマがRESTを介して通信していることに注意してください。要求を処理するために必要なRMI / IIOP接続（たとえば、Enterprise JavaBeans? 3 [EJB3] Bean）およびAMQP接続 。 マイクロサービスは複数のプロトコルタイプをサポートできますが、サービスコンシューマとサービスは同じプロトコルを使用する必要があります。 SOAでは、必要に応じてそれらを混在させることができます。
Figure 3-12. Protocol transformation capability
次の章では、これらの機能について、マイクロサービスとSOAのアーキテクチャ機能の比較に関連して説明します。
通常、サービスはマイクロサービスやSOAでリモートからアクセスされるため、これらのアーキテクチャパターンはサービスコンシューマがリモートサービスにアクセスする方法を提供する必要があります。 リモートアクセスに関するマイクロサービスとSOAの根本的な違いの1つは、マイクロサービスアーキテクチャがRESTをプライマリリモートアクセスプロトコルとして使用する傾向がありますが、SOAにはそのような制限はありません。 実際、数十種類のリモートアクセスプロトコルを処理する能力を持つことは、マイクロサービスとは別にSOAを設定する主なものの1つです。
アーキテクチャパターンの簡素化に寄与するマイクロサービスの基本原理の1つは、テクノロジとアーキテクチャの選択肢の数が一般にいくつかの選択肢に限定されていることです。 たとえば、ほとんどのマイクロサービスアーキテクチャは、通常、サービス-RESTと単純なメッセージング（JMS、MSMQ、AMQPなど）にアクセスするために、2つの異なるリモートアクセスプロトコルのみに依存しています。 これは、SOAPや.NET Remotingなどの他のリモートアクセスプロトコルを活用できないと言っているわけではありませんが、マイクロサービスで検出されるリモートアクセスプロトコルは通常均質であるという点が重要です。 言い換えると、サービスはRESTベース、メッセージングベース、または他のアクセスプロトコルに基づいていますが、アクセスプロトコルはほとんど同じアプリケーションまたはシステム内で混在しています。 1つの例外は、パブリッシュおよびサブスクライブのブロードキャスト機能に依存するサービスがメッセージベースであるのに対し、他の非ブロードキャストサービスはRESTベースである場合になります。
SOAには、アーキテクチャー・パターンの一部としてどのリモート・アクセス・プロトコルを使用できるかに関する事前に記述された制限はありません。 次の章で説明するように、アーキテクチャのメッセージングミドルウェアコンポーネントは、任意の数のリモートアクセスプロトコルをサポートし、あるプロトコルから別のプロトコルへの変換を可能にします。 つまり、ほとんどのSOAアーキテクチャは、通常、プライマリサービスのリモートアクセスプロトコルとしてメッセージング（JMS、AMQP、MSMQなど）とSOAPに依存しています。 SOAアーキテクチャーの範囲とサイズに応じて、異機種間サービス間で6つ以上の異なるリモート・アクセス・プロトコルを使用することは珍しくありません。
担当者のつぶやき †
みんなの突っ込み †
