Java アーキテクチャをさまざまな製品に適用する方法

システムをセットアップするときは、通常、他のシステムとどのように対話するかを考慮する必要があります。そのため、まず、さまざまなシステムがどのように相互対話するのか、また、それを実装するためにどのようなテクノロジが使用されているのかを知る必要があります。

1. 異なるシステムおよび異なる言語間の対話

現在、異なるシステムおよび異なる言語間の一般的な対話では、WebService および Http リクエストが使用されます。 WebService、つまり「Webサービス」、略してWSとなります。文字通りに理解すると、実際には「Web ベースのサービス」です。しかし、サービスは双方のためのものであり、サービス需要者がいればサービス提供者が存在します。サービスプロバイダーはサービスを外部に公開し、サービス要求者はサービスプロバイダーが公開したサービスを呼び出します。より専門的に言うと、WS は実際には、異種システム通信を実現するために HTTP プロトコルに基づいて構築されたツールです。それは正しい！端的に言えば、WS は HTTP プロトコルに基づいており、データは HTTP を介して送信されます。最初は CXF を使用して WS を実装するための SOAP サービスを開発し、その後、REST サービスを使用して WS を実装しました (現在はこれがより頻繁に使用されており、私も最もよく使用しています)。 REST サービスは CXF に基づいて開発することもできますが、通常は springMVC または他の MVC フレームワークを直接使用して REST サービスを実装します。

しかし多くの人にとって、Web サービスというと、IBM が 10 年以上前に主導したさまざまな XML ベースのインタラクティブ技術を指すことが一般的であり、現在では一部の企業を除いて、それを使用している人はほとんどいません。広い意味では、Web サービスは Web サービスであり、すべてがサービスです。

2. 同じ言語を使用した異なるシステム間の対話

同じ言語を使用した異なるシステム間の一般的な対話では、RPC (リモート プロシージャ コール) または RMI (リモート メソッド) を使用します。 call) は外部サービスを提供せずに実装されており、上記は同じ言語間のやり取りにももちろん利用できますが、私は通常 RPC を使用します。

さまざまな製品のアーキテクチャ

3. 単一製品のアーキテクチャの進化

通常、必要に応じて製品は 1 つだけです。外部に対しては、通常、REST サービスを使用して実装されます。

#以下の内容は Zhihu からのものです

#1) 分散アーキテクチャの進化システム アーキテクチャの進化プロセス - 初期段階のアーキテクチャ

#初期段階では、小規模システム アプリケーション、データベース、ファイルなどのすべてのリソースが、一般に LAMP として知られる 1 つのサーバー上にあります。

特徴: アプリケーション、データベース、ファイル待機すべてのリソースが 1 つのサーバー上に配置されるまで。

説明: 通常、サーバー オペレーティング システムは Linux を使用し、アプリケーションは PHP を使用して開発され、その後 Apache にデプロイされ、データベースは Mysql を使用します。また、さまざまな無料のオープン ソース ソフトウェアと安価なサーバーで開発を開始できます。システムの。

2) システム アーキテクチャの進化 - アプリケーション サービスとデータ サービスの分離

良い時代は長くは続かず、システムへのアクセス数が再び増加すると、ピーク時に Web サーバー マシンへの負荷が比較的高いレベルに上昇することがわかりました。この時点で、Web サーバーの追加を検討してください。

機能: アプリケーション、データベース、ファイルは独立したリソースにデプロイされます。

説明: データ量が増加し、1 台のサーバーでは性能や保存容量が不足し、アプリケーションとデータを分離する必要がある場合に、同時処理能力とデータ保存容量が大幅に向上しました。

3) システム アーキテクチャの進化 - キャッシュを使用してパフォーマンスを向上させる

機能: データベース内のデータの一部アクセスが集中する キャッシュ サーバーに保存されるため、データベース アクセスの数が減り、データベース アクセスの負荷が軽減されます。

