高並行性と高可用性のアーキテクチャシリーズ
-大規模な分散サービスを構築するためにあなたを連れて行きます
この（シリーズ）記事を読むと、次のことが得られます。
- 大規模分散システムにおけるサービスガバナンスの包括的かつ体系的な理解
- 第一線のインターネット企業の同時実行性とトラフィックの多いシナリオに対処する方法、安定性保証システムを明らかにする（同時実行性と可用性が高いために必要）
- 一般的な電流制限アルゴリズムの実現、Alibaba（Double Eleven）の電流制限およびヒューズ保護ツールの歩哨の設計原則と実際の経験（高い同時実行性と高可用性に必要）
- 高性能で高可用性の構成センターの本質、アーキテクチャ設計のアイデア、原則、および実践的な経験（マイクロサービスアーキテクチャに必要）
- 高性能で高可用性のサービスレジストリの本質、アーキテクチャ設計のアイデア、原則、および実践的な経験（マイクロサービスアーキテクチャに必要）
- インターネット企業の技術アーキテクチャの一般的な問題点、アーキテクチャのビジョンとソリューション（技術の幅と思考能力）
「サービスガバナンス」について話しているとき、私たちは何について話しているのですか？
キャリアの初めに、WebサービスやHessainなどをベースにしたさまざまな言語間分散システムに触れました。SOAのアーキテクチャと概念が非常に人気があった時代であり、高齢者が「SOA」について話すのをよく耳にしました。ガバナンス」などですが、当時は「ガバナンス」とは何かがわからず、「マネジメント」と呼んでみませんか？それまでは、小学校の教科書で「下水処理」という言葉にしか触れていませんでした。近年のインターネット企業の大規模なサービスプロセスまで、DubboやSpring Cloudに代表されるオープンソースのサービスフレームワークが普及し、「サービスガバナンス」が再び普及しました。
では、「ガバナンス」とは正確には何ですか？大規模なインターネット企業には数万のアプリケーションがあり、中規模の企業にも少なくとも数百のアプリケーションがあります。マイクロサービスの人気の後、サービスの数は日々増加しており、ガバナンスが緊急に必要とされています。根本的な原因は依然として非常に複雑であり、それを整理し、標準化し、最適化する必要があります**。アーキテクチャの本質は、複雑さを管理し、さまざまな利害関係者の要求を満たすことです。以下では、「サービスガバナンス」の分野を含むがこれに限定されないすべての側面を簡単に要約します。これにより、包括的かつ体系的な理解と理解を確立して、さらに詳細な調査と実践を行うことができます。
サービスの定義と管理
サービスを定義する方法と公開する方法、アップストリームを呼び出す方法、分割の粒度を把握する方法...これらはすべて、統一された仕様と制約を必要とします。そうしないと、組織とコラボレーションが台無しになりやすくなります。建築家が「マイクロサービスはインターフェースでありサービスである…」と言うのを聞いたことがありますが、私も同様のシステムを引き継いでいます。これは技術や方法論の本質を理解できない典型的な「技術理論学校」です。別の例として、特定のビジネス機能を開発している場合、他のドメインのサポートに依存する必要があることがわかります。これには、特定のサブドメインに含まれるサービスと、ビジネスを提供するかどうかにかかわらず、会社のアプリケーションを知る必要があります。必要な機能、およびサービスをさらに理解する契約の説明がどのように見えるかを理解して、すばやくアクセスできるようにします。これには、優れた管理メカニズムとプラットフォームのサポートが必要です。数十のアプリケーションシステムまたはサービスと20人の技術者しかいない新興企業の場合、同様の複雑さに直面することはなく、顔を合わせて叫ぶだけです。ただし、あらゆる規模のチームには、最も基本的な仕様と制約が必要です。いくつかの常識的な経験があります。例：インターフェイス定義のパラメータにマップタイプを使用しないでください。構造が過度に柔軟であると、インターフェイスコントラクトの定義が不明確になることがよくあります。理解するのが難しく、プロバイダーのコードロジックもさまざまな判断と特別な処理でいっぱいになります;サービスプロバイダーが列挙値とサービスコンシューマーを追加する場合は、応答結果のDTO定義で列挙を使用しないでくださいは2者間パッケージをアップグレードしません。逆シリアル化が失敗するのは非常に簡単です。これにより、Ali期間中に同様のオンライン事故が発生しました。新しいインターフェイスのみが許可され、既存のインターフェイスの定義は変更できません。すべての上流の消費者が均一にアップグレードされることを保証できます。通常の企業は明らかに達成することが不可能です。
私がリストした問題は非常に初歩的なように見えますが、多くの企業はこの分野でうまくいっていません。そうでなければそうはなりません。テクノロジー界の多くの人々** "ピットを掘り、未来の世代がピットを埋める" **ストーリー
サービスの登録と発見
サービスプロバイダーがサービスを登録する方法と、消費者がサービスをすばやく発見して選択する方法は、この分野で解決すべき主要な問題です。オープンソースレジストリを選択する方法は？登録センターの容量は十分ですか？サービスプロバイダーがオフラインになった後、レジストリは消費者を迅速に検知して通知できますか？オープンソースまたは自己研究を選択しますか？これらはすべて、建築家が考慮する必要のある問題です。サービスの登録と検出に関しては、ネットワーク通信、負荷分散、ヘルスチェック、データストレージ、分散選択アルゴリズムとプロトコルなどが含まれます。詳細については、別の章で説明します。
サービスコール、ルーティング、フォールトトレランス
サービスコールの場合、通信プロトコルからTCP / UDPまたはアプリケーション層HTTPプロトコルを選択できます。スタイルに関しては、主にバイナリRPC、つまりHTTP + JSONがあります（ここでは、多くの技術者の誤解を修正します。多くの企業のいわゆる「Restful」サービスは、実際には提供されるHTTPインターフェイスです。多くの人と同じように」H5 「実際には、携帯電話の画面サイズに合わせた小さなページであり、HTML5の新機能はまったくありません）。RPCフレームワークを例にとると、コーデックレベルでカスタムプライベートプロトコルがあります。アプリケーション層に行くと、シリアル化と逆シリアル化があります。protobufシリアル化またはHessaion2の使用は、パフォーマンス、互換性、安定性、言語間、可読性、テスト容易性などの観点から包括的に検討する必要があります。
サービスルーティング、これも理解しやすいです。たとえば、オープンソースのDubboフレームワークで提供されるグループ管理は、一種のルーティングとして理解できます。HSFが提供する「同じ部屋の優先順位」機能もルーティング戦略です。条件付きルーティングの一種である、サービスの「ブラックリスト、ホワイトリスト」フィルタリング保護メカニズムを実装する必要がある場合があります。私たちが何かやるときなど、「グレースケール出版、交通着色、環境隔離」**を、私たちは特別なタグを使用する必要があり、その後、透過的にそれらを送信し、ルートをそれらのサービスが呼び出されたルールに従って。もちろん、さらに重要なことに、レジストリのモデル設計は、同様のタグ付け機能をサポートするのに十分な柔軟性があります。外部サービスの場合、ゲートウェイ、Nginxなどを介したルーティングを実装します（これは基本的にリクエスト転送です）
サービスセキュリティ、ほとんどすべてのシステムは通常、ID検証、権限検証などを行う必要があります。分散型マイクロサービスアーキテクチャでは、通常、認証やその他の横断的な操作をゲートウェイに配置します。外部アプリケーションがサービスにアクセスする場合は、ゲートウェイを経由する必要があります。より一般的なのは、Oath2プロトコルであるJWTコンポーネントを使用することです。達成するなど。内部サービス間の通話は、すべて内部ネットワーク内にあるため、ファイアウォールなどのセキュリティ対策が講じられ、パフォーマンスやワークロードを考慮して、多くの企業が独立認証を行わなくなります。もちろん、これらを検証するために必要なレベルの権限は依然として必要です。さらに、WAF（Webアプリケーションファイアウォール）は通常、トラフィックアクセスの前に悪意のある要求をフィルタリングするように設定されています。より一般的なセキュリティの問題には、XSS、SQLインジェクション、DDOS、水平方向のアクセス許可などがありますが、ここでは展開されません
多くのサービスフォールトトレランスモードがあり、一般的なモードはおそらく次のとおりです：
failfast、fastfailure。たとえば、Javaコレクションフレームワークで、ArrayListや他のコンテナなどの操作を同時に変更または削除すると、システムはConcurrentModificationExceptionをスローします。これは典型的なフェイルファストメカニズムです。分散サービス呼び出しで最も一般的に使用されるフェイルファストメカニズムはタイムアウトです。サービスプロバイダーであろうとサービス呼び出し者であろうと、タイムアウトを設定する必要があり
ます。フェイルオーバー、フェイルオーバー、および分散サービス呼び出しでの時折のネットワークジッターの問題。再試行する別のマシンを選択します。これは一般的なフェイルオーバーです。さらに、データベースやメッセージミドルウェアの分野では、マスターやスレーブと同様のアーキテクチャモデルがよく使用されます。障害が発生すると、マスタースレーブの切り替えが自動的に実行され、クラスターの高可用性が確保されます。
フェイルバック、障害の自動回復、リクエストが異常または失敗した場合コンテキスト情報を保持し、何らかのメカニズムで自動的に再試行できるようにする必要があります。一般的な実装方法は、異常状態をキャプチャし、ログを記録するか、「異常回復テーブル」にドロップしてから、バックグラウンドタイミングタスクスキャンを通じて補正を実行することです。通常、データの適時性と一貫性にあまり敏感ではないシナリオに適しています。
フェイルセーフ、フェイルセーフティ、リクエストで例外または障害が発生した場合は、ログを記録して無視し、メインプロセスを続行します。これは、次のような一部の非メインリンクおよび依存度の低い要求に適しています。ビッグデータプラットフォームへの操作ログのレポート。
ガバナンスに依存する
まず、魂の拷問の下で、私のサービスはどのアプリケーションに依存していますか？アップストリームコールの量は私を引き下げますか？私の障害はアップストリーム障害を引き起こしますか？私は自分自身にどのようなサービスを頼っていますか？彼らが電話を切った場合、彼らは私に影響を与えますか？強い依存関係と弱い依存関係はどれですか？これらの問題は心にはっきりと伝える必要があります。ガバナンスに依存することの本質は、複雑さを管理し、リスクを回避または軽減することです。
サービスの監視と緊急措置
サービス監視には主に、ログ監視、コールチェーン追跡、およびメトリックが含まれます。これらはそれぞれ、詳細な調査に値する領域です。クラウドネイティブの時代では、まとめて**「可観測性」**と呼びます。
大規模な分散システムは通常、数百または数千のアプリケーションで構成され、マシンの数は数千に達することがよくあります。サーバーにSSHで接続してテールを実行することは不可能です。まず、統一されたログ形式と統一されたログパスを用意し、次にログを収集、レポート、迅速に分析、表示、および警告する必要があります。この分野で、オープンソースコミュニティの最も人気のある傑作はELKです。
「依存関係ガバナンス」についてお話ししたとき、分散システム間の依存関係の複雑さはすでに理解しており、コールチェーンは複雑であり、個人的な経験に頼ることは不可能です。障害またはパフォーマンスの問題が発生した場合、障害またはパフォーマンスのボトルネックをすばやく特定するという目的を達成するには、「一目で確認」および「つるを追跡」できる必要があります**。この分野の代表的な作品には、ピンポイント、猫、スカイウォーキング、淘宝網イーグルアイなどといくつかの商用APMが含まれます。
アプリケーションの観点から、サービスコールの量、成功率/エラー率、応答時間、およびその他の指標を理解する必要があります。同時に、スレッドプール、遅いクエリ、接続数などにも注意を払います。ビジネス面では、現在の注文数や総注文数など、同様のビジネス指標データに注意を払う必要があります。これらのインジケーターデータはすべて時間ディメンション**に関連しています。統計、ランキング、表示または警告を集計するために、これらのインジケーターデータを時系列データベースに保存する必要があります。
電流制限。これには、ページ電流制限、インターフェイス電流制限、アクセスソースまたはIP電流制限、単一マシン電流制限、クラスター電流制限、ゲートウェイ電流制限、ホットパラメーター電流制限、カスタム電流制限などが含まれます。北京地下鉄入口の朝と夕方のピーク期間制御は典型的な「電流制限」です（通常は「等速キューイング」と「高速障害」に分けられます）。
ダウングレードは、手動ダウングレードと自動ダウングレードのトリガー条件に分けることができます。シーンからは、一貫性の低下、整合性の低下、ユーザーエクスペリエンスの低下、読み取りと書き込みの低下などに分類できます。eコマースは、ピーク時にリソースが不足している場合、製品レビューサービスと推奨サービスをシャットダウンします。これは典型的な「放棄」「保証」は降格の手段です。さらに、インターフェースの自動ヒューズも一般的なダウングレード方法です。
依存関係のガバナンス、キャパシティプランニング、電流制限、ダウングレードなどについては、後続の安定性保証システムの章の後半で詳しく説明します。
サービステスト
サービスが公開された後、サービスに問題がないかどうかをどうやって知ることができますか？opsコンソールがある場合は、サービスを選択した後で直接パラメータを入力し、簡単にクリックしてサービスがスムーズであることを確認できます。かっこいいですね。共同デバッグや単体テストの開発中に、相手が気づかず、サービス契約を確認したばかりの場合は、簡単にデータをモックできる必要があります。従来のテストシステムでは、通常、単体テスト、統合テスト、コンポーネントテスト、エンドツーエンドテストなどに分けられ、古典的な「テストピラミッドモデル」を形成します。
マイクロサービスの時代には、異なるサービス間の呼び出しが「統合テスト」の焦点となったため、サービスプロバイダーとコンシューマーの両方が仕様を満たしていることを確認するために「契約テスト」が導入されました
概要
アーキテクトの観点からサービスガバナンスを見ると、開発、テスト、運用と保守、およびビジネスパーティ（利害関係者）の要求に注意を払う必要があります。テクノロジの選択とアーキテクチャ設計のトレードオフを比較検討する必要があります。可能な限り彼らの要求に応えます。
後続の章
同時実行性の高いシナリオでの一般的な問題と安定性保証システム
歩哨の設計原理と実務経験
高性能構成センターの原則と実践経験
サービスレジストリの原則と実際の経験