etcd は大規模なサービス ガバナンス アプリケーションの実践を実装します

 

ガイド: サービス ガバナンスは現在、企業構築においてますます重要視されており、特にクラウド ネイティブやマイクロサービスなどのさまざまなテクノロジがより多くの企業で適用されているため、この記事の内容は、Baidu Mini プログラム チームの大規模モデルに基づくサービス ガバナンスの実践経験の概要です。同時に、現在人気のある分散型オープンソース kv 製品 etcd と組み合わせて、ectd、Raft、boltdb の 2 つのコア テクノロジの実装原理を深く分析するだけでなく、サービス ガバナンスの実際の実践経験も公開します。サービス ガバナンスへの取り組みにおいて、より多くの支援を得られるようサポートしていきたいと考えています。

1. サービスガバナンスの概念の紹介

サービス ガバナンスは IT ガバナンスの一部です。サービス ライフ サイクルの関連要素に焦点を当てています。その主要なリンクには、サービスの登録と検出、スムーズなサービス アップグレード、トラフィック監視、トラフィック制御、障害位置、セキュリティなどが含まれます。

 フレームワークのソースコードが必要な友人は私のプロフィールを見て連絡してください。分散アーキテクチャのソースコードを推奨する

サービスには「ガバナンス」が必要ですが、ガバナンスにはコストが必要です。サービスにシンプルなビジネス ロジック、明確な運用プロセス、タイムリーな問題の特定とロールバックがある場合、サービス ガバナンスのコストは非常に低くなり、手動処理のみが必要になる場合もあります。ただし、複雑なビジネスでは、サービス プロバイダーとサービス ユーザーが異なるプロセス (異なる物理ノード上であっても) で実行され、異なるチームによって開発および保守される場合があります。チームワークとサービスのコラボレーションには多くの調整が必要です。調整作業が増えるほど複雑になるため、サービス ガバナンスが求められます。統合されたサービス ガバナンス プラットフォームを構築することで、協調的な標準化、リアルタイム監視、通話リンクの効率の継続的な最適化、依存関係の複雑さの軽減とリスク回避の支援など、ビジネスのサービス ガバナンス機能を効果的に向上させることができます。大規模なビジネス システムでは、サービス ガバナンスはすでに技術アーキテクチャの不可欠な部分であり、ビジネス システム全体の最も重要なインフラストラクチャの 1 つです。

上の図は、インターネット上で流通している netflix のサービス トポロジ マップです。図中の密な白い点は netflix のサービス ノードです。ノード間の接続は、サービス間に呼び出しがあることを示します。ノードと接続は複雑なサービス呼び出しチェーンを形成します。このような巨大なアプリケーション システムは、強力なサービス管理プラットフォームを通じて管理する必要があります。

サービス ガバナンスは本質的にサービス ライフ サイクルの管理と制御であるため、サービス ガバナンス プラットフォームの中核となる要件は、サービス ライフ サイクルの問題点をどのように解決するかであり、これには次の側面が含まれます。

1. 登録と発見

サービスの呼び出し元は、サービスを呼び出す前にサービス プロバイダーのアドレスを取得する必要があります。つまり、呼び出し元は、サービス ディスカバリーという方法でサービス プロバイダーを「検出」する必要があります。サービスディスカバリを完了するには、サービスプロバイダーの情報を特定の通信事業者に保存する必要がありますが、この保存の動作が「サービス登録」であり、保存されている通信事業者を「サービス登録センター」と呼びます。どのようなサービス管理プラットフォームにおいても、「登録センター」は必須のモジュールです。サービスの登録と検出はサービス ガバナンスの最も基本的な機能であり、サービスのライフ サイクルにおいて、サービスの最初のリンクを担当します。

2. トラフィック監視
サービス登録が発見された後はサービスコールとなり、大量のサービスコールがトラフィックを形成します。トラフィック監視は、多くのサービスの呼び出し関係とステータスを明確に制御することです。主に、コールトポロジ、コール追跡、ログ、監視、アラームなどが含まれます。サービスガバナンスは、コールトポロジを通じてサービスコール関係全体を監視し、監視システムを確立することで問題を迅速に発見して特定し、ビジネスシステム全体の稼働状況を把握します。サービスのライフサイクルでは、トラフィック監視はサービスの実行ステータスを認識する役割を果たします。

3. トラフィックのスケジューリング
業務システムの運用中には、販促活動、スパイク、芸能人の不祥事などのホットな問題や、ネットワーク障害、停電、コンピュータ室の大規模システム改修などの緊急事態が発生し、業務システム内の一部のサービスのトラフィックが急激に増減することがあるため、サービスのトラフィックをスケジュールして管理する必要があります。トラフィック管理には 2 つの側面が含まれます。マイクロ レベルでの単一サービスの観点から見ると、ロード バランシング戦略、ルーティング戦略、サーキット ブレーカーと電流制限戦略をいつ採用するかなど、サービス呼び出しプロセスの管理です。サービス呼び出し戦略とトラフィック分散戦略はすべて、トラフィック監視によって収集された呼び出しデータを通じて分析して決定を行い、サービス ガバナンス プラットフォームに実装する必要があります。トラフィック スケジューリングは、サービスの実行状態の管理を担当します。

4. サービス制御
トラフィック スケジューリング戦略がサービス プロバイダーと呼び出し元にどのように影響するかは、再起動して有効にすることも、実行状態でリアルタイムで有効にすることもできます。これは、サービスに対するサービス ガバナンス プラットフォームの制御によって決まります。サービス ガバナンス プラットフォームがサービス ガバナンス機能を完全に構築した後、サービス ガバナンス戦略をリアルタイムでサービスに配布し、すぐに有効にすることができます。

5. サービスのセキュリティ
各サービスは独自のビジネス責任を負っており、ビジネスに依存する一部のサービスでは、他のサービスへのアクセスを認証および許可する必要があり、これがセキュリティ上の問題となります。

この記事では、数千のサービスを持つ大規模なアプリケーション システムについて説明します。このシステムは、多数のサービス、多数のサービス インスタンス、および多数のサービス呼び出しによって特徴付けられます。サービス管理プラットフォームがそのようなビジネス システムのサービスを管理する場合、次のような大きな課題に直面する必要があります。

1. 高信頼性
大規模な業務システム、膨大なサービスコール、複雑なコール関係などではサービスの信頼性に対する要求が高く、多くの草の根サービスでは99.99%の信頼性が要求されており、そのためこれらのサービスを維持するサービスガバナンス基盤にも非常に高い信頼性要求が求められており、このような高信頼性を実現するためには、サービスガバナンス基盤自体に多層展開、マルチサイトホットバックアップ、ダウングレード分離、スムーズなオンライン等のソリューションを実装する必要があります。

2. 高いパフォーマンス
信頼性を確保することを前提として、サービスガバナンスにも高いパフォーマンスが必要であり、例えばデータ監視においては、サービスの単一障害点を迅速かつ正確に把握し、サービスの他のプロセスにトラフィックを分散することができます。業務システム内のサービス数が少なく、呼び出し量が多くない場合には、監視データの量も多くないため、サービスの単一障害点を容易に発見できますが、リアルタイムの大量呼び出しデータの場合、従来の一部のクエリ方法では時間がかかり、単一障害点が検出された時点で取り返しのつかない業務損失が発生している可能性があります。したがって、パフォーマンスはサービス ガバナンス プラットフォームのガバナンス機能を検討するための重要な指標であり、高パフォーマンス、高速ストレージ、マルチレベル キャッシュ、リニア デプロイメントをどのように確保するかが重要です。

3. 高い拡張性
高い拡張性には、大規模なアプリケーションシステムのサービスは複数のチームで開発・保守されることがあり、そのレベルや技術力にもばらつきがあるため、サービスガバナンス基盤には互換性と拡張性が求められ、スケーラビリティによって異なるサービスを可能な限り管理できると同時に、業務システムのサービス量が増加した場合にはサービスガバナンス基盤も同時に拡張して高い信頼性とパフォーマンスを確保できる必要があります。

大規模なサービスのガバナンス課題に直面しているため、サービス ガバナンス プラットフォームには、それに対処するための強力で使いやすいストレージ ツールも必要であり、etcd は良い選択です。

2. etcd の概要

2.1 etcd開発の背景と関連競合製品の紹介

2013 年、CoreOS 起業家チームがオープンソースの軽量オペレーティング システム ContainerLinux を構築していたとき、ユーザー サービスの複数のコピー間の調整の問題に対処するために、構成共有とサービス検出のための高可用性 KV 分散ストレージ コンポーネントである ETCD を自社開発しました。

以下では、Zookeeper と Consul の比較も行いました。

・ZooKeeper
ZooKeeper は高可用性、データ整合性、機能の面で十分な要件を満たしていますが、CoreOS が etcd の自社開発にこだわる理由は以下のとおりです。

1. ZooKeeperはAPIによる安全なメンバー変更をサポートしていないため、手動でノード構成を変更してプロセスを再起動する必要があるが、操作を誤るとスプリットブレインなどのオンライン障害が発生する可能性がある一方、CoreOSにはクラウド環境への適応やクラスタサイズのスムーズな調整、ランタイム構成のオンライン変更などが期待されており、この点でZooKeeperの保守コストは比較的高い。

1. ZooKeeper は、高負荷の読み取りおよび書き込みパフォーマンスのため、大規模なインスタンス接続の場合にはパフォーマンスが低下します。

etcd 名は、「/etc」フォルダーと「d」分散システムで構成されます。「/etc」フォルダは単一システムの構成データを格納するのに使用され、「etcd」フォルダは大規模な分散システムの構成データを格納するのに使用され、etcdクラスタは、高安定性、高信頼性、高拡張性、高性能の分散KVストレージサービスを提供します。etcd はレプリケーション ステート マシンに基づいて実装されています。Raft 整合性モジュール、ログ モジュール、およびボルトデータベース永続ストレージに基づくステート マシンで構成されています。構成管理、サービス検出、分散システムの分散整合性に適用できます。

ZooKeeper は etcd と同様に、分散システムの一貫性やメタデータ ストレージなどの問題を解決できますが、etcd には ZooKeeper に比べて次のような利点があります。

1. クラスターメンバーシップの動的な再構成

2. 高負荷時でも安定した読み書き能力

3. マルチバージョン同時実行制御データモデル

4. 信頼性の高いキー監視

5. Lease プリミティブは接続をセッションから分離します。

6. 分散ロックにより API のセキュリティを確保

7. ZooKeeper は独自の RPC プロトコルを使用しますが、使用が制限されていますが、etcd クライアント プロトコルは gRPC に基づいており、複数の言語をサポートできます。

・領事

Consul と etcd は異なる問題を解決します。etcd は分散一貫性のある KV ストレージに使用されますが、Consul はエンドツーエンドのサービス検出に重点を置いています。組み込みのヘルス チェック、障害検出、DNS サービスなどを提供します。さらに、Consul は RESTful HTTP API を通じて KV ストレージ機能を提供します。ただし、KV の使用量が数百万に達すると、高いレイテンシやメモリ負荷などの問題が発生します。

コンセンサス アルゴリズムに関しては、etcd と Consul は Raft アルゴリズムに基づいてデータ レプリケーションを実装し、ZooKeeper は Zab アルゴリズムに基づいてデータ レプリケーションを実装します。Raft アルゴリズムはリーダーの選出、ログの同期、セキュリティで構成され、Zab プロトコルはリーダーの選出、検出、同期、ブロードキャストで構成されます。

分散 CAP に関しては、etcd、Consul、ZooKeeper はいずれも CP システムであるため、ネットワーク分断が発生すると、新しいデータを書き込むことができなくなります。

次の表は、3 つの主要な機能を比較分析したものです。

2.2 etcdコアテクノロジーの紹介

Raftプロトコルに基づいた高いデータ可用性と強力な一貫性を実現

初期のデータ ストレージ サービスでは、単一点の問題を解決するためにマルチコピー レプリケーション テクノロジ ソリューションが導入されましたが、マスタースレーブ レプリケーションと分散レプリケーションの両方に特定の欠陥があります。マスタースレーブレプリケーションは運用保守が難しく、一貫性と可用性のバランスが難しく、分散レプリケーションでは業務処理を必要とするさまざまな書き込み競合が発生します。分散コンセンサス アルゴリズムは、マルチコピー レプリケーションの問題を解決する鍵となります。コンセンサス アルゴリズムとしても知られる分散コンセンサス アルゴリズムは、レプリケーション ステート マシンの背景に基づいて最初に提案されました。最初のコンセンサス アルゴリズムである Paxos は非常に複雑で、理解するのが難しく、エンジニアリングで実装するのが困難です。スタンフォード大学の Diego によって提案された Raft アルゴリズムは、問題を 3 つのサブ問題に分割するため、理解しやすく、エンジニアリングの実装の困難さを軽減します。これら 3 つのサブ問題は、リーダーの選出、ログのレプリケーション、およびセキュリティです。

リーダー選挙

etcd (バージョン 3.4 以降) の Raft プロトコルは、クラスター ノードの 4 つの状態 (リーダー、フォロワー、候補、および事前候補) を定義します。

通常の状況では、リーダー ノードは、ハートビート間隔に従って定期的にハートビート メッセージをフォロワー ノードにブロードキャストして、リーダー ステータスを維持します。それを受信したフォロワーは、ハートビート応答パケット メッセージをリーダーに返信します。リーダーにはターム番号 (ターム) があり、選挙から始まり、選挙に勝ったノードがこのタームの間リーダーとして機能します。項番号は単調に増加し、各ノードの古いデータと新しいデータを比較したり、期限切れのリーダーを識別したりするための Raft アルゴリズムの論理クロックとして機能します。

リーダー ノードが異常な場合、フォロワー ノードはリーダーのハートビート メッセージを受信し、タイムアウトになります。タイムアウト時間が選挙タイムアウト時間より大きい場合、候補前状態に入ります。項数は増加しませんが、事前投票 (ノード データが他のノードに大きく遅れていることによる無効な選挙を防ぐための世論調査) が開始されるだけです。ノードは選挙投票情報を送信します。

ノード B がノード A の選出メッセージを受信すると、次の 2 つの状況が発生します。

1. ノード B は、ノード A のデータが少なくともそれ自体と同じくらい新しく、ノード A のターム数がノード B のターム数より大きく、ノード B が他の候補に投票していないと判断し、ノード A に投票でき、ノード A はクラスター内のノードの大部分によってサポートされており、新しいリーダーになることができます。

2. ノード B も選挙を開始して自分自身に投票した場合、ノード A への投票を拒否します。現時点で、どのノードも過半数の票の支持を得ることができない場合、選挙がタイムアウトして新たな選挙ラウンドを開始するのを待つことしかできません。

ログのレプリケーション

Raft ログの構造を次の図に示します。

Raft ログは順序付けされたインデックスのエントリで構成されており、各ログ エントリには用語番号と提案の内容が含まれています。リーダーは 2 つのフィールドを維持することで各フォロワーの進捗情報を追跡します。1 つは NextIndex で、リーダーによってフォロワー ノードに送信される次のログ エントリのインデックスを示します。もう 1 つは MatchIndex で、フォロワー ノードがコピーした最大のログ エントリのインデックスを示します。

この記事では、「hello=world」プロポーザルの送信から応答の受信までのプロセス全体を例として取り上げ、etcd ログ レプリケーション プロセスを簡単に紹介します。

1. リーダーがクライアントによって送信された提案情報を受信した後、ログ エントリを生成し、同時に各フォロワーのログの進行状況をトラバースし、各フォロワーにログを追加するための RPC メッセージを生成します。

2. ネットワーク モジュールを通じて各フォロワーにログを追加する RPC メッセージをブロードキャストします。

3. フォロワは追加のログ メッセージを受信して​​保持すると、リーダーが最大のログ エントリ インデックス、つまり MatchIndex をコピーしたと応答します。

4. フォロワーからの応答を受信した後、リーダーはフォロワーに対応する MatchIndex を更新します。

5. 各フォロワーによって送信された MatchIndex 情報に基づいて、リーダーはログ エントリの送信されたインデックス位置を計算します。これは、ログ エントリがノードの半分以上によって永続化されることを意味します。

6. リーダーは、ログ インデックスの位置がハートビートを通じて送信されたことを各フォロワーに通知します。

7. クライアントの提案が提出済みとしてマークされると、リーダーはクライアントに提案が承認されたと返信します。

上記のプロセスを通じて、リーダーはログ エントリを各フォロワーに同期して、etcd クラスターのデータの一貫性を確保します。

安全性

etcd は、選挙とログのレプリケーションに一連のルールを追加することで、Raft アルゴリズムのセキュリティを確保します。

選挙規則:

1. 用語番号に対して、リーダーは 1 人だけ選出でき、リーダーの選出にはクラスター内のノードの半分以上のサポートが必要です。

2. 選挙投票を受け取ったノードは、候補者の最新のログエントリの項番号が自分より小さい場合は投票を拒否し、項番号が同じでもログが自分より短い場合も投票を拒否します。

ログ複製ルール:

1. リーダーの完全な特性。ログ エントリが特定の用語番号で送信された場合、このログ エントリは、より大きな用語番号を持つすべてのリーダーに表示される必要があります。

2. 追加専用の原則では、リーダーはログ エントリを追加することしかできませんが、永続的なログ エントリを削除することはできません。

3. ログマッチング機能 リーダーがログ付加情報を送信すると、前回のログエントリのインデックス位置（Pで示される）とターム番号が送信され、フォロワーはリーダーからログ付加情報を受け取った後、インデックス位置Pのターム番号がリーダーと一致するかどうかを検証し、一致した場合にのみ追加できます。

ボルトデータベースストレージテクノロジー

ectd のもう 1 つのコア テクノロジは、効率的な b+ ツリー取得機能を提供し、トランザクション操作をサポートするboltdb ストレージです。これは、etcd の高性能読み取りおよび書き込みをサポートする重要な機能の 1 つです。

Boltdb の実装は、効率的かつ高速なメモリマップド データベース ソリューションに基づく LMDB (LightningMemory-MappedDatabase) の設計思想を参照しており、B+ ツリー構造設計に基づいています。データ ファイル デザイン ボルトは、別のメモリ マップト ファイルを使用してコピーオンライト B+ ツリーを実装し、読み取りを高速化します。さらに、BoltDB のロード時間は、特にクラッシュから回復する場合に非常に高速です。これは、最後に成功したトランザクションを見つけるためにログを読み取る必要がなく (実際にはログがまったくありません)、2 つの B+ ツリーのルート ノードから ID を読み取るだけです。

ファイルストレージの設計

単一ファイルのマッピング ストレージにより、ボルトは指定された長さに応じてファイルをブロックに処理し、各ブロックには異なるコンテンツ タイプが格納されます。デフォルトでは、4096 バイトの長さがチャンク化に使用されます。各ブロックの先頭には、個別のページ ID (int64) 識別子があります。

ファイルブロックの種類は次のとおりです。 

 データファイルのパノラマ構造

例証します:

• メタページはpage0とpage1に固定されています

• ページサイズは 4096 バイトに固定されています

• ボルトのファイル書き込みはローカルオーダー(リトルエンディアン)モードを採用しており、例えば16進数0x0827(2087)で書き込まれた内容は2708000000000000となります。

単一ファイル ソリューションの利点は、ファイルの結合や削除などの操作が不要で、元のファイルに拡張子の長さを追加するだけで済むことです。

クエリデザイン

boltdb は非常に効率的なクエリ機能を提供します。まずそのオブジェクト設計を見てみましょう。

オブジェクト設計の観点から見ると、boltdb がロードされると、最初にメタデータがメモリにロードされ、次にバケットに従ってデータ ブロックの場所が特定され、次にキーの値に従ってブランチ ノードの場所が特定され、次にリーフ値ノードが特定されます。

クエリを例にして説明します。以下は基本的なクエリのサンプル コードです。

tx, err := db.Begin(true) // 开启事务
 
  if err != nil {
 
      return
 
  }
 
  b := tx.Bucket([]byte("MyBucket")) // 根据名称查询bucket
 
  v := b.Get([]byte("answer20")) // 根据key进行查询 
 
  fmt.Println(string(v))
 
  tx.Commit()

上記のコードに対応する次のシーケンス図は、クエリの操作プロセスをより詳細に理解するために役立ちます。

上記の最も重要なコードは検索メソッドです。以下は主要なコード スニペットであり、読みやすいようにコメントが追加されています。

func (c *Cursor) search(key []byte, pgid pgid) {
    p, n := c.bucket.pageNode(pgid)
    if p != nil && (p.flags&(branchPageFlag|leafPageFlag)) == 0 {
        panic(fmt.Sprintf("invalid page type: %d: %x", p.id, p.flags))
    }
    // 把当前查询节点(page,node)压入栈
    e := elemRef{page: p, node: n}
    c.stack = append(c.stack, e)
 
    // If we're on a leaf page/node then find the specific node.
    if e.isLeaf() {
        c.nsearch(key)
        return
    }
    // if node cached seach by node's inodes field
    if n != nil {
        c.searchNode(key, n)
        return
    }
    // recursively to load branch page and call search child node again
    c.searchPage(key, p)
}

3. Baidu が etcd をベースに大規模なサービスガバナンス構築アイデアを構築

3.1 具体的な課題

Tianlu は、大規模なビジネス サービス ガバナンスのニーズに合わせて Baidu Mini プログラム チームによって開発および構築された一連のソリューションであり、その目標の 1 つは、Baidu のサービス ガバナンスの標準モデルになることです。Tianlu-mesher は、登録センター、ビジュアル管理プラットフォーム、SDK フレームワーク、統合ゲートウェイ、tianlu-mesher の 5 つの部分で構成されており、現在 150 以上の製品ラインにアクセスでき、インスタンス数は数十万に達しています。プラットフォームにアクセスするチーム数の増加とサービス インスタンスの急速な成長に伴い、多数のチーム間で簡単に連携し、大規模なサービス ガバナンス プラットフォームの高可用性と高性能を実現する方法は、TELLO が常に直面し続ける課題でした。

3.2 アーキテクチャ全体の構築に関するアイデアと計画

サービス管理プラットフォームとしての Tianlu の中心的なコンセプトは、すべてのサービスに対する便利な通話、統合されたサービスの監視と管理を提供し、サービスの開発とメンテナンスのコストを簡素化することです。私たちは、高可用性、高パフォーマンス、高スケーラビリティ、使いやすさといったさまざまな側面から etcd に基づく大規模なサービス ガバナンス プラットフォームの構築を検討します。

· 高可用性

• etcd のコンピューター ルーム間の呼び出しによるネットワーク遅延が大きいことを考慮して、単一コンピューター ルームのデプロイメントを採用し、単一コンピューター ルーム内のすべてのインスタンスがダウンしているときに etcd クラスターが使用できないという問題を解決するために、マスター/スタンバイ クラスター切り替えソリューションも実装しています。

• プラットフォームの etcd への強い依存を軽減するために、キャッシュを使用するように etcd をダウングレードするソリューションを作成しました。etcd クラスターのパフォーマンスが現在のプラットフォームをサポートできないことが監視されている場合、インスタンス データを保存するためにキャッシュを使用すると、運用保守担当者は etcd を復元する前にシステムに影響を与えることなく正常に動作でき、etcd が復元された後は etcd クラスターに戻って作業を継続できます。

・ ハイパフォーマンス

• etcd クラスターの kv クエリのパフォーマンスは非常に高く、qps は 10,000 以上に達することがあります。極端な同時実行下でのパフォーマンスの問題を解決するために、レジストリはマルチレベル キャッシュを使用してクエリ効率を向上させ、etcd へのアクセス圧力を軽減します。

• サービス間の通話は直接接続方式を採用しており、登録センターを経由する必要がなく、基本的に通話時間のロスがありません。

・高拡張性

• サービスインスタンスの数が将来的に数百万に達することを考慮すると、アーキテクチャの高い拡張性を考慮する必要があります。

・ 使いやすさ

• ユーザーは、視覚的な管理プラットフォームを通じて登録されたサービスを表示でき、管理プラットフォームを通じてサービス ガバナンス戦略の構成をリアルタイムで更新し、サービス ガバナンス戦略をリアルタイムで調整することもできます。

• 通話ログをトレース プラットフォームに接続すると、ユーザーは、traceId を通じてトレース プラットフォーム上で通話チェーン全体の記録を見つけることができます。これは、エラーが発生したときに問題を迅速に特定するのに便利です。

• 多言語 SDK は、Baidu の自社開発 RPC テクノロジ brpc や http jsonrpc プロトコルなどを含む複数の RPC テクノロジをサポートします。

 アーキテクチャ図

3.3 主要な指標と運用および保守の目標

さらに、サービスガバナンスプラットフォームの運用・保守をより適切に実施するためには、以下の重要な評価指標と運用・保守要件も必要となります。

主な指標:

· 99.99% 以上の可用性。

・フラットな音は100ms以下です。

運用と保守の目標:

• 早期故障検出

· レジストリ インスタンスの健全性、etcd ping、メモリと CPU の監視などの監視アラームを構成します。

• トラブルシューティングが早い

・自動処理：noahのコールバック機構により、一部の障害は自動処理され、処理速度が向上します。

・手動加工：時計機構。

4. まとめ

サービス ガバナンスは、特にクラウド ネイティブやマイクロサービスなどのさまざまなテクノロジがより多くの企業で適用されている現在、企業構築においてますます重視されていますが、真に適用し、適切に統合するにはまだ多くの課題があります。サービス ガバナンスに関するチームの全体的な理解、深い技術経験、サービス指向の設計能力などをフォローする能力など、一連の成熟したサービス ガバナンス製品に加えて、最終的な実装効果に影響します。この記事は、サービス ガバナンス製品の選択に関するヒントを提供するだけであり、サービス ガバナンスの道をより良く、より着実に歩むのに役立つことを願っています。