Alibaba はなぜサービス検出に ZooKeeper を使用しないのですか?

現在、スプリットブレイン(P)下でデータの整合性(C)を確保するために登録センター自体が可用性を放棄しているため、同じコンピュータルーム内のサービスを呼び出すことができません。これは絶対に許されません。 実際には、登録センターは、いかなる理由であってもサービス間の接続を破壊することはできないと言えます。これは、登録センターの設計が従うべき鉄則です。 登録センター クライアントの災害復旧については、後ほど引き続き説明します。

同時に、この場合のデータの不整合について考えてみましょう。計算機室 1、2、3 が孤立した場合、各計算機室の svcA がこの計算機室の svcB のみを取得するとします。 IP リスト、つまり各コンピュータ室の svcB の IP リスト データが完全に一致していません。影響は何ですか?

実際には大きな影響はありませんが、この場合、すべての電話は同じコンピュータ室から行われます。この登録センター内のデータの不一致 アプリケーションが同じコンピュータ ルームを積極的に呼び出せるようにすることで、サービス コール リンク RT の効果を最適化します。

上記の説明を通じて、CAP のトレードオフでは、データの強い一貫性よりも登録センターの可用性の方が価値があることがわかります。そのため、全体の設計はむしろ AP に偏るべきです。 CP よりもデータの不一致は許容範囲であり、P の下で A を破棄することは、登録センターが独自の理由でサービス自体の接続を破壊できないという原則に完全に違反します。

サービスの規模、容量、サービスの接続性

あなたの会社の「マイクロサービス」の規模はどれくらいですか?何百ものマイクロサービス?何百ものノードを導入しましたか? 3年後はどうでしょうか？インターネットは奇跡が起こる場所です。もしかしたら、あなたの「サービス」が一夜にして有名になり、トラフィックが 2 倍になり、規模が 2 倍になるかもしれません。

データセンターのサービス規模が一定数(サービス規模 = F{サービスパブ番号,サービスサブ番号})を超えると、登録センターであるZooKeeperはすぐに下の写真のロバのように圧倒されてしまいます

実際、ZooKeeper が適切な場所、つまり粗粒度の分散ロックおよび分散調整シナリオで使用される場合、ZooKeeper がサポートできる TPS と接続数は次のようになります。これらのシナリオでは、ZooKeeper のスケーラビリティと容量に対する強い要求がないためです。

しかし、サービスの検出と正常性の監視のシナリオでは、サービスの規模が大きくなるにつれて、アプリケーションが頻繁にリリースされるときのサービス登録によって引き起こされる書き込みリクエストであっても、ミリ秒レベルのサービスの正常性ステータスが更新される書き込みリクエストであっても、書き込みリクエストが発生する可能性があります。データ センター全体のすべてのマシンまたはコンテナは、登録センターへの長い接続を持っています。ZooKeeper は、長い接続によってもたらされる接続圧力にすぐに対処できなくなります。ただし、ZooKeeper の記述はスケーラブルではなく、ノードを追加しても解決できません。水平方向スケーラビリティの問題。

ZooKeeperをベースにサービス規模の拡大という課題を解決したい場合、事業を整理して事業ドメインを縦割りにし、複数のZooKeeperに分割するという現実的な方法が考えられます。しかし、総合サービスを提供するプラットフォーム組織集団として、サービス力不足から技術バトンに応じた事業分割・運営が本当に可能なのか？

そして、これは、登録センター自体 (容量不足) がサービスの接続を破壊するという事実に違反します。簡単な例を挙げると、1 つの検索ビジネス、1 つの地図ビジネス、1 つの大手エンターテイメント ビジネス、1 つのゲーム ビジネスでは、それらのサービスは相互に排他的ですか?おそらく今日はそうだと思いますが、明日はどうなるでしょうか、1 年後、10 年後はどうなるでしょうか?将来、奇妙なビジネス イノベーションを生み出すためにいくつかのビジネス ドメインが開かれることを誰が知っていますか?基本サービスとして、登録センターは将来を予測することができず、将来の固有の接続に対するビジネス サービスの要求を妨げることはできません。

登録センターには永続ストレージとトランザクション ログが必要ですか?

必要なものと不要なもの。

ZooKeeper の ZAB プロトコルは、書き込みリクエストごとに各 ZooKeeper ノードにトランザクション ログを書き込み続け、同時にメモリ データ (スナップショット) をディスクに定期的にミラーリングして、データが確実に保存されることを私たちは知っています。一貫性と耐久性、およびクラッシュ後のデータ回復は非常に優れた機能ですが、サービス検出シナリオでは、コア データ、つまり健全なサービスのリアルタイム アドレス リストが本当に必要であることを確認する必要があります。データは永続的ですか？

このデータの場合、答えは「ノー」です。

上図に示すように、svcB で登録サービス (ip1)、2 ノードへの拡張 (ip1、ip2)、ダウンタイムによる縮小 (ip1 ダウンタイム) が発生した場合) )、このプロセス中に、ZooKeeper への 3 つの書き込み操作が発生しました。

しかし、注意深く分析すると、トランザクション ログを通じて、この変更プロセスを永続的かつ継続的に記録することは、実際にはほとんど重要ではないことがわかります。これは、サービス検出では、サービス呼び出しの開始者が、サービス呼び出しのリアルタイム アドレス リストをより重視するためです。呼び出すサービスとリアルタイムの健全性ステータス 呼び出しが行われるたびに、呼び出されるサービスの履歴サービス アドレス リストや過去の健全性ステータスは考慮されません。

しかし、なぜそれが必要なのでしょうか? 実稼働環境で利用可能な完全な登録センターには、サービスのリアルタイムのアドレスリストとリアルタイムの正常性状態に加えて、サービスのメタデータ情報も保存されるためです。バージョン、グループ、データセンター、重み、認証ポリシー情報、サービスラベルなどのサービスのメタ情報など。これらのデータは永続的に保存する必要があり、登録センターはこれらのメタ情報を取得する機能を提供する必要があります。

サービス ヘルス チェック

ZooKeeper をサービス登録センターとして使用する場合、サービスのヘルス チェックでは、多くの場合、ZooKeeper のセッション アクティブ トラック メカニズムと、エフェメラル ZNode と組み合わせたメカニズムが使用されます。サービスのヘルス モニタリングを組み合わせるには、ZooKeeper のセッションのヘルス モニタリング、または TCP ロング リンク アクティビティ検出にバインドされます。

これは、多くの場合、致命的な問題を引き起こす可能性もあります。ZK とサービス プロバイダー マシン間の TCP ロング リンク アクティビティ検出が正常であれば、サービスは正常ですか?答えはもちろんノーです！登録センターは、より充実した健全性監視ソリューションを提供する必要があります。また、サービスが健全であるかどうかのロジックは、画一的な TCP アクティビティ テストにするのではなく、サービス プロバイダーが定義できるようにオープンにする必要があります。

健全性検出の基本設計原則の 1 つは、サービス自体の真の健全性状態を可能な限り忠実にフィードバックすることです。そうでない場合、サービス呼び出し元が信じない健全性状態の判定結果は、健全性検出がないことよりも悪いものになります。

登録センターの災害復旧に関する考慮事項

前述したように、実際には、登録センターは何らかの理由でサービス間の接続を破壊することはできません。可用性の条件について、重要な質問があります。登録センター (レジストリ) 自体が完全にダウンした場合、svcB を呼び出す svcA のリンクは影響を受けますか?

はい、影響はありません。

サービス コール (要求応答フロー) リンクは、登録センターに弱く依存する必要があります。サービスのリリース、マシンのオンラインとオフライン、サービスの拡張と縮小などに必要な場合にのみ登録センターに依存する必要があります。

これには、登録センターが提供するクライアントを慎重に設計する必要があります。クライアントには、クライアント キャッシュ データ メカニズム (クライアント スナップショットと呼びます) の設計など、登録センター サービスが完全に利用できなくなった場合に備えた災害復旧手段が必要です。 ）が有効な方法です。さらに、登録センターのヘルスチェックメカニズムは、このような状況で空になるような状況が発生しないように慎重に設計する必要があります。

ZooKeeper のネイティブ クライアントにはこの機能がないため、ZooKeeper を使用して登録センターを実装する場合は、すべての ZooKeeper ノードが強制終了された場合に、プロダクション内のすべてのサービス コール リンクが実行できるかどうかを自問する必要があります。何らかの形で影響を受けていますか？そして、この点に関して定期的に失敗訓練を行う必要があります。

信頼できる ZooKeeper の専門家はいますか?

ZooKeeper は非常にシンプルな製品に見えますが、本番環境で大規模に使用したり、使いこなすのは当然のことではありません。 ZooKeeper を運用環境に導入することに決めた場合は、いつでも ZooKeeper の技術専門家に支援を求められるように準備しておいたほうがよいでしょう。最も一般的な症状は 2 つの側面にあります。マスターするのが難しいクライアント/セッション ステート マシン

• ZooKeeper のネイティブ クライアントは決して使いやすいものではありません。Curator の方が優れているでしょうが、実際には十分ではありません。 ZooKeeper クライアントとサーバー間の対話プロトコルは単純ではなく、ZooKeeper クライアント/セッション (下の図) のステート マシンを完全に理解して習得することは、それほど単純かつ明確ではありません。
  #ただし、ZooKeeper に基づくサービス検出ソリューションは、ZooKeeper が提供する長時間接続/セッション管理、一時的な ZNode、イベントと通知、および ping メカニズムに依存しているため、サービス検出に ZooKeeper を有効に活用するには、次のことが必要です。 ZooKeeper のこれらのコア メカニズムを理解してください。これは、イライラすることがあります。サービスの検出が必要なだけです。なぜそんなに多くのことを知る必要があるのですか?これらすべてを理解し、落とし穴に足を踏み入れることがなければ、おめでとうございます。あなたは ZooKeeper の技術専門家になったことになります。
• 耐えられない例外処理

ZooKeeper を Alibaba の内部アプリケーションに接続する場合、「ZooKeeper アプリケーションを接続する際に知っておくべきこと」WIKI があります。例外処理については次の説明があります:

ZooKeeper を使用する際にアプリケーション開発者が最も明確に知っておく必要があることを選択したい場合は?したがって、これまでのサポートの経験に基づくと、それは例外処理である必要があります。

幸いなことにすべて (ホスト、ディスク、ネットワークなど) が適切に動作している場合、アプリケーションと ZooKeeper も正常に動作する可能性がありますが、残念なことに、私たちは一日中あらゆる種類の事故に直面することになります。これはマーフィーの例に続きます。法則によれば、予期せぬ悪いことは、常に最も心配しているときに起こります。

したがって、一部のシナリオで ZooKeeper で発生する可能性のある例外とエラーを注意深く理解し、これらの例外とエラーを正しく理解し、アプリケーションがこれらの状況を正しく処理する方法を理解してください。

• ConnectionLossException と切断イベント

簡単に言えば、これは同じ ZooKeeper セッション内で回復できる例外 (回復可能) ですが、アプリケーション開発 オペレータは、アプリケーションを正しい状態に復元する責任があります。

この例外には、アプリケーション マシンと ZooKeeper ノード間のネットワークの中断、ZooKeeper ノードのダウン、サーバーのフル GC 時間が長すぎる、アプリケーション プロセスがハングしてアプリケーションプロセスがフルになった場合 GC時間が長すぎる場合でも回復可能です。

この例外を理解するには、以下に示すような分散アプリケーションの典型的な問題を理解する必要があります。

典型的なクライアント要求とサーバー応答では、接続が長いとき、サーバー側は、このリクエストを受け取りましたか?加工されているのでしょうか？これを判断できないため、クライアントがサーバーに再接続するときに、リクエストを再試行するかどうか (Retry) について疑問符が付きます。

したがって、接続切断イベントを処理するとき、アプリケーション開発者は、中断に近いリクエストが何であるか (これは判断が難しい場合が多い)、リクエストが冪等であるかどうか、およびサーバー側のビジネス リクエストのサービス処理を把握する必要があります。 、「1 回だけ処理する」、「最大 1 回処理する」、「少なくとも 1 回処理する」のセマンティクスには選択と期待が必要です。

たとえば、アプリケーションが ConnectionLossException を受け取り、前のリクエストが Create 操作だった場合、アプリケーションがこの例外をキャッチした場合、アプリケーションで考えられる回復ロジックは、前のリクエストによってノードが作成されたかどうかを判断することです。存在します。存在する場合は、再度作成しないでください。存在しない場合は、作成します。

別の例として、アプリケーションが存在監視を使用して存在しないノードの作成イベントを監視する場合、ConnectionLossException が発生している間に、この中断期間中に他のクライアント プロセスがノードに存在する可能性があるという状況が発生する可能性があります。が作成および削除されたため、現在のアプリケーションでは、問題のノードの作成イベントが欠落しています。この欠落がアプリケーションに与える影響は何ですか?それは許容できるものですか、それとも許容できないものですか?アプリケーション開発者は、ビジネス セマンティクスに従ってアプリケーションを評価し、処理する必要があります。

• SessionExpiredException および SessionExpired イベント

セッション タイムアウトは回復不可能な例外です。これは、アプリケーションがこの例外をキャッチすると、アプリケーションは復元できないことを意味します同じセッション内のアプリケーションの状態を確認するには、新しいセッションを再確立する必要があります。古いセッションに関連付けられた一時ノードの有効期限が切れている可能性もあり、所有しているロックの有効期限が切れている可能性もあります。 ...

ZooKeeper をサービス検出に使用しようとする過程で、アリババの友人たちがイントラネット テクノロジ フォーラムで共有した経験をまとめました



記事で適切に言及されています:

... コーディングのプロセス中に、考えられる多くの落とし穴が発見されました。 , クラスター管理に初めて zk を使用する人の 80% 以上が落とし穴に陥ります。一部の落とし穴はより隠蔽されており、ネットワークの問題または異常なシナリオでのみ現れます。暴露されるまでには長い時間がかかる可能性があります...

左に進み、右に進みます

アリババは ZooKeeper をまったく使用していないのでしょうか?あまり。

Alibaba の技術システムに精通している人なら、Alibaba が実際に中国最大の ZooKeeper クラスターを維持しており、その全体規模は約 1,000 の ZooKeeper サービス ノードであることを知っています。

同時に、Alibaba ミドルウェアは ZooKeeper のコード ブランチも維持しており、TaoKeeper は大規模な生産を指向しており、可用性が高く、監視と操作が容易です。過去10年間の様々な事業内容や生産実績を踏まえ、ZooKeeperの実績を踏まえてZooKeeperを評価する言葉を一言で言うなら、ZooKeeperは「ビッグデータコーディネートの王様」と言えるでしょう！



これは、高 TPS サポートを必要としない、粗粒度の分散ロック、分散マスター選択、マスター/スレーブの高可用性スイッチングなどのシナリオで、かけがえのない役割を果たします。ビッグデータやオフラインタスクなどの関連ビジネス分野では、ビッグデータの分野ではデータセットをセグメント化することが重要であり、ほとんどの場合、これらのデータセットは複数のプロセスによって並行して処理されます。しかし、これらのタスクとプロセスを統合して調整する必要がある点が常にいくつかあり、ここで ZooKeeper が大きな役割を果たします。

ただし、トランザクション シナリオのトランザクション リンクでは、主要なビジネス データ アクセス、大規模なサービス検出、大規模なヘルス モニタリングなどに当然の欠点があります。ZooKeeper の導入を避けるために最善を尽くす必要があります。 Alibaba の実稼働環境では、アプリケーションは ZooKeeper の使用を申請する際に、シナリオ、容量、および SLA 要件を厳密に評価する必要があります。

つまり、ZooKeeper を使用することはできますが、ビッグ データには左、トランザクションには右、分散調整には左、サービス検出には右に移動してください。

結論

ここまで読んでいただき、ありがとうございました。この時点で、私たちが ZooKeeper を完全に否定するためにこの記事を書いているわけではなく、アリババの見解に基づいているだけであることがご理解いただけたと思います。過去 10 年間の経験を基に、大規模なサービス化の実践において、サービス ディスカバリおよび登録センターの設計と使用に関する経験と教訓を要約し、より効果的な利用方法について業界に洞察を提供したいと考えています。 ZooKeeper と独自のサービス登録センターをより適切に設計する方法。刺激的で役に立ちます。 最後に、すべての道はローマに通ず、あなたの登録センターがローマに直接誕生することを心から願っています。