著者つい最近経験したまま、6月19日の卒業生で、終了し、ホームオフィスの間に何もない、マイクロサービスとspringcloud初心者の白いくつかの洞察のためのあなた自身の会社アップロールは、楽しみにして間違った場所を言ってきました偉大な神の補正。
どのようなマイクロサービス？
同時に新しい何かについて、あなたはそれが表示される背景を見たいことがあり、すべての問題を解決するために表示されます。
Java Webアプリケーション開発プロセスでは、より多くの典型的な建築様式は、フロント（フロントエンド）とバックエンド（バックエンド）同じプロジェクト上のすべての下のすべてのファイルにある、またはかかるのGradleの再生などMavenのビルドツールを使用して戦争へのパッケージ、またはサービスが、コンテナを実行してTomcatの桟橋に投げ込ま。次のように：
このアーキテクチャの欠点は、次のとおりです。
1複雑かつシンプル。使用I最初の会社はSSHアーキテクチャ（春+ Strutsの+休止状態）で、典型的なjavawebアプリケーションは、多くの場合、手動で戦争を戦うために、コードの行を変更する必要があり、その後、サーバーに投げ込まれたの開発では、Mavenのプロジェクトの依存関係を管理するために有用ではありませんでしたTomcatの、検索プロセスのkillプロセス、Tomcatを再起動します。すべての私たちのプロジェクトチームの限り、誰が再起動するように何かを言う必要があるように、グループ、テスト中に他のグループが多いインターンバグを持っているので、ハハ、私たちは、ローカル接続タイムアウトを開発し、この時間はあなたが出て行くと煙ことができます。
2.技術を拡張し、更新するために行う助長されていません。これは、Javaを使用して、唯一のプロジェクト構造、バックエンド理解しやすいですが、それが唯一の唯一のPHPのPHPとJava言語、することができ、復興事業に一日一回、Naogua紫はあなたに乾腐を与えることができます。
3.維持し、理解するのが難しいです。想像し、企業への学生の卒業時にブレークポイントをデバッグするときにブレークポイントをデバッグしたい理由、プロジェクトがより多くのダースのバックエンド・モジュールよりも、パッケージの各数十、あなたは忘れることがあります。
-モノマー地獄の後、業界がよりよい解決策を探しています、マイクロサービス（MicroService）がされて入ってきた
マイクロサービスアーキテクチャを言うことができる機能、アーキテクチャパターンの一連のサービスに分解する方法です。例えば、あなたは顧客サービス、コミュニティサービス、インテグレーションサービスなどに分けることができるブログシステムを持っていたされ、単純な理解以上に分け、各サービスは、特定のコンテナ内で実行することができ、単一のアプリケーションすることができ、達成するためにデカップリング用途。
図は、上記の単純なスケッチIは、ネットワークプロトコルを介して、サービスに応じて、複数のモノマーのアプリケーションとサービスに分割元が、各サービスは、Webアプリケーションに相当し、それらの間の情報インタラクションをマイクロサービスを描いています、それは多くの場合、このジレンマを再起動して、プロジェクト全体を待つ時間にサービスA、Cの開発を変更していないだろう。
一般的にビジネス要件に基づいてマイクロサービス部門、サービスの粒度の概念があります。サイズは、あなたは、単に実際には必要ないが、2つのサービス、にDAOとサービスのスプリットにログインするための簡単なユーザーインターフェースであれば、厚すぎると小さすぎることはなく、プロジェクト全体の複雑さを拡大すべきではありません。巨大な電力供給システムの反対側唯一の倉庫サービスと注文サービスへのあなたが、順番ではない、このカップリングは依然として非常に高いです、小さなモジュールに一体化し、メールなどがあるかもしれません。
SpringCloudは何ですか？
Springcloudピボタルチームはマイクロサービスアーキテクチャのプログラムを構築する上での基礎NetflixのOSSに基づいて導入されます。
まず、SpringCloud箱から出していないフレームに使用できるが、初心者の多くでは、この時間は、多くの場合、この概念を混同します。、SpringCloud思考、方法、マイクロサービスアーキテクチャコンポーネントのさまざまには、例えば、統合作るために、業界を成熟します（KFCハハに類似）マイクロサービスアーキテクチャの概念の完全なセットや家族のバケツ、あるとしてあなたは、理解することができます自分のバケット内のサービス管理、サービスゲートウェイ、サービスヒューズ、統一構成、コンポーネントの通信サービス、リンク追跡、サービスの監視、および洗練されたマイクロサービスアーキテクチャが必要なので、springcloud場所それらは、ホイールを作成繰り返しません。
マイクロサービスに目を向けると、我々はそれにいくつかの中核となる概念を言及する必要があります
。1.サービス管理
私たちが最初に遭遇したときのマイクロサービスアーキテクチャの構築を開始した問題があるときは：どのようにアクセスし、サービスプロバイダが提供する通話サービスへの消費者として、サービスプロバイダとして、彼らが提供するサービスはので、他の消費者のことを確認する方法コール。我々はこの問題を解決するための言語レベルの開発に直接であるの伝統的な用途では、例えば、クラスA - >コール- > Bクラスメソッド、それはマルチモジュールプロジェクトの場合でも、唯一と仮定して、リモートコールのHttpクライアントツールのために使用することができます人前は100のインスタンスは、あなたは100ランダムなアドレスおよびサービス呼び出しを達成するためにそれを使用するが、それはあなたが今、明日まで待つ必要がないことがコード例でストレージアレイを使用している、100台のマシンに配備されたましたこのアプローチは、自分を恥じるだろう。マイクロサービスアーキテクチャでは、各サービスは、それらが互いを知っているどのように、複数のインスタンス、およびオンラインノンストップで組立ラインオフこれらの実施例であってもよいですか？明日はあなたがあるため、巨大なトラフィックのではないだろう知っているし、いくつかのサーバーに展開サービスを買っていないため、物理アドレスは（聞かないで、お金ようお願いいたします）、確かに望ましいことではありません。サービスがオンラインでない場合は、ネットワークを呼び出すときに、そして最終的に失敗につながる、長い待ち時間になります。
サービス管理は、上記の問題を解決するために提唱されています。サービスは、消費者は、プロバイダの物理アドレスを知る必要がないことがわかっを通じて、あなただけ明確に定義されたサービス名を実装することによって実現されるサービスを呼び出すことができます。プロバイダは、彼らのサービスを気にしない、最終的に誰が呼び出します。サービス登録メカニズムは、情報サービスは、サービス管理サーバに話すに提供されるオンライン登録時のサービスプロバイダを許可することであり、その情報の時に通知する管理サーバをオフラインに間違ったアドレスを入力しないトラフィック、インスタンスを削除しました。
2.マイクロサービスの負荷分散
、負荷分散のためには、図に理解することができます。従来のアプリケーションは、入口のユーザによって要求された負荷分散装置（nginxの）を負荷分散を実現してもよいです。しかし、マイクロサービスアーキテクチャでは、このアプローチは、ユーザが要求を考慮していないという理由だけで、現実的ではありませんが、また、サービス間のコールの負荷を考慮する必要がありますが、私たちはこの方法を続ける場合は、この時点で、それは確かにシステムが増加します構造の複雑さ、そしてあなたは、サービスがどのように変化するかのあなたの例を期待することはできません。したがって、マイクロサービスコールの負荷のための別の方法を見つけるために、ニーズのバランスを取ります。そのため、業界では、トラフィックが自分のポリシーに従って達成するために、クライアントで来るサービスコンシューマクライアントで管理サーバーのすべてのサービスのリストを保存他のインスタンスがあるという考えをクライアントのロードバランシングを提案しました。
3.統一入り口マイクロサービス
その後、まずマイクロサービスアーキテクチャの選択は、そのようなサービスとして、1つか2つのインスタンスことができない場合は、エンタープライズアプリケーションのインスタンスの数十を有していてもよく、サービスはより微細で、サービス全体で数十万人があり、質問、あなたはあなただけの比較的明確な少数の担当であなたを果たすことができるが、MM？（PS。ええお母さんの先端の心理的な影については考えていない、バックエンドエンジニアは、私はそれが複数のサービスを扱うことを覚えておきたいです。 ...）友情のこの時間は、船を回すためになるかもしれないと述べました。フロントエンドまたは第三者のように、これは間違いなくあなたは非常に多くのマイクロサービスが対処したくないものです、ヘルプクライアントに統一されたエントリーのマイクロサービスを提供する必要上、この時間は、事前に定められたルールをルーティングベースのサービスのニーズにルーティングされます。
4.フォールトトレラントマイクロサービス。
フォールトトレラントは、実際には、別の方法もヒューズと呼ばれています。、想像して何のシステムの回路のヒューズが存在しない場合、その後、温度が回路線で高すぎる直接燃やす、これは非常に恐ろしいことで、そのマイクロサービスアーキテクチャでは同じです。初期の建物からマイクロサービスアーキテクチャは非常に分散化される運命、分散アーキテクチャは、ネットワークの広がりアウト間のサービスコールは、下流のサービスの数を含むサービスを呼び出すことが可能性があります。電力供給システムの中で、100件のスレッドと同等の100シングルユーザー要求が存在すると仮定して、サービスに関連する次のシングルの受注を開始し、あなたは、単一の統合サービス、倉庫保管サービス、オーダーサービスで対応する株式を控除した後、倉庫保管サービスを通知する必要があり、通知および統合サービスは、あなたがそう吹き例存在しない場合に、ダウンによるクラッシュや理由にインテグレーションサービス、ネットワークインテグレーションサービスを呼び出すときに、ユーザーが唯一の訪問タイムアウトするまで、インターフェイスは円でラウンド予定されている見ることができると仮定して、ユーザーのポイントを増加させた後、 500エラーのうち、どのような地獄、手紙の山。ユーザーは膨大な量の下にある場合は、すべてのスレッドが、業界の多くの古典的な「サービスなだれ」現象を引き起こし、その上のシステムがクラッシュし、メモリオーバーフローまでここに統合サービスで立ち往生しています。
サービスのヒューズを使用すると、今回はタイムアウトと再試行の無効を検出した後、私たちは事前に比較的友好的な応答を自分の利益を定義することができ、またはそれはまでは、データベース内のレコードを保持する、統合サービスのタイムアウトルールを指定することができます復旧後にネットワークデータを手動で変更することができます。はい、フォールトトレランスは、この事をやっています。
5.マイクロ統一設定サービス
プロジェクトは複数の設定ファイルであってもよいし、単一のアプリケーションでは、同じ項目の下に変更し、一元管理することができます。または、別々に各サービスで管理されたサービスインスタンスの数百の、顔を分散場合にはマイクロサービスアーキテクチャ内のどの起因マルチサービス番号に、このときの同じ設定データ等が存在し得る場合、この管理難易度は間違いなく非常に大きく、あなたが巨大な難易度の設定を変更したいファイルをプレビューすることができます。そして、私たちはとても大きな変化や混乱のサービスを引き起こす可能性があり、各システムの各ファイルの設定を変更する必要はありません。
6.マイクロ監視サービス。
柔軟で強力なマイクロサービスは、開発者のための夜明けをもたらし、両刃の剣であるだけでなく、それをもたらす「悪夢」。それは一つのプロジェクトの下で、全体、すべてのものとして、ゼロの概念であるため、単一のアプリケーションで一般的なデバッグおよびトレース分析は、問題ではありません。追跡の重要性と分析のための呼び出しは、問題を迅速に見つけることができ、それが正式に立ち上げを適用するための時間である場合は特に、優れたログ分析があり、私たちはすべてのノウハウを言っていないと信じています。しかし、マイクロサービスのシナリオでは、なぜなら、次に、どのようにすべての、サービスの下流の複数のサービスとの間に存在し、各サービスは、独自のログを持っていてもよい上記コールマイクロサービスの、困難です統合ログシステムにログの統合は、これは非常に大きな課題となります。もちろん、このマイクロ監視サービスでspringcloudは今よりELKは、システムログに生まれたテクノロジー・スタックのために設計されているなど、ログの集約、視覚化ログ分析、コール・リンク・トラッキング・ソリューションなどを提供し、強力なマイクロサービスを構築するために考えることができます監視システムは、強力な支援を提供します。
それは、実際には、私はちょうど彼らの浅い理解は、心の中でベアリングが、その核となるアイデアや、さまざまなシナリオを理解しなければならない言語の学習を開始、任意の成熟のフレームワークを言われたspringcloudとマイクロサービスの子供の靴を勉強したいと述べましたビジネス上の問題や出産の多様性を解決し、それがマイクロサービスアーキテクチャであるためには、良い解決策をspringcloud。あなたは私はあなたが修正を願ってのご質問がある場合は、バックからのスタート、最初のブログのビットみすぼらしい、少し疲れた戦闘の関連Springcloudを構築し、更新していきます。
少なくとも最後のではなく、話は安いです、私のコードを表示
