[SOA] モノリシック アーキテクチャから分散マイクロサービス アーキテクチャへ

序文

2016年、局B局初の生放送では、急激な視聴者の流入により、ウェブサイトの生放送システムが崩壊した。初期の Bilibili はライブ ブロードキャストから始まりませんでした。当時、ライブ ブロードキャスト システムはまだ php で書かれた単一のアーキテクチャ システム、つまり LAMP (Linux+Apache+MySql+PHP) でした。基本的にすべてのモジュールが結合されていました。これ:完了 単一のプロジェクトに携わる誰もが、プロジェクト内のサブモジュールの 1 つが間違っている限り、システム全体がダウンする可能性があることを知っています。私自身の経験から話
ここに画像の説明を挿入
をさせてください: 私がセント レジスのテイクアウトをしていたとき(SpringBoot+MySQL の単一プロジェクト) Jmeter を使用して 1000 スレッドを開いてインターフェイスのパフォーマンスをテストしました (キャッシュなし)。その結果、テスト ケースの実行途中でデータベースがクラッシュしました。モジュールは有効にならず、結合されたモジュールは失敗します。他のモジュールのインターフェイスへのアクセス要求が、ドミノがすべてエラーであるような結果を返すと、モノリシック アーキテクチャは青白く無力に見えます。

画像
話題に戻りますが、このような突然の同時実行性の高い状況では、サブモジュールはプレッシャーに耐えられないはずです。そのため、B ステーション全体のライブブロードキャストシステムが崩壊しました~B ステーションがゆっくりと変化したのもそれ以来です。 Php to Go、著 モノリシック アーキテクチャはマイクロサービス アーキテクチャに変わりました。では、モノリシックアーキテクチャとは何でしょうか? 以前はモノリシック アーキテクチャを使用していた理由は何ですか? マイクロサービス アーキテクチャとは何ですか?

モノリシックアーキテクチャシステム

システム全体のすべての機能ユニットが全体として同じプロセスにデプロイされます (すべてのコードを 1 つ以上のファイルにパッケージ化できます)。これを (SSM+Tomcat+Mysql) ビジネス ロジック レイヤーなどの「単一システム」と呼ぶことができます
。データ アクセス層のサービス、コントローラー、dao 層は war パッケージにパッケージ化され、Tomcat、Jetty、またはその他のコンテナーにデプロイされます。
ここに画像の説明を挿入
このようなシステムの利点は特に明白です。

開発、テスト、デプロイが容易で、各関数、モジュール、メソッドの呼び出し処理がプロセス内で呼び出されるため、プロセス間通信が発生しないため、プログラムの動作効率も高くなります。すべてのコードは同じプロセス空間で実行され、すべてのモジュールとメソッド呼び出しはネットワーク分割、オブジェクトのレプリケーション、その他の面倒なことを考慮する必要がなく、データ交換によるパフォーマンスの低下を心配する必要もありません。

しかし、デメリットも非常に致命的です。

ビジネスがますます複雑になると、単一のアーキテクチャでは拡張性が不十分となり、ビジネス拡大のコストが増大しますユーザーがますます増えており、プログラムの同時実行性はますます高くなっています。すべてのコードがプロセス空間を共有しているため、単一アプリケーションの同時実行能力は非常に限られています。一度メモリ リーク、スレッドの爆発、またはブロックが発生すると、プログラムの実行中にデッドロック、無限ループ、その他の問題が発生すると、特定の関数やモジュール自体の通常の動作だけでなく、プログラム全体の動作に影響が及びます。また、ポートなどのより高いレベルのパブリック リソースが消費された場合にも影響します。占有が多すぎる場合やデータベース接続プールのリークは、マシン全体に影響を与え、さらにはクラスター内の他の単一コピーの通常の動作にも影響します。
ここに画像の説明を挿入
以前 Spring の IOC について勉強していたときに、その「デカップリング」機能について触れましたが、IOC はクラス間の結合を軽減しますが、クラスの範囲を離れても、単一システム内のモジュール間の結合は常に保証されます。

マイクロサービスアーキテクチャシステム

上記の欠点により、初期の水平アーキテクチャから垂直アーキテクチャ、そして最終的な分散アーキテクチャに至るまで、アーキテクチャの進化が促進されます。分散アーキテクチャの完璧なソリューションとして、「マイクロサービス」は近年非常に人気があります。

名前が示すように、マイクロサービスはシステムをいくつかの独立したモジュールに分割し、独立したプロセスで実行します。各サブモジュールは「マイクロサービス」とも呼ばれ、各サービスには独自のデータベースがあり、事故の可能性が大幅に減少します。
ここに画像の説明を挿入
モノリシック アーキテクチャでは、すべてのサブモジュールが同じプロセス内にあり、プロセス間の呼び出しはなく、モジュールが別のモジュールを呼び出したい場合は、インスタンスを直接挿入してインスタンスを呼び出します。

サービスガバナンス

しかし、マイクロサービスの場合、モジュール間の呼び出しはプロセスにまたがります。対象のインスタンスを取得したい場合は、直接インジェクトすることができないため、各サブモジュール、つまりマイクロサービスをNacos(登録&設定センター)に登録して関連設定を行い、Feignを使って実装する必要があります。サービス間のリモート呼び出しを行うには、Gataway を使用します。マイクロサービスモジュール間のメッセージの高可用性とサービス応答速度を確保するために、非同期通信ツールMQが使用され、これらのガバナンスコンポーネントはSpringによって統合されているため、サービスガバナンスソリューションとしてSpringCloudが通常使用されます。

したがって、SpringCloud とマイクロサービスの間で「=」を描画するのはやめてください。

おすすめ

転載: blog.csdn.net/weixin_57535055/article/details/128984358