システムアーキテクチャとは何ですか（アーキテクチャ）
デザインは、ルックアンドフィールだけでなく、動作方法も含まれます。 - スティーブ・ジョブズ
システムアーキテクチャとソフトアーキテクチャはIT分野では一般的な用語であり、アーキテクチャの設計はソフトウェアシステム構築プロセスの非常に重要な部分です。
システムアーキテクチャが重要なのはなぜですか？一般的な建築パターンは何ですか？[Code Gebyte]をフォローして、さまざまなアーキテクチャー設計で使用されるさまざまな設計哲学を理解してください。
一般的なアーキテクチャパターンを見てみましょう：クライアントサーバー、ピアツーピア、MVC、階層化、分散クラスター、マイクロサービス、偶数ソース、六角形、それらを 1つずつ倒します。
アーキテクチャは、アーキテクチャの本来の意味であり、実際、ソフトウェアアーキテクチャの概念はアーキテクチャから派生しています。建築とは、建物の設計と建設に関連する芸術と技術の統合です。建築は工学技術と人文科学にまたがる分野です。建物の利用可能なスペース、高く評価できるイメージ、スペースを取り巻く一連の問題、およびイメージの確立、調整、美化の方法を研究します。そして、その研究の目的は建物自体だけではなく、より重要なこととして、建物に対する人々の要件とそれらをどのように満たすかを研究し、エンティティをゼロから構築するプロセスにおける対応する計画、設計、実装を研究することです。
建築は、建物の計画、設計、実装を研究します。ソフトウェアアーキテクチャは、ソフトウェアの計画、設計、実装を研究します。
アーキテクチャ設計では、アプリケーションシステムは、ビジネス、テクノロジー、組織、柔軟性、スケーラビリティ、保守性などの要因に応じてさまざまな部分に分割されているため、これらの部分が分業し、互いに協力して特定の要件を完了することができます。 。アーキテクチャは、システム実現の全プロセスを通じて実行され、ソフトウェアシステム実現の主要なリファレンスであり、ソフトウェアシステム実現の青写真です。ソフトウェアシステムの計画、設計、および実装は、アーキテクチャの設計に従って編成および実装されます。
システムアーキテクチャが重要な理由
ムーアの法則を知っています。コンピューターハードウェアの容量は、2年ごとに約2倍の速度で成長しています。ただし、ソフトウェア開発プロセスにはそのような高速化プロセスがなく、開発コストは削減されていません。システムアーキテクチャの設計方法論と設計モードは常に変化しており、この重要なプロセスはまだ完全に信頼できる万能ソリューションではありません。どうして？ソフトウェア開発プロセスの特別な問題は何ですか？次の点があります。
複雑
ソフトウェアは、人間が作成する最も複雑なタイプのシステムと言えます。ソフトウェアのさまざまなモジュール間には、さまざまな明示的または暗黙的な依存関係があり、システムの成長とモジュールの増加に伴い、これらの関係の数は幾何学的な割合で増加することがよくあります。これらの複雑さを理解して使用する人々は、それほど変わっていません。
不可視
ソフトウェアエンジニアはソースコードを直接見ることができますが、ソースコードはソフトウェア自体ではありません。さらに、静的なソースコードと実行中のシステムは異なり、ソフトウェア動作環境の複雑さもソフトウェアシステムの予測不能性を高めます。ソフトウェアシステムを簡単に説明することはできません。設計ドキュメント、説明、フローチャート、およびアーキテクチャ図は、複雑なソフトウェアシステムをわかりやすく説明するためのものですが、システムの全体像を完全に説明することはできません。
変更可能性（変更可能性）
ソフトウェアの変更は簡単に思えます。ハードウェアを変更するよりもソフトウェアを変更する方がはるかに簡単です。また、そびえ立つ建物を変更するよりもソフトウェアシステムを変更する方がはるかに簡単です。したがって、人々は当然、ソフトウェアシステムが将来の変化に適応することを期待しています。しかし、変化は複雑であり、環境も複雑であり、これらの複雑な状況は、変更が容易なものをますます困難なものにします。
適合
ソフトウェアシステムは独立して存在することはできず、常にハードウェア上で実行され、常にシステム内の他のコンポーネントの要件、およびユーザーと業界の要件に従います。
ソフトウェアシステムの上記の特性により、システムアーキテクチャの設計が特に重要になります。システムアーキテクチャ設計は、次の方法で上記のソフトウェアの問題を解決します。
概要
抽象化は、システムアーキテクチャ設計における重要なステップです。抽象化は、複雑な概念を単純化したものです。最高レベルでは、ソフトウェアシステムは、オブジェクトとプロセスという 2つの高レベルの概念に抽象化されます。オブジェクトには、システム、コンポーネント、インターフェース、クラス、メソッドなど、さまざまなレベルの概念があります。プロセスは、システム操作の方法とフローです。抽象化は、境界を定義し、理解しやすく、通信しやすいように具体的なものを概念化します。
壊す
分解と組み合わせは相互作用します。分解とは、高レベルの抽象概念を低レベルの抽象概念に分解することです。エンティティを小さな部品またはコンポーネントに分割することです。複雑さに対処する多くの方法の中で、「分割統治」は大きな問題を解決しない基本的な戦略です。小さな問題がすべて解決できるまで、小さな問題に分解します。
言語
言語の境界は世界の境界です。言語の分野、言語体系が決まっている
what、howそしてwhy。言語は、システムをドキュメント、設計図面などの理解しやすいレベルで可視化し、予測可能で制御可能な範囲でシステムの変動性を調整します。
いくつかの建築パターン
クライアントサーバー
インターネットでは、クライアントサーバーモデルがあります。クライアントサーバーモードはリクエストレスポンスモードで動作し、クライアントはリクエスト情報を送信し、サーバーはリクエストを受け入れ、対応する処理を行ってからレスポンス情報を返します。私たちがアクセスするすべてのインターネットサイトはこの構造を持っています。デスクトッププログラムが普及した時代、インターネットは今日ほど発達していません。クライアントサーバーもデスクトップクライアントサーバーモードを表すだけであり、ブラウザーの使用方法はBSモード、つまりブラウザーサーバーモードと呼ばれます。現在、ブラウザ、デスクトップアプリケーション、モバイルアプリケーション、モバイルWebなどを総称してクライアントと呼びます。
したがって、ニュースコンサルティングサイト、ブログサイトなど、現在アクセスしているほとんどのWebサイトはこのモデルに属しています。
ピアツーピア
エンドツーエンドのサービスモデル（ピアツーピア、P2Pとも呼ばれます）は、「ポイントツーポイントモデル」とも呼ばれ、インターネットを介して個人を個人に接続し、サービスと完全なトランザクションを直接提供する中央プラットフォームをバイパスするモデルを指します。P2Pの初期の意味は、コンピュータ通信の分野における「ピアツーピアネットワークプロトコル」であり、従来のクライアント/サーバー（C / S）モデルを破り、数千台のコンピュータをピアツーピアの位置で相互に接続します。参加者は、自身のハードウェアリソースの一部を直接共有します（処理機能、ストレージ機能、ネットワーク接続機能、プリンターなどを含みます）。これらの共有リソースには、統合された中間手段を経由せずに、インターネットを介して他のピアノード（ピア）から直接アクセスできます。体。このネットワークの参加者は、リソース（サービスまたはコンテンツ）プロバイダー（サーバー）とリソース取得者（クライアント）の両方です。
P2Pモデルは、ファイルの共有とダウンロード、コンピューティングとストレージ、インスタントメッセージング、および共同共有の分野で人気があります。
MVC
Model-View-Controller、MVCアーキテクチャは、オブジェクト指向プログラミングの大きな進歩です。このサービスは、ロジックを3つの異なるコンポーネントに分割します。モデル-モデル、つまり通常はデータベースに格納されているデータと、論理演算はメモリ内で実行されます。表示-ユーザーに表示されるコンポーネント。WebGUIなどのユーザー操作とデータ表示に使用されます。コントローラー論理操作、モデルとビューのコンポーネントの接続、モデルロジックの操作とインタラクティブな表示ロジックの表示。
MVCモデルは、クライアントとH5フロントエンドの両方で人気があります。これは常にWebバックエンドでよく使用されるアーキテクチャパターンであり、Java Webフィールドで生成されたStrutsやSpring MVCなどのWebバックエンドフレームワークは、かつて複雑であったWeb開発を非常に単純な開発に変えました。
フロントエンドとバックエンドが段階的に分離されているため、以前のバックグラウンドMVCはViewをフロントエンドに完全に引き渡し、フロントエンドとバックエンドは関連するプロトコルを介して通信してViewデータの送信を完了します。
レイヤード
階層化アーキテクチャは、最も広く使用されているアーキテクチャモデルです。ほとんどすべてのソフトウェアシステムは、さまざまな要件の変更に対処するために、さまざまな懸念事項（懸念事項）をレイヤで分離して、そのような変更を個別に実行できるようにする必要があります。
単一責任の原則は、システムの設計と開発にとって重要な原則です。階層化アーキテクチャは常に単一責任の原則に従います。異なるレベルは互いに分離され、異なる責任を負います。
階層化アーキテクチャといえば、最もよく知られているのは、古典的な3層アーキテクチャです。従来の3層アーキテクチャは、上から順に、ユーザーインターフェイスレイヤー（ユーザーインターフェイスレイヤー）、ビジネスロジックレイヤー（ビジネスロジックレイヤー）、およびデータアクセスレイヤー（データアクセスレイヤー）で構成されています。3層アーキテクチャは、単純なクライアントサーバーアーキテクチャのアップグレードです。
古典的で人気のある3層アーキテクチャ、および多数のWebバックエンドフレームワークが3層アーキテクチャに近接しているため、Webバックエンド開発は、開発を始めたばかりの開発者がWeb開発を行うのと同じくらい簡単になります。ほとんどのWeb開発者の思考がこれによって制限されているのは、まさにこのためです。これは、誰もが馬鹿にするCRUD-Boyになっています。MISシステムの時代が去るにつれ、3層アーキテクチャーも一部の領域で「銀の弾丸」になることに失敗し始めています。
従来の3層アーキテクチャーを削除します。ドメイン主導の設計では、Eric Evansがクラシックな4層アーキテクチャを設計し、ユーザーインターフェイスレイヤーとビジネスロジックレイヤーの間に新しいレイヤーであるアプリケーションレイヤーを導入しました。他のレイヤーもそれに応じて調整されています。
分散クラスター
上記のアーキテクチャはすべてモノリシックアーキテクチャの下にあります。モノリシックアーキテクチャとマルチサービスアーキテクチャは、サービスの展開モードと操作モードから考慮されます。
モノリシックアーキテクチャには次の利点があります。
開発が容易：開発フレームワークを利用することで、単一のアプリケーションの開発は非常にシンプルになり、開発者はシステム、デプロイメント、およびネットワークの問題を考慮する必要がほとんどなくなります。
テストが容易：単一のアプリケーションが1つのプロセスにデプロイされ、環境はシンプルです。サービスが開始されている限り、すべての機能をテストできます。
デプロイが簡単：多くの場合、アプリケーションを単純なパッケージにパッケージ化するだけで済みます。
水平方向への拡張が容易：パッケージに複数のサービスをデプロイするだけで済みます。
単一アプリケーションの短所：
メンテナンスコストの増加：需要の増加に伴い、単一のシステムがどんどん肥大化し、メンテナンスの複雑さも増します。
長い継続的な相互作用サイクル：一方で、メンテナンスが困難であり、他方で、モノリシックアプリケーションを並行して開発およびテストすることは非常に困難です。モノリシックアプリケーションは、迅速な反復的なアジャイル開発には適していません。
スケーラビリティの低下：システムの肥大化により、システムのスケーラビリティが困難になります。システムのアップグレードも非常に注意する必要があります。
初心者にはフレンドリーではありません。
分散システム分割：
一方、インターネットの急速な発展に伴い、インターネットアプリケーションへのアクセスレベルが大幅に向上し、データ量も大幅に増加しています。一方、アプリケーションの反復速度も高速化しています。単一のアプリケーションモデルは、インターネットの急速な発展にはもはや適していません。このようにして、バックグラウンドの分散クラスターアーキテクチャはますます人気が高まっています。
マイクロサービス
マイクロサービスの厳密な定義はありません。Martin Fowlerによって記述されたマイクロサービスは次のとおりです。
マイクロサービスアーキテクチャは、単一のアプリケーションを一連の小さなサービスに分割することを提唱するアーキテクチャパターンであり、サービスは相互に調整および連携して、ユーザーに究極の価値を提供します。各サービスは独自のプロセスで実行され、軽量の通信メカニズムがサービス間で使用されて相互に通信します（通常はHTTPベースのRESTful API）。各サービスは特定のビジネスを中心に構築されており、本番環境に個別にデプロイできます。
マイクロサービスには通常、次の特性があります。
単一の責任：ビジネスの独立、チームの独立。単一の責任を持つサービスには、コアドメイン、高い凝集度、低い結合、および他のシステムやドメインとの明確な境界が必要です。
軽量なコミュニケーション：コミュニケーションはシンプルで軽量でなければなりません。言語やプラットフォームとは関係ありません。
独立性：独立した開発、独立したテスト、独立した配備。
すべての選択肢は計量のプロセスです。マイクロサービスは、モノリシックアプリケーションの多くの問題を解決し、当然対応する問題をもたらします。分散環境とクラスター環境は複雑であり、これに基づくマイクロサービスアーキテクチャも対応する複雑さを持っています。
マイクロサービスの人気により、マイクロサービスの多くの問題は、ますます多くのフレームワークとサービスによって解決されています。例としてSpring Cloudテクノロジースタックを見てみましょう。
SpringBoot：モノリシックサービス、迅速なプロジェクトの作成、さまざまなフレームワークの迅速な統合、テストと導入が容易。
Feign：マイクロサービスは独立して展開され、関連するプロトコルを介して通信します。Feignは、HTTP RESTfulに基づくシンプルな宣言型通信フレームワークです。
Eureka：ますます多くの独立したサービス、そしてますます多くのサービスインスタンスがあります。Eurekaは、可用性の高いサービス登録およびサービス検出機能を提供します。
リボン：Feignは通信のみを担当し、システムの最適化の一部であるクライアントロードバランシングを提供します。
Hystrix：マイクロサービスはサービス間の複雑な依存関係をもたらし、分散およびクラスタリングの複雑さも多くの予測できない問題を引き起こします。複雑なネットワークと複雑なシステムの問題がシステム全体のなだれを引き起こすのを防ぐために、HystrixはSpring Cloudシステムの優れた回路ブレーカーであり、システムがシステム全体のクラッシュを防止できない場合にサービスの低下を実行できます。
Zuul：ユニファイドゲートウェイ。ユニファイドゲートウェイはファサードモデルを採用し、外の世界へのフレンドリーなインターフェイスを提供します。マイクロサービスの後、ますます多くのサービスがますます複雑になります。外部システムコールの複雑さを軽減するために、ユニファイドゲートウェイは一般的なソリューションです。
構成：分割されるサービスが多いほど、構成も多くなります。Springクラウド構成は、統合された構成管理を提供します。
Sleuth：サービスの監視とガバナンス。監視は、複雑なシステムに必要なインフラストラクチャです。システムの認識、問題の発見、パフォーマンスの位置付けには、すべて監視の恩恵が必要です。
偶数源
イベントソーシングは、最新の人気のあるアプリケーションアーキテクチャモデルです。イベントソースは、アプリケーションによって行われた状態変更を、不変のシーケンスまたはイベントの「ログ」としてモデル化します。フィールドのアプリケーションの状態を変更する代わりに、イベントソースは、状態変更をトリガーするイベントを不変のログに保存し、状態変化をログ内のイベントへの応答としてモデル化します。
CQRSモデルは通常、イベント追跡可能性モデルに基づいています。従来のアーキテクチャでは、データベースのクエリと更新に同じデータモデルが使用されます。これは非常にシンプルで、基本的なCRUD操作に非常に適しています。ただし、より複雑なアプリケーションでは、この方法は操作が困難になる可能性があります。たとえば、読み取りに関して、アプリケーションは多数の異なるクエリを実行し、異なる形状のデータ転送オブジェクト（DTO）を返す場合があります。オブジェクトのマッピングは複雑になる可能性があります。作成に関して、モデルは複雑な検証とビジネスロジックを実装する場合があります。その結果、モデルは非常に多くの操作を実行し、過度に複雑になります。
CQRS（クエリ責任分離コマンドクエリ責任分離）は、コマンドを使用してデータを更新し、クエリを使用してデータを読み取る、異なるモデルへの読み取りおよび書き込み操作。
六角
????「ポートおよびアダプターモード」とも呼ばれる六角形のアーキテクチャは、Alistair Cockburnによって提案された対称的な機能を持つアーキテクチャスタイルです。このアーキテクチャでは、システムはアダプターを介して外部と対話し、システム内のアプリケーションサービスとドメインサービスをカプセル化します。
六角形のアーキテクチャは、次の3つのコンポーネントで構成されています。
ポート：システムと他のシステムの間のインターフェースである入力端子と出力端子に分けることができます。
アダプター：一方で、他のシステムのアダプテーションレイヤーは、コアシステムとドメインが外部から影響を受けること、つまり腐食防止を防止します。他方では、APIの使用に便利です。
ドメイン：アプリケーションとモデルはプログラムの中核です。
六角形のアーキテクチャのコアコンセプトは、アプリケーションが「ポート」を介して外部と対話することです。従来のレイヤードアーキテクチャでは、レイヤー間の境界を越えて、ビジネスロジックを他のレイヤーに浸透させるのは簡単です。六角形の構造で重要なのは、「境界」と「ドメイン」です。六角形のアーキテクチャの本来の目的は、テクノロジーとビジネスシステムの間のデカップリングの問題と、テクノロジーとテクノロジーの間のデカップリングの問題を解決することです。このアーキテクチャは、ビジネスのエンティティサービスから始まる設計パターンに由来し、特にインターフェース用に設計されます。標準化されたポートプロトコルとアダプタの実現により、サービス自体が独立性と完全性を実現します。
参照：
「システムアーキテクチャ-製品設計と複雑なシステムの開発」Daniel Selva
「構築方法-現代エンジニアリング」Zou Xin
「マイクロサービスのアーキテクチャと実装」Wang Lei
「ドメイン駆動設計-ソフトウェアのコアな複雑さに対処する方法"Eric Evans
、Realizing Domain-Driven Design"、Vaughn Vernon、
"Spring Cloud Microservices in Action "、Zhai Yongchao、
"Engineering-Endless Frontiers"、Ouyang Yingzhi、
"The Myth of the Moon" Frederick P. Brooks、Jr.
方法はありませんが、テクニックは達成できます。方法がない場合は、テクニックで終わります
みんながJava Wayパブリックアカウントをフォローすることを歓迎します
良い記事、私は読んでいます❤️