システムアーキテクチャ設計における高度なスキル・サービス指向アーキテクチャ設計の理論と実践
1. SOA の関連概念
1.1SOAの定義
ソフトウェアの基本原理の定義から、SOA は、明確に定義されたインターフェイスとサービス間のコントラクトを通じて、アプリケーションのさまざまな機能単位 (サービスと呼ばれる)を接続するコンポーネント モデルであると考えることができます。インターフェイスは中立的な方法で定義され、サービスが実装されているハードウェア プラットフォーム、オペレーティング システム、プログラミング言語から独立している必要があります。これにより、このようなさまざまなシステムに組み込まれたサービスが統一された共通の方法で対話できるようになります。
1.2 ビジネスプロセスとビジネスプロセス実行言語
ビジネス プロセスおよびビジネス プロセス実行言語 (ビジネス プロセス実行言語、BPEL)。ビジネスプロセスとは、特定のビジネス目的を達成するために実行されるプロセスまたは一連のアクションを指します。BPEL を使用すると、ユーザーは Web サービスを構成、オーケストレーション、調整することで、上から下までサービス指向アーキテクチャを実装できます。現在、BPELは、既存のWebサービスを統合し、必要な業務プロセスに応じて新たなWebサービスとして編成し、その上で外部から見ると単一のサービスと同等のサービスを構築するために利用されています。
2. SOAの開発経緯
(1)初期段階: XML のこの広範な使用により、組織は文書のメタデータを定義し、企業内および企業間の電子データ交換を可能にし、サービス間およびサービス内でのデータ交換の形式と構造を指定できるようになります。
(2)標準化段階: 国際標準と仕様 - Simple Object Access Protocol (SOAP)、Web サービス記述言語 (Web Service description、UDDI)。
(3)成熟段階: 3 つの強力な仕様 - SCA、SDO、WS-Policy。SCA と SDO は SOA プログラミング モデルの基礎を形成し、WS-Policy は SOA コンポーネント間の安全な対話のための仕様を確立します。
3. SOA とマイクロサービスの違い
(1) マイクロサービスは SOA よりも高度であり、マイクロサービスは独立したプロセスとして存在し、相互に影響を与えません。
(2) マイクロサービスが提供するインターフェース方式は、HTTP RESTful方式など、言語やプラットフォームの制限に関係なく、さまざまな端末から呼び出すことができる汎用性の高い方式です。
(3) マイクロサービスは、インターネット ビジネス シナリオにより適した、分散型および分散型の展開方法を採用する傾向があります。
以下は、SOA アーキテクチャとマイクロサービス アーキテクチャの比較表です。
3. SOA リファレンス アーキテクチャ
IBM の Websphere ビジネス統合リファレンス アーキテクチャは、典型的なサービス中心のエンタープライズ統合アーキテクチャであり、次の 6 つのカテゴリに分類できます。
(1) ビジネスロジックサービス。
(2) コントロールサービス。
(3) 接続サービス。
(4) ビジネスの革新と最適化サービス。
(5) 開発サービス。
(6) ITサービス管理。
4. SOAの主なプロトコル仕様
Web サービス プロトコルに基づいて次のようになります。
(1) UDDI プロトコル: 統一された記述、検出、統合プロトコル。サービスの説明と検出に関する標準仕様が含まれており、これによりビジネス エンティティが相互に検出できるようになり、インターネット上でどのように対話し、グローバル登録アーキテクチャで情報を共有するかを定義します。
(2) Web サービス記述言語 (WSDL) : WSDL は、Web サービスを記述し、Web サービスとの通信方法を説明するために使用される XML 言語です。Web サービスの 3 つの基本属性について説明します。
- サービスが行うこと - サービスによって提供される操作 (メソッド)。
- サービスへのアクセス方法 - サービスと対話するために必要なデータ形式とプロトコル。
- サービスが存在する場所 - URL などのプロトコル関連のアドレス。
この文書の基本的な構造フレームワークは次のとおりです。
(3) SOAP プロトコル: SOAP は、分散環境で情報を交換するための単純なプロトコルであり、XML ベースのプロトコルです。
(4) REST 仕様: 異なるソフトウェアまたはアプリケーションが、どのようなネットワーク環境でも相互に情報を転送できるようにするための仕様です。マイクロサービスは、REST API の形式で呼び出し元に公開されます。RESTful は REST の形式です。これは、設計制約を満たしながら REST 設計のアイデアに従うアーキテクチャ設計またはアプリケーションのタイプの一般用語です。このタイプは RESTful と呼ばれ、リソース表現による状態転送として理解できます。
- リソース: インターネット上でクライアントに公開されるすべてのトランザクションはリソースと見なすことができます。
- リプレゼンテーション: リプレゼンテーションは、Web 上の特定の時点でのリソースのステータスを記述するために REST で使用されます。
- 状態転送: 2 つのタイプに分けられます。
アプリケーション状態- クライアントに保存される、一定期間内のユーザー要求セッション関連情報のスナップショット。
リソース ステータス- サーバーに保存され、特定の時点でのリソース要求表現のスナップショットです。 - ハイパーリンク: ページにリンクを埋め込むことで、他のリソースへの接続を作成します。
5. SOA設計標準要件
(1)文書の標準化。
SOA サービスには、プラットフォームに依存しない自己記述型 XML ドキュメントがあります。Web サービス記述言語は、サービスを記述するための標準言語です。
(2)通信プロトコルの規格。
SOA サービスはメッセージを使用して通信します。メッセージは通常、XML スキーマ (XML スキーマ定義、XSD とも呼ばれます) を使用して定義されます。
(3)アプリケーションの統合登録と統合。
企業内では、SOA サービスは、ディレクター リストの役割を果たすレジストリを通じて維持されます。アプリケーションはレジストリ内のサービスを検索して呼び出します。統一された記述、定義、統合はサービス登録の標準です。
(4)サービス品質 (Qos)。主に以下が含まれます：
- 信頼性: サービス利用者とサービスプロバイダーの間でドキュメントを送信するときの送信特性 (1 回のみ送信、最大 1 回送信、メッセージ フィルタリングの繰り返し、メッセージ配信の保証)
- セキュリティ: Web サービスのセキュリティ仕様は、メッセージのセキュリティを確保するために使用されます。
- ポリシー: サービス プロバイダーは、サービス利用者に特定のポリシーと通信することを要求する場合があります。たとえば、サービス プロバイダーは、特定のサービスを取得するために消費者に Kerberos セキュリティ トークンの提供を要求する場合があります。
- コントロール: SOA では、プロセスは個別のサービスのセットを使用して作成されます。BPEL4WS または WSBPEL (Web Service Business Process Execution Language) は、これらのサービスを制御するために使用される言語です。
- 管理: システム管理者がサービスを効果的に管理できるように、複数の環境で実行されているすべてのサービスを統合した管理システムが必要です。WSDM に基づいて実装されたサービスはすべて、WSDM 企業の管理ソリューションによって管理できます。
6. SOA の役割と設計原則
(1) SOA の主な機能: 情報の孤立を解消し、アプリケーションとリソースをサービスに変換します。そして、これらのサービスを標準サービスに変換して、リソース共有を形成します。
(2) SOA の設計原則には主に次のものが含まれます。
- ステートレス。
サービスリクエスタがサービスプロバイダーの状態に依存することを避けるため。 - 単一インスタンス。
機能の冗長性を避けるために、一貫性の高い実装方法を使用してください。 - 明確に定義されたインターフェイス。
サービスのインターフェイスは WSDL によって定義されます。WSDL は、サービスのパブリック インターフェイスとその内部プライベート実装の間の境界を示すために使用されます。 - 自己完結型のモジュール式。
サービスは、ビジネス内で安定して繰り返し実行されるアクティビティとコンポーネントをカプセル化します。サービスを実装する機能エンティティは完全に独立しており、個別にデプロイ、バージョン管理、自己管理、復元が可能です。 - 粗粒度。
サービスの数は多すぎてはならず、リモート プロシージャ コール (RPC) ではなくメッセージの対話に依存する必要があります。通常、メッセージの量は多くなりますが、サービス間の対話の頻度は低くなります。 - サービス間の疎結合。
サービス利用者に見えるのはサービスのインターフェースであり、サービスの場所、実装技術、現状は利用者には見えない、サービスのプライベートデータはサービス利用者には見えない。 - 相互運用性、互換性、およびポリシー ステートメント。
サービス仕様が包括的かつ明確であることを保証するために、ポリシーを使用して構成可能な相互運用性セマンティクスを定義し、特定のサービスの期待を記述し、その動作を制御します。ポリシー ステートメントを活用して、サービスの期待とセマンティック互換性に関する完全性と明確性を確保します。
7. SOA 設計パターン
7.1 サービスレジストリモード
サービス レジストリは、SOA ガバナンスを推進するサービス コントラクト、ポリシー、メタデータの開発、公開、管理をサポートします。
(1)サービス登録: アプリケーション開発者 (サービス プロバイダーとも呼ばれます) は、その機能をレジストリに公開します。
(2)サービスの場所: つまり、サービス アプリケーションの開発者は、登録サービスをクエリし、独自の要件を満たすサービスを見つけるのに役立ちます。
(3)サービス バインディング: サービスの利用者は、取得したサービス コントラクトを使用してコードを開発し、開発されたコードは登録されたサービスにバインドされ、登録されたサービスを呼び出して対話します。
7.2 エンタープライズサービスバスモデル (EBS)
エンタープライズ サービス バス モデルは、標準ソフトウェア基盤アーキテクチャを提供し、さまざまなプログラム コンポーネントをサービス ユニットとしてプラットフォームに「挿入」し、標準メッセージ通信方式で相互に対話できます。その中心的な機能は次のとおりです。
(1) 位置の透過性を提供するメッセージ ルーティングおよびアドレス指定サービス。プログラム コンポーネントは、互いのルーティングやアドレス指定に注意を払う必要はありません。
(2) サービスの登録やネーミングの管理機能を提供します。
(3) 複数のメッセージング仕様 (リクエスト/レスポンス、パブリッシュ、サブスクライブなど) をサポートします。
(4) 広く使用されているさまざまな伝送プロトコルをサポートします。
(5) 複数のデータ形式とその相互変換をサポートします。
(6) ロギングおよびモニタリング機能を提供します。
以下に示すように、EBS 図は次のとおりです。
7.3 マイクロサービスモデル
マイクロサービス アーキテクチャ大規模な単一のアプリケーションまたはサービスを複数のマイクロサービスに分割するとマイクロサービス アーキテクチャは、ビジネス領域に沿ってサービスを分割します。各サービスは、独立して開発、管理、反復できます。それらは、統一されたインターフェイスを使用して相互に通信し、分散したコンポーネントで展開、管理、およびサービス機能を実現し、製品の提供が容易になります。アプリケーションを効果的に分割し、アジャイルな開発と展開を実現します。マイクロサービス モデルの特徴は次のとおりです。
(1)複雑なアプリケーションの分離: マイクロサービス アーキテクチャは、全体の機能を変更せずに、単一モジュールのアプリケーションを複数のマイクロサービスに分解します。
(2)独立: マイクロサービスは、システム ソフトウェアのライフ サイクルにおいて独立して開発、テスト、デプロイされます。
(3)柔軟な技術選択：マイクロサービスアーキテクチャにおけるシステムアプリケーションの技術選択は分散化されており、各開発チームは自身のアプリケーションのビジネスニーズに基づいて適切なシステムアーキテクチャと技術を選択できます。
(4)フォールトトレランス：各マイクロサービスは互いに独立しており、フォールトは単一のサービスに分離され、システム内の他のマイクロサービスはリトライやスムーズなデグラデーションなどのメカニズムを通じてアプリケーション層のフォールトトレランスを実現でき、それによってサービスのフォールトトレランスが向上します。システムアプリケーション。
(5)疎結合と容易な拡張: マイクロサービス アーキテクチャの各サービスは疎結合であり、マイクロサービス アーキテクチャの柔軟性を反映して、実際のニーズに応じて独立して拡張できます。モノリシック アプリケーション アーキテクチャとマイクロサービス アーキテクチャの概略図は次のとおりです。
7.4 マイクロサービス アーキテクチャ モデル ソリューション
マイクロサービス アーキテクチャ モデルソリューションには主に以下が含まれます。
(1)アグリゲーター マイクロサービス: アグリゲーターはプロセス コマンダーとして機能し、複数のマイクロサービスを呼び出してシステム アプリケーションに必要な機能を実装します。
(2)チェーンされたマイクロサービス: クライアントまたはサーバーがリクエストを受信した後、複数のサービス間でネストされた再帰呼び出しが発生し、処理された応答が返されます。
(3)データ共有マイクロサービス：モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行段階に適しており、複数のマイクロサービスがキャッシュやデータベースストレージを共有するなど、サービス間の強い結合関係が可能です。
(4)非同期メッセージング マイクロサービス: 同期的に実行する必要がない一部のビジネス ロジックでは、REST の代わりにメッセージ キューを使用してリクエストと応答を実装し、サービス呼び出しの応答速度を高速化できます。
モノリシック アーキテクチャとマイクロサービス アーキテクチャは次のとおりです。
7.5 マイクロサービス アーキテクチャが直面する問題と課題
(1)サービスの発見とサービス コール チェーンの追跡が困難になります。
(2)従来のデータベースでは強整合性を実現することが難しく、結果整合性を追求します。
8. SOAアーキテクチャ構築時に注意すべき点
(1)元のシステム アーキテクチャにおける統合要件には、アプリケーション統合要件、端末ユーザー インターフェイス統合要件、プロセス統合要件、および既存のシステム情報統合要件が含まれます。
(2)サービス粒度の制御とステートレス サービスの設計は次のように表現されます。
- サービス粒度の制御: システム全体の外部に公開されるサービスには粗粒度のインターフェイスを使用することをお勧めしますが、エンタープライズ システム アーキテクチャ内では通常、比較的粒度の細かいサービス インターフェイスが使用されます。
- ステートレス サービスの設計: SOA システム アーキテクチャ内の特定のサービスは、独立した自己完結型のリクエストである必要があります。これらのサービスを実装する場合、前のリクエストの状態は必要ありません。つまり、サービスは他のサービスのコンテキストに依存すべきではありません。そして、状態、つまり SOA アーキテクチャのサービスはステートレス サービスである必要があります。
9. SOA実装プロセス
(1) SOAソリューションを主に以下の3つの観点から選定します。
- 全体的な計画を立てることができるプランを選択するようにしてください。
- 選択するときは、企業自体のニーズを十分に考慮してください。
- プラットフォームや実装など技術面からの検証を実施します。
(2)ビジネスプロセス分析は主に以下に焦点を当てます。
- サービスモデルの確立：
トップダウン分解法、ビジネス目標分析法、ボトムアップ分析法。 - ビジネス プロセスの確立:
ビジネス オブジェクト (エンティティ、プロセス、イベントなどのビジネス オブジェクト) を確立し、サービス インターフェイスを確立し、サービス プロセスを確立します。