rest - Erlang/OTP アーキテクチャ: SOAish サービス用の RESTful プロトコル

Question

設計および構築するピザ店の注文処理システムがあるとします。

要件は次のとおりです。

R1. システムは、クライアントやユースケースに依存しない必要があります。これは、初期設計時に考慮されなかったクライアントがシステムにアクセスできることを意味します。たとえば、ピザ屋が後で顧客の多くが Samsung Bada スマートフォンを使用すると判断した場合、Bada OS 用のクライアントを作成するためにシステムの API とシステム自体を書き直す必要はありません。または、たとえば、Android デバイスの代わりに iPad を使用する方が配送ドライバーにとって何らかの方法で優れていることが判明した場合、iPad クライアントを作成するのは簡単であり、システムの API にはまったく影響しません。

R2. 再利用性。これは、ビジネス プロセスが変更された場合に、多くのコードを書き直すことなく、システムを簡単に再構成できることを意味します。たとえば、後でピザ店が配達ドライバーによる現金の受け入れに加えてオンラインでの支払いの受け入れを開始した場合 (注文を受ける前に支払いを受け入れる VS 配達時に支払いを受け入れる)、システムを新しいビジネスプロセスに適応させるのは簡単です。 ;

R3. 高可用性と耐障害性。つまり、システムはオンラインで、24 時間年中無休で注文を受け付ける必要があります。

したがって、R3 を満たすために、Erlang/OTP を使用し、次のアーキテクチャを持つことができます。

ここでの問題は、この種のアーキテクチャには多くの「ハードコーディングされた」機能があることです。たとえば、ピザ屋が配達時の現金支払いから注文前のオンライン支払いに移行すると、システム全体を書き直したり、システムの API を変更したりするのに多くの時間と労力がかかります。

さらに、ピザ屋が CRM クライアントを強化する必要がある場合は、API、クライアント、およびシステム自体を書き直す必要があります。

したがって、次のアーキテクチャは、これらの問題を解決し、R1、R2、および R3 を満たすのに役立つことを目的としています。

システム内の各「サービス」は、RESTful API を備えた Webmachine Web サーバーです。このようなアプローチには、次の利点があります。

• 各 Webmachine は Erlang アプリケーションであり、監視することができ、Erlang リリースに入れることができるため、Erlang/OTP のすべての利点。
• SOA のすべての利点を備えたサービス指向アーキテクチャ。
• ビジネスプロセスの変更に簡単に適応できます。
• クライアントは 1 つの「中央」API (SOA に関するサービスの構成可能性) ではなく、システム内のすべてのサービスの RESTful API を使用できるため、新しいクライアントと新しい機能をクライアント (CRM クライアントなど) に簡単に追加できます。

したがって、基本的に、2 番目の図で提案されているシステム アーキテクチャは、各サービスが WSDL コントラクトの代わりに RESTful API を持ち、各サービスが Erlang/OTP アプリケーションであるサービス指向アーキテクチャです。

そして、ここに私の質問があります：

1. 写真 2: ここで車輪の再発明を試みているのでしょうか? 代わりに、純粋な Erlang/OTP アーキテクチャに固執する必要がありますか? (「純粋な Erlang」とは、リリースにパックされた Erlang アプリケーションを意味し、gen_server:call および gen_server:cast 関数呼び出しを介して互いに通信します);
2. 提案されたアプローチの欠点を挙げることができますか? (写真2)
3. 真の Erlang/OTP システムよりも、このようなシステム (図 2) の維持と拡張 (R1 と R2) の方が簡単だと思いますか?
4. このようなシステムのセキュリティ (図 2) は問題になる可能性があります。これは、1 つのエントリ ポイント (図 1) ではなく、多くのエントリ ポイント (すべてのサービスの RESTful API) が Web に対して開かれているためです。そうではありませんか?
5. そのようなシステムに複数の「オーケストレーション モジュール」を配置しても問題ないでしょうか。(写真2の「受注」「CRM」「発送」サービス);
6. 純粋な Erlang/OTP (図 1) には、メッセージ パッシングとプロトコルの制限に関して、このアプローチ (図 2) よりも利点がありますか? (私の以前の同様の質問、gen_server:call VS HTTP RESTful 呼び出しで部分的に説明されています)