説明: システム アクセス特性は 80/20 ルールに従います。つまり、ビジネス アクセスの 80% がデータの 20% に集中します。キャッシュはローカルキャッシュとリモート分散キャッシュに分けられ、ローカルキャッシュはアクセス速度が速いですが、キャッシュできるデータ量が限られているため、アプリケーションとメモリを競合する可能性があります。

4) システムアーキテクチャの進化 - アプリケーションサーバークラスタの利用

サブデータベースとサブテーブルの作業完了後、データベース システムへの負荷が比較的低くなり、毎日アクセス数が増えていくのを眺めながら幸せな生活を送り始めましたが、ある日突然、システムへのアクセスが制限され始めていることに気付きました。また遅くなります。このとき、最初にデータベースを確認しました。圧力はすべて正常でした。Web サーバーを確認した後、Apache が多くのリクエストをブロックし、アプリケーション サーバーは各リクエストに対して比較的高速であることがわかりました。リクエスト数が多すぎて順番待ちが発生し、応答速度が遅くなる

特徴：負荷分散により複数のサーバーが同時に外部にサービスを提供し、処理の問題を解決単一サーバーの電力とストレージ容量の制限。

説明: クラスターの使用は、システムが高い同時実行性と大量のデータの問題を解決するための一般的な方法です。クラスターにリソースを追加することにより、システムの同時処理能力が向上し、サーバーの負荷圧力がシステム全体のボトルネックになることがなくなります。

5) システム アーキテクチャの進化 - データベースの読み取りと書き込みの分離

#システム アクセス数の急速な増加をしばらく楽しんだ後、しばらくすると、システムが再び遅くなり始めたことがわかりました。今回はどのような状況ですか? 検索したところ、データベースの書き込みおよび更新操作のための一部のデータベース接続のリソース競合が非常に激しく、システムの速度が低下していることがわかりました。 down.

特徴: 複数のサーバーが負荷分散を通じて同時に外部にサービスを提供し、単一サーバーの処理能力とストレージ容量の制限の問題を解決します。

説明: クラスターの使用は、システムが高い同時実行性と大量のデータの問題を解決するための一般的な方法です。クラスターにリソースを追加すると、サーバーの負荷圧力がシステム全体のボトルネックになることがなくなります。

6) システム アーキテクチャの進化 - リバース プロキシと CDN の高速化

特徴: CDN とリバース プロキシを使用したシステムの高速化アクセス速度。

説明: 複雑なネットワーク環境と異なる地域のユーザーからのアクセスに対処するために、CDN とリバース プロキシを使用して、バックエンド サーバーの負荷を軽減しながらユーザー アクセスを高速化します。 CDN とリバース プロキシの基本原理はキャッシュです。

7) システム アーキテクチャの進化 - 分散ファイル システムと分散データベース

システムが稼働し続けると、データ、ボリューム、この時点で、データベースを分割してもクエリが少し遅いことがわかったので、サブデータベース

# の考えに従ってテーブルのパーティショニングに取り組み始めました。

## 特徴: データベースは分散データベースを使用し、ファイル システムは分散ファイル システムを使用します。

説明: 大規模システムの増大するビジネス ニーズを満たす強力な単一サーバーはありません。データベースの読み取りと書き込みを分離しても、ビジネスが発展するにつれて最終的にニーズを満たすことができなくなります。分散データベースと分散データベースを使用する必要があり、サポートするファイル システムが必要です。分散データベースは、システム データベースを分割する唯一の方法です。単一テーブル データの規模が非常に大きい場合にのみ使用されます。データベース分割のより一般的に使用される方法は、異なる物理サーバーに異なるビジネス データベースをデプロイするビジネス サブ データベースです。優れた。

8) システム アーキテクチャの進化 - NoSQL と検索エンジンの使用

特徴: システムには NoSQL データベースと検索エンジンが導入されています。検索エンジン。

説明: ビジネスがますます複雑になるにつれて、データの保存と取得の要件もますます複雑になります。システムでは、NoSQL やサブデータベースなどの非リレーショナル データベースを使用する必要があります。検索エンジンなどのクエリ技術。アプリケーション サーバーは、統合されたデータ アクセス モジュールを通じてさまざまなデータにアクセスし、多数のデータ ソースを管理するアプリケーションの手間を軽減します。

