サービス指向アーキテクチャ（設計）とその応用について
まとめ：
2017年5月に同社の「データセンター管理システム」プロジェクトの開発に参加し、システムのアーキテクチャ設計を担当するシステムアーキテクトを務めました。同システムは、全国に点在する同社のデータセンターにある機器の状態や情報を一連の通信プロトコルでサーバーに送信し、サーバーで解析・処理した後、機器の動作指示にフィードバックしたり、通知情報をサーバーに送信したりすることを目的としている。管理担当者、そして最終的には端末の監視とすべてのデバイスの管理を実現します。このペーパーでは、データセンター管理システムを例として、プロジェクトにおけるソフトウェア アーキテクチャ スタイルの選択と適用について説明します。システム全体は、データ抽象化とオブジェクト指向、パイプライン/フィルター、ルールベースのシステムとプロセス通信の 4 つのアーキテクチャ スタイルを組み合わせたアプリケーションを選択してプロジェクトを完成させ、端末によるすべてのデータセンターの統合管理を効果的に実現します。時間は、アーキテクチャ スタイルの適切な選択を証明し、アプリケーションはシステムのパフォーマンス、可用性、その他の指標を期待された目標に達成します。2018年11月に受付完了後、プロジェクトが正式に開始され、納品・安定稼働を続けており、社内からの受賞やユーザーからの賞賛をいただいております。
(交換ノート 345092496 へようこそ)
文章：
背景とプロジェクトの概要:
2016 年 7 月、チャイナ テレコムは、インテリジェンスの時代に適応し、ネットワーク インテリジェンス、ビジネス エコロジー、運用インテリジェンスの推進に重点を置き、インテリジェンスの時代に適応し、業界をリードするモノのインターネット向けのオープン プラットフォームを構築する 3.0 戦略を提案しました。そして、強力なモノのインターネット機能アプリケーション サービスを顧客に提供し、顧客のビジネス プロセスを再構築し、ビジネス価値を掘り起こし、運用コストを削減します。同社はグループ戦略を実行する一方で、長年にわたる事業の継続的な拡大により、同社は徐々に全国に複数のデータセンターを建設してきました。単独、つまりデータセンターごとにデータセンターを設計し、管理システムを構築し、状態監視、イベント処理、データレポートを担当する管理者を配置します。データセンターが継続的に増加し、地理的に広範囲に分散しているため、従来のスタンドアロン モードを使用し続けると、多くの人的および物的リソースが増加します。
全データセンターの設備をいかに一元管理し、管理コストを削減し、人的・物的支出を削減するかが、同社にとって喫緊の課題となっている。当社は長年データセンター機器の生産、モジュール設計、機器管理、関連ソフトウェア開発に従事しており、豊富な経験を持っており、社内各部門リーダーとの協議の結果、開発部門が責任を負うことが決定しました。データセンター管理システムの開発に。会社は 12 名と 3 人のシステム実装者からなるソフトウェア開発チームを設立し、私をプロジェクトのシステム アーキテクトとして任命し、ソフトウェア アーキテクチャの設計と開発を担当しました。
慎重に検討した結果、システムは 4 つの主要モジュールに分割されます。デバイス アクセス モジュールは、ゲートウェイ デバイスと直接対話するモジュールであり、ゲートウェイ デバイスとのメッセージ対話を担当します。メッセージ処理モジュールは、デバイスの受信メッセージとビジネス層の処理結果を、それぞれによって認識および処理される; カスタムに従ったルール モジュール ルールは、対応するメッセージの処理結果をフィードバックし、メッセージを永続化する; ビジネス モジュールには、システム管理、デバイス管理、ネットワーク コンポーネント管理、通知管理、ルール管理、ログ管理やその他の機能。
遷移：
アーキテクチャ設計の初めに、開発するすべてのモジュールの特性を分析しました。システム内のモジュールの数が多いため、各モジュールの開発言語、アーキテクチャ スタイル、実行標準が異なる場合がありますが、各モジュールが統一的かつ共通の方法で相互作用し、全体の標準化を確実に満たすために、疎結合、システムの粒度の粗さ サービスや移植性などさまざまな要素を考慮した結果、サービス指向のアーキテクチャ設計を採用してシステムを開発することにしました。この記事では、最初に SOA の主要な技術と標準、および各技術と標準の具体的な内容を説明し、サービス指向アーキテクチャを使用してシステムを開発する方法について説明し、最後にサービス指向コンポーネントで発生する問題と解決策について説明します。プロジェクト開発プロセス中のアーキテクチャと個人的な認識。
口論：
技術紹介:
サービス指向アーキテクチャ (SOA) は、明確に定義されたインターフェイスとサービス間のコントラクトを通じて、アプリケーションのさまざまな機能単位 (サービスと呼ばれる) をリンクするコンポーネント モデルです。インターフェイスは中立的な方法で定義され、サービスを実装するハードウェア プラットフォーム、オペレーティング システム、プログラミング言語から独立している必要があります。これにより、さまざまなシステムに構築されたサービスが統一された共通の方法で対話できるようになります。SOA と密接に関連するテクノロジーには、主に UDDI、WSDL、SOAP があります。このうち、UDDI (Unified description, Discovery, and Integration) は、サービスの公開、検索、検索の方法を提供するサービスの登録仕様であり、主にデータモデル、API、登録サービスの 3 つの内容から構成されます。記述言語）は、サービス実装定義とサービス インターフェイス定義を含む XML ベースの構文定義のセットを持つサービス記述言語であり、SOAP（Simple Object Access Protocol）は、サービス要求者とサービス プロバイダー間のメッセージ送信仕様を定義します。SOAP は XML を使用してメッセージをフォーマットし、HTTP を使用してメッセージを伝送します。データ交換とリモート プロシージャ コールは、SOAP アプリケーションを通じてネットワーク内で実行できます。SOAP には主に、カプセル化、エンコード ルール、RPC、バインディングの 4 つの部分が含まれます。
SOAの主な実装方法にはWebService、ESB、サービスレジストリがありますが、今回はWebServiceを利用してSOAを実現します。この手法では、サービス提供者、サービス依頼者、サービス登録センターの3つの重要な役割があり、具体的な構築プロセスと課題、導入効果について以下に説明します。
プロジェクトを結合します:
サービスプロバイダーは主に、サービスの設計、記述、定義、リリースを完了します。ビジネスの分析・整理を通じて、粗粒度、疎結合、自己完結型の特性を総合的に考慮してサービスを設計します。同時に、過剰な通信トラフィックやサービス間の頻繁なやり取りを避けるために、サービスの数は可能な限り削減されます。設計後、デバイス アクセス、メッセージ処理、ルール フィードバック、ビジネス分析の 4 つの主要なサービスが事前に抽出されます。このうち、デバイス アクセス サービスはゲートウェイ デバイスと接続されており、ゲートウェイ デバイスとのメッセージ対話を担当します。メッセージ処理サービスは、ゲートウェイ デバイス アクセス サービスとビジネス分析サービスの間で入力メッセージを処理および変換して、出力を生成します。ストリーム; ルール フィードバック サービスは、頻繁に使用されるメッセージに対するフィードバックと対応する操作を自動的に実行します; ビジネス分析サービスは、システム管理、デバイス管理、ネットワーク コンポーネント管理、通知管理、ルール管理、ログ管理などを担当します。
サービス登録センターは、サービス プロバイダーとサービス要求者の間のリンクであり、サービス プロバイダーはここでサービスの説明を公開し、サービス要求者はここで必要なサービスを見つけます。サービス レジストリは場合によってはオプションの役割ですが、レジストリの存在により、サービス プロバイダーとサービス コンシューマがさらに分離される可能性があります。システム内のサービスの疎結合と相互独立性を確保するために、このプロジェクトではアーキテクチャ設計にこのテクノロジーが使用されており、登録センターには、デバイス アクセス、メッセージ処理、ルール フィードバック、ビジネス分析の 4 つの公開サービスが含まれています。情報には主に、サービス機能の説明、パラメータの説明、インターフェイス定義、およびその他の関連コンテンツが含まれます。
サービス リクエスタ。サービス リクエスタはサービス コンシューマであり、サービスはサービス レジストリを通じて検索、バインド、および呼び出すことができます。システムの主なプロセスは、設備情報の収集と業務結果のフィードバックです。データセンター管理システムは、サービス登録センターを使用して、対応するサービス インターフェイス、パラメーター、および戻り値を取得し、動的バインディングを実現します。デバイス情報収集段階では、デバイスはデバイス アクセス サービスを通じてメッセージ処理サービスにメッセージを送信し、メッセージはフォーマット変換後にルール フィードバックまたはビジネス分析に送信されます。ビジネス結果フィードバック フェーズでは、ビジネス分析サービスまたはルール フィードバック サービスが、メッセージ処理後に処理結果をデバイスに送信します。サービスコール中、要求者はサービスプロバイダーの業務処理や技術実装を意識する必要がなく、自社の業務のみに集中すればよいため、開発プロセスが簡素化され、作業効率が向上します。
結論：
このプロジェクト開発の全体的な観点から見ると、SOA アーキテクチャの使用によりモジュール間の結合度が低減され、システムのパフォーマンス、使いやすさ、変更可能性などの指標が向上し、企業の予想される要件を満たし、システムの二次開発を迅速に行うことができます。後の段階とデータアクセス。しかし、システム開発の過程で、SOAPはXML通信をベースとしているため通信効率が低く、メッセージが爆発的に増加すると大量のメッセージが滞り、フィードバックが発生するため解決が間に合わないという問題が発生しました。シーケンス要件が厳しいため、この問題を解決するために、柔軟なルーティング、フォールト トレランスの優れたメッセージ ミドルウェア RabbitMQ を追加し、ハードウェアの組み合わせソリューションをアップグレードすることにしました。
今回のプロジェクトが順調に進んだことで、システムのアーキテクチャ設計の重要性をより深く理解することができ、経験も積みましたが、同時に自分のアーキテクチャ設計にまだまだ至らない点があることも分かりました。このプロジェクトの経験を要約し、次のプロジェクトではより良い結果を出せるように努めます。