Answer 1

SOAに関して覚えておくべきことは、アーキテクチャーはテクノロジー（REST、WS *）に関するものではないということです。したがって、必要に応じて、いくつかのタイプのエンドポイントで適切なSOAを導入できます（私がEdgeコンポーネントと呼んでいます-ビジネスロジックを通信やプロトコルなどの他の懸念事項から分離します）また、サービス境界は信頼境界であることに注意することが重要ですそのため、クロスする場合は、認証と承認、クロスネットワークなどが必要になる場合があります。さらに、レイヤー（データやロジックなど）への分離によって、サービスのパーティション分割が行われることはありません。

したがって、私があなたの質問で読んでいることから、私はおそらくサービスをより粗いサービスに分割するでしょう（以下を参照）。サービスの境界内での通信は何でもかまいませんが、サービス間の通信ではパブリックAPIを使用します（RESTまたはErlangネイティブはあなた次第ですが、重要なのは、管理、バージョン管理、セキュリティ保護などです）。サービスには、さまざまなユーザーを容易にするために複数のテクノロジーのエンドポイントがある場合があります（ESBを使用してサービスとプロトコルを仲介する場合もありますが、その必要性はシステムのサイズと複雑さによって異なります）

あなたの特定の質問について

• 1上記のように、単一のエントリポイントよりも多くのパブリックAPIを公開する場所があると思いますが、public-apiを使用してサービスとしてすべての機能を公開することが正しい方法であるかどうかはわかりません。
• 2＆3あらゆる小さなことを公開することの欠点は、管理のオーバーヘッド、パフォーマンスの低下です（たとえば、これらの呼び出しで認証する必要があります）。オーバーヘッドが実用性以上のナノサービスサービスを利用できます。

• セキュリティについて追加することの1つは、一部のサービスにREST APIがあるという事実は、そのAPIを一般の人々が利用できるようにすることを意味する必要がないということです。展開に関しては、ファイアウォールの背後に保持し、既知のアドレスなどへのアクセスを制限できます。

  • 5いくつかのオーケストレーションモジュールがあっても問題ありませんが、いくつかを超える場合は、オーケストレーションモジュール（およびESBまたはオーケストレーションエンジン）を検討する必要があります。あるいは、イベントベースの統合を使用して、より柔軟なコレオグラフィーベースの統合を取得することもできます（ただし、やや扱いにくい）

  • 6最初のオプションには、開発が簡単で、おそらくパフォーマンスが向上するという利点があります（それが問題になる場合）。ハードコーディングされた統合レイヤーは、時間の経過とともに維持するのが難しくなる可能性があります。erlangサービスを作成した場合、APIの統合とメッセージの受け渡しを維持すれば、書き込みを独立して進化させることができるはずです（幸い、Erlandは、固有の機能（不変性など）によってこれを比較的簡単に実現できます）

Answer 2

費用対効果が高く、変化に敏感な 3 番目の方法を紹介します。明示的にサービスがあるため、アーキテクチャは間違いなくサービス指向である必要があります。ただし、各サービスを RESTful または WSDL 定義のサービスとして公開する必要はありません。私は Erlang の開発者ではありませんが、メッセージングによってローカルおよびリモート プロセスを呼び出し、内部呼び出しの不必要なシリアライゼーション/シリアライゼーション アクティビティを回避する方法があると信じています。しかし、ある日、新しい統合の問題に直面するでしょう。たとえば、会計システムや物流システムを統合することになります。次に、SOA の原則に基づいてアーキテクチャを適切に設計した場合、他のサービスへの既存の接続をリファクタリングする手間をかけずに、RESTful フロントエンド ラッパーを使用して既存のサービスを公開することにほとんどの労力が費やされます。しかし問題は、責任の範囲をきれいに保つことです。つまり、各サービスは、最初に設計されたアクティビティに対して責任を負う必要があります。

あなたが言及したセキュリティの問題は既知の問題です。たとえば、トークンを使用して、公開されているすべてのサービスで認証/承認が必要です。