ヘビーシェアリング！高性能アーキテクチャ学習ロードマップ-分散アーキテクチャの進化+リファレンスノート

1.分散アーキテクチャ学習のロードマップ

統計によると、完全な献身を達成するために人の読書時間は20分未満です。単一の記事の長さは将来可能な限り短縮されますが、更新は可能な限り頻繁になります。

画像

2.コンピュータソフトウェア開発の歴史

まず、コンピュータソフトウェアの開発履歴を大まかにまとめて、c / s時代、web1.0時代、web2.0時代に分けて理解します。

c / s時代：リッチクライアントソリューション。ソフトウェアを売ることはお金を稼ぐことができます。たとえば、qq、オーディオとビデオ、ゲーム。

1.0時代：これは主に一方向の情報リリース、つまり情報ポータル---広大なブラウザクライアントです。インターネットコンテンツは少数の編集者（またはウェブマスター）によってカスタマイズされています。

この表は、Sina / Netease / Sohuの3つの主要なポータルです。Sinaはニュースと広告に焦点を当て、NetEaseはゲームの拡張に焦点を当て、Sohuはポータルマトリックスを拡張します

2.0時代：ユーザーインタラクションに焦点を当てます。誰もがコンテンツの寄稿者です。RSSサブスクリプションは非常に重要な役割を果たします。

例：ブログ、ポッドキャスト、ウィキ、P2Pダウンロード、コミュニティ、共有サービス

今日、インターネットの形態は、すべての年齢層に適した、すべての従業員が参加できるイベントに進化しました。そのため、インターネット関連の技術はますます要求が厳しくなり、参加者数の増加はシステムにますます負担をかけています。

第三に、技術アーキテクチャの進化の歴史

以下は、2017年のTmall Double11の取引指標です。このように大量のデータと要求の処理が非常に高速であるため、単一のマシンと単一のサービスがそれをサポートできないことは明らかです。

では、どうすればよいでしょうか。元々単一のサーバーに展開され、単一のサーバーによって処理されたサービスを異なるサーバーに分割して展開し、複数のマシンを使用してプレッシャーを処理および共有できるようにする必要があります。ただし、システムの整合性を確保する必要があります。これが分散設計です。次に、サービスアーキテクチャの進化の歴史を見ていきます。

アーキテクチャの進化1：初期のプロトタイプ

機能：アプリケーションプログラムは主に静的ファイルを読み取り、コンテンツをブラウザに返します。

アーキテクチャの進化2：データベース開発（LAMP専門）

機能：アプリケーションプログラムは主にデータテーブルの値を読み取り、htmlモジュールに入力します。シンプルなビジネスロジック、SQLを書く

アーキテクチャの進化3：javawebのプロトタイプ

機能：Tomcat +サーブレット+ jsp + mysql。戦争パッケージが世界を襲う

プロジェクト構造：ssh / ssm3層構造。

アーキテクチャの進化4：javawebクラスターの開発

機能：ハードウェアマシンの水平レプリケーションは、プロジェクト構造全体に影響を与えません。

アーキテクチャの進化5：javawebの分散開発

機能：サービスレイヤーを別のプロジェクトjarに分割します。一人で走る。ウェブサーバーは、rpcフレームワークを介して分離されたサービスを呼び出します。

アーキテクチャの進化6：javawebのマイクロサービス開発

特徴：ビジネスの観点から、ビジネスはマイクロサービスに細分され、各マイクロサービスは完全なサービスです（httpリクエストからリターンまで）。マイクロサービスでは、外部に提供する必要のあるインターフェースは、外部に公開されているrpcインターフェースにパッケージ化されています。

クラスターと分散の違い

インタビューをしていると、多くの学生がクラスタリングと分散を混同していることに気づきました。実際、それらは完全に2つのものです。

分散型：垂直方向に分割され、ビジネスは複数のサブビジネスに分割され、異なるサーバーに展開されます。これは主に、ビジネスレベルを分割し、ビジネスを分離して、サービスの高可用性と高性能を向上させることです。
クラスター：水平レプリケーション。同じサービスが複数のサーバーにデプロイされ、負荷分散が前面で使用されてプレッシャーを共有します。また、これらのサーバーの1つまたは2つがダウンしても、ビジネス全体に影響はありません。

この章では、主に高性能アーキテクチャの学習ルートと技術進化の歴史について説明します。次に、アリババの数百万人の年俸アーキテクトに必要なスキルについて話しましょう-高性能アーキテクチャ学習ルート（注）：ミドルウェア、Nginx、キャッシング、ZKなど...以下の高性能アーキテクチャの高度なスキル図を参照してください....。

注：ミドルウェア、Nginx、キャッシュ、ZKなど、アーキテクトに必要なスキルに関する次の高性能アーキテクチャ学習ルートと関連するメモはすべて、スペースが限られており、その多くはスクリーンショットですが、写真は非常に高いです-定義、内容がはっきりとわかります。そして完全なオリジナルのpdf + xmindファイル、編集者もここにそれを集めました

1.Zookeeper分散環境コマンダー

1.1飼育係の基本

ZooKeeperは、大規模なホストを管理するために使用される分散調整サービスです。分散環境でのサービスの調整と管理は複雑なプロセスです。ZooKeeperは、そのシンプルなアーキテクチャとAPIを通じてこの問題を解決します。ZooKeeperを使用すると、開発者は、アプリケーションの分散性を気にすることなく、コアアプリケーションロジックに集中できます。

1.2分散アプリケーションの利点

（1）信頼性-1つまたは複数のシステムに障害が発生しても、システム全体に障害が発生することはありません。
（2）スケーラビリティ-マシンを追加し、ダウンタイムなしでアプリケーション構成に小さな変更を加えることで、必要に応じてパフォーマンスを向上させることができます。
（3）透明性-システムの複雑さを隠し、単一のエンティティ/アプリケーションとして表示します。

1.3分散アプリケーションの課題

（1）競合状態-2台以上のマシンが特定のタスクを実行しようとします。実際、一度に1台のマシンのみがタスクを完了できます。たとえば、共有リソースは、常に1台のマシンでのみ変更できます。
（2）デッドロック-2つ以上の操作が、互いに無期限に完了するのを待ちます。
（3）一貫性がない-データの一部が失敗しました。

1.4動物園管理者関連の注意事項

ZK手書きメモ（1）：概要+ CPA +環境マッチング+整合性合意+基本的な使用

ZK手書きメモ（2）：ソースコード分析+アプリケーションシナリオ

第二に、Nginxの高い同時実行性シャントは高度な実際の戦闘

2.1nginxはどのようにして高い同時実行性を実現しますか

簡単に言えば、epollと多くの低レベルのコード最適化を使用して、非同期で非ブロッキングです。
もう少し詳しく説明すると、これはnginxの特別なプロセスモデルとイベントモデルの設計です。

2.2プロセスモデル

Nginxはマスタープロセスと複数のワーカープロセスを使用します。
マスタープロセスは、主にリクエストの収集と配布を担当します。リクエストが来ると、マスターはリクエストを処理するためにワーカープロセスをプルアップします。
マスタープロセスは、高い信頼性を確保するために労働者のステータスを監視する責任もあります
ワーカープロセスは通常、CPUコアの数と同じになるように設定されます。nginxのワーカープロセスはapacheのそれとは異なります。apcheプロセスは、一度に1つのリクエストしか処理できないため、数百または数千ものプロセスを開きます。nginxのワーカープロセスは、メモリによってのみ制限された数のリクエストを同時に処理できるため、複数のリクエストを処理できます。

2.3イベントモデル

Nginxは非同期で非ブロッキングです。

すべてのリクエストが届き、ワーカープロセスがそれを処理します。しかし、それはプロセス全体ではありません、どの程度ですか？リクエストをアップストリーム（バックエンド）サーバーに転送したり、リクエストが返されるのを待ったりするなど、ブロッキングが発生する可能性のある場所への処理。そうすれば、処理担当者はそれほど愚かな待機をせず、リクエストを送信した後、「アップストリームが戻ってきたら、教えてください、続行します」というイベントを登録します。それで彼は休んだ。この時点で、別のリクエストが届いた場合、彼はすぐにこの方法でそれを処理できます。アップストリームサーバーが戻ると、このイベントがトリガーされ、ワーカーが引き継ぎ、リクエストがダウンします。

Webサーバーの動作の性質により、各要求の寿命のほとんどはネットワーク送信にあると判断されます。実際、サーバーマシンに費やされる時間はそれほど多くありません。これは、いくつかのプロセスで高い同時実行性を解決する秘訣です。

2.4Nginx関連のメモ

Nginxコモンアプリケーションテクノロジーガイド[Nginxのヒント]

Nginxの詳細な分析

3、rabbitMQメッセージミドルウェア

（1）ブローカー：メッセージミドルウェアインスタンス。単一ノードまたはマルチノードクラスターで実行されている論理エンティティの場合があります。
（2）メッセージ：メッセージは、メッセージヘッダーとメッセージ本文の2つの部分で構成されます。メッセージヘッダーには、routing-key、priority、その他のカスタムメッセージヘッダーなどの標準メッセージヘッダーが含まれます。これらは、RabbitMQのメッセージ動作を定義するために使用されます。メッセージ本文はバイトストリームであり、メッセージの内容が含まれています。
（3）接続：クライアントとブローカー間のTCP接続
（4）チャネル（チャネル）：チャネルは、TCP接続で確立された論理（仮想）接続です。複数のチャネルが同じTCP接続を再利用して、TCP接続を確立するための大きなオーバーヘッドを回避します。RabbitMQは、各スレッドが独立したチャネルを使用することを公式に要求しており、複数のスレッドがチャネルを共有することは禁止されています。
（5）プロデューサー（パブリッシャー）：メッセージを送信するクライアントスレッド
（6）コンシューマー：メッセージを処理するクライアントスレッド
（7）交換：交換は、対応するキューにメッセージを配信する責任があります
（8）キュー：スイッチによって配信されたメッセージを受信して、コンシューマーによって正常に消費されるまで保存します。論理構造は先入れ先出しFIFOに従います。
（9）バインド：キュー（Queue）をExchange（Exchange）のルーティングテーブルに登録します。
（10）仮想ホスト（Vhost）：各ブローカーの下に複数のvhostを確立でき、各vhostは独立したExchange、キュー、バインディング、および権限システムを確立できます。同じブローカーの下のvhostは、接続、チャネル、およびユーザーシステムを共有します。つまり、同じユーザーIDを使用して、同じチャネルを使用して異なるvhostにアクセスできます。

3.1rabbitMQメッセージミドルウェア関連の注意事項

RabbitMQ-最も完全で完全なチュートリアル

RabbitMQ戦闘ガイド

4、ActiveMQメッセージミドルウェア

（1）クライアントは複数の言語とプロトコルで書かれています。言語：Java、C、C ++、C＃、Ruby、Perl、Python、PHP。アプリケーションプロトコル：OpenWire、Stomp REST、WS通知、XMPP、AMQP
（2）JMS1.1およびJ2EE 1.4仕様（永続性、XAメッセージ、トランザクション）を完全にサポートします。
（3）Springのサポート、ActiveMQはSpringを使用してシステムに簡単に組み込むことができ、Spring2.0の機能もサポートします。
（4）一般的なJ2EEサーバー（Geronimo、JBoss 4、GlassFish、WebLogicなど）のテストに合格し、JCA 1.5リソースアダプターの構成により、ActiveMQをJ2EE1.4互換の商用サーバーに自動的にデプロイできます。
（5）複数の伝送プロトコルをサポート：VM内、TCP、SSL、NIO、UDP、JGroups、JXTA
（6）JDBCおよびジャーナルを介した高速メッセージ永続化のサポート
（7）高性能クラスター、クライアントサーバー、ポイントツーポイントを保証するように設計されています
（8）Ajaxをサポートする
（9）Axisとの統合をサポート
（10）テストのために組み込みJMSプロバイダーを呼び出すのは簡単です

5、カフカの百万レベルのスループット戦闘

KafkaはもともとLinkedInの内部インフラストラクチャシステムでした。最初の開発の理由は、LinkedInにはデータの保存に使用できるデータベースやその他のシステムがありますが、継続的なデータフローの処理に役立つコンポーネントが不足しているためです。したがって、設計コンセプトの観点から、開発者は、リレーショナルデータベース、Nosqlデータベース、検索エンジンなどのデータを格納できるシステムを開発するだけでなく、データを継続的に変化し成長するストリームとして扱いたいと考えています。そして、このアイデアに基づいて、データシステム、データアーキテクチャを構築します。

Kafkaは、外部的にはメッセージシステムのように動作し、メッセージストリームの公開とサブスクライブを可能にしますが、従来のメッセージシステムとは大きく異なります。

まず第一に、Kafkaはクラスター内で実行され、自由に拡張できる最新の分散システムです。
第二に、Kafkaは必要に応じて可能な限りデータを保存できます。
第三に、ストリーム処理はデータ処理のレベルを新しいレベルに引き上げます。メッセージシステムはデータのみを送信します。Kafkaのストリーム処理機能により、非常に少ないコードで派生ストリームとデータセットを動的に処理できます。つまり、Kafkaは単なるメッセージミドルウェアではありません

Kafkaはメッセージミドルウェアであるだけでなく、ストリーミングプラットフォームでもあります。このプラットフォームでは、データストリーム（Kafkaのストリーム、別のパッケージStream処理があります）をパブリッシュおよびサブスクライブし、処理のために保存できます。これが設計です。カフカの作者のコンセプト。

5.1カフカ百万レベルのスループット実際の戦闘関連のメモ

手書きの「カフカノート」

Kafkaソースコード分析と実際の戦闘

6、Redis高性能キャッシュデータベース

6.1Redisデータ構造と関連する一般的なコマンド

キー：RedisはKey-Valueタイプの基本データ構造を採用しており、任意のバイナリシーケンスをRedisキーとして使用できます（たとえば、通常の文字列やJPEG画像）
文字列：文字列はRedisの基本的なデータ型です。RedisにはInt、Float、Booleanなどのデータ型の概念はありません。すべての基本的な型はRedisでは文字列として具体化されます。
SET：キーの値を設定し、EX / PXパラメーターでキーの有効期間を指定し、NX / XXパラメーターを使用してキーが存在するかどうかを区別できます。時間計算量はO（1）です。
GET：キーに対応する値を取得します。時間計算量はO（1）です。
GETSET：キーの値を設定し、キーの元の値を返します。時間計算量はO（1）です。
MSET：複数のキーの設定値、時間計算量O（N）
MSETNX：MSETと同じですが、指定されたキーのいずれかがすでに存在する場合、操作は実行されず、時間計算量はO（N）です。
MGET：複数のキーに対応する値を取得します。時間計算量はO（N）です。
INCR：キーに対応する値を1インクリメントし、インクリメントされた値を返します。整数に変換できる文字列データでのみ機能します。時間計算量O（1）
INCRBY：キーに対応する値を指定された整数値だけインクリメントし、インクリメントされた値を返します。整数に変換できる文字列データでのみ機能します。時間計算量O（1）
DECR / DECRBY：INCR / INCRBYと同じで、インクリメントからデクリメントに変更します。

6.2Redisの高性能キャッシュデータベース関連の注意事項

Redis高性能キャッシュ

Redis戦闘

Redisの設計と実装

6.一般的に使用されるテクノロジーと分散システムのケーススタディ（PDF）

このPDFは、分散システムの基本理論、分散システムの一般的なテクノロジ、および分散システムの古典的なケーススタディの3つの部分に分かれています。

最初の部分では、主に分散システムの基本的な理論的知識を紹介し、スレッド、通信、一貫性、フォールトトレランス、CAP理論、セキュリティと並行性など、分散システムを設計するときに考慮する必要のあるいくつかのパラダイム、知識ポイント、および考えられる問題を要約します。およびその他の関連コンテンツ。同時に、最近人気のあるRESTfulスタイルのアーキテクチャ、マイクロサービス、コンテナテクノロジーなど、分散システムの一般的なアーキテクチャについても説明します。
第2部では、主に分散システムアプリケーションで頻繁に使用されるいくつかの主流テクノロジーをリストし、これらのテクノロジーの機能と使用法を紹介します。これらのテクノロジーは、分散メッセージサービス、分散コンピューティング、分散ストレージ、分散監視システム、分散バージョン制御、RESTful、マイクロサービスを対象としています。、コンテナおよびその他のフィールド。
第3部では、淘宝網やTwitterに代表される、国内外の有名なインターネット企業の大規模分散システムの事例を選択し、そのアーキテクチャ設計と進化のプロセスを分析します。この部分は、散在する技術の「串」を作ることに相当します。読者が技術理論を組み合わせて実際の戦闘の効果を見ることができるように、第2部のポイント」。

総括する

すべてのプログラマーの友人は彼自身の建築家の夢を持っていますが、夢はしばしば美しく、現実は非常に残酷です。あなたが一生懸命働いたり苦労したりしないなら、あなたは一生草の根に立ち寄るかもしれません。たぶん、多くの友人は、プログラマーも若い人であり、彼らは年をとると登ることができず、彼らの脳と体が追いつくことができないと言うでしょう。そういうわけで、あなたがまだ若いうちに自分を利用して、チャンスをつかみ、一生懸命働きなさい、そうすれば明るい未来があなたと手を振る機会を持つでしょう！もちろん、これは私の個人的な意見を表すだけです。結局のところ、100人の人々が100の異なる心を持っている場合、何千もの異なるアイデアがあります。

しかし、たった一文、あなたがまだこの行にいるのなら、あなたはまだプログラマー（元）であり、上り坂に行きたいと思っています、多分私のアリババ百万年俸必需品-高性能アーキテクチャ学習ルートはあなたのためかもしれません助けた。