9) システムアーキテクチャの進化 - 事業分割

特徴: 業務、アプリケーションサーバに応じてシステムを分割・変革事業の差別化に応じて分けて導入します。

説明: ますます複雑化するビジネス シナリオに対処するために、通常、システム ビジネス全体を異なる製品ラインに分割する分割統治手法が使用されます。ハイパーリンクを介してアプリケーション間の関係が確立され、データの分散も可能です。もちろん、同じデータ ストレージ システムにアクセスして、関連する完全なシステムを形成することも重要です。垂直分割: 大規模なアプリケーションを複数の小さなアプリケーションに分割します。新しいビジネスが比較的独立している場合は、独立した Web アプリケーション システムとして直接設計して展開します。垂直分割は比較的単純です。ビジネスを分類することで、小さなアプリケーションはより小さなアプリケーションに分割され、関連する事業は売却される可能性があります。水平分割: 再利用可能なビジネスを分割し、分散サービスとして独立して展開します。新しいビジネスは、これらの分散サービスを呼び出すだけで済みます。水平分割では、再利用可能なビジネスの特定、サービス インターフェイスの設計、およびサービスの依存関係の標準化が必要です。

10) システム アーキテクチャの進化 - 分散サービス

Q: 分散サービス アプリケーションはどのような問題に直面しますか? ?

(1) サービスの数が増えると、サービス URL の構成管理が非常に困難になり、F5 ハードウェア ロード バランサーに対するシングルポイントの負荷も増大します。

(2) さらに発展すると、サービス間の依存関係が非常に複雑になり、どのアプリケーションをどのアプリケーションより先に開始する必要があるのか​​さえ不明確になり、アーキテクトはアプリケーションのアーキテクチャ上の関係を完全に記述することができなくなります。

(3) サービスへの呼び出し数が増えると、サービスのキャパシティの問題が明らかになります。このサービスは何台のマシンをサポートする必要がありますか?いつマシンを追加すればよいですか?

(4) サービスが増えて通信費も高くなり始めていますが、サービスの調整に失敗した場合はどこに問い合わせればよいのでしょうか？サービスパラメータの規則は何ですか?

(5) サービスに複数の企業消費者がいる場合、サービスの品質を確保するにはどうすればよいですか?

(6) サービスを継続的にアップグレードすると、常に予期せぬことが起こります。たとえば、キャッシュが正しく書き込まれず、メモリ オーバーフローが発生します。障害は避けられません。コア サービスが障害を起こすたびに、広範囲に影響が及び、失敗の影響を制御するにはどうすればよいでしょうか?サービスは機能的にダウングレードできますか?それとも資源の劣化？

大規模Webサイトの技術アーキテクチャの中核原則と事例分析の始まりのようですが、著者がうまくまとめてくれたので再掲します。

4. 製品ライン構成

上記の事業分割もあります。ここで製品ラインを構築する必要がありますが、必要なのはデータ層、一般的なビジネス ロジック層、およびその前にあるさまざまなアプリケーション層とインターフェイス層だけであり、外部システム (外部企業のシステム) にサービスを提供する必要はありません。以前は、通常、分散アプリケーションを構築するために EJB を使用することを選択していましたが、現在では、dobbo、thrift、avro、hessian などの RPC フレームワークを使用して分散アプリケーションを構築し、異なるアプリケーションとデータ ソース間の対話を実現できるようになりました。この構造モデルでは、他の企業にサービスを提供する必要があり、外部システムに残りのサービスを提供する専用のアプリケーションを作成できます。一般に、ほとんどのインターネット サービスは数十、場合によっては数百の内部サービスにアクセスする必要があり、それらの間の通信方法は通常 RPC です。つまり、リモート メソッドにアクセスするのと同じように、パラメータを入力して結果が返されるのを待ちます。これは、複雑なシステムを構築する最も簡単な方法です。

以下に示すように、モデル、ファイル システム、キャッシュは表示されないため、誰でも理解できます。

以上がJava アーキテクチャをさまざまな製品に適用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。