springcloud-コンセプト

springcloud-コンセプト

 

A.アーキテクチャの進化

モノマー分散アーキテクチャアーキテクチャ---- ---- SOA（eg.dubbo）サービスのガバナンス構造---- microService

 

インターネットの発展に伴い、規模のWebアプリケーションを展開し、最終的には技術的な圧力になってする需要の急増をもたらし

システムアーキテクチャとそのためには、アップグレード、反復を進化させ続けます

1.1集中型アーキテクチャ

サイトのトラフィックが少ない場合には、一つだけのアプリケーションは、すべての機能は、コストを削減し、ノードを展開するために一緒に配備されています。この時点で、プロジェクト開発するためのキーとしてCRUDデータアクセスフレームワークのワークロード（ORM）を簡素化します。

 

 

 

問題：

• コードのカップリング、開発と保守の困難
• 異なるモジュール用に最適化対象外
• ない水平展開
• シングルポイントフォールトトレランスが低い、貧しい同時実行

 

1.2垂直分割

トラフィックが徐々に増加すると、単一のアプリケーションは、需要を満たすことができない、高い同時実行性とビジネスニーズに対応するため、この時間は、我々は、ビジネス機能に応じてシステムを分割しました：

 

 

 

 

 

利点：

• スプリットシステムは、トラフィックの共有を実現するために、並行性の問題を解決するために
• 異なるモジュール用に最適化することができます
• 便利な水平方向のスケーリング、負荷分散、フォールトトレランス率の増加

短所：

• 互いに独立したシステム間で、開発効率に影響を与える、開発作業の重複がたくさんあるだろう

1.3分散サービス

より多くの垂直アプリケーションとして、アプリケーション間の必然的な相互作用は、独立したサービスとして、コアビジネスの外に描画され、徐々にフロントエンドアプリケーションをより迅速に変化する市場ニーズに対応するため、安定したサービスセンターを形成します。この時点で、分散型サービスの多重化および統合を高めるために呼び出すことが鍵です。

 

 

 

利点：

• 基本的なサービスは、抽出システムとの間で互いを呼び出す開発やコードの再利用の効率を改善しました

短所：

• 関係を呼び出すシステム間の結合度が高いが、維持するのが難しい複雑です

 

 

1.4サービス管理アーキテクチャー（SOA）

 

 

 

SOA：サービス指向アーキテクチャ

より多くのサービス、キャパシティ・アセスメント、リソースおよびその他の小さなサービスの問題の廃棄物が徐々に浮上している、派遣センターは、リアルタイム圧力管理クラスタ能力へのアクセスを向上させるクラスタの利用率を改善する必要性に基づいて、今回のように。この場合、キーがある（SOA）マシンのスケジューリングとリソース管理センター利用率を向上させるために使用

前に問題がありましたか？

• より多くのサービス、各サービスのアドレスを管理する必要
• コール関係は依存関係を整理して、複雑で困難な
• あまりにも多くのサービス、サービスのステータスが管理することは困難である、サービスの動的管理に基づいていません

どのようなサービスは、ガバナンスのですか？

• サービスレジストリは、人間の記録なし自動登録およびサービス検出、サービスのアドレスを達成するために
• 自動サブスクリプションサービス、サービス自動プッシュサービスのリストは、透明性を呼び出し、依存関係を気にしません
• ダイナミック・モニタリング・サービス状態監視レポート、人間のコントロールサービスの状態

短所：

• ルームサービスは依存関係、一度リンク誤差が大きく影響するだろう
• サービスの複雑な関係、運用、保守、テスト、展開の困難、DevOpsチームのアイデアを満たしていません

1.5マイクロサービス

 

最後に、現在のマイクロサービスへと進化

 

 

II。マイクロサービスを提供しています

彼は、SOA、英語の翻訳は、サービス指向である以前に述べました。マイクロサービスは、サービスはそう、システムに分割されています。だから、非常に2を混同しやすいが、実際にいくつかの違いが不足しています：

マイクロサービス機能：

• シングル責任者：各サービスは、独自のビジネス能力に対応したマイクロサービスなので、単一の責任
• マイクロ：スプリットサービス小型マイクロサービスは、例えば、ユーザがサービスとして管理することができます。各サービスは、「完全に形成される。」小さいですが、
• サービス指向：サービス指向は、各サービスは、外国のサービスインタフェースAPIの残りのスタイルを公開しなければならないと言うことです。、技術サービスを気プラットフォームや言語とは何の関係もありません、休息を提供するためのインタフェースである限り、どのような技術によって限定されるものではありません。
• オートノミー：自治がお互いを乱すことなく、互いのサービスの独立の間で言っています
• チームの独立：各サービスは独立した開発チーム、あまりないの数です。
• テクノロジーの独立：それはサービス指向であるため、残りのインタフェースを提供する、他の人とどのような技術を妨げることはありません。
• 分離の終了前と後：前面および分離開発の後端、レストは、バックエンドへの統一されたインタフェースを提供し、もはやPC、異なるインターフェイスのモバイルセグメント開発されていません
• データベースの分離：各サービスは、独自のデータソースを使用しています
• 独立した展開、コールがあるものの、サービスが、サービスを行うためには、他のサービスに影響を与えずに再起動しました。継続的インテグレーションと連続的送達を助長します。各サービス・コンポーネントは、独立した再利用可能な、あるいは、結合を低減、維持が容易です

 

 

 

 

安らかなスタイル：統一要求パス、要求異なる方法、異なる操作

 

 

三.RPCおよびHTTP

 

それはマイクロサービスやSOAであるかどうか、私たちは、サービス間の長距離通話に直面しています。そして、リモート呼び出しのルームサービス、何でしょうか？

一般的なリモート呼び出し、次の2つの方法：

• RPC：リモートリモートプロシージャコールをコールプロデュース、同様のRMI（リモートメソッド呼び出し）があります。カスタムデータ形式、ネイティブのTCPベースの通信、高速かつ効率。初期のWebサービス、今人気のダボは、RPCの典型的な代表です。
• Http：HTTP、実際にTCPに基づいて、ネットワークの伝送プロトコルは、データ伝送の形式を指定します。今、ブラウザとサーバーの通信は基本的にHTTPプロトコルを使用しているクライアントは、リモートサービス呼び出しのために使用することができます。欠点は利点がサービスを提供することであり、呼び出し側は、より微細なサービスのコンセプトに沿って、任意の技術的な制限され、自由と柔軟性を持っていない、メッセージが肥大化し、カプセル化されていることです。

今人気のスタイルを休ま、それはhttpプロトコルを介して達成することができます。

あなたの会社は、すべてのJavaテクノロジー・スタックを使用する場合は、マイクロサービスアーキテクチャとしてダボを使用することは良い選択です。

逆に、マイクロSpringCloudサービスを構築し、その後、同社の多様な技術スタックならば、あなたは春の家族を好むことは最良の選択です。私たちのプロジェクトでは、我々はSpringCloudスイートを選択しますので、我々はサービス間の通話を実現するために、HTTPの方法を使用します。

 

 

IV。ロード・バランシング・リボン

リボンは、Netflixのロードバランサを発表しています

 

負荷分散の役割は次のとおりです知らせる消費者が呼び出すべきでは多くのプロバイダ

4.1問題：

念のために、我々は、DiscoveryClientを介して情報を取得し、IPおよびポートへのアクセスを取得するために、ユーザ・サービス、サービスインスタンスを開始しました。

しかし、実際の環境では、我々は、ユーザーがサービスクラスタの数をオンにする傾向があります。この時点で、我々は1回の訪問の終わりに、より多くなります取得サービスの一覧はありますか？

 

ユーレカはリボンを統合しましたので、私たちは新しい依存関係を導入する必要はありません。コードを変更します：

RestTemplateの構成に@LoadBalancedノートを追加します。

@Beanは
@LoadBalanced
公共RestTemplate restTemplateは（）{
    ）（新しいRestTemplateを返します。
}

 

 

 

怠惰な負荷に4.2のデフォルト

リボンのデフォルトは遅延ロードを使用することで、ロードバランシングは最初の訪問であるクライアントを作成することになります。多くの場合、タイムアウトが発生します。あなたが空腹をロードする必要がある場合、つまり、プロジェクトの開始が作成され、あなたが設定できます。

リボン：

  熱心な負荷：

    有効：真

    クライアント：ユーザーサービス

 

 

ファイブ。Hystrix

Hystix、で翻弄見える英語意味ヤマアラシ、とげの本体は、保護メカニズムです。

Hystrixネットフリックスはまた、同社のコンポーネントです。

 

 

 

 

だから、どのような役割Hystixですか？具体的にどのような保護に？

HystixオープンソースNetflixがカスケード障害を防止するために、リモートアクセスサービス、サードパーティのライブラリを、単離するために遅延やフォールトトレラントライブラリです。

 

マイクロサービス、サービスコールの間の複雑な関係、リクエストが一つ以上のマイクロサービス・インターフェースを実現することができる呼び出す必要があり、それは非常に複雑な通話リンクを形成します。

 

示されるように、サービス要求は、A、P、H、I 4つのサービスを呼び出し、4つのサービスは他のサービスを呼び出すことができます。

この時点で場合は、サービス例外が発生しました：

 

マイクロ-Iサービス例外が要求をブロックし、発生するなど、ユーザーが応答を取得することはできません、このスレッドのTomcatがリリースなので、より多くのユーザーのリクエストが来ていない、より多くのスレッドがブロックされます。

 

サーバは、アバランシェ効果は利用できない他のすべてのサービスで、その結果、サーバリソースの枯渇を引き起こす可能性があり、同時スレッドの限られた数をサポートしており、要求がブロックされています。

これは、一部には、それは全体の車がするために、代わりに部品まで待ちの状態に、部品を組み立てることができない原因になります、何らかの理由で利用できない場合は、別の部品を使用する必要があり、別の車を生産、自動車生産ラインのようなものですアセンブリを続けます。あなたが部品を必要とする多くのモデルがある場合は、この時点で、プラント全体は、すべての生産が麻痺した原因と、待ちの状態に突入します。絶えず拡大する範囲の部分に広がります。

Hystixには、主にアバランシェサービス低下という問題を解決することを意味します。

5.1スレッド分離

5.2サービスヒューズ

 

5.3 SOAサービスのガバナンス構造

SOA：サービス指向アーキテクチャ

 

5.4 HTTPクライアントツール

マイクロサービス選択のHttpので、我々は要求と応答の処理を実装するために自分自身を考慮する必要があります。：しかし、オープンソースの世界では、次のような、これらのことを行うために私たちを助けることができるHTTPクライアントツールをたくさん持っています

• HttpClientを
• OKHttp
• URLConnection

 

六装う（英語翻訳：迷彩）。

長距離通話を実現することができ装うを使用します

6.1ロードバランシング

統合されました

6.2 Hystrix

統合されました

6.3圧縮要求

6.4ログレベル

 

七.ZUULゲートウェイ

7.1ロードバランシング

統合されました

 

7.2ヒューズ

統合されました

 

7.3高可用性（zuulクラスタ）

 

7.4ユーレカ

統合されていません