【3.工事開発】-マイクロサービス建設関連
本編では、マイクロサービスだけで増加するものを変える必要があると述べています.表示:サービス検出.トポロジー.問題の位置付け.監視する.制御可能:全リンク障害トレーニング/圧力測定.本サービスでは、問題の位置付け/トポロジを特定します.https://segmentfault.com/a/11...全プロセス配置/配置センター/監視:https://segmentfault.com/a/11...フルリンク障害トレーニング/圧力測定:https://segmentfault.com/a/11...その他のプロジェクト:https://segmentfault.com/a/11...
サービス発見プロセス
サービス発見と登録の記事:https://www.nginx.com/blog/se....ここでは会社の応用案だけを話します.
サービス発見
背景:既存のThriftを置き換えてすべてのIPを構成する新しいサービス、人工サービス登録:サービス発見ノードを作成し、ルーティング規則の構成;トラフィックスケジューリング;人工サービスの抜粋;1.呼び出し元の各機器にagentがある.sdk.ポケットファイル、リアルタイムファイル、disfにアクセスするローカルリアルタイムファイル、ポケットipポケットファイルの生成:1.1コードスキャンはプラットフォームの配置結果と比較し、1.2を検査する.コンパイル後にoutput/_を生成naming__/__self.json1.3.odinはdisfプラットフォームに構築する構成をポケットファイルとする.デプロイメントパッケージは、デプロイメントクラスタに基づいて、独自のクラスタをデプロイメントします.naming__/ポケットps:テイクアウト時に追加します:初回テイクアウト生成_naming__ディレクトリ、ポケットにはすべてのipが含まれており、更新プッシュ方式はスキャンチェック構成を変更し、2回目に生成する.deploy(デプロイメントノード情報、odinは異なるノードパッケージに基づいて各クラスタのipを生成する) リアルタイムファイル生成agent起動時.odin導入システムのオンラインでは、起動前にクラスタに報告されます.disf-agentへ.構成を取ります./home/xiaoju/に生成する.サービス/disfで構成変更した場合.プラットフォームで操作すると、ファイルはagentに直接プッシュされます.常態運行時、agentは定期的にファイルバージョンをスキャンしてプラットフォームに報告し、プラットフォームの検査後にバージョン異常ファイルをagent に配布する. agentとconf長接続(grpc)は を対話する.自動摘出/発見摘出:phpクラスポイントマルチサービスは1つのポートを共通にし、1つのunregesterはすべてをもたらす.オンラインになると大量のunregesterやexistがブレてしまい、機械が切られても自動的には取り外されず、ipリストに戻るだけ(サービス発見のみ.dirpcは負荷均衡、健康診断、自動摘出を担当する)発見:自動的に発見されず、サービスが開始されても正式にオンラインに行く必要はない xrpc
機能
内蔵サービス発見(endpointなどを直接取得)は多言語多プロトコル標準化ログ出力&モニタリングをサポートし、標準化サービス呼び出し規範(sdkを統一的に提供)フォールトトレランスメカニズム(フェイルオーバー、過負荷保護、負荷等化)
コード#コード#
1.endpoint情報を取得するsign等の初期2を生成する.server管理サーバー、負荷均衡、過負荷保護は論理機械室を管理力とし、minHealthyRatioなどの配置、ip/portリスト、状態、balancer filterホワイトリスト、ブラックリスト、機械室にまたがるかどうか フェイルオーバーノードに対して投票を行い、アクセス失敗+1、アクセス成功-1、票数最低は0である.各ノードの票数はその健康度を表し、値が大きいほど不健康であり、小さいほど健康であることを示している.投票数が閾値を超えると不健康とみなされ、デフォルトのアドバイザ構成は10、すなわち1ノードの投票数が10を超えると不健康とみなされる.トラフィックスケジューリングは、健康ノードのみで選択され、すなわち、非健康ノードは障害によって除去されると考えられる.また,ノードが非健康と表記されている時間が冷却時間を超えた後,次回健康リストを再生成すると,健康ノードとして扱われる,すなわち故障回復である.デフォルトのアドバイザ値は60 sです. 過負荷保護(利用可能なノードが少なすぎることを防止し、利用可能なノードが掛けられることを防止するだけ) 負荷等化は、健康ノード間の選択のみをサポートし、最小使用可能度が不足した場合、非健康ノードによって補充される.現在、Random、Hashの2つのスケジューリングポリシーがサポートされており、RRはサポートされていません.
3.send4.成功するかどうかはvote phpがapcu(バッファ)に記入されているかどうかによって、支持しなければ投票できません.このそれぞれの呼び出し先投票は異なる場所に記録され,それぞれ判断し,それぞれ摘出する.他の投票結果は互いに得られない.5.ログを記録する
Servicemeshの概要
アーキテクチャ上、データプレーンと制御プレーンの2つの部分に分けられ、データプレーンは代理マイクロサービス間の通信を担当し、具体的にはRPC通信、サービス発見、負荷均衡、降格溶断、限流許容誤りなどを含み、データプレーンはマイクロサービスフレームワークの通信とサービスガバナンス能力が独立した単独の言語に関係のないプロセスと見なすことができる.さらに汎用性と拡張性を重視し、Service Meshでは、データプレーンエージェントを孤立したコンポーネントと見なすのではなく、これらのエージェントを接続してグローバルな分散ネットワークを形成します.制御プレーンはデータプレーンを管理し、サービス発見、ルーティング、流量制御、遠隔測定統計などのポリシーを定義する.これらのポリシーはグローバルであってもよいし、あるデータプレーンノードを配置することによって単独で指定してもよい.制御プレーンは一定のメカニズムを通じて各データプレーンノードにポリシーを送信し、データプレーンノードは通信時にこれらのポリシーを使用する.
Istio
Envoyをベースに、Envoyをデフォルトのデータプレーンとし、強力な制御プレーン能力を提供します.
制御:Pilot、Mixer、SecurityはIstioの3つのコアコンポーネントであり、Istioの構成管理、ポリシー、遠隔測定、通信セキュリティの実現を担当しています.pilot:共通の配置管理能力を提供し、異なるプラットフォーム、異なる環境での配置が一致した方式でEnvoyを配置し、下にし、Envoyのライフサイクル管理を担当し、Envoyを起動し、Envoyの運行状態を監視することを保証する.起動し、他のノードなどのmixerにスケジューリングする:遠隔測定統計に関するデータと指標を収集し、サービスに対して全方位の監視を行うことができ、戦略制御:いくつかの核心資源に対して、一定の策略を通じて、異なる消費サービスとサービスの異なる実例の中で分配を行い、資源が予想通りに管理できることを保証する.
データenvoy
C++で作成されたクラウドオリジナルの高性能エッジエージェント、中間エージェント、サービスエージェントであり、マイクロサービスアーキテクチャに特化した通信バスとして設計されています.Envoyは独立したプロセスとして、各アプリケーションと一緒に実行するように設計されており、すべてのEnvoyは透明な通信グリッドを形成し、各アプリケーションがローカルEnvoyエージェントにメッセージを送信したり、ローカルEnvoyエージェントからメッセージを受信したりするが、具体的なネットワークトポロジを知る必要はない.
サービス発見プロセス
サービス発見と登録の記事:https://www.nginx.com/blog/se....ここでは会社の応用案だけを話します.
サービス発見
背景:既存のThriftを置き換えてすべてのIPを構成する新しいサービス、人工サービス登録:サービス発見ノードを作成し、ルーティング規則の構成;トラフィックスケジューリング;人工サービスの抜粋;1.呼び出し元の各機器にagentがある.sdk.ポケットファイル、リアルタイムファイル、disfにアクセスするローカルリアルタイムファイル、ポケットip
機能
内蔵サービス発見(endpointなどを直接取得)は多言語多プロトコル標準化ログ出力&モニタリングをサポートし、標準化サービス呼び出し規範(sdkを統一的に提供)フォールトトレランスメカニズム(フェイルオーバー、過負荷保護、負荷等化)
コード#コード#
1.endpoint情報を取得するsign等の初期2を生成する.server管理サーバー、負荷均衡、過負荷保護は論理機械室を管理力とし、minHealthyRatioなどの配置、ip/portリスト、状態、balancer
， ， ， ， ， ， 。3.send4.成功するかどうかはvote phpがapcu(バッファ)に記入されているかどうかによって、支持しなければ投票できません.このそれぞれの呼び出し先投票は異なる場所に記録され,それぞれ判断し,それぞれ摘出する.他の投票結果は互いに得られない.5.ログを記録する
Servicemeshの概要
アーキテクチャ上、データプレーンと制御プレーンの2つの部分に分けられ、データプレーンは代理マイクロサービス間の通信を担当し、具体的にはRPC通信、サービス発見、負荷均衡、降格溶断、限流許容誤りなどを含み、データプレーンはマイクロサービスフレームワークの通信とサービスガバナンス能力が独立した単独の言語に関係のないプロセスと見なすことができる.さらに汎用性と拡張性を重視し、Service Meshでは、データプレーンエージェントを孤立したコンポーネントと見なすのではなく、これらのエージェントを接続してグローバルな分散ネットワークを形成します.制御プレーンはデータプレーンを管理し、サービス発見、ルーティング、流量制御、遠隔測定統計などのポリシーを定義する.これらのポリシーはグローバルであってもよいし、あるデータプレーンノードを配置することによって単独で指定してもよい.制御プレーンは一定のメカニズムを通じて各データプレーンノードにポリシーを送信し、データプレーンノードは通信時にこれらのポリシーを使用する.
Istio
Envoyをベースに、Envoyをデフォルトのデータプレーンとし、強力な制御プレーン能力を提供します.
制御:Pilot、Mixer、SecurityはIstioの3つのコアコンポーネントであり、Istioの構成管理、ポリシー、遠隔測定、通信セキュリティの実現を担当しています.pilot:共通の配置管理能力を提供し、異なるプラットフォーム、異なる環境での配置が一致した方式でEnvoyを配置し、下にし、Envoyのライフサイクル管理を担当し、Envoyを起動し、Envoyの運行状態を監視することを保証する.起動し、他のノードなどのmixerにスケジューリングする:遠隔測定統計に関するデータと指標を収集し、サービスに対して全方位の監視を行うことができ、戦略制御:いくつかの核心資源に対して、一定の策略を通じて、異なる消費サービスとサービスの異なる実例の中で分配を行い、資源が予想通りに管理できることを保証する.
データenvoy
C++で作成されたクラウドオリジナルの高性能エッジエージェント、中間エージェント、サービスエージェントであり、マイクロサービスアーキテクチャに特化した通信バスとして設計されています.Envoyは独立したプロセスとして、各アプリケーションと一緒に実行するように設計されており、すべてのEnvoyは透明な通信グリッドを形成し、各アプリケーションがローカルEnvoyエージェントにメッセージを送信したり、ローカルEnvoyエージェントからメッセージを受信したりするが、具体的なネットワークトポロジを知る必要はない.