Huawei CloudのGo言語クラウドネイティブ実践体験：クラウドネイティブアプリケーション開発の基本機能の構築

中国で最も権威があり、最も影響力のある囲碁カンファレンスである Gopher China は、多数の Gopher に第一線の共有とコミュニケーションの機会を提供することに尽力しており、また、多くの第一線のインターネット企業のリーダーに Go 言語の応用と開発について深く議論する機会も提供しています。

先日上海で開催された第6回Gopher China Conferenceでは、 Huawei Cloud MicroservicesのチーフアーキテクトであるTian Xiaoliang氏が招待され、「Huawei CloudのGo言語クラウドネイティブ実践体験」を共有し、回復力があり、信頼性が高く、安全なクラウドネイティブアプリケーションシステムを構築する方法や、クラウドネイティブアプリケーション開発フレームワークGoシャーシをインキュベートしてチーム開発効率を向上させる方法について語りました。

ファーウェイは2016年にクラウドBUを設立して以来、Go言語で書かれたKubernetesやPrometheusなどのCNCFプロジェクトを導入してきた。 Huawei CloudのR＆Dチームも、クラウドサービスの構築にGo言語を使い始めました。しかし、当時の Go エコシステムは完璧ではなかったので、基本的な機能モジュールを最初から最後まで記述する必要がありました。

それでは、Go を使用してクラウド サービスを構築し、基本的な機能を段階的に確立する方法を説明します。

シンプルなクラウド アプリケーションからクラウド サービスを構築する方法

Eureka と同様に、シンプルな登録および検出サービスであるサービス センターは、さまざまな方法で強化できます。

1. 静的情報と動的情報の定義

データ情報量を削減し、共通部分を抽出して一元管理し、静的情報でインスタンスグループを分割します。このように、マイクロサービスとマイクロサービスインスタンスは 1 から n にマッピングされ、マイクロサービス名、バージョン、データセンターなどの情報がパブリック部分に抽出されます。冗長性を削減することで、ネットワークのオーバーヘッドが削減され、マイクロサービス モデルが標準化されます。

2. 契約型マイクロサービス

前の図では、マイクロサービスの静的情報に複数のスキーマが含まれており、それらのスキーマはマイクロサービスに関連付けられた契約ドキュメントに関連付けられており、1 対 n のマッピング関係でもあることがわかります。手動でアップロードするか、コードからドキュメントを自動的に生成することで、登録センターでマイクロサービス ドキュメントを表示できます。ドキュメントはマイクロサービスのバージョンにバインドされており、変更することはできません。

これは、統合開発を開始する前にバックエンド サービスが記述されるのを待つというクライアント開発チームのアプローチとは対照的です。効率的な方法は、ドキュメントに基づいてクライアントとサーバーを同時に開発し、クライアントが Mock を通じてサーバーへの依存を削除することです。

なぜ文書を最優先にする必要があるのでしょうか?ドキュメントがタイムリーにレビューされない場合、非常に悪い状況が発生する可能性があります。たとえば、一貫性のない命名規則、類似した API 定義、スケーラビリティの低さなど、いずれも研究開発コストを大幅に増加させます。早めに確認して回避することが重要であり、そのために登録センターではドキュメントのアップロードとクエリ機能を追加しました。

3. サービス間の依存関係管理

通話レベルが高すぎると、位置決めが困難になり、パフォーマンスが低下します。適切なレベルは 3 つのサービスです: a->b->c コールで通話を完了できます。相互に依存する 2 つのサービスの機能がアップグレードまたは変更された場合、その影響を分析するにはより多くの時間がかかります。たとえば、a と b が相互に依存しており、新しい機能には両方への変更が必要な場合、どうすればそれらを一緒に起動できるでしょうか?

シンプルな依存関係によりシステムのテストと分析が容易になり、アーキテクトはマイクロサービス間の依存関係を確認してアーキテクチャをタイムリーに調整できるようになります。

4. キャッシュメカニズム

サービス センターはデータを保存しないため、etcd でネットワーク障害が発生すると、サービス センターは利用できなくなります。そのため、Service Center では非同期キャッシュ メカニズムが導入されています。起動時に、Service Center は etcd との長い接続、つまり watch を確立します。監視時間ウィンドウの変更を防ぐために、別の保護レイヤーが追加され、監視の前に完全なクエリが実行されます。操作中、クエリによって取得されたリソースの変更は、Service Center にローカルにキャッシュされ、その後非同期で循環されます。

一般的に、マイクロサービス開発の効率を向上させ、ネットワークのオーバーヘッドを削減し、非同期キャッシュを通じてパフォーマンスを向上させるために、さまざまな方法を使用してきました。これは Huawei Cloud が蓄積してきた能力ですが、クラウド サービスを提供するということは、単にビジネス機能を提供するというだけではありません。また、マイクロサービスのセキュリティ、回復力、プライバシー、保守性についても考慮する必要があります。

私たちが今見たものは氷山の一角に過ぎません。まだ書き込む必要がある基本的な機能が水面下にたくさん隠されています。マイクロサービス アーキテクチャ モデルのビジョンを実際に実現するには、膨大な作業負荷が必要です。氷山と同じように、共通の機能を沈殿させて再利用できるようにする必要があります。各事業チームに氷山の両端を担当させ、独自の事業を展開させると、結果は悲惨なものとなり、会社の雇用コストは極めて高くなります。サービス センターのアーキテクチャを見てみましょう。

サービスセンターのアーキテクチャに基づいて、「氷山の下」の基本機能ライブラリをコンパイルすることが重要です。

次のコンポーネントは、主にマイクロサービスの登録と検出を担当し、Restful API を提供します。

4 つの主要モジュールがあります。

● サービスの登録と検出: サービス トポロジの認識は、登録と検出を通じて実現されます。

● 契約の検出: 各サービスには契約レコードがあり、Open API や gRPC proto などの複数の形式をサポートしています。

● RBAC: ロールベースのアクセス制御。管理者はアカウントを管理し、マイクロサービスやさまざまな担当者にアカウントを配布できます。

● サービスガバナンス: 再試行、電流制限、サーキットブレーカー、ルーティング戦略など、マイクロサービスのガバナンスルールを発行します。

クラウド サービスを提供するということは、単にビジネス機能を提供するということではありません。セキュリティ、回復力、プライバシー、保守性、その他の機能を総合的に考慮する必要があります。もちろん、ゲートウェイなどのミドルウェアに一部の機能を委任することもできます。ただし、各マイクロサービスで再利用できる、自分で記述する必要があり、多くの関数が依然として存在します。これが、基本機能ライブラリを作成した本来の目的です。

● クォータ管理：クラウドリソースはテナントに応じたクォータで管理され、テナントが使用できるリソースは厳しく制限されます。

● アラーム: マイクロサービスで重大な問題が発生した場合、クラウド サービスを通じてしきい値などのアラーム戦略を設定するのではなく、アラーム システムに直接報告する必要があります。

● セキュリティ: 暗号化および復号化証明書、パスワード

● ID 生成: マイクロサービス ID、インスタンス ID などの生成に使用される ID 生成アルゴリズム。

● さまざまなミドルウェア: 呼び出しプロセスを監査し、呼び出しチェーンを追跡し、監視用のインジケーターを生成する必要があるなど。

このプロジェクトはオープンソース化され、Apache に寄贈されました。プロジェクトのアドレスは https://github.com/apache/servicecomb-service-center です。

これらの機能では、通常のライブラリ関数を抽出するだけでは不十分なので、次の機能が必要です。

プラグ可能:これは、必要に応じてコンパイル時に導入できることを意味します (Go 言語の機能によって制限されます)。たとえば、コミュニティではクォータ システムの具体的な実装は必要ありません。

異種システム:これは、1 つの機能に複数の特定の実装が必要であることを意味します。たとえば、監査の場合、パブリック クラウドには接続する必要がある監査システムがあり、コミュニティはローカル ログを出力します。

さまざまなアルゴリズム:復号化ツール、ID ジェネレーター... さまざまな配信シナリオやセキュリティ要件に応じて、さまざまな実装を通じてアルゴリズムを置き換える必要があります。たとえば、ID 生成はスノーフレークまたは UUID になります。暗号化および復号化アルゴリズムには、AES またはその他の公開アルゴリズムが使用されます。

Go Chassis を使用してクラウド サービスの開発を加速する方法

前述の多様なニーズを満たし、新たに計画されたすべてのコンポーネントにメリットをもたらし、迅速に開発するためには、開発を加速するための統一されたフレームワークと標準が必要です。そこで、Huawei Cloud が Go 言語で記述した開発フレームワークである Go Chassis が誕生しました。したがって、Go シャーシのソース コードと設計には、サービス センター コードの影があることがわかります。興味のある学生は詳しく読むことができます。

Go Chassisの開発フレームワークから、ビジネスロジックはユーザー自身が記述したビジネスコードであることがわかります。フレームワークは、プロトコル層、中間層、プラグイン スイートの 3 つの部分に分かれています。管理部分はクラウドサービスです。フレームワークによって開発されたアプリケーションは、これらのクラウド機能にすぐに接続して使用できます。例えば：

● 登録検出プラグインはService Centerとkubenetesに接続できます

● クォータ管理プラグインはクラウドサービスのクォータ管理サービスに接続できます

● Prometheusに接続された指標監視などのミドルウェア

では、このフレームワークをどのように使用して開発をスピードアップできるのでしょうか?

方法1: バックエンドサービスをプラグインとして使用する

バックエンドサービスとは、自社の組織で開発・運用されておらず、アプリケーション運用からインフラまで見えないブラックボックス型のサービスを指します。一般的なバックエンドには、クォータ管理、認証サービス、オブジェクト ストレージ サービスなどがあります。クラウド ネイティブの要素の 1 つは、バックエンド サービスを追加のリソースとして扱うことです。

これらのバックエンド サービスを呼び出す場合、それらは実際にはマイクロサービス ガバナンス システム内にはありません。テスト可能性（模擬テストなど）や置き換え可能性（事業継続性、変化するニーズに合わせていつでもより良いサービスに置き換えることなど）を考慮し、置き換えや削除を柔軟に選択できるようにプラグイン化する必要があります。

方法2: 需要ベースラインを構築する

いかなる種類のサービスを提供する前にも、次のような基本要件を満たす必要があります。

● リクエスト本体のサイズは制限される必要がある

● APIの制限が必要

● パスワードはプレーンテキストで保存できません

● アクセス認証

● 単一障害点なし

● アクセス監査

● 運用・保守能力

これらの要件を念頭に置いて、最初のステップはランタイム呼び出しモデルを標準化することです。部門ごとに独自のプロトコル要件がある場合があるため、サービス ガバナンスはコア フレームワークに委ねられ、ビジネス部門が独自にプロトコルを開発するか、既存のプロトコルを統合するかを決定します。

企業内のさまざまな部門が独自のプロトコルを開発し、独自のサービスガバナンスを行っている場合、1 つのアーキテクチャとツール チェーンでビジネスを統一することは非常に困難です。

したがって、呼び出しの概念を使用してプロトコル記述を統一し、統一された処理チェーンで処理できるようにします。

処理チェーンの設計は AOP に準拠しており、ユーザー操作の監査などの特別な処理のために、ビジネス処理の前後にコード ロジックが追加されます。

ResponseCallBack はポスト ハンドラーによって返された結果を受け取るために使用されるため、各ハンドラーは必要に応じて独自の ResponseCallBack を定義して、後続のハンドラーまたはビジネス ロジック コードの実行結果を取得できます。これにより、一般的なロジック (ミドルウェアなど) とビジネス ロジックが完全に分離されます。

現在、Go Chassis は、電流制限、回路遮断、負荷分散、認証、監査などのミドルウェアをすでにサポートしており、これらはすべてこのメカニズムを使用して実装されています。同社のすべてのツール チェーン、サービス ガバナンス メソッド、セキュリティ コンプライアンスなどが処理チェーンに組み込まれているため、研究開発が迅速に加速され、標準が統一され、管理の負担が軽減されます。

このフレームワークは、インジケーターのコレクションなどの命令型の呼び出し機能を提供します。

また、トラフィック特性に基づいてトラフィックを制限する機能を持つトラフィック管理などの宣言型の使用法も提供します。

プラグイン機能の全体像から、Go Chassis は現在複数のエコシステムをサポートしており、複数のバックエンド システムに抽象インターフェースを提供して、迅速なアプリケーション開発を支援していることがわかります。

このようなフレームワークにより、ビジネス チームはバックエンドの複雑さやその他の非機能要件を理解する必要なく、ビジネス コードの開発に集中できるようになります。メリットは次のとおりです。

大規模システムで模擬テストを実施して配信品質を向上させることができます

さまざまな配信シナリオへの対応

バックエンドの交換可能性を確保する

R&D責任の分離インターフェース

アーキテクチャやビジネスの進化の観点から見ると、バックエンドで使用されるテクノロジーは急速に進化しています。バックエンド サービスを迅速に置き換えることで、システムと製品のタイムリーな進化を確保する必要があります。したがって、インターフェースの設計は再利用性よりも交換性を重視したものにする必要があります。これはプログラミングの依存性逆転の原則も満たしています。新しいマイクロサービスを開発するときは、そのビジネス ロジックを実装するだけで済みます。

方法3: 構成を通じて開発プロセスを簡素化する

これも命令型の呼び出しメソッドであり、その構造は次のようになります。

ソース レイヤー:構成ソースは、ソースを実装することでさまざまな構成ソースにアクセスするために使用できる標準インターフェイスです。構成の取得元となるリソースを定義します。リモート システム、ローカル ファイル、環境変数、または起動コマンド ラインから取得できます。ソースは、構成項目をローカル メモリにキャッシュする役割を担います。ユーザーは任意のソース実装をロードすることを選択できます。

リモート ソース:分散構成管理システムに接続します。現在、Ctrip のオープン ソース構成センターである Apollo に接続しています。

構成マネージャー:すべてのソースの構成を統合および管理する責任を負います。各ソースは優先順位を定義できます。マネージャーを通じて構成を取得するときに、2 つの異なるソースの構成が同じである場合は、優先度が最も高い構成が採用されます。

イベント ディスパッチャー:ユーザーは Archaius API を通じて構成の変更を監視できます。ソース内の構成項目が追加、更新、または削除されると、リスナーに通知されます。

ソースの優先順位:優先順位は、Config Center、CLI、ENV、ファイルです。同じ設定項目がある場合、最も優先度の高い設定のみが有効になります。分散システムでは、リモート構成センターに最高の優先順位を与える必要があります。独立したプロセスをローカルで実行する場合、一般的な考え方としては、コマンド ライン パラメーターが環境変数やローカル ファイルの内容よりも優先されます。このようなメカニズムにより、ユーザーは構成項目の有効性のロジックを処理するコードを記述する必要がなくなります。

Archaius API:基礎となる実装をカプセル化し、開発者が使いやすい API を提供します。

その中で、メモリ ソースは非常に重要であり、UT テストをより簡単にします。ファイル ソースを使用すると、ローカル プロセスのテストが可能になります。 Ctrip の Apollo などのリモート構成センターは、システムが共同でデバッグとテストを実施し、運用環境をサポートするのに役立ちます。

方法4: 扱いやすい

つまり、瞬時にオンまたはオフにすることができます。 Go 言語と Docker ランタイム、コンテナ プラットフォームはこのようなシナリオを処理できるため、ここではクイック スタートについては説明しません。そのため、予期しない処理について説明します。

このプロトコル サーバーは通常、プロトコルを表しますが、http などのプログラミング モデルを表すこともできます。

フレームワークの構成例もあり、これは 2 つの http ポートと grpc ポート サービスがマイクロサービス プロセスでプルアップされることを意味します。

システム信号を受信すると、各サーバーが 1 台ずつ停止されます。

さらに、コミュニティ開発者によって提供されたカスタムの正常なシャットダウン機能により、ユーザーはシグナルとシャットダウンのプロセスをハイジャックでき、前後のプロセスをカスタマイズすることもできます。

方法5: 軽量カーネル

現在、Go Chassis は、必要な Prometheus、OpenTracing、JWT、K8s クライアント、および Go-Restful 関連の依存ライブラリのみに依存しています。

レジストリ検出もプラグ可能です。

さらに、grpc プロトコルや Kubernetes 登録センターなどのさまざまな機能が別のウェアハウスで提供されており、必要に応じて導入できます。

自分だけのリメイクホイールを所有する

自分専用の作り直したホイールを所有するというのが、Go Chassis 開発フレームワークのロゴが伝えたいアイデアです。

本当に有能なチームは、車輪とは何か、そしてどのような車輪が自分たちに適しているかを理解しているので、自分たちで車輪を再発明することはないと思います。彼らはこの抽象的なホイールを導入し、強化して、自分たちにとってより適したホイールにします。 「オフロードホイール」でも「スノーホイール」でもカテゴリーはあなた次第です。当社では、R&D チームが蓄積した機能をさまざまなインターフェースやプラグインに抽象化することで、車輪の再発明ではなく、既存の車輪に基づいて再構築し、プロジェクト製品の実行速度を向上させています。

Two Go シャーシのケーススタディ

1 つ目は、サービス管理用の Go Chassis と Service Center をベースにしたビデオ通話バックエンドです。 Huawei Honorの携帯電話やスマートスクリーンなどの端末に採用されており、パブリッククラウド上で展開され、端末企業が数億人の登録ユーザーとつながることを効果的にサポートしています。

2つ目の事例は、Go Chassisをベースに開発されたサービスガバナンス基盤のエッジ処理能力であり、全国29省・自治区の約10万のエッジノードと50万以上のエッジアプリケーションの展開を管理しています。 1万ヶ所以上の料金所におけるガントリー情報収集業務の継続的な調整・更新をサポートし、毎日3億件以上の情報収集に対応します。将来的には、車道協調や自動運転などの革新的なビジネスの発展に優れたプラットフォームサポートを提供します。

https://github.com/kubeedge/kubeedge

さらに、Huawei Cloud ServiceStageは、GoChassisをベースに開発されたマイクロサービスをシームレスにホストし、メンテナンスフリーのマイクロサービスエンジン機能を提供します（https://www.huaweicloud.com/product/servicestage.html）

要約する

1. アプリケーション開発の通信プロトコルを定義する

企業にとって非常に重要な 2 つのことは、企業文化と行動規範であり、これらはすべての企業のリーダーが優先事項として定義しなければならないものです。これは、チーム間の良好なコラボレーションを保証する通信プロトコルのようなものです。このように、リーダーは自分ですべてを行う必要はなく、何もせずに統治の目標を達成することさえできます。この仕組みはいわゆる「通信プロトコル」と呼ばれるものである。

したがって、一連の通信プロトコルを定義することが非常に重要です。 GoシャーシはGo R&Dチームの通信プロトコルです

各マイクロサービスは、同じチームまたは異なるチームの小規模なチームによって開発されます。私たちが作成したフレームワークは、スケーラビリティを考慮し、開発に過度の制限を課さずに、研究開発コストを削減するための最小限のパラダイム（インターフェースとモデル）のセットを定義することです。まず API を標準化して API 設計を見直し、依存関係管理で合理的なサービス関係を見直し、すべての機能をプラグインとミドルウェアに預けることを規定しました。これらはすべて、R&D チームがクラウド サービスを開発および管理するための「通信プロトコル」を定義するためのものです。

2. 新しいインフラにおけるGoの役割

インターネットの進化の第一世代は PC、第二世代は携帯電話、そして第三世代は Internet of Everything です。 5G時代では、より多くのデバイスがアクセスでき、より小型のデバイスからは必然的に新しい半導体や新しいオペレーティングシステム（Huawei Hongmengなど）が誕生するでしょう。レイヤーごとに、新しい言語と対応するフレームワークが必要になります。 Go 言語の特性はこのようなポジションに非常に適しており、分散デバイスにもガバナンスのためのフレームワークが必要です。 Go Chassis もここで比較的重要な役割を果たします。

まとめると、KubeedgeやVideo CloudなどのプロジェクトでGo Chassisが使われていることからもわかるように、Go言語はインフラ分野の開発ベースになる可能性が高いと思います。

コミュニティへの参加を歓迎します。 Go Chassis オープンソース プロジェクト アドレス: https://github.com/go-chassis/go-chassis