I.はじめに
アーキテクチャ設計は、実装プロセスに応じて、エンジニアリング アーキテクチャ、ビジネス アーキテクチャ、デプロイメント アーキテクチャなどの複数の次元に分けることができ、優れたシステム アーキテクチャ標準には、拡張性、保守性、信頼性、セキュリティ、および高性能の特性が備わっている必要があります。これらの機能は誰もがよく知っていますが、私たちはこれらの機能をアーキテクチャ設計に組み込むために、これらの要件を達成するための重要な道筋を知りたいと考えています。この方法によってのみ、システムが将来のビジネスの成長と配信効率に確実に適応できるようになります。この記事では、エンジニアリング アーキテクチャの設計を実行する方法に焦点を当てます。
2. 価値を第一に
計画に曖昧な点がある場合には、製品（商品）価値の観点から計画を精査し、決定することが非常に重要です。
テクノロジーが陥りやすい 2 つの誤解:
新規参入者は拒否されません。プロダクト マネージャーによって提起されたニーズはすべて合理的であり、私にはそれらを完了する責任があります。
テクノロジー主導: この種のテクノロジーの実装は特に独創的であり、製品の機能をテクノロジーの実装に適応させることができます。
上記の 2 種類の誤解は、製品価値に対する研究開発の理解に容易に逸脱をもたらす可能性があり、その後の技術的反復に容易に破壊的な影響を与える可能性があります。製品 (商業) 価値の観点から見ると、コラボレーションに関係するすべての関係者が平等な観点から問題を検討できるため、合意形成が容易になるだけでなく、ビジネスの進化とテクノロジーの反復をより適切に計画することもできます。
ソフトウェアも製品であり、システムの設計時には、市場、組織、リソースなどのいくつかの生産要素も中心に展開します。
市場は当社の製品のターゲットであり、当社の建設システムの基盤です。
組織は、製品配送プロセスにおけるリソースの調整と保証メカニズムを中心にしています。
リソースとは、製品に投資される機械、人員、時間、操作などの生産資材です。
ソフトウェア開発は、インプットとアウトプットの比率 (ROI) を中心とした生産および管理活動です。拡張性、保守性、信頼性、セキュリティ、高性能はすべて当社製品の特徴であり、各機能を実現するには多大な投資が必要です。
スポーツカーのスピードは最も顕著な特徴ですが、道路状況への適応性、乗り心地、運転の安全性は犠牲になります。
オフロード車のハイライトは道路状況への適応性ですが、これにより速度と快適性が犠牲になります。
自動車は道路状況への適応性、乗り心地、運転の安全性、運転速度の相対的なバランスを実現しており、一般的な交通手段となっています。
「将軍は向かっているのであって、子うさぎを追うのではない」ということわざがあるように、常にトレードオフが存在します。完璧で複雑なシステムを構築することは求めませんが、限られた条件の中で卓越性を追求することは可能です。
3. アーキテクチャ設計
アーキテクチャ パターンは、ソフトウェア システム内のさまざまなコンポーネント間の関係、責任、対話方法を記述し、それによってソフトウェア設計に仕様と制約を提供し、ソフトウェアの生産効率を向上させます。それは主に次の 2 つの側面に反映されます。
開発者がソフトウェア システムをより適切に整理および設計できるように支援します。
チーム間のコラボレーションとコミュニケーションを促進し、チームメンバーが仕事を理解し、分担しやすくします。
3.1 エンジニアリングフレームワーク
新しいシステムは、多くの場合、ディレクトリ構造、構成ファイル、コード テンプレートなどのエンジニアリング上の制約を含む、プロジェクトの基本的なエンジニアリング フレームワークの構築から始まります。これらは主に、プロジェクトの構造、責任の境界、コード スタイルを標準化するために使用され、それによってコードの品質とコードの品質が向上します。メンテナンス性。具体的には次の側面が含まれます。
各モジュールの依存関係と対話方法が合意されています。
インターフェース対話プロトコルを標準化する。
統合された例外のコーディング、キャプチャ、および処理。
ログの出力形式を標準化します。
その他の公的規範の制約。
以下に、最も一般的に使用される階層化アーキテクチャと DDD アーキテクチャに関する実践的なアイデアをいくつか示します。
3.1.1 階層化アーキテクチャ
階層化アーキテクチャには、MVC、ヘキサゴナル アーキテクチャなど、さまざまな形式があり、ビジネスやテクノロジーの発展とともに徐々に進化しました。
インターネットの初期には、コンピューターのハードウェアのパフォーマンスの低さ、ネットワークの速度の遅さ、ストレージのコストの高さなどの制限により、インターネット製品の形式は比較的単純で、単純なポータル Web サイトや単純なポータル Web サイトなどの比較的単純な製品のみでした。 BBSフォーラムが実現できるかもしれない。当時の技術アーキテクチャには階層化の概念はなく、ASP、JSP、PHPなどのスクリプト言語が主に使用されており、これらのスクリプトにHTML、JavaScript、CSS、SQLを混在させて記述することが非常に一般的でした。ファイル。インターネット技術の発展と、より複雑なビジネスのオンライン化に伴い、動的スクリプト言語の欠点が徐々に明らかになってきました。JSP スクリプト言語を例に挙げると、次のようになります。
複雑さ: JSP スクリプト言語の開発と保守は、Java コードと HTML コードの混合に対処する必要があるため、より複雑です。
セキュリティ: JSP スクリプト言語は SQL インジェクション攻撃などのセキュリティ脆弱性に対して脆弱であり、システムの不安定性や攻撃を引き起こします。
スケーラビリティ: Java コードは HTML ページに直接記述する必要があり、システム構造が不明確になるため、スクリプト言語のスケーラビリティは比較的制限されています。
上記の問題を解決するために、Spring や Struts などのさまざまなフレームワークが登場しています。これらのフレームワークは徐々に JSP スクリプト言語に取って代わり、階層化アーキテクチャの概念も提案しました。これらの中で最も典型的なのは MVC (モデル、ビュー、およびコントローラー) アーキテクチャ パターンです。その主な目的は、アプリケーションのさまざまな部分を分離して、保守と拡張を容易にすることです。具体的な実装は以下の通りです。
関心事の分離: アプリケーションを 3 つの主要な部分に分割すると、各部分を独立して開発およびテストできるため、関心事がより適切に分離されます。
保守性の向上: 関心事項が 3 つのレベルで分離されているため、アプリケーションのさまざまな部分の保守と変更が容易になります。
スケーラビリティの向上: 表示ロジックとビジネス ロジック制御が分離され、アプリケーションのさまざまな部分を拡張しやすくなります。
マルチレイヤー アーキテクチャでは、ビュー レイヤーは通常、テンプレート ベースのフレームワーク (Thymeleaf、Freemarker、Velocity など) または別のテクノロジ スタック (Vue.js、React など) を使用します。これらのテクノロジーの進化により、金融保険や電子商取引のシナリオなど、より複雑な問題を解決できる可能性がありますが、次のような新たな問題点ももたらすでしょう。
急峻な学習曲線: MVC アーキテクチャ パターンでは、開発者が複数の概念とテクノロジを理解して習得する必要があるため、学習曲線は急峻です。
複雑さの増加: MVC アーキテクチャ パターンではアプリケーションを複数の部分に分割する必要があるため、アプリケーションの複雑さが増加します。
開発時間の増加: より多くのテストと統合作業が必要となり、開発時間が増加します。
製品の提供効率を向上させ、技術的な敷居を下げるために、現代の研究開発作業は通常、フロントエンド開発、バックエンド開発、品質テスト、運用保守保証などを含む複数のポジションに分割されています。これらの役職は、製品の研究開発タスクを完了するために協力する必要があります。複数の事業部門と複数の役職間の秩序あるコラボレーションを確保し、プロセスのリスクを効果的に管理および制御するために、通常はプロジェクト管理役職が存在します。
MVC アーキテクチャはビジネス実装全体の焦点を分離しますが、より複雑で大規模なプロジェクト、特に複数人のコラボレーションや複数サービスの並列処理のシナリオでは、MVC アーキテクチャが無力であるように見えることがよくあります。現時点では、タスク リソースの大きな競合を発生させずに複数のビジネス ラインの並列処理を実現するには、より細かい粒度で分割する必要があります。もちろん、ビジネス シナリオが異なれば分割モードも異なります。最も一般的な分割モードは、次の図に示すように、マルチレイヤー アーキテクチャ モードです。
水平階層型アーキテクチャを通じて、研究開発における分業と協業を実現し、あらゆる経験上の制約がここに反映されます。上の図では、制御層が 2 回再分割されています。実際のアプリケーションシナリオに応じて再調整することもできます。たとえば、Web モジュールが RPC モジュールに依存できるかどうかを POM ファイルで制限できるため、全員が既存のプロジェクト契約に従って開発作業を実装できます。
各モジュールの階層化の役割を簡単に説明します。
データ アクセス層: ビジネス ロジック層とデータ ストレージ層の分離は、モデル層のカテゴリに属します。基盤となるデータ ソース (MySQL、Hbase、EleasicSearch) と対話します。一般的なフレームワークには、MyIbatis、Hibernate などが含まれます。
リモート呼び出し層: DAO 層と並行するデータ アクセス層である RPC 層。違いは、サードパーティのインターフェイスまたはプラットフォーム サービスを介してアクセス機能を提供することです。DAO 層との違いは、データの所有権とドメイン トランザクションの制御です。
トランザクション管理層: 一般業務処理層とも呼ばれ、次の特徴があります。
◦上位事業では、複数業態の統一受注生産能力、汎用分散トランザクション一貫性ソリューション等の事業・技術共有力が低下。
◦下位層に依存し、DAO層とRPC層の機能を組み合わせて、単一ビジネスのトランザクション管理を実現します。
単純なビジネス システムの場合、マネージャー層の責任をサービス層に置き換えることができます。
4.ビジネス ロジック層: 比較的特殊なビジネス ロジック サービス層。主にビジネス プロセスの組み立てと配置を担当し、実際の柔軟性と拡張性が主にここに反映されます。
5.リクエスト処理層:主にアクセス制御の転送、入力パラメータの形成、出力パラメータのカスタマイズなど。その責任は各端末またはサードパーティのサービスプロバイダーと直接向き合うことです。
6.オープン サービス層: 外部に提供される RPC サービスを定義します。機能的責任は Web 層の責任と同様です。ゲートウェイのセキュリティ制御やフロー制御などの要素も考慮する必要があります。
7. 端末表示層：各端末のテンプレートレンダリングと実行表示、Velocity、React、IOSモバイル端末など。
従来のソフトウェア設計では、さまざまなコンポーネント間の結合が密になることが多く、コードの保守や拡張が困難になります。ヘキサゴナル アーキテクチャ パターンはレイヤード パターンの変形であり、ビジネス ロジックをフレームワークやライブラリなどの技術的な詳細から分離することで疎結合設計を実現し、コードの保守と拡張が容易になります。同時に、六角形のアーキテクチャ パターンは、開発者が単体テストと統合テストをより適切に実装できるようにすることで、ソフトウェアの品質を向上させることもできます。これは、次の図に示すように、さまざまなテクノロジーベースのビジネス シナリオで非常に役立ちます。
3.1.2 DDD アーキテクチャ
ドメイン駆動設計（DDD）とは、ビジネスドメインに焦点を当てたソフトウェア開発手法であり、ビジネスドメインの知識を深く理解することで、ビジネスロジックをドメインモデルにカプセル化し、より優れたコードの保守性と保守性、拡張性、再利用性を実現します。
DDD は緩やかな階層構造に属しており、各層の責任と機能は次のとおりです。
ユーザー インターフェイス層: Web リクエスト、RPC リクエスト、MQ メッセージなどの外部入力リクエスト。
アプリケーション層: オーケストレーション、転送、検証などを担当します。大量のビジネス ロジックを格納する MVC のサービス層とは異なります。
ドメイン層: ビジネス概念、ビジネスステータス、ビジネスルールを表現する役割を担うモデル層。エンティティ、値オブジェクト、集計 (集計ルート)、ドメイン サービス、ドメイン イベント、倉庫、工場などを含む、このフィールドのすべての複雑なビジネス知識の抽象化とルール定義が含まれます。
インフラストラクチャ層: メッセージ通信、一般的なツール、構成など、ドメイン モデルの永続化メカニズムとその他の一般的な技術サポート機能を提供します。
DDDの人気は年中衰えることがないのに、実際のシステム開発現場では、本格的に導入されているプロジェクトが少ないのはなぜでしょうか。言い換えれば、MVC アーキテクチャ スタイルのシステムは非常に一般的ですが、DDD アーキテクチャ スタイルのシステムはほとんど見られません。これは DDD 自体に遡る必要があります。DDD は、複雑なビジネスを解決するためのソフトウェア開発方法論です。
共通の CRUD 業務システムもこのモデルに従って実装すると、システムの複雑さが増大します。一般に、DDD モードは次のシナリオに適用できます。
複雑なビジネス ロジック シナリオの処理をサポート: アプリケーションが複雑なビジネス ロジックを処理する必要がある場合、DDD はビジネス ロジックをドメイン モデルにカプセル化することで、ビジネス要件とビジネス プロセスをより適切に反映し、システム アーキテクチャの複雑さを軽減します。
高度に保守可能でスケーラブルなシナリオ: DDD はアプリケーションを複数のサブドメインに分割し、それぞれが独自のドメイン モデルを持つため、ビジネスの複雑さをより適切に管理できます。
迅速な反復と配信が必要なシナリオ: 各サブドメインは個別に開発、デプロイ、拡張できるため、チームはアプリケーションを迅速に反復して配信できます。
ビジネスの複雑さを評価するには、ビジネス プロセス、製品ルール、データ構造、需要の変化の頻度など、複数の側面を考慮する必要があります。一般に、この開発パターンの実装では次の課題に直面するため、このアーキテクチャ パターンの採用には慎重な評価が必要です。
ビジネスドメインを深く理解する必要がある: DDDはビジネスドメインを中心とした設計手法であるため、ビジネス要件を満たすドメインモデルを設計するにはビジネスドメインの知識を深く理解する必要があります。
部門間のコラボレーションが必要: DDD の実装には、ビジネス担当者、開発者、テスターなどを含む部門間のコラボレーションが必要であり、全員が協力して合意に達する必要があります。
技術的な難易度が高い: DDD は、ドメイン イベント、集約ルート、ドメイン サービスなど、多くの複雑な概念を理解する必要があり、開発者には一定の技術レベルが必要です。
要するに、チームのコラボレーションモード、個人の技術的能力の要件、ビジネス上のコンセンサスなど、あらゆる面で大きな課題があります。ただし、これは DDD が通常のビジネス システムでは役に立たないという意味ではありません。複雑な問題を解決するためのそのアイデアは、今でも私たちに恩恵をもたらしてくれます。CQRS フレームワーク、イベント駆動型アーキテクチャ、マイクロサービス フレームワークなど、一般的に使用されるツール フレームワークにはすべて DDD 設計アイデアの影があります。
マイクロサービス アーキテクチャを例として、まず次の質問を検討してください。
マイクロサービスはどのように設計すべきでしょうか?
マイクロサービスを分割する根拠は何ですか?
マイクロサービスはどのように境界を分割するのでしょうか?
マイクロサービスを細かく分割しすぎるとサービスが増えて運用管理の難易度が上がり、粗すぎると機能結合度が高く、柔軟性やスケーラビリティに不足が生じます。したがって、これはより難しい質問です。
ビジネスとアプリケーションの境界を決定することが、マイクロサービスのジレンマを解決する鍵となります。DDD はビジネス境界の問題を非常にうまく解決し、ビジネス ドメインの範囲を分割するための方法論を提供します。
マイクロサービスとは、アプリケーションを複数のサブドメインに分割し、各サブドメインがその機能をマイクロサービスの形で外部に公開することです。マイクロサービスは、ドメインの範囲内で複雑なビジネス プロセスとルールを制限します。つまり、独自のドメイン モデルとデータ ストレージを内部に実装します。アプリケーション層の観点から見ると、これによりドメイン サービスの実装が標準化および統一され、コード ロジックが大幅に簡素化され、ビジネスの複雑さがより適切に管理されます。
3.2 テクノロジーの選択
エンジニアリング アーキテクチャの構築には、基本的なフレームワークに加えて、さまざまな基本的なミドルウェアの選択、いわゆるテクノロジーの選択も重要な部分があります。技術選定の際に注意すべきポイントを事例をもとにお伝えします。
3.2.1 ビジネス要件
ビジネス要件を理解し、システムの機能、パフォーマンス、セキュリティ、将来の拡張要件を明確にします。
例: システム モジュールを分割する場合、一部のシステムは [WEB] + [JSF マイクロサービス] 2 セットのアプリケーションに分割されて個別にデプロイされますが、一部のシステムは 1 つの [WEB] アプリケーションのみをデプロイします。その中間の判断基準は何でしょうか？逆アセンブルされた[JSFマイクロサービス]の機能は何ですか?
機能の再利用: マイクロサービス層は、より一般的なモデル設計と、複数のビジネス シナリオを再利用するための強力な機能を備えています。サービス運用のプロセスにおいては、業務に応じて垂直展開が可能であり、
リソースの分離: ビジネスごとに垂直に展開され、ネットワークやマシンなどのハードウェア リソースをより洗練された方法で最適化できます。一方で、上位層の WEB アプリケーションと下位層のマイクロサービス間のリソース分離により、より洗練されたリソース割り当てを実現することもできます。
要約すると、サービスが複数端末の多重化とリソース操作を必要としない場合は、展開を分解してコール リンクとマシン リソースへの複数の投資を増やす必要はありません。それどころか、サービス分割のメリットはさらに大きくなります。
3.2.2 技術的特徴
使いやすさ、パフォーマンス、セキュリティ、拡張性、保守性などの側面を含む、さまざまなテクノロジーの特性を評価します。
例: 基盤となるストレージ層が db4o (オープンソースのオブジェクト指向データベース) を使用しているシステムに遭遇したことがありますが、このミドルウェアには多くの利点があります。
オブジェクトを保存することでデータに直接アクセスします。
データベース サーバーは必要ありません。必要なデータ ファイルは 1 つだけです。dll のサイズは 300k を超えるだけです。
SQL を使用しなくても、操作が簡単で強力なデータ クエリ。
ただし、ここでの使用はお勧めできません。分散クラスター サービスであり、このデータベース ファイルは 1 台のマシンにのみ保存できるためです。つまり、最も致命的な単一障害点の問題が存在します。場合によっては、同様の欠陥を補うために、より多くのコストが必要になる場合があります。逆に、組み込みデータベースとして使用し、一部のシングルチップマイコンに適用すると、その利点が発揮されます。
3.2.3 コミュニティサポート
活発なコミュニティがあるかどうか、多数のドキュメントやチュートリアルがあるかどうか、成熟したサードパーティ ライブラリがあるかどうかなど、テクノロジのコミュニティ サポートの程度を考慮してください。
例: 分散スケジューリング フレームワークでは、tbschedule が比較的早くからオープンソース化されましたが、オープンソース化されてから長い間誰も保守しませんでした。通常の業務で軽く使用され、アプリケーション層が十分に監視されている場合には、大きな問題にはなりません。 。ただし、基本的なミドルウェアとして広く使用されている場合、スケジューリング プロセスの可観測性、zk 再接続メカニズム、およびスケジューリング例外の自動回復の観点から、早急にアップグレードして最適化する必要があることは明らかです。しかし、現実にはコミュニティはすでに維持を停止しており、それは厄介なことです。
3.2.4 チームスキル
チームのスキル レベルに基づいて適切なテクノロジを選択し、過度に複雑なテクノロジや馴染みのないテクノロジは避けてください。これは非常に重要です。そうしないと、後のメンテナンスコストと反復効率の向上が大きな問題になります。
例: COBOL 言語は、1970 年代に金融業界で広く使用されていたプログラミング言語です。大量のデータや複雑な計算を処理でき、高い信頼性とセキュリティを備えています。2015 年までは、世界の銀行システムの 43% と ATM の 95% も稼働していました。
しかし、2023年3月に日本は、銀行システムCobol全体をJAVA言語に変換する計画を発表した。その理由は、この古代言語に精通した技術者が非常に不足しており、Cobol エコシステムが機械学習やクラウド統合などの新しい開発に追いつけないためであり、システム全体のメンテナンス コストと反復効率は現代の JAVA エコシステムよりもはるかに低いです。 。
3.2.5 費用対効果
開発コスト、運用保守コスト、ライセンス料など、さまざまなテクノロジーの費用対効果を評価します。
利用可能な成熟したオープンソース プラグインがある場合は、車輪を再発明するのではなく、それらを使用してみる必要があります。
他のチームが完了したタスクについては、再利用できるかどうかを検討する必要があります。
例: 現在のテクノロジー ミドルウェアのほとんどは JDK8 以降のサポートを必要とするため、テクノロジーを選択する際には、適切な JDK バージョンを考慮する必要があります。Spring Boot 3 のリリースにより、デフォルトでサポートされる JDK バージョンは 17 になり、JDK8 はサポートされなくなりました。新しいシステムの場合は、新しいバージョンを選択する方が適切と思われます。既存システムの場合、新技術を当たり前に追求するのではなく、新たなバージョンアップがシステム変革のコストとそれによってもたらされるメリットに見合ったものであるかを検討する必要があります。
3.2.6 リスク評価
テクノロジーの成熟度、セキュリティの脆弱性、依存関係など、さまざまなテクノロジーのリスクを評価します。
例: Fastjson はオープン ソースの JSON 解析ライブラリであり、JSON 形式の文字列を解析でき、Java Bean の JSON 文字列へのシリアル化、および JSON 文字列から JavaBeans への逆シリアル化をサポートします。実行効率が高く、応用範囲が広いのが特徴です。ここ 2 年間、テクノロジーの選択には注意が必要ですが、その理由は、過去 2 年間で頻繁にセキュリティ上の脆弱性が露出しており、脆弱性を修正するために依存アプリケーションを頻繁に更新する必要があるためです。これは表面上だけであり、より深い理由は、技術を選択する際に考慮しなければならない要素である安全性の保証の欠如です。
3.2.7 概要
技術的なソリューションを選択する際には、最新の話題のテクノロジーにこだわる必要はなく、ビジネス ニーズやチームのスキル余力など、複数の要素を総合的に考慮して、最適なソリューションを選択することをお勧めします。もちろん、刻々と変化するビジネスニーズや技術開発動向に適応するためには、タイムリーな技術評価とアップデートを意識することも必要です。
4. 規範的合意
コンセンサスの重要性は、チームメンバー間で一貫したコミュニケーションと理解を確保することです。仕様やプロセスを策定することで、作業の重複やミスを減らし、矛盾や誤解を避けることができ、研究開発の効率と品質の向上につながります。
4.1 データの階層化
4.1.1 オブジェクトの変換
層状アーキテクチャでは、層間に相互依存性と参照があり、データはパラメータ オブジェクトを介して渡されます。各層の内部構造の安定性を確保するためには、耐食設計を行う必要があります。これが、高い凝集性と低い結合性を実現する鍵となります。
例: モデル レイヤーのテーブルには 20 個のフィールドがあり、対応する PO オブジェクトには 20 個の属性があります。ただし、端末表示層は 10 個のフィールドを表示するだけでよく、リクエスト処理層（Web）がデータを取得する際に PO オブジェクト全体を返す必要はなく、このときこの 10 個だけで DTO オブジェクトを使用できます。属性を使用して結果をリクエスト処理層に渡し、サーバーのテーブル構造と一部の機密データが公開されないようにします。
データ腐食防止設計の一般的な方法は、各レイヤーで独自のデータ構造を定義することです。
VO (View Object): ビュー オブジェクト。主にインターフェイスに表示されるデータ オブジェクトに対応します。
DTO (Data Transfer Object): データ転送オブジェクト。主にリモート呼び出しなど、多数の転送オブジェクトが必要な場所で使用されます。
DO (Domain Object): ドメイン オブジェクトは、現実世界から抽象化された有形または無形のビジネス エンティティです。
PO (永続オブジェクト): 永続オブジェクト。永続層 (通常はデータベース) のデータ構造と対応するマッピング関係を形成します。
実際の開発においては便宜上、サービス層ごとに独自のデータオブジェクトを定義する必要はなく、実情に応じて柔軟に対応できます。たとえば、いくつかの単純なビジネス シナリオでは、DO レイヤー オブジェクトをスキップして、PO オブジェクトを VO オブジェクトに直接変換できます。
4.1.2 オブジェクトの再利用
長期間にわたって反復されてきたシステムでは、一部のオブジェクトのスコープが制御不能になるという問題が発生しやすくなります。その典型的な特徴は次のとおりです。
入力オブジェクトの場合、複数のメソッドが共有されるため、属性値の定義を調整すると影響範囲が広く、リスクも高くなります。
Map コンテナを独自のサービスの入力または出力オブジェクトとして直接使用します。コンテナ内にどれだけのコンテンツがあるかは誰もわかりません。
オブジェクト定義には、類似した属性定義が複数あります。新しい要件が発生した場合、リスクを軽減するために、単に新しい要件を定義するだけです。
オブジェクトのスコープの制御不能な問題は、システム全体の安定性と反復効率の大幅な低下につながります。この問題は通常、無意識のうちに進行するゆっくりとした累積的なプロセスです。システムの大幅な調整が行われると、その欠点が表面化することがよくあります。
このような問題を解決するには、次の側面から始めることができます。
予防策: アーキテクチャを設計するときに明確な仕様定義を与えます。
発見: 設計とコードのレビューを定期的に実施し、問題を発見したら適時に修正します。
ストップロス: このようなシステムが発見された場合は、継続的な破損を防ぐためにマイクロリファクタリングを検討する必要があります。
レビュー: システムをタイムリーに定期的にレビューし、適切な進化を奨励し、欠陥を指導し、良好な技術的雰囲気を醸成します。
4.2 例外管理
4.2.1 例外のキャッチ
例外キャプチャでは、メソッドごとの try-catch と、1 つのメソッド内に複数のグループが存在するという 2 つの極端な状況に陥りやすいです。もう 1 つは、リンク全体に Try-Catch がなく、ストリーキング状態にあることです。では、どうやって例外をキャッチするのでしょうか? まず例外をキャッチする目的を見てみましょう。
例外の事前判定処理により、プロセスの続行が可能になります。
問題を迅速に発見して特定し、システムの安定性を確保します。
例外処理の目的に基づいて、対応する処理戦略も明確になります。
プロセスを続行するには、例外を対応するノードでキャッチして処理する必要があります。
問題を迅速に見つけて特定する場合は、コール エントリで統合キャプチャ処理を実行できます。例外スタックには例外の詳細な理由が記録されます。
つまり、例外をキャッチする必要がありますが、どこでどのようにキャッチするかは目的に応じて柔軟に対応できます。
4.2.2 例外の処理
ビジネスおよびシステムの例外は、将来の問題の特定や統計分析を容易にするために、ログやメッセージなどの痕跡を残す必要があります。
さまざまな例外を定期的にエンコードすることで、問題を迅速に特定し、緊急計画の設定を容易にすることができます。ルールは HTTP 要求応答のエンコードを参照できます。
例外スタック情報を出力します。これは、問題の原因を迅速に特定するための重要な手段です。
システムの健全性状態の特定を容易にするための長期的な統計と異常データの比較。
4.3 ログ管理
ログ フレームワークを統合します。SLF4J ログ ファサード フレームワークを使用し、特定の実装には Log4j2、Logback などを選択することをお勧めします。
ログの出力形式、出力場所、出力レベル、出力方法（非同期印刷）などを含むログ フレームワークを設定します。
異なるレベルを使用して、異なる種類の情報を記録し、異なるファイルに出力します。
ディスク容量を過剰に消費しないように、ログ ファイルを定期的にチェックしてクリーンアップしてください。
必要に応じて、ログ情報を他のシステムに送信したり、分析および処理したりして、システムの監視と管理を改善できます。
必要に応じて、ログ レベルを動的に調整する機能を構築します。
4.4 監視と管理
システム パフォーマンスの監視: システムの CPU、メモリ、ディスク、ネットワーク、その他のリソースの使用状況、およびアプリケーションの実行ステータスを監視します。Nagios、Zabbix など。
ログ監視: システムとアプリケーションのログ情報を監視し、traceId とビジネス ID ID を導入し、異常な状況を適時に検出します。ELK (Elasticsearch、Logstash、Kibana) など。
セキュリティ監視: システムとアプリケーションのセキュリティ状態を監視し、潜在的なセキュリティ脅威を適時に検出します。Snort、Suricata など。
業務監視：業務システム、訪問量、応答時間、エラー率などの各種指標を監視し、業務の異常をタイムリーに発見します。グラファナ、プロメテウスなど。
コール リンクの追跡: 分散システム全体でリクエストのコール リンクを追跡し、各サービス ノードの処理時間とステータスを記録し、この情報を集約して完全なコール リンク グラフを形成することで、問題の分析とトラブルシューティングを容易に行うことができます。例: ジップキン、スカイウォーキング。
監視と早期警告: さまざまな監視ツールは、問題を迅速に特定するのに役立つ効果的な方法です。そもそも問題を発見するには、効果的な早期警告および連絡メカニズムを改善することが不可欠です。電子メール、企業 WeChat、SMS、電話など。
4.5 協調的な合意形成
4.5.1 すべての HTTP サービス リクエストは POST を使用しますか?
最近、私たちのアプリに問題が発生しました。場合によっては、サービス呼び出しが「HTTP 414 URI Too Long」応答エラーを返すことがありました。この問題の根本的な原因は、Tomcat のデフォルトの get リクエストの長さ制限 (リクエスト行とリクエスト ヘッダーを含む) が 8192 文字を超えていることです。この問題を解決するには、いくつかのオプションがあります。
この制限を緩和するには、server.xml ファイルの Connector 要素の maxHttpHeaderSize 属性値を変更します (例: 16384)。
POST リクエスト メソッドにはこのサイズ制限がないため、サービスのリクエスト プロトコルを GET メソッドのみのサポートから POST リクエスト メソッドも同時にサポートするように調整します。
ヘッダーリクエストパラメータを簡素化し、Cookie とビジネスパラメータの書き込みを標準化および制限します。
解決策 1 の Tomcat のコンテナ制限を拡張することは短期的には可能であるように見えますが、これは公的な問題であり、数千のアプリケーション コンテナの調整が必要になる可能性があり、永久的な解決策ではなく一時的な解決策です。
2 番目のオプションは、POST リクエスト メソッドを同時にサポートするようにすべての GET リクエスト メソッドを調整することですが、これには数百のアプリケーションが関係しており、作業負荷はかなり大きくなります。
解決策 3 のヘッダー リクエスト パラメーターの合理化は、最も合理的かつ安全であり、問題の本質的な原因でもありますが、2 つの APP 間の相互作用や、数十個のアプリの共同ソートと変換が含まれる場合、これも非常に困難です。何百もの部門。
あなただったら、どのように解決策を選択しますか?
4.5.2 フロントエンドはロジック処理を行わず、データのレンダリングのみを行いますか?
フロントエンドの観点: APP バージョンのリリースにはバージョンのレビュー、ユーザーによるダウンロードと更新などのプロセスが含まれるため、サイクルが長い一方で、ユーザーがアップグレードを拒否する可能性があります。このため、フロントエンドの研究開発では「フロントエンドはビジネスロジックの処理は行わず、データのレンダリングのみを行う」というスローガンが打ち出されるようになりました。ビジネスロジックの処理をフロントエンドが請け負う場合、一方でバグが発生すると修正に多大なコストがかかり、ユーザーがバージョンアップしないと修正することもできません。一方で、フロントエンドがビジネス ロジックの一部を引き受ける場合、バックエンドとの責任の境界を明確に区別することが難しくなり、コラボレーションの隠れた危険が埋もれてしまいます。
バックエンドの観点: デフォルトの背景画像、プロンプト コピー、フォントの色... これらの調整されない予測可能なデータをすべて送信する必要がありますか? データの複雑さが増し、ネットワーク帯域幅が増加します。さらに、フロントエンドにもホットアップデート技術があり、変更が容易な複雑なページもH5で実現できるのに、簡単なビジネスロジックをなんとかできないものか！
プログラムはどのように選べばよいのでしょうか？
4.5.3 概要
多くの技術的問題の解決策には、その時の環境や立場に応じて明らかな偏りはありません。たとえば、HTTP GET リクエスト パラメーターが長すぎる問題に対する最も合理的な解決策は、ヘッダー パラメーターを簡素化することですが、これには長期的な取り組みが必要であり、短期的には達成が困難です。したがって、現在の問題を解決する場合、他の 2 つのオプションを検討できます。同様に、ビジネス ロジックをフロントエンドで処理するかどうかについては、APP の位置付けと、フロントエンドとバックエンドの基本的な機能の構築を考慮する必要があります。良いソリューションを判断する基準は、現在の問題を低コストで解決でき、新たな問題を引き起こさないことです。
V. まとめ
この記事では、システム エンジニアリング アーキテクチャを構築する際に注意する必要があるいくつかの重要な側面について詳しく説明します。製品の価値に基づいて決定を下してください。そして、システム エンジニアリング アーキテクチャの進化、技術的ソリューションの選択、システム仕様の合意形成に始まり、実装プロセスにおける一般的な問題の解決策を提供します。最後に、結びの言葉として『ランガ・スートラ』の「月の指に印を付ける」を借用し、読者の皆さんに「それは謙虚な意見で月を指差すようなものだが、月を眺めても月は見えない」と共有します。その指。その名前を覚えている人には私の真実が見えないでしょう。」
-終わり-