ソフトウェア アーキテクチャ スタイルの選択について
まとめ：
2017年5月に同社の「データセンター管理システム」プロジェクトの開発に参加し、システムのアーキテクチャ設計を担当するシステムアーキテクトを務めました。同システムは、全国に点在する同社のデータセンターにある機器の状態や情報を一連の通信プロトコルでサーバーに送信し、サーバーで解析・処理した後、機器の動作指示にフィードバックしたり、通知情報をサーバーに送信したりすることを目的としている。管理担当者、そして最終的には端末の監視とすべてのデバイスの管理を実現します。このペーパーでは、データセンター管理システムを例として、プロジェクトにおけるソフトウェア アーキテクチャ スタイルの選択と適用について説明します。システム全体は、データ抽象化とオブジェクト指向、パイプ/フィルター、ルールベースのシステムとプロセス通信の 4 つのアーキテクチャ スタイルを組み合わせてプロジェクトを完成させ、端末によるすべてのデータセンターの統合管理を効果的に実現します。アーキテクチャ スタイルの適切な選択が証明され、アプリケーションによってシステムのパフォーマンス、可用性、その他の指標が期待される目標に到達します。このプロジェクトは2018年11月の受付完了後に正式にスタートし、納品・安定稼働を続けており、社内からの受賞やユーザーからの満場一致の賞賛をいただいております。
(交換ノート 345092496 へようこそ)
文章：
背景とプロジェクトの概要:
2016 年 7 月、チャイナ テレコムは、インテリジェンスの時代に適応し、ネットワーク インテリジェンス、ビジネス エコロジー、運用インテリジェンスの推進に重点を置き、インテリジェンスの時代に適応し、業界をリードするモノのインターネット向けのオープン プラットフォームを構築する 3.0 戦略を提案しました。そして、強力なモノのインターネット機能アプリケーション サービスを顧客に提供し、顧客のビジネス プロセスを再構築し、ビジネス価値を掘り起こし、運用コストを削減します。同社はグループ戦略を実行する一方で、長年にわたる事業の継続的な拡大により、徐々に全国に複数のデータセンターを建設してきました。つまり、データセンターごとに管理システムが設計され、システムの状態監視、イベント処理、データレポートを担当する管理担当者が配置されます。データセンターが継続的に増加し、地理的に広範囲に分散しているため、従来のスタンドアロン モードを使用し続けると、多くの人的および物的リソースが増加します。
全データセンターの設備をいかに一元管理し、管理コストを削減し、人的・物的支出を削減するかが、同社にとって喫緊の課題となっている。当社は長年データセンター機器の生産、モジュール設計、機器管理、関連ソフトウェア開発に従事しており、豊富な経験を持っており、社内各部門リーダーとの協議の結果、開発部門が責任を負うことが決定しました。データセンター管理システムの開発に。会社は 12 名と 3 人のシステム実装者からなる開発チームを設立し、私をプロジェクトのシステム アーキテクトとして任命し、ソフトウェア アーキテクチャの設計と開発を担当しました。
慎重に検討した結果、システムは 4 つの主要モジュールに分割され、各モジュールに適切なアーキテクチャ スタイルが選択されます。デバイス アクセス モジュールは、ゲートウェイ デバイスに接続されているモジュールであり、ゲートウェイ デバイスとのメッセージ対話を担当します。このモジュールは、データ抽象化とオブジェクト指向アーキテクチャ スタイルを採用しています。メッセージ処理モジュールは、デバイスの受信メッセージと処理結果を変換します。ビジネス層の識別と処理の形式はパイプライン/フィルター アーキテクチャ スタイルを採用し、ルール モジュールはカスタム ルールに従って対応するメッセージの処理結果をフィードバックし、メッセージの永続化を実行します。ルールベースのシステムを採用しており、ビジネス モジュールにはシステム管理、デバイス管理、ネットワーク コンポーネント管理、通知管理、ルール管理、ログ管理などの機能が含まれており、このモジュールはプロセス通信アーキテクチャ スタイルを採用しています。
遷移：
アーキテクチャ スタイルは、現場の多くのシステムに共有される構造的および意味論的な特性を反映しています。適切なアーキテクチャ スタイルは、システムの開発全体を満たす制約を提供することができます。したがって、開発の開始時に適切なアーキテクチャ スタイルを選択することが非常に重要です。建築設計。本稿では、まず一般的なアーキテクチャ スタイルの種類と各アーキテクチャ スタイルの意味を紹介し、データ抽象化とオブジェクト指向、パイプライン/フィルタ、ルールベースの 4 つのアーキテクチャ スタイルを使用してデータセンター管理システムを実装することを選択した理由について説明します。システムとプロセスのコミュニケーションについて説明し、最後に、このプロジェクトの開発中に遭遇した問題と解決策、および私の個人的な洞察について説明します。
口論：
技術紹介:
建築スタイルは、建築要素の役割と機能、およびそのスタイルに従う建築で許可される要素間の関係を制限する一連の協調的な建築上の制約です。一般的なソフトウェア アーキテクチャ スタイルは、主にデータ フロー スタイル、コール/リターン スタイル、独立コンポーネント スタイル、仮想マシン スタイル、ウェアハウス スタイルの 5 つのカテゴリに分類されます。このうち、データフロー形式には、各ステップが独立して処理され、順次実行されるバッチシーケンスやパイプライン/フィルターアーキテクチャ形式があり、単純な線形処理に適しています。コール/リターン スタイルには、メイン プログラム/サブルーチン、データ抽象化、およびオブジェクト指向の階層構造アーキテクチャ スタイルが含まれており、これによりシステムの結合がさらに軽減され、システム レベルが明確になります。独立したコンポーネント スタイルには、プロセス通信とイベント ドリブン アーキテクチャ スタイルが含まれており、そのコンポーネントの特性によりソフトウェアの再利用がサポートされます。仮想マシン スタイルには、インタプリタとルール ベースのシステム アーキテクチャ スタイルが含まれており、柔軟性が高く、ルールをカスタマイズできます。ウェアハウス スタイルには、データ中心のデータベース アーキテクチャ スタイルと黒板アーキテクチャ スタイルが含まれます。
プロジェクトを結合します:
デバイス アクセス モジュールはデータ抽象化とオブジェクト指向アーキテクチャ スタイルを採用しており、デバイス アクセス モジュールの中心機能はゲートウェイ メッセージを受信することであり、MQTT アクセス、TCP 透過送信、HTTP アクセス、CoAP などの多くのゲートウェイ デバイス アクセス方法があります。アクセス メーカーやデバイスによって採用されているアクセス方法は異なります。データ抽象化とオブジェクト指向アーキテクチャ スタイルは、デバイス アクセス操作をインターフェイスとしてカプセル化し、アクセス メソッドとゲートウェイ メッセージをモジュール内のオブジェクトとしてカプセル化するという要件を満たしています。この構造スタイルのカプセル化、相互作用、ポリモーフィズム、統合、および再利用の特性により、デバイス アクセス インターフェイスが統一され、各オブジェクトの属性が変更されないため、デバイス アクセスの柔軟性が向上します。
メッセージ処理モジュールはパイプライン/フィルタアーキテクチャ形式を採用しており、デバイスアクセスモジュールから入力されたメッセージを順次処理・変換して出力ストリームを生成し、入力ストリームとしてビジネス層に渡され、処理結果が入力されます。ビジネス層からのデータは順次処理され、処理と変換の後、出力ストリームが生成され、入力ストリームとしてデバイス アクセス モジュールに渡されます。パイプライン/フィルターのアーキテクチャ スタイルに沿って、記録方法の変更、データの増分変換などによってデータを変換するプロセス。
ルール モジュールはルール ベースのシステムを採用しています。ルール モジュールは、頻繁に受信するメッセージや頻繁に使用される操作に合わせて、ルール セット、ルール インタプリタ、およびルール/データ セレクタをカスタマイズします。ルールは正しいロジックであり、ルール フローを通じて自動的に実行されます。フィードバックと対応する操作により、メッセージ処理モジュールとビジネス モジュール間の結合度が低減され、システムの高パフォーマンスと高同時実行性が実現されます。
ビジネスモジュールはプロセスコミュニケーションアーキテクチャスタイルを採用しており、ビジネスモジュール内のコンポーネントは独立したプロセスであり、コネクタはメッセージ送信です。システム管理、デバイス管理、ネットワークコンポーネント管理、通知管理、ルール管理、ログ管理などの各管理をコンポーネントとみなすことができ、各コンポーネントは独自の独立した機能を持ちます。ネットワークコンポーネント管理者は、デバイス送信プロトコルに対応するネットワークサーバーを作成し、管理者にフィードバックメッセージを送信するように管理者に通知します。同時に、各コンポーネントは、メッセージ送信を通じてビジネス モジュールの機能を実装します。たとえば、デバイス管理コンポーネントのドライバーは、ネットワーク コンポーネント管理のネットワーク サーバーに登録メッセージを送信することでデバイスとの接続を確立し、通知管理コンポーネントは、通知メッセージをネットワーク サーバーに送信し、管理に転送します。また、プロセス通信アーキテクチャ スタイルにより、モジュール内のコンポーネント間の結合が軽減され、変更可能性が向上します。
結論：
このプロジェクト開発の全体的な観点から見ると、アーキテクチャ スタイルを適切に選択すると、モジュール間の結合度が減少し、システム パフォーマンス、使いやすさ、変更可能性、その他の指標が向上し、企業の予想される要件を満たし、システムの二次開発を迅速に行うことができます。後の段階の開発とデータ アクセス。しかし、システム開発の過程では、デバイスの数が多いため、ID を使用してデバイスを識別すると、データの視覚化が不十分になり、デバイスの位置を特定することが困難になるといういくつかの問題が発生しました。このため、私は経度および緯度の測位とデバイス ID の識別を組み合わせて使用し、Echarts+VUE を使用してデータを取得し、Baidu マップをベースとして使用してすべてのデバイスを視覚的に表示します。これは迅速な測位に便利です。次に、多数の制御層コードとリレーショナル データベースの永続層間の相互作用により実行速度が低下するため、効率を向上させるために、キャッシュとして Redis と Elasticsearch 検索エンジンを追加しました。システムの複雑さは増加しましたが、 、データ アクセス速度が大幅に向上しました。大幅な改善です。
このプロジェクトが無事に完了したことで、私はプロジェクトの建築スタイルの選択においてより多くの経験を積むことができましたが、同時に、建築スタイルの選択におけるいくつかの欠陥も明らかになりました。