内容：
まず、分散システムは何ですか？
第二に、なぜ分散型システムアーキテクチャを行きますか？
第三に、システムがどのように分割するには？
第四に、技術的な課題の後に分散をもたらしますか？
まず、分散システムは何ですか？
分散システムアーキテクチャの話をする前に、のは、分散システムが何であるかを見てみましょうか？
元我々はシステムを持っていると仮定すると、コードの3000万人以上の行の量。20は、現在小さなシステム、コードの10,000行にわたって各小システムに分割されます。
元のコードを直接別のマシンに配備20の小規模システムに今開いているJVMのメモリ・コールを、歩くSpringフレームワークに基づいている間、その後、RPCコールベースの分散サービスフレームワーク（例えばダボなど）、インターフェースとインターフェースに従事要求およびネットワークを介した通信に応答して間。
分散システムは、機能がネットワークを介して通話を行うためのルームサービスで、我々は以下のチャートを見て非常に重要です。
また、分散システムは、おそらく2つのカテゴリに分けることができます。
（A）、分散システムの底
例えばようにHadoopのHDFS（分散ストレージシステム）、スパーク（分散コンピューティングシステム）、嵐（分散ストリーム・コンピューティング・システム）、elasticsearch（分散型検索システム）、カフカ（分散型パブリッシュ・サブスクライブ・メッセージング・システム）と。
（II）、分散ビジネス・システム
複数のサブシステムに分割する分散サービスシステム、Java開発システムと元のチャンクは、複数のサブシステムとの間の各呼び出しは、大きな全体的なシステムを形成します。
例えば、モジュール、金融モジュールを残して、あなたが許可モジュールが含まれているOAシステム、スタッフのモジュールを行うだろうと仮定し、モジュールの束を含むプロジェクトは、モジュールとモジュールの間でお互いを呼び出すことになり、1マシンの展開。
今、あなたはシステム、金融システム、4系統、4つのプロジェクトは、4台のマシン上で展開されたが、システム、機関システム、従業員のシステムを開いたままに彼を置く場合。
金融システムを呼び出して、システムコールを残して、要求、スタッフの許可制度を呼び出すためのシステムを完成するための要求が来た後、4つのシステムは、物事の一部を完了しました。
最後に、4つのシステムでは、この要求が完了したことを考えるのは、それから、仕事を終えました。これは、分散ビジネスシステムと呼ばれています。
ここでも、私たちは、1枚の画像は、上記のプロセスを感じて来ます：
第二に、なぜ分散型システムアーキテクチャを行きますか？
一部の学生がお聞きしたいことがあり、私は正常に稼働しているサーバーを持って、すべてのシステムのプロジェクトのすべてがはるかに良くなります。なぜ私たちは、リモート行くためにお互いを呼び出し、任意の分散システムアーキテクチャに従事しなければならない、多くの作業を追加しているようですか？
ここで私は、私は一度この問題について話をする、例えば、悲劇的な経験で働いていた会社としています。
何年も前に、分散型アーキテクチャをしていない時点で、同社のさまざまなビジネスラインは「煙突」プロジェクトであることが私に垂直です。
インターネットの急速な発展に伴い、同社のビジネスも発展を続け、登録ユーザーは、Webアプリケーションの機能性を高め、APP、マイクロチャネル、セルフサービス端末などがそれぞれ、モバイルインターネットの特に増加したアクセスチャネルの開発を拡大していますビジネスの新しい種類は、新たな需要の継続的な流入は、システムは、さまざまな問題が発生しました。
最初は、制御されていないプロジェクトは、多くの場合、紛争に対処するために、様々なコードをマージし、DAO層は、コードに使用の多くをコピーしている肥大化し、増加し、システムの複雑化、コードの行数千人の大規模な数百、開発者の数十、サービス層となっています非常に時間がかかります。
私は、多くの場合、再テストする必要があり、自分のコードにつながることも問題であり、他の人が私のインターフェイスを呼び出し、トラブルの死を自分のコードを変更します。
次に、各放出系は皆、一緒に誰もがtenterhooks上のオンライン準備ができていた一緒にリリースされたコードの行数十万人が、オンライン何百何千行ものコードの、ライン上のすべての時間は、チェックの多くを行うために例外を処理するために多くの問題を持っていますハイテンションは、ほとんど崩壊し作られています。
私は今、新たなビジネスを持っている場合と、それは、そのような春の最新バージョンにアップグレードすると、その依存関係をアップグレードする予定で、これは他の人のコードの誤りではなく、無差別の変化技術につながる可能性として、それは、十分ではありません。そして、あなたはWebプロジェクトを起動するたびに数分かかる場合、その地域のIDEのデバッグコード一度は非常に痛みを伴うだろう。
第二に、ユーザトラフィックの増加に伴い、システムの負荷圧力が大きくなり、インスタンスの数を増加させる効果に圧倒されつつ、拡大をもたらすことができる追加のハードウェアは少し、障害の発生しやすい、非効率的です。このシステムは、企業の事業開発のニーズを満たすことができ、テストサイクルの品質が長くなっている保証することもますます困難です。
これらは、同社が以前に過去の「痛い」のイベントの一部で働いていた、一般的に言えば、問題は主に以下の分野に反映されます。
（A）、アプリケーション・コードは、重度の困難拡張を結合します
（二）、インタラクティブな開発サイクルの新たな需要が長い、重い作業負荷テスト
（C）の開発に参加するための新しい同僚は、システムに慣れるまでに時間がかかります
（4つ）、アップグレード及びメンテナンス（変更は、システム全体をアップグレードする必要が任意の時点で）も非常に困難です
（E）、システム性能難しく、低可用性と不安定。
我々は深く結合系の痛みを理解する必要があるためまあ、今のシステムは、スプリットをもたらす利点を見てみましょう：
まず、システムは、将来を分割し、全世界が爽やかな感じになります。
20サービス、コードの平均1から3000000本のライン上サービス、別のマシン上に展開各サービスに分割を想定したコードの行の数千のシステム何百、。20件のプロジェクトは、20は、誰もがそれに独自のサービスを維持していること、コード、20の開発者のgitリポジトリを使用します。
因为是自己独立的代码，跟别人没关系。再也没有代码冲突了，爽！
每次就测试我自己的代码就可以了，爽！
每次就发布我自己的一个小服务就可以了，爽！
技术上想怎么升级就怎么升级，保持接口定义不变，输入输出内容不变就可以了，爽！言葉を要約すると、分散システムの分割後、大幅に複雑な大規模システムの開発チームの効率を高めることができます。
第三に、システムがどのように分割するには？
一般に、システムが分割され、最初に、システム全体に精通している必要があります。多くのラウンドは、アイデアは大粗粒のモジュールが開いて各分割の前に最初の分割で分割行くことができます。
例えば、システムは、その上の電気の供給業者の発注システム、商品・システム、店舗システム、会員システム、マーケティングシステム、決済システムとに分割することができます。
各システム後に、彼らは、このような注文システムとして、ますます複雑になる可能性はさらにショッピングカートシステム、在庫管理システム、価格システムを分割することができます。
一般的には考えに基づいており、実用的な教訓は、ドメイン駆動設計だけでなく、業界の慣行にいくつかの一般的な参照を学んだ、我々は分割を議論するために来て、徐々に最適化された、マルチラウンドスプリット、小さなラン、そして最終的には比較的良好な状態を達成されました。
第四に、技術的な課題の後に分散をもたらしますか？
第一は、国内の主流又はダボとばね雲の点で、分散サービス・フレームワークの選択です。
のは、主にこの問題を解決するために使用されているサービスフレームワークを使用して考えてみましょうか？あなたは雲の分散アーキテクチャは、それを行うことができますか春ダボない場合は？
ないダボや春のクラウドサービスフレームワークはもちろん可能であるが、これは自分自身を処理するために多くのことを要求します。
例えば、各サブシステムのインターフェース呼び出しが安らかに行く、それはHTTP呼び出しで、ときにそのような過去の転送などのオブジェクトは、私たちは混乱にJSON、行うにはどのように失敗し、再試行した後、最初のコールを所有している必要がありますか？
また、一般的には、展開をクラスタ化され、ターゲット・システムの複数のインスタンスがある場合、我々はまた、ランダムターゲット・マシンの複数から選択された各を呼び出す方法、ロードバランシングアルゴリズムを書きたいですか？
ターゲット・システムの拡張は、サーバの障害またはオフラインの例の新しいインスタンスを展開した場合にも、どのように動的に呼び出し側がそれを知覚できるようにするには？そう自分自身いじりそのような多くの質問、そうでない場合は、サービスフレームワークは、さまざまな問題が発生します。
あなたにそれを提示するの景色を上記のプロセス：
あなたが1つの分散サービスフレームワークを選択した場合、我々は、次を理解するためにいくつかの問題を実行するダボ必要性などのフレームワークの基本原則の深さの使用を習得する必要があります。
（A）、作品をダボ？
（二）は、サポートのシリアル化プロトコルをダボ？
（三）、ダボ負荷分散と高可用性戦略？ダイナミックプロキシポリシー？
（四）、SPIの思考のダボ？
（V）、ダボサービス管理、サービスの劣化、故障の再試行タイムアウトと再試行をベースとする方法？
（六）、冪等はどのように（重複したカード番号を作成することはできませんリピートオーダーを生成することができない、などの控除を繰り返すことはできません）サービス・インターフェースを設計することダボ？
（七）、要求されたサービス・インターフェースを確保するためにどのようにダボのため？
（八）、のフレームワーク同様のダボRPCあなた自身をどのように設計しますか？
このようユーレカ作品として、あまりにも、春の雲を使用しますか？宣言型の原理を呼ん装いますか？だから、さまざまな基本原理に知ってもらうこと。
技術的な問題を解決するための分散アーキテクチャを歩いた後、他の一般的ながあります。
（A）、分散セッション
（二）、分散ロック
（C）、分散トランザクション
（4個）、分散検索
（五）、分散キャッシュ
（VI）、分散メッセージキュー
（七）、統一されたコンフィギュレーション・センター
（8個）、分散ストレージ、データベースサブライブラリサブテーブル
（ナイン）、電流制限ヒューズ、降格など。
これらの質問は、言って深く行く、各点は、ここでは一つ一つが、これらの分散アーキテクチャの下で、様々な技術的問題とのチャット、我々はいくつかの記事をバック続ける、展開することはできません、N記事を精緻化する必要があるかもしれません。