まず、単一サーバーアーキテクチャ
なぜなら、同社は当初、中小企業の加入者とライン上の不安に限られた資金で会社がサーバーにサイトを開発するには、サーバー、小さな猿チームを購入し、電力会社のWebサイトの販売製品を構築する準備ができて、早期の小さな猿を設立これは正式に開始されます。
第二に、サーバークラスタ
ライン上のプロジェクトがすぐに多くの問題を暴露されました：
- シングルポイントの（サーバーのダウンタイムは、システム全体が使用不能に原因となります）
- 処理効率は、前記量は、受信することができる単一のサーバーが非常に制限されている大規模なユーザ応答時間の場合の実質的な減少、さらにはメモリのオーバーフローを要請しました。
サーバーがダウンしている間に遭遇するこれらの問題は、サービスアーキテクチャに調整しなければならない、我々はいくつかはまた、通常の外でサービスを提供することができたとしても、あなたが過度の圧力要求の問題を解決するための単一のサーバーを持つことができるので、小さな猿チームの話でサーバーの数を増やすことにしました。
クラスタのいくつかの新しい質問導入されています。
- 各サーバのIPアドレスがどのように訪問する一人のユーザーを知ることができるように最終的には、同じではありませんか？
- など、ユーザーのログイン情報の前にセッションの問題、お買い物カートの情報は、どのように各サーバー共有セッションデータ・サーバ・クラスタを確保するために、サーバーのメモリが存在する、です。
第三に、ロード・バランシング
今、各サーバ処理している要求は、実際に、このようなラウンドロビンなど、可能性の数のバランスをとることができるように対処する必要があります。これは、負荷分散。
主な仕事は、ロードバランサにした後、ユーザの要求を受け付け、特定のアルゴリズムに図の構造調整モードを形成する別のサーバーに要求を、方法。
（問題をクラスタリングセッションを持参することは一般的に議論するために、ここではなく、処理するためのRedisまたは他のキャッシュサーバを採用することができます）
第四に、分散
同社のビジネス、より多くの小さな猿の負荷では、チームのメンバーは、より多くのシステムはゆっくりますます大きくなっているが、また、いくつかの問題をもたらしました：
- わずかなビジネス機能の数が、再リリースするシステム全体への必要性を修正。
- 複雑なビジネス・システム、開発者はあまりにも悪い管理、開発の効率が低いです。
- 特定のビジネスのためのサーバの処理能力を拡張することができません。
私は、システムモジュールに従って、さまざまなサブシステムに分割された中で、各チームはそれぞれのビジネス機能を呼び出す完全なサブシステムに対応する責任を持って、解決策を考えます。
もちろん、図は、依然としてフレームワークに存在する単一の点の、この時間は、アーキテクチャの安定性を改善するために、互いに技術クラスタと組み合わせることができます
第五に、マイクロサービス
分割されたシステムは、各小独立したビジネスシステムのための完全なシステムであり、独自の個別のデータベースを持つことができ、各小システムがされた後、マイクロサービス、外国人が公開、独自のAPI、マイクロサービスを通じて、それは非常に良いことができますこうした二から一一活動、受注の急増、高強度の要求の圧力に対処するために、いくつかの取引システムよりも多くの導入を検討するために、この時間などの拡大を実現、システムの数の増加に伴い、我々はまた、などのサービス管理ツールを（導入する必要があります。それが持っているユーレカ）は、各サービスの健康を管理します。
もちろん、マイクロアーキテクチャはまた、このような分散トランザクションとして、対処する必要があり、多くの新しい問題を導入するコール例外処理を果たす権限、認証、などの問題の範囲を、ここにいない最初の延長上で、その後のフォローアップサプリメントを改善していきます。
最後に書かれました：
私は、みんなの注目[公共の数歓迎コードとして冷静に ]、大量のJava関連の記事、材料は材料が内側になります仕上げ、内側に更新されます学習します。
私は賞賛のポイントに書き込みに良い感じ、プラス信者が聖歌！注目点は、継続的に更新され、迷子にしないでください！！！