この記事REVIEW：
- マイクロサービス選択は、技術アーキテクチャを紹介します
- K8Sコンテナ展開アーキテクチャプログラム
- ユーレカレジストリの問題のシーン
- 問題解決の方法や分析の原則
勧告を理解するために、この記事を読みます：
- レジストリの基本原理
- K8S（Kuberneters）基本概念
当社のマイクロサービスは、現在展開にドッカーをベースも、サーバーにデプロイされています。
運用・保守部門の自己開発K8Sコンテナのクラウド管理プラットフォームのセットに基づいて、プラットフォーム名はアレスと呼ばれ、私たちは、サーバリソースの効率を向上させる、物理マシンまたは仮想マシンサーバの運用・保守コストを削減し、このマイクロサービスプラットフォームに移行する準備を始めています。
アレス：アレス（ARES）
ギリシャ神話の神、オリンパスの12件の神々の一つから生まれた戦争で、彼は武道精神の化身とみなされています。非常に高速なハードウェアは次のようになります！
1、マイクロサービス技術アーキテクチャの選択導入
マイクロサービスフレームワークは、人気の春クラウドフレームワークを使用しています。
次のようなフレームワーク技術のコンポーネントは次のとおりです。
- 登録機関は、ユーレカを選びました
- Zuulゲートウェイ使用
- センターで使用アポロ構成
- ヒューズはSentienl + Hystrixの使用を制限します
ゲートウェイZuul層はHystrixは、電流制限ヒューズを行い、負荷分散を行うためにリボンを使用しています。
バックエンドサービスは、マイクロアリババは、オープンソースセンチネル制限ヒューズを行い使用しています。
その時、このような低構成された仮想マシン、ならびに高プロファイル物理サーバマシンとサーバの異なる構成、。
だから、私たちはリボン自体に基づいて、サーバは現状に基づいた設定少し改装を行うにはユーレカレジストリ管理インターフェイスに、負荷分散戦略に従い、重いウェイトを拡張し、各サーバは、ダイナミックな変化の重みをサポートすることができます。
そのためユーレカについて、レジストリを使用してこの問題のため、ユーレカフレームワークは、次導入されます。
ユーレカレジストリシンプルなアーキテクチャ図：
図は、簡単に3つの文字からなる、ユーレカの基本的なアーキテクチャについて説明します。
1）ユーレカサーバー
サービス登録、発見、ヘルスチェックを提供します。
2）サービスプロバイダ
サービスプロバイダは、
サービス消費者が検索しているので、ユーレカにサービスを登録します、
我々は、サービスプロバイダなどの容器になり、ユーレカに登録されます。
3）サービス消費
サービス消費者、
サービス消費することを可能にするために、ユーレカから登録されたサービスのリストを取得するために
、消費者へのサービスとして、我々はZuul CANゲートウェイを。
2、K8Sコンテナ展開アーキテクチャプログラム
提供される容器プラットフォームの動作および保守に関連して使用されるスプリングクラウドフレームワークを考えます。
次のようにコンテナ展開アーキテクチャを開発することです。
プロセスへのコンテナからアクセスの作成：
1）コンテナを作成します。
ミラーとバージョン、CPU、メモリ構成、設定のヘルスチェック、ログ収集、コピーのポッド番号を選択します。コンテナを作成し提出してください。
2）サービス登録
コンテナが起動すると、ユーレカに登録を開始するサービスIPとして登録SLB VIPを、適用されます。
3）ゲートウェイは、要求を開始します
要求されたドメイン、サーバーGSLB（グローバル負荷分散ソフトウェア）リボン・ロード・バランシング、ローカル登録からサービスのリストをZuulゲートウェイ、ユーレカレジストリレジストリからゲートウェイZuulプルサービスへの負荷、それらのいずれかを選択して解決DNSは、打ち上げのHttp呼び出します。
4）コンテナサービス
容器は、複数のバックエンドポッドIPコンテナにnginxの負荷分散メカニズム内部ポーリングによってSLBのVIP（ソフト負荷分散）、SLBを登録し、ポッドIPは、我々はマイクロサービス事業を展開するものです。
SLB VIPは、なぜそれを使うのか？
私たちは、界面圧測定にしており、内部K8SサービスIPのパフォーマンスのボトルネックの使用は、問題はまだそれを勉強していることが分かりました。その後、操作や内部の議論のメンテナンス、SLBを使用すると、負荷分散を実現しています。
：またことに注意して
、ネットワークを介して各部屋を取得し、再勃起を行い、最適化するため、この容器プラットフォームのK8S研究へのウィキペディアからの交通ネットワークレベル。
私たちのアーキテクチャを展開するためにそうするためにはメリットもたらします：
唯一のマイクロサービス事業の移行のために早期に目標を、そのような安定性などの要素を考慮し、正式にK8Sクラスタの外部に展開Zuulゲートウェイとユーレカレジストリ、コンテナにデプロイマイクロビジネス・サービスを開始しましたネットワークを通過することができるので、容器後に開始VIPアプリケーションは、ユーレカに直接登録することができます。
シミュレーション環境（オンライン環境事前）登録センターもコンテナプラットフォームで展開、直接ユーレカで、次は次言うので、問題に起因して問題を解決する方法のいくつかになります。
** 3、ユーレカレジストリの問題のシーン**
コンテナテスト段階を伴うSLB VIP、（ポッドのコンテナに複数のアプリケーションを含む）以前のアプリケーションの運用・保守の調整に、完成されて削除され、我々は、パフォーマンステスト環境の前にオンラインのためのシミュレーション環境を-構築し直します。
我々はユーレカの展開を終えたときには、以前削除されたアプリケーションのVIPもアップ登録した、とVIPネットワークは不合理であり、アクセスできません。
ユーレカ管理コンソールイラスト：
テストへのtelnetコマンド：
telnet 10.11.195.197 80
Trying 10.11.195.197...
telnet: connect to address 10.11.195.197: Network is unreachable
telnet: Unable to connect to remote host結果は、VIPを10.11.195.197示唆、ネットワークが到達できません。
なぜこのサービスは、それを登録することができますか？
最初は、コンテナ内の調査の後、聞いても、一時的にソリューションの多くの見通しを持っていない、VIPを決定兄と運用・保守は、ネットワークが通らない、組立ラインオフされています。
この推測によれば、ユーレカまで登録することはほとんどありません。
ユーレカは、思考メカニズムは問題ではありません考えるが、ビューのユーレカの枠組みの基本原理のポイントと組み合わせて「お尻」、上の推測は、これは起こるべきではないかについて慎重に考えるようになりました。
IPは、（送信サービスを更新するために沈黙の中で、「相棒」でなければなりませんユーレカの更新メカニズムによります向注册中心发送心跳）。
我々ユーレカServerサービス側では、メカニズムが実際にIPが更新アクションを送ってきたこのサービスを持って、ログビューに応じて、そのような登録サービス、更新サービス、オフラインサービスなどの個々のアクションを、モニターがあります。
リニューアルは、コードをリッスン：
@EventListener
public void listen(EurekaInstanceRenewedEvent event) {
InstanceInfo instanceInfo = event.getInstanceInfo();
if (instanceInfo != null) {
logger.info("renew ...." + instanceInfo.getInstanceId());
} else {
logger.info("renew ....instanceInfo is null");
}
}4、問題解決の方法と分析の原則
今では、上述の問題につながるもちろん、一人で残すことはできません、それをチェックアウトしてください。
この問題は、あなたが彼を無視した場合、遅かれ早かれ、来て何か他のものを思い付きます。
ユーレカ・サーバは、登録を受けていると更新が密かにハートビートを送信しておく必要がありますどのサービスを示し、要求されています。
ああやった最後に？
最終的にどのようにそれを報告するために、このサービスを見つけるには？
運用・保守の兄は忙しくて、それが唯一のネットワークリンクを見つけるように見える、クロールネットワークパケットを最後に確認してくださいそれが起こるかです。
ネットワークツールは、一般的に使用されるのtcpdump、Wiresharkのです。
Wiresharkのストーリーは：
おそらく10年前に起き、大手Etherealの（それを聞いているはず）の首長は、この商標を継続して使用することはできませんが、終了しますが、このツールは、その時点で人気があった、と後でギャングプロジェクトは、Wiresharkの名前が変更されます。
サーバのコマンドラインtethereal上のパケットキャプチャプログラムはtsharkのに社名を変更しました。
デフォルトでは、これらのツールが付属してミラーリングコンテナではありません。ミラーはCentOSのを使用して、Linuxオペレーティングシステムであり、yumのソースは、より便利なネットワークインストールキット、伝わってきます。
wiresharkのをインストールします。
yum install -y wireshark
インストールのtcpdump：
yum install -y tcpdump
ここでは、Wiresharkのツールは、このツールの簡単な紹介を使用します。
あなたはすべてのネットワークパケットを表示したい場合は、直接tsharkのコマンドを実行しました。
1）コマンドのヘルプtsharkのを取得します
tshark --help
2）tsharkのキャプチャモードパラメータリスト
3）tsharkのコマンド戦闘使用
ソースターゲットホストおよびHTTPプロトコル情報を印刷：
tshark -s 512 -i eth0 -n -f 'tcp dst port 80' -t ad -R 'http.host and http.request.uri' -T fields -e "frame.time" -e "ip.src" -e "http.host" -e "http.request.method" -e "http.request.uri" | tr -d ' '
パラメータの説明：
-i eth0のキャプチャカード。
すべてのアドレスを禁止し-n名前解決が（デフォルトでは、すべてをできるようにすることです）
時刻形式の-t復号結果。
「広告」は、日付と絶対時間を表し、「」絶対的な時間と日付を表し、「R」は今相対時間に最初のパケットを示し、「D」は、2つの隣接するパッケージ間の増分を表します時間（デルタ）-R設定読み出し（表示）式をフィルタ（フィルタ式を読み取ります）
-T -e指定された出力フィールド
結果：
テキストセグメントに：
[root@mas-manager-eureka-es1-66cb79bfb7-snmxm manager]# tshark -n -t a -R http.request -T fields -e "frame.time" -e "ip.src" -e "http.host" -e "http.request.method" -e "http.request.uri" | grep 10.11
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
Sep 27, 2019 00:22:05.174770971 10.124.12.169 10.124.14.4 PUT /eureka/apps/LETV-MAS-CALLER-TVPROXY-USER/10.11.195.197:80?status=UP&lastDirtyTimestamp=1569490783397
Sep 27, 2019 00:22:13.814821143 10.124.11.125 10.124.14.4 PUT /eureka/apps/LETV-MAS-CALLER-TVPROXY-USER/10.11.195.197:80?status=UP&lastDirtyTimestamp=1569407741389
Sep 27, 2019 00:22:15.180243816 10.124.11.123 10.124.14.4 PUT /eureka/apps/LETV-MAS-CALLER-TVPROXY-USER/10.11.195.197:80?status=UP&lastDirtyTimestamp=1569490783397パケット、得られた結果に基づいて、IPフィルタリングの問題を捕捉することによって、我々は参照
/eureka/apps/LETV-MAS-CALLER-TVPROXY-USER/10.11.195.197:80?status=UP&lastDirtyTimestamp=1569490783397
明確にIPで報告されている、IPソースは、IPの2番目の列ことを報告しました。
学生への情報の運用・保守、送信元IPに基づいて、手がかりを探すために継続します。
しかし、それは2番目の列は見つける、実際のサーバーIPのIPノードではないことがわかりました。IPを介したこれらの仮想IPはホスト、異なる各報告元IP、そうでも逆引きホストノード実際に属しているので。
なぜ仮想IPがあるはず？
負荷がこのホスト上のデフォルトは、単一のTCP接続のために、より多くの数をサポートすることができますので、それはより多くの仮想IPがたくさん出てくる、最大65,535 TCP接続をサポートすることができ、それが属するノードをホストするため、実際にSLB上の仮想IPノードです。10仮想IP、仮想IPのサポート65535 TCPコネクションがあると仮定し、このホストは60万人以上の10 * 65535 =接続の合計をサポートすることができます。
クラスタのK8Sいくつかのセット、各ノードは、これらの仮想IPにそれを見つける方法を、ホストの広大なプールをホストをたくさん持っています
実際には、私たちの目的は、レジストリに要求を送信し、またはあなたがネットワークパケットをつかむことで、問題を見つけるために続けることができる人を見つけることです。
これらのネットワークパケットは、K8Sクラスタノードの段階を経る一度、多くの問題、されます编写简单脚本抓包查找：
#!/bin/bash
tcpdump -i any host 10.124.14.4 -n -s 0 -X -l | grep 10.11.195>/tmp/1.txt &
sleep 20s
kill -2 %1
cat /tmp/1.txtPacketCapture結果：
重要な情報のEtherealの傍受：
11:41:56.598204 IP 10.110.157.81.54078 > 10.124.14.4.http: Flags [P.], seq 273:622, ack 218, win 245, options [nop,nop,TS val 3348483954 ecr 1420800289], length 349: HTTP: PUT /eureka/apps/LETV-MAS-CALLER-TVPROXY-USER/10.11.195.197:80?status=UP&lastDirtyTimestamp=1569394834392 HTTP/1.1ここでは10.110.157.81.54078、ホストノードのIPで、宛先アドレスは10.124.14.4、コンテナ内のアドレスユーレカ登録センターです。
リクエストが送信され/eureka/apps/LETV-MAS-CALLER-TVPROXY-USER/10.11.195.197:80?status=UP&lastDirtyTimestamp=1569394834392
、ネットワーク上10.11.195.197のIPアドレスの要求に応じてこのアドレスには到達できません。
ここでは、実際には、我々は基本的に、コンテナK8Sクラスタ内から送られなければならないことを目標としています。
K8S内クラスタに接続され、この貴重な情報ノードによると、ノード上に展開されているコンテナを探します。
K8Sクラスタ内の行ポッドコマンドを探します：
kubectl get pod --all-namespaces -o wide |grep 10.110.157.81
配置船のノードに変更します。
ユーレカの名前による操作やメンテナンスは、おそらく推測し、最終的にはコンテナの「犯人」を発見しました。
容器の中に、コンフィギュレーション・SVIP（ユーレカに登録されたIP）を確認することは10.11.195.197 IPです。
この問題は完全に密閉された容器の後、もはやユーレカレジストリ上でIPを削除するには時間をかけて、更新要求を送信し続けません。
走行時のK8S内のビジネス・クラスターがあるので、あなたは、なぜK8Sクラスタに直接行かないので、複雑な問題を有していてもよい、クラスタ内で実行上のコンテナの何百もあります。操作やメンテナンス時に一緒に試験した場合、それはよく見ていないので、血管の名前は、カスタマイズ可能です。
のは、捜査の過程見ていきましょう、不合理なもののユーレカレジストリ上のアドレスを確認したが、容器の中に報告されており、10.11.195.197:80アドレスを指して「サーバID」を報告しました。
我々はまた、次を理解することが基本となるソースコードと組み合わせることができます。
ユーレカ更新タイミング図：
レジストラと同じようにインターフェイス、後に自分のステータスを更新、それは他のクラスタノードに同期されます。
更新方法PeerAwareInstanceRegistryImplクラスは、登録方法AbstractInstaceRegistry抽象クラスのインスタンスを更新するために呼び出されます。
AbstractInstaceRegistry＃メソッドのソースを更新します：
リースは、サービスIDに基づいて、レジストリからオブジェクトを取得し、空でない場合は、契約を完了し、にlastUpdateTimestampフィールドを更新します。
ユーレカレジストリデータ構造：
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();ConcurrentHashMapの構造で、キー値マップが構造体である、アプリケーション名です。
マップ構造のキーが登録ID（IP +ポート）で、値などのアクションの種類、最後に報告された（ハートビート）の更新タイムスタンプとを含むオブジェクトのリース更新サービスです。
ユーレカクライアントとしてコンテナサービス、一定の時間間隔（デフォルト60秒）で更新登録センターを開始します。
ユーレカServerインスタンスは、定期的にハートビートが一定の時間間隔（90秒）は、更新しない場合は、サービスがレジストリアウトから削除され、正常なサービスをテストします。
彼は結論付けました。
上記の分析を要約すると、百聞は一見にしかずです。
結果は重要ではありませんが、このプロセスは、私はあなたにも、プロセスを楽しむことができると思います。
参考文献：
Wiresharkのは、ドキュメントを使用しています。
https://www.wireshark.org/docs/man-pages/tshark.html
Netflixのユーレカソース：
https://github.com/netflix/eureka
私は〜、二次元コードのスキャンコードを懸念し、あなたと一緒に成長し、公共の数の関心を歓迎し、よりエキサイティングな記事
