データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

システムを設計するプロセスは建物を建てるプロセスであり、建築設計の良し悪しが建物の品質に直結します。

システムのアーキテクチャを設計するとき、大規模なシステムのアーキテクチャをどのように開始するか、どこから設計を開始するかなど、常に一連の問題に遭遇します。システムを複数のモジュールに分割する必要がありますか? より合理的にモジュールを分割するにはどうすればよいですか? あるいは、製品によって提示された要件が非常に不合理で、通常のアーキテクチャ設計に完全に影響を与えていると感じているかもしれません。機能以外の要件に注意を払わずに、なんとかやっていけるでしょうか?

アーキテクチャ設計を始めた当初はこれらの問題に戸惑いましたが、システムアーキテクチャ設計を次々と完成させていくうちに、アーキテクチャ設計には守るべきルールやルールがあることが分かり、それを覚えて使いこなせば、継続的な蓄積と沈殿により、完全なアーキテクチャ設計方法論が形成され、新たな大規模システムのアーキテクチャ設計に直面する場合、ステップバイステップかつリズミカルに実行され、最終的に全体のアーキテクチャ設計が完成します。

建築設計の原則

アーキテクチャ設計では、いくつかの原則に従う必要があります。

1. アーキテクチャ設計にはメソッドシステムが必要

建築設計は、建築設計に直接用いられる「単一の手法」ではなく、複数の独自の手法から構成される「手法体系」であり、この体系は新たな技術の発展とともに進化し続けます。

2. 建築設計は疑問によって推進される

建築設計は質問駆動のプロセスです。「要求駆動」に基づいて、建築設計の中間結果に常に疑問を持ち、さらに「質問」を通じてより多くの「品質属性」とより多くの「機能シナリオ」を導入する必要があります。。

3. マルチステージ下のマルチビュー

アーキテクチャ設計、マルチステージまたはマルチビュー? 建築設計はまず「多段階」であり、建築設計を複数の段階に分け、それぞれの段階でのみ「見方」の次元を考慮します。

建築設計の 3 つの段階

ステージ 1. 準備段階

準備段階の目標: 要件を包括的に理解し、要件の特徴を把握し、アーキテクチャ設計の推進力を決定します。

準備段階では、要件を網羅的に整理して理解し、要件の細部を見逃さないようにする必要があります。同時に、要件によって生成されるさまざまな品質属性とシステム制約を分析し、主要なアーキテクチャ属性が見逃されないように、アーキテクチャを設計する際にこれらの制約を考慮します。

フェーズ 2. 概念アーキテクチャ

概念的なアーキテクチャでは、機能、品質、制約を含む要件のあらゆる側面を考慮する必要があります。

フェーズ 3: アーキテクチャの改良

アーキテクチャの改良段階では、5 つの異なる視点から 5 つのビューを設計し、システム全体の包括的な設計を完了しました。

建築設計の貫徹

非機能要件の検討:非機能要件は、設計プロセス中に新たな要件が発見され続けるため、一朝一夕に解決できるものではなく、設計が完了しても、開発段階で非機能要件に影響を与える制約が発生します。したがって、このフェーズ全体を通じて、非機能要件に注意を払う必要があります。

準備段階のアーキテクチャ分析

アーキテクチャを準備する最も重要な目標は、需要の全体像を確立し、需要の特性を把握し、アーキテクチャ設計の推進力を決定することです。要件の詳細な分析を通じて、システムの品質要件と制約によってシステム設計に課せられる制約も考慮しながら、要件をマクロに認識します。

要件の構造化

需要は分散した需要点ではなく構造化されており、分析された需要を構造化することによってのみ需要全体を巨視的に把握することができます。ADMEMS 2 次元マトリックスを使用して、アーキテクチャに影響を与える要因を分類できます。

例えば、次のようなマトリックス分析では、要件を多次元に分割し、「一般機能」「品質」「制約」の3つの側面から横断的に分析します。、商品の特徴や担当者に直接聞いてください。品質の次元とは、システムが基本的なニーズを満たしながら、その後のシステムの進化や極端なシナリオ (たとえば、：ユーザー数の急増、フラッシュセール）待つ満足感。制約とは、起動日、起動環境、開発者のスキルレベルなど、システム設計時のいくつかの制限です。保守レベルは「業務レベル要件」、「ユーザーレベル要件」、「開発レベル要件」の3つに縦に分かれており、「業務レベル要件」とは製品や業務担当者から提示される基本的な要件を指し、「ユーザーレベル要件」は「ユーザーレベル要件」を指します。システムから導き出される「レベル要件」は、ユーザーの視点からはユーザーのコンピュータの操作レベルやユーザーの使用習慣などの潜在的なニーズを発見し、「開発レベルのニーズ」は研究開発担当者の視点からは拡張性や、テスト容易性、技術環境、その他のさまざまな側面のニーズ。

要件を構造化することで、要件全体を総合的に分析して要件全体を把握することができると同時に、システムの制約を多角的に発見し、システム設計の最初の段階から漏れのない設計を行うことができます。大きな制約があり、アーキテクチャ設計の失敗。

制約の影響を分析する

制約分析のいくつかの側面:

1. 製品または運用担当者からの拘束力のある要件

システムの非機能要件（オンライン時間、予算、工期要件など）

ビジネスルールやビジネス上の制限、関連する法律、特許などのビジネス領域に関連する制限。

2.ユーザーからの拘束力のある要件

システムのユーザーには、ユーザーのコンピュータレベル、年齢層、使用方法、国などの制限的な要件もあります。

たとえば、ユーザーのコンピュータスキルが一般的に弱い場合、開発時の対話方法は複雑すぎないようにする必要があり、同時にユーザーがシステムをハングアップさせないようにシステムの堅牢性も考慮する必要があります。。

ユーザーが製品を使用するときの外部環境によっても制約が生じる場合があり、たとえば、アクセス環境がイントラネットか外部ネットワークかによって、リンクにアクセスするためにシステムが提供するさまざまなネットワーク権限が決まります。アクセス環境の信号強度が低い場合、システムのパフォーマンス要件は高くなります。

3.開発担当者または運用保守担当者からの拘束力のある要件

開発チームの技術レベルや統合度によってもシステム開発は制限されますが、開発者全員が上級研究開発担当者であり、現在の技術スタックを深く理解していれば、開発の進捗はより速くなります。開発に介入する前にテクノロジースタックを学習する必要がある場合は、構築期間やシステムリスクの観点から追加の考慮を行う必要があります。

4.業界の現在の技術環境

現在の技術環境におけるミドルウェアの成熟度、プログラミング言語と人気、長所と短所などはすべて、アーキテクチャ設計に制約を課します。

制約の分類:

1. 直接拘束

例: システムは Linux プラットフォームで実行されます。

2. 制約を機能要件に変換する

このような制約については、機能要件に直接変換できます。

例: サプライヤーは独自の都市情報テーブルのセットを持っています -> 導き出される機能要件: 都市の変換が必要です

例: サプライヤーのサーバーのパフォーマンスが低く、最大 tps は 10 -> 結果として生じる機能要件: 電流制限リクエストが必要です

3. 制約を品質属性要件に変換する

例: システムユーザーのコンピュータスキルが高くない

品質属性に変換: 使いやすさ (そうでないと使用されない)、堅牢性 (システムが麻痺する)

重要な品質を決定する

システムの主要な品質にはトレードオフの関係があり、業務担当者がどの点に注意を払うべきかを確認したり、ニーズを満たすためにどの点が必要でどの点を無視してもよいかを判断する必要があります。

まず、アーキテクチャがどの品質属性のサポートに重点を置いているかを決定し、次に、矛盾する品質属性の間でトレードオフを行う必要があります。たとえば、パフォーマンスの品質属性が満たされると、新しいソリューションやコンポーネントの導入により保守性やテスト容易性が低下し、拡張性が向上すると、システムのパフォーマンスやセキュリティに影響が生じます。私たちが行う必要があるのは、さまざまな主要な品質の間でトレードオフを行うことです。

主要な機能を特定する

主要な機能の 4 つの側面を特定する

1. コア機能

2. 必ずやるべき機能

3. リスクの高い機能

4. 独自の機能

他の一般的なシステムには存在しない機能

派生した要件に注意してください。

要件から設計に移行する際、ソリューション策定プロセスの複雑さにより、多数の派生要件が生成され、派生要件は元の要件の数倍になります。

例：

元の要件: サプライヤーデータを定期的に取得する。

派生要件:

1. サプライヤーの数が多いため、分散スケジュールされたタスクとクラスターの同時プルを導入する必要がある

2. サプライヤーのデータが大量にあるため、個別のデータベースとテーブルの設計が必要です。

3. 迅速な検索、ストレージエンジンコンポーネントの導入などを行う必要がある。

これらの派生要件を考慮する必要がありますが、ビジネス要件は反映されていないものの、アーキテクチャ設計に影響を与える重要な要素が欠落しています。

アーキテクチャドライバーの比較:

ビジネス要件がアーキテクチャを推進します:

重要な需要主導型のアーキテクチャ:

このことから、主要な要件によって駆動されるアーキテクチャを通じて、より重要な部分を考慮することができ、設計されたアーキテクチャが要件をよりよく満たすことができ、アーキテクチャ設計が成功する確率が高くなることがわかります。

概念アーキテクチャ段階分析

概念アーキテクチャの段階では、細部にこだわることなくシステムを適切に分解します。

概念アーキテクチャのプロセスは、最初に主要な機能に基づいて予備設計を実行し、次に設計されたシステムを高レベルで分割し、次に非機能要件 (主要な品質と制約) を検討して、予備設計を修正します。このサイクルが続き、疑問と最適化のプロセスで、アーキテクチャ設計が改善されます。

初期デザイン

予備設計の目的は、詳細設計に入らずに責任を明らかにすることです。主要な機能に基づいて予備設計を実行し、メインプロセス、キープロセス、ゴールデンプロセスなどに基づいてフローチャートの設計を実行して、責任を見つけます。

高レベルのセグメンテーション

複雑なシステムを複数の二次システムに分割します。または、特定のサブシステムに直接分割されます。

高レベルのセグメンテーションには 2 つの方法があります。

1. システムのセグメント化

セグメンテーションの考慮事項には、システム機能、導入環境、言語、システム規模などが含まれます。

たとえば、大きなシステムは、注文、製品、サプライチェーン、その他のシステムに分割されます。

2. システム内のセグメント化

システムの責任、呼び出し関係、汎用性などに基づいてシステムの内部セグメント化を実行します。

最も一般的なのは階層化であり、たとえば、システムはゲートウェイ層、サービス層、検索モジュール、マンターミナルなどに分割されます。

レイヤーアングル

1. 論理的な階層化

論理階層化では、責任の分割が非常に重要視されます。責任は多くの場合、上位層と下位層の関係に直接関係します。上位層と下位層は、異なるマシン上に分散することも、同じマシン上に分散することもできます。

2. 物理的なレイヤリング

さまざまなマシンに分散されたソフトウェアユニット。

3. ユニバーサルレイヤリング

汎用性の異なるものは階層に分かれており、一般に汎用性が高いほどレベルが低くなります。

非機能要件を考慮する

具体的な方法は、目標シナリオ決定テーブルを使用することです。次の図を参照してください。

アーキテクチャ設計は疑念によって引き起こされます。たとえば、システムの可用性に疑問があり、システムがダウンしている可能性があることを考慮すると、クラスタ展開設計を導入します。ダウンストリームインターフェイスがタイムアウトする可能性や例外が発生する可能性があることを考慮すると、クラスタ展開設計を導入します。インターフェイスの劣化などを考慮した設計を導入します。

シーンで考慮すべき 5 つの要素

1. 影響源（それがシステムの内部から来るのか、システムの外部から来るのか）

2. 影響

3. 影響を受けるオブジェクト

4. 問題や価値観は何ですか?

5. 環境は何ですか?

シナリオのトレードオフ:

価値、コスト、開発難易度、発生確率。シナリオによっては、総合的に検討した結果、サポートされない場合があります。すべてのシナリオをサポートする必要はなく、サポートしない場合は過剰設計になる可能性があります。

詳細なアーキテクチャ段階の分析

論理ビュー

論理ビューは、システムのさまざまな部分の責任の分割です。さまざまな責任に応じて、システムを複数のサブシステムに細かく分割できます。

階層化された洗練

システム設計のニーズに応じて、システムの層を細分化できます。たとえば、プレゼンテーション層 -> ビジネス層 -> データ層を、プレゼンテーション層 -> 制御層 -> インターフェース層 -> インターフェース実装に細分化できます。レイヤー -> データレイヤー。

パーティションの導入

パーティショニングの概念はビジネスプロセスに関連しています。パーティショニングの基礎は:責任です。たとえば、決済プロセスをパーティションとして使用したり、注文プロセスをパーティションとして使用したりできます。システムを複数のパーティションに分割すると、並行開発がサポートされるだけでなく、システムを複数のサブドメインに分割できるため、ビジネス概念とビジネスプロセスの収束にも役立ちます。

機構抽出

メカニズムとは、パブリックツール、パブリックコンポーネント、パブリックプロセスなど、抽象化できるシステムのパブリック部分を指します。これらのパブリック部分を抽出することは、アーキテクチャ設計にとって重要です。

サブシステムを分割するための原則:

1. 異なる責任を持つユニットが異なるサブシステムに分割される

2. 汎用性の異なるユニットを異なるサブシステムに分割

3. 異なる開発スキルを必要とするユニットは作業負荷を考慮して異なるサブシステムに分割され、大きすぎるシステムはさらに分割されます。

展開図

アーキテクチャビューを作成する作業は、独立して作成する「ソースプログラム」、再利用可能なライブラリ、フレームワークなどの「プログラム単位」に「論理的責任」をマッピングすると同時に、開発テクノロジの選択、開発言語、開発ツールなど、さらにプログラム単位、プロジェクト分割、ディレクトリ構造、コンパイルの依存関係などの間の関係を確立する必要もあります。

実行ビュー

実行アーキテクチャ設計の作業内容は、プロセス、スレッドなどのどの制御フローを導入するかを決定し、各制御フローのタスクを決定し、作成、破棄、通信メカニズムなどの関連する問題にも対処します。制御フロー間、制御フロー間の同期関係、リソース競合の有無、ロックの必要性なども考慮する必要があります。

物理的な見方

物理アーキテクチャ設計の 3 つのタスク

1. ハードウェアの選択と物理トポロジ

2. ソフトウェアとハードウェアのマッピング関係

3. 計画の最適化

考え方のポイント：「オーバーヘッド」と「競合」が核心となり、競合を回避し、オーバーヘッドを削減する必要がある。

データビュー

データビューはシステムのデータストレージ設計です。システムの分析に基づいて、1 つ以上のデータ戦略が決定されます。6 つの一般的なデータ分散戦略は次のとおりです:

1. 独立したスキーマ

システムアプリケーションごとに異なるデータスキーマが使用され、データは完全に独立しているため、一般に、明確な境界を持つ異なるシステムでこの方法を使用できます。

2.集中する

異なるシステムアプリケーションが同じデータベースを使用します。一般に、関連付けられた属性を持つアプリケーションでこの方法を使用できます。たとえば、システムがサーバー側と管理側に分かれていても、両方が同じシステムに属している場合、同じデータベースを使用できます。

3.パーティション

水平パーティション

水平パーティショニングは、一般的なテーブルパーティショニングスキームであり、スキーマがデータボリュームの要件を満たせない場合、スキーマを複数のパーティションに分割し、各パーティションにデータの一部を保存することができます。

垂直パーティション

垂直パーティショニングはパーティショニング戦略の別の側面であり、単一のデータベースで大量のデータを保持できない場合は、データの種類に基づいて垂直パーティショニングを実行することもできます。

4. コピー

複数のデータベースが同じデータを保存し、確立された更新戦略に従って異なるデータベース間でデータの同期を確保します。一般的に、読み取りライブラリと書き込みライブラリを分離することがこのソリューションです。メインライブラリは書き込み機能を提供し、スレーブライブラリは読み取り機能を提供します。このうち、スレーブライブラリのデータは、メインデータベースのデータに基づいて同期されます。

5. サブセット

一部の特殊なシナリオの要件に従って、元のデータの一部を保存する必要があります。たとえば、application1 はすべての注文を保存し、application2 は後続の分析操作のために正常に発行された注文の一部のみを必要とします。データビューのデザイン。

6. 組織再編

複数の異なるアプリケーションをデータソースとして使用し、データ分析やその後のプロセスでの使用のために他のアプリケーションに対して異種混合を使用します。

要約する

アーキテクチャ設計の 3 つの段階: 予備アーキテクチャ段階、概念アーキテクチャ段階、詳細アーキテクチャ段階

アーキテクチャ設計の 4 つの要素: 要件の構造化、制約の影響の分析、重要な品質の決定、主要な機能の決定

概念アーキテクチャの 3 つのステップ: 主要な機能に基づく予備設計、システムの高レベルのセグメント化、非機能要件の分析

洗練されたアーキテクチャの 5 つのビュー: 論理ビュー、開発ビュー、運用ビュー、物理ビュー、データビュー

スルーリンク: 非機能要件の考慮

参考文献

1.「ファーストラインアーキテクチャ設計ガイド」

著者: JD Retail 馮暁涛

出典：JD Cloud Developer Community 転載の際は出典を明記してください

建築設計で良い仕事をするにはどうすればよいですか?建築設計で従うべきルールはありますか? | JDクラウド技術チーム