分散ソフトウェア アーキテクチャ - モノリシック アーキテクチャ

前文

大規模なプロジェクトで、ネットワーク上に分散した多数のサーバーノードを同時に動作させるため、多人数による共同開発が必要となる場合、プロジェクトの規模が大きくなり、実行時間が長くなると、必然的に容赦なく開発が行われます。マーフィーの法則に引っかかる。

マーフィーの法則: うまくいかない可能性のあるものはすべてうまくいかない
マーフィーの法則: うまくいかない可能性のあるものはすべてうまくいかない。

高品質のソフトウェア製品を入手するには、開発者の能力を向上させるか、全体的なプロセスとアーキテクチャに重点を置く必要があります。
どちらも重要で、前者は外科に焦点を当て、後者は道教に焦点を当てます。前者は個々の開発者のレベルで決定され、後者は技術的な意思決定者のレベルで決定されます。

建築は「発明された」ものではなく、継続的な進化の結果です。

springboot の単一層アーキテクチャは、gitclone でプロジェクト参照をダウンロードできます
git clone https://gitclone.com/github.com/fenixsoft/monolithic_arch_springboot

ダウンロード後、docker を使用してプロジェクトを開始するか、BookStoreApplication を直接実行して、ブラウザで http://localhost:8080 にアクセスすると、システムによってユーザー (user:icyfenix、pw:123456) が事前設定され、登録することもできます。テストする新しいユーザー。今回実行したのは、jekenis がポート 8080 を占有しているためです。jekenis のポートまたはこのプロジェクトのポートを変更できます。

docker を実行する場合、input コマンドはdocker versionデフォルトで、クライアントとサーバーの 2 つの部分を含む docker バージョン情報を出力します。以下はクライアント部分です。Docker version コマンドを参照してください。

大規模なモノリシックシステム

モノリシック アーキテクチャは、ほとんどのソフトウェア開発者が学習し、実践しているソフトウェア アーキテクチャです。マイクロサービスを紹介する多くの書籍や技術資料では、このアーキテクチャ スタイルの適用は「モノリシック アプリケーション」と呼ばれることがよくあります。
「モノリシックアーキテクチャ」とは、ソフトウェアアーキテクチャの進化の歴史の全過程の中で、最も早く出現し、最も広い適用範囲、最も多くのユーザーを擁し、最も長い統治の歴史を持つアーキテクチャスタイルです。マイクロサービスが普及した後に形成された概念は「事後的に認知される」ものでした。以前は、「モノリシック」をアーキテクチャの一種として捉える人は多くはありませんでしたが、ソフトウェア アーキテクチャの開発資料を探せば、マイクロサービスをテーマにした書籍や記事は簡単にたくさん見つかりますが、特別に見つけるのは困難です。モノリシック システム用のあらゆる形式のマテリアルを開発する方法を教えます。これは、モノリシック アーキテクチャ自体の単純さを反映している一方で、長い時間スケールで誰もがソフトウェアに慣れていることも反映しています。建築はこうあるべきです。

モノリシック アーキテクチャを分析する前に、概念的な誤解を明確にする必要があります。多くのマイクロサービス資料では、モノリシック システムはしばしば「悪役」として登場します。たとえば、有名なマイクロサービス入門書「マイクロサービス アーキテクチャ デザイン パターン」では、第一章は「単体地獄からの脱出」。これらの資料で言及されているモノマー系には、実際には、明示的には述べられていない暗黙の属性があります:「大きなモノマー系」。小規模なシステム、つまり良好な動作をサポートするには 1 台のマシンで十分である場合、モノマーは開発、テスト、展開が簡単であるだけでなく、各関数、モジュール、およびシステム内のメソッドはプロセス内呼び出しであり、プロセス間通信はありません（プロセス間通信、IPC。大まかに言えば、RPC は IPC の特殊なケースと考えることができますが、2 つの「PC」は略称ではないことに注意してください）最も効率的でもあります 決して「悪役」とレッテルを貼られるべきではないアーキテクチャ スタイル 逆に、技術トレンドを追うのが好きだが需要の現状を無視するマイクロサービス支持者むしろ悪役のようです。

プロセス間通信: プロセス間通信、IPC。RPC (リモート プロシージャ コール、リモート プロシージャ コール) は、IPC の特殊なケースです。

単一システムが存在しないということは、ソフトウェアのパフォーマンス要件が単一マシンの要件を超えており、ソフトウェア開発者の規模が明らかに「ピザ 2 チーム」の範疇を超えているという事実に基づいているに違いありません。この記事のその後の議論では、どちらも特に「大規模モノリシック システム」に言及する必要があり、このため、このセクションでは「モノリシックは最も初期のアーキテクチャ スタイルである」と述べており、これは「アイデアとアイデアを使用する」と同様です。複数の独立した分散サービスを組み合わせて大規模なシステムを構築するという実際の試みは、今日誰もが知っている大規模な単一システムよりも早くに登場しました。」 実際には矛盾はありません。

取り外し可能なシングルシステム

モノリスとは、すべてが1 つの
ピースで構成されたことを意味します。モノリシック アプリケーションとは、さまざまなコンポーネントが単一のプラットフォームから単一のプログラムに結合された、単一層のソフトウェア アプリケーションを指します。—— モノリシック アプリケーション、
Wikipedia
プロシージャ コールはすべてプロセス内呼び出しであり、プロセス間の呼び出しはありません-プロセス通信が発生する、それだけです。

Wikipedia における単一システムの定義は「All in One Piece」で、「単一の鉄片」と訳されていますが、実際には自給自足（Self-Contained）の意味に近いです。

• 垂直パースペクティブ
  階層化アーキテクチャ (Layer Architecture) は、現在、ほぼすべての情報システム構築で一般的に認識され、採用されているソフトウェア設計手法です。単一のユニットであるか、マイクロサービスであるか、その他のアーキテクチャ スタイルであるかに関係なく、コードは垂直に分割され、受信した外部リクエストは異なる形式のデータ構造で層間で転送され、データベースは順番に応答を返します。
  

• 水平方向の視点
  モノリシック アーキテクチャは、テクノロジー、機能、再利用とチーム管理の責任の観点から、ソフトウェアをさまざまなモジュールに分割することもサポートします。
  ロードバランサーの後には、モノリシックシステムのコピーを複数同時に導入してトラフィック圧力を分散する効果を実現するため、モノリシックアーキテクチャに基づいて簡単に実現できます。

依存性モノマー

ただし、「分割」という点で言えば、モノリシック システムの本当の欠陥は、実際にどのように分割するかではなく、分割後に分離と自律性が欠如することです。

モノリシック アーキテクチャでは、すべてのコードが同じプロセス空間で実行され、すべてのモジュールとメソッド呼び出しでネットワークの分割、オブジェクトのレプリケーション、その他の面倒なことを考慮する必要がなく、データ交換の損失によるパフォーマンスの低下を心配する必要もありません。ただし、インプロセス呼び出しの簡素化と高効率の利点が得られる一方で、モノリシック アーキテクチャ内のコードの一部に欠陥があり、プロセス空間内のパブリック リソースを過剰に消費すると、その影響はグローバルに及ぶことも意味します。隔離するのが難しい。

メモリ リーク、スレッド爆発、ブロッキング、無限ループなどの問題がアーキテクチャ内で発生すると、特定の関数やモジュール自体の通常の動作だけでなく、プログラム全体の動作に影響を及ぼします。過度のポート占有やデータベース接続プールのリークは、マシン全体に影響を与え、さらにはクラスター内の他の単一コピーの通常の動作にも影響します。

すべてのコードは同じプロセス空間を共有しているため、コードを分離できない場合、コードの特定の部分を個別に停止、更新、アップグレードできないことを意味します。これは、「プロセスの半分を停止して 1/ を再起動する」ということが不可能であるためです。 4 プロセス」という非論理的な操作です。そのため、動的な保守性の観点からはモノリシックシステムでも不十分であり、プログラムのアップグレードや不具合修正などの作業では、特別なダウンタイム更新計画を策定する必要があることが多く、グレースケールリリースの方が比較的容易であるため、複雑です。

分離能力の欠如により、エラーの伝播を阻止することが困難である、プログラムの動的更新が不便であるといった問題に加えて、技術の異質性が困難であるなどの困難も生じる。

テクノロジーの異質性
Martin Fowler (マーティン ファウラー) はマイクロサービスの 9 つの特徴を提案しました。テクノロジーの異質性はその 1 つです。これは、システムの各モジュールが、実装するさまざまなプログラミング言語、さまざまなプログラミング フレームワーク、その他のテクノロジー スタックを自由に選択できることを意味します。単一システムの技術スタックの異質性は必ずしも不可能ではなく、たとえば、JNI を使用すると Java に C/C++ を混在させることができますが、これも非常に面倒であり、強制的な選択になります。

基本的に言えば、モノリシック アーキテクチャ スタイルの基礎となるコンセプトは、システムのすべての部分、さらにはコードのすべての部分が、可能な限り信頼性が高く、エラーがなく、間違いが少ないことを望み、7×24 のシステムを構築することに尽力することです。何時間も中断されない信頼性の高いシステム。この概念は小規模なソフトウェアにはうまく機能しますが、システムが大きくなるにつれて、信頼性の高いモノリシック システムを提供することがますます困難になります。コードの量がますます大きくなるにつれて、システムの破損は避けられないという言葉を覚えておいてください。

一般に、モノリシック アーキテクチャの発展とその利点と欠点を次の図に示します。

参考リンク：
1. https://zhuanlan.zhihu.com/p/575500324
2. 「周志明のソフトウェアアーキテクチャコース」 - Geek Academy