最近書き込みので、Javaの開発プロジェクトの伝統的な意味は、彼自身がここにマイクロサービスの開発に向かってゆっくりであったに深く、ソースコードの理解に加えて、ボトルネックを行われているが、マイクロサービスとの最初の接触は、どのように内部の概念を理解していませんポストはマイクロサービスの概念についての記録しますか？最終的にはマイクロサービスは何ですか？
まず、見マーティン - ファウラー提案氏はマイクロサービスアーキテクチャの説明：
マイクロサービスは、建築、パターン、および5の最も基本的な要件を満たすために、このアーキテクチャモデルです。
（1）マイクロサービスが小さいサービスの一連の組み合わせです。
（2）サービスを実行するために別個のマイクロあってもよいです。
（3）マイクロサービスのビジネスモデルが構築を行うために周りにあることを。
（4）任意のマイクロサービスは、別々の配備を必要とします。
（5）統一、集中サービス管理システム（分散管理）を避けます。
私たちは、ソフトウェアプロジェクトの進化を見てみましょう。
最初は、オールインワン（スタンドアロンシステム）、我々は理解できるが、大規模な完全なプロジェクトは、日食/アイデアを置かれ、一般的には、伝統的な産業は、この方法を採用している、ビジネスプロジェクトのすべての機能がAにパッケージ化されています戦争のパッケージ、すべてを解決するためのプロジェクトが、リンクエラー一度、すべての問題がありそうな影響を受けています。
その後、分散システムは、それぞれが、この時間は、彼は大きなを解くように注意を払うにどのような各モジュール、独立した展開に、各専門の人がいることを、それぞれが小さなプロセスを形成し、分離、各モジュール/サービスされて入ってきました他のモジュールには影響を与えない問題をモジュール戦争パッケージのすべての問題を、解決するため、ここではソフトウェアのアーキテクチャの質的変化を完了しました。
今、さらにカップリングの最も低い程度に分解するために、分散システムの技術を改善すると、別のサービスとして分類された各モジュール/ビジネスに、各サービスは、単一のサービスを提供する、独自のデータベースを有し、マイクロサービスの形になりました。この形で、ライブラリと一緒に、これらの両方のサービスを、外部の構成によって、ブートおよび破壊を分離するだけでなく、独自のライブラリを持って、したがって、この巨大プロジェクトの堅牢な動作を保証することができますでも、大規模なプロジェクトは、マイクロサービスの数百を有することができます。
進化を読んだ後、我々はマイクロサービスの利点を見てみましょう。
各サービス＃凝集十分、十分に小さい、各コード専念しやすいです。
＃小さなチームは、開発シンプルかつ効率的に開発します。
＃マイクロサービスが疎結合されている独立しており、サービス、開発と展開の機能的意義があります。
＃マイクロサービスを開発するために別の言語を使用することができます。
＃マイクロサービスやサードパーティの容易な統合、および自動展開の容易な統合を可能にする柔軟な方法。
＃マイクロサービスビジネス・ロジック・コードだけではなく、HTML、CSS混合または他のインターフェース構成要素（特に優しい分離前端と後端）。
＃各サービスは、独自のマイクロ記憶容量を有し、独自のデータベースを持つことができ、あなたも統一されたデータベースを使用することができます。
利点を持つこと、そして確かにそれはまた、独自の欠点があります：
＃分散システムの複雑さ、理解することは困難である、非常に高いです。
＃マルチサービス・運用・保守が難しい、高い運用および保守コストが（長い元のパッケージとしてとしての戦争を失って、今、あなたは、サービスの数百数十を展開すると、各サービスの状態を監視する場合があります）。
＃システムの展開は面倒を依存しています。
＃高い通信コストのシステム。
＃厳密なデータの整合性の要件。
コインは常に2つの側面を持っていますが、全体的に、それは本当に非常に高い長所と短所よりますので、大規模なプロジェクトの技術アーキテクチャの選択成長数はマイクロに向かって徐々に持っているように、もちろん、完璧なアーキテクチャはあり得ませんサービスに近いです。
これらの概念は、これらの寸法は、それがマイクロサービスアーキテクチャの必要性そして、私たちの技術スタックのプログラマが最も心配しているの問題について話を来て、終了していますか？
サービス開発：SpringBoot、春、SpringMVC
コンフィギュレーションおよび管理サービス：アリダイヤモンド、ネットフリックスや他の企業Archaius
サービスの登録と発見：ユーレカ、領事、飼育係など
サービスコール：残り、RPC、gRPC
ヒューズサービス：Hystrix、特使など
ロードバランシング：リボン、nginxの、など
インタフェースコールサービス：装うなど
メッセージキュー：カフカ、RabbitMQの、ActiveMQのなど
サービスセンターの構成管理：SpringCloudConfig、シェフなど
サービスルーティング（APIゲートウェイ）：Zuulなど
サービス監視：Zabbixの、Nagiosは、メトリック、観客など
全リンクトレース：ZipKin、ブレイブ、Dapperの、など
サービス展開：ドッカー、OpenStackの、Kubernetesなど
データフロー開発キット：SpringCloudストリーム
イベントメッセージ・バス：SpringCloudバス
これらのテクノロジ・スタックを使用すると、我々はマイクロサービスフレームワークを選択する必要があり、そしてここで私はSpringCloud（個人的な好みSPRNGああ！）、まあ、次の重大なポイントことを選択した理由は次のとおりです。
（1）社会活動の最初の春には、例えば、Tomcatサーバーとして選択し、インターネットは様々なソリューションがありますが、それはほとんど問題に対処するための任意の記事を見つけることができませんでした別のガラスの魚のApacheを選択することができます。
（2）私たちは、シーナはMotan、详细DubboXマイクロブログ、ダボの第二世代として理解マイクロサービスアーキテクチャの大きなバット会社、アリ・ダボ/ HSF（非常に快適な）、を見て、JingdongはJSF（快適北京） 。ここでは、様々なコミュニティが理解からの情報は、私は両方のクラウドへのダボ後にそれを感じるとドラゴンを入力し、春の傾向を考慮して、私は学習のクラウドを開始することを躊躇し、だけでなく、利用可能な最善すべての後に、ダボで学び、馬のお父さんああ。
ここで私はいくつかの比較フレームワークを学んだ上。
ネットフリックス/春の雲：完全なマイクロサービスフレームワーク、サポート休憩（のみサポート）、リボンは、プラグイン可能なシリアル化の選択肢の様々なサポート、RPCをサポートしていません。複数の言語のサポート
Motan：RPCフレームワークが、基本的な登録と発見（及びカップリングなど）クラスタ環境を実現するために、飼育係と領事を統合し、休息をサポートしていません。サポートRPCを、複数の言語をサポートしていません。
gRPC（グーグルRPC）：RPCフレームワーク、休憩をサポートしていません。サポートRPC;複数の言語のサポート
スリフト：RPCフレームワーク、休憩をサポートしていません。サポートRPC;複数の言語のサポート
ダボ/ DubboX：サービス・フレームワーク、休憩をサポートしていません。サポートRPCは、複数の言語をサポートしていません。
気持ちはまだ比較的信頼性の高いクラウドであるので、実際には、いくつかはありますが、私は、（それ円はすべてそれを知っている必要があり、ダボコミュニティが維持されていない）5年間の主要なクラウドやダボのコントラストが、ダボの睡眠で包括的な見ています。
さて、その後に来ますか？最初spring.ioから行く、公式サイトを入力することができないことはありません、私たちのマイクロサービスのバーをはじめ。のは、何SpringCloudはいを見てみましょう。
~~~~~~~~~~~~~~~~~~~~~~~~~公式サイトの読み込み~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
