Kitex 2 周年レビュー - 能力のアップグレード、コミュニティの協力、および将来の展望

[深セン] 源創輝: 午後 5 時 26 分、パーティー会場があなたを待っています。」

この記事は、CloudWeGo の 2 周年を祝うシリーズの最初の記事です。

今日の共有は主に 3 つの部分に分かれています。最初は、Kitex の機能のアップグレードであり、この 1 年間でのパフォーマンス 、機能、 使いやすさの 進歩を見てみましょう。 2 つ目は、コミュニティ協力プロジェクトの進捗であり、特に 2 つの重要なプロジェクト、 Kitex-Dubbo の 相互運用性 と 構成センターの統合です 。 3 つ目は、現在行っていること、および計画していることのいくつかについてネタバレを紹介することです。

機能のアップグレード

パフォーマンス

2021 年 9 月に、CloudWeGo 公式 Web サイトに掲載されている記事「 ByteDance Go RPC Framework Kitex Performance Optimization Practice 」を公開しました。この記事では、自社開発のネットワークライブラリ Netpoll と自社開発の Thrift Decoder を使用して編集する方法を紹介します。 fastCodec を使用して Kitex のパフォーマンスを最適化します。

それ以来、Kitex コアリクエストリンクのパフォーマンスを向上させることは非常に困難になってきました。実際、私たちは常に新しい機能を追加しながら、Kitex のパフォーマンスの低下を回避するために懸命に努力する必要がありました。

それにもかかわらず、私たちは Kitex のパフォーマンスを最適化する努力を決してやめませんでした。 Byte 内では、コアリンクのパフォーマンス向上をすでに実験し、推進していますが、これについては後ほど紹介します。

DynamicGo に基づく一般化された呼び出し

まず、リリースされたパフォーマンスの最適化、DynamicGo に基づく一般化された呼び出しを紹介します。 汎用呼び出しは、 Kitex Generic Client を使用して、事前に SDK コード (つまり、Kitex Client) を生成せずに、ターゲットサービスの API を直接呼び出すことができる、Kitex の高度な機能です。

たとえば、ByteDance の内部インターフェイステストツール、API ゲートウェイなどは、HTTP リクエスト (リクエスト本文は JSON 形式) を受信し、それを Thrift バイナリに変換して、Kitex サーバーに送信できる、Kitex の汎用クライアントを使用します。

実装計画では、 map[string]interface{} 汎用コンテナとしてを利用し、リクエスト時にまず json をマップに変換し、次に Thrift IDL に基づいてマップ -> thrift 変換を完了し、応答を逆に処理します。

この利点は、柔軟性が高く、事前に生成された静的コードに依存する必要がないことです。ターゲットサービスをリクエストするために必要なのは IDL のみです。
ただし、その代償として、このような汎用コンテナは Go の GC とメモリ管理に依存しており、大量のメモリを割り当てる必要があるだけでなく、複数のデータコピーが必要になります。

そこで、プロトコル変換のパフォーマンスを向上させるために使用できるDynamicGo (ホームページ: http://github.com/cloudwego/dynamicgo ) を開発しました。プロジェクトの紹介に非常に詳細な説明があります。ここでは、その中心となる設計アイデアのみを紹介します。 元のバイトストリーム に基づいて、 データ処理と変換が その場で完了します。

プーリングテクノロジーにより、Dynamicgo はメモリを 1 回事前に割り当てるだけで済み、高速化のために SSE や AVX などの SIMD 命令セットを使用することで、最終的に大幅なパフォーマンスの向上を実現します。

以下の図に示すように、一般化呼び出しの元の実装と比較して、6KB データのエンコードおよびデコードテストでは、パフォーマンスが 4 ～ 9 倍 向上し、事前に生成された静的コード よりもさらに優れてい ました。

実際の原理は非常に単純です。IDL の解析に基づいて型記述子を生成し、次のプロトコル変換プロセスを実行します。

毎回、JSON バイトストリームからキーと値のペアを読み取ります。
IDL 記述子に従って、キーに対応する Thrift フィールドを見つけます。
対応するタイプの Thrift エンコード仕様に従って Value のエンコードを完了し、それを出力バイトストリームに書き込みます。
JSON 全体が処理されるまで、このプロセスをループします。

DynamicGo は、JSON/Thrift プロトコル変換の最適化に加えて、データオーケストレーションシナリオのパフォーマンスを最適化するための Thrift DOM メソッドも提供します。たとえば、Douyin のビジネスチームは、リクエスト内の特定のフィールドのみで不正なデータを削除する必要がある場合、DynamicGo の Thrift DOM API を使用するのが非常に適しており、10 倍のパフォーマンス向上を達成できます。詳細については、を参照してください。 DynamicGo のドキュメント。ここでは詳しく説明しません。

Frugal - 高性能の JIT ベースの Thrift コーデック

Frugal は、 JIT コンパイルテクノロジに基づいた高性能 Thrift コーデックです。

公式の Thrift および Kitex のデフォルトコーデックは、Thrift IDL の解析と、対応するエンコードおよびデコード Go コードの生成に基づいています。 JIT テクノロジを通じて、 実行時 のパフォーマンスが向上した エンコードおよびデコードコードを 動的に生成できます。つまり、よりコンパクトなマシンコードを生成し、キャッシュミスを削減し、分岐ミスを削減し、 SIMD 命令を使用して高速化し、レジスタベースの関数呼び出しを使用します (Go のデフォルトはベースです)。スタック上にあります)。

エンコードおよびデコードテストのパフォーマンス指標は次のとおりです。

ご覧のとおり、Frugal のパフォーマンスは従来の方法よりも大幅に優れています。

パフォーマンス上の利点に加えて、コーデックコードが生成されないため、さらなる利点もあります。

一方では、 ウェアハウスがより簡潔になり 、生成されたコードが 700MB になったプロジェクトがありますが、frugal に切り替えた後は、元のサイズの約 5% にすぎなくなり、ウェアハウスのメンテナンスの負担が大幅に軽減されました。実際にレビューできないコードは、IDL の変更後に生成されなくなります。その一方で、 IDE の 読み込み速度 とプロジェクトの コンパイル速度 も大幅に向上します。

実際、Frugal は昨年リリースされましたが、当時の初期バージョンのカバー範囲は十分ではありませんでした。今年は安定性の最適化に重点を置き、最近リリースされたバージョン v0.1.12 は運用運用で安定して使用できるように、既知の問題をすべて修正しました。たとえば、ByteDance の電子商取引ビジネスラインでは、あるサービスのピーク QPS は約 25K であり、Frugal に完全に切り替えられ、数か月間安定して稼働しています。

Frugal は現在 Go1.16 ～ Go1.21 をサポートしていますが、現在は AMD64 アーキテクチャのみをサポートしていますが、将来的には ARM64 アーキテクチャもサポートする予定で、将来のバージョンでは Frugal を Kitex のデフォルトコーデックとして使用する可能性があります。

関数

Kitex は過去 1 年間に v0.4.3 から v0.7.2 にアップグレードされており、コマンドラインツール 、 gRPC 、 Thrift エンコードとデコード、再試行、一般化された 呼び出し、および サービスガバナンス設定を 含む 40 を超える機能関連のプルリクエストがあります。多くの点で、ここではさらにいくつかの重要な機能に焦点を当てます。

フォールバック - ビジネスカスタムダウングレード

1 つ目は、バージョン v0.5.0 で Kitex によって追加されたフォールバック機能です。

需要の背景としては、RPC リクエストが失敗して応答を取得できない場合、ビジネスコードで何らかのダウングレード戦略を実装する必要があることがよくあります。

たとえば、情報フロービジネスにおいて、推奨サービスをリクエストする際に API アクセス層で偶発的なエラー (タイムアウトなど) が発生した場合、ユーザーにエラーが発生したことを通知し、ユーザーに再試行させるというのが単純かつ粗雑なアプローチですが、これにより、エクスペリエンスが低下します。より良いダウングレード戦略は、ユーザーがそれについてほとんど知らない、人気のあるアイテムをいくつか返すことです。これにより、エクスペリエンスが大幅に向上します。

Kitex の古いバージョンの問題は、サーキットブレーカーやタイムアウトなどの組み込みミドルウェア以降のミドルウェアにビジネス向けにカスタマイズされたミドルウェアを実装できないことです。唯一の方法はビジネスコードを直接変更することであり、これは非常に煩わしいものです。呼び出されるすべてのメソッドを変更する必要があるため、見落としがちです。特定のメソッドを呼び出すビジネスロジックを追加する場合、それが見逃されないことを保証するメカニズムはありません。

新しいフォールバック機能により、 企業はダウングレード戦略を実装するためにクライアントを初期化するときにフォールバック方法を指定できるようになります 。

簡単な使用例を次に示します。

クライアントの初期化時に指定されたこのメソッドは、各リクエストの終了前に呼び出されます。これに基づいて、カスタムダウングレード戦略を実装でき、その実装を統合できます。戦略。

Thrift FastCodec - 未知のフィールドをサポート

実際のビジネスシナリオでは、リクエストリンクには複数のノードが関与することがよくあります。

リンク A -> B -> C -> D を例にとると、ノード A の特定の構造は、B と C を介してノード D に透過的に送信される必要があります。前の実装では、たとえば、新しいフィールドが A に追加された場合 Extra 、 新しい IDLを使用して すべてのノードのコードを再生成し 、それを再デプロイしてノード D の Extra フィールドの値を取得する必要があります。プロセス全体が複雑で、更新サイクルが比較的長くなります。中間ノードが別のチームのサービスである場合、チーム間の調整が必要となり、非常に手間がかかります。

Kitex v0.5.2 では、自社開発の fastCodec に不明なフィールド機能を実装しました。これにより、この問題をうまく解決できます。

たとえば、同じリンク A -> B -> C -> D では、ノード B と C のコードは変更されません (次の図に示すように)。解析すると、フィールドが存在することがわかります id=2 。対応するフィールドが構造体に見つからないため、この未エクスポートの _unknownFields フィールド (実際にはバイトスライスのエイリアス) が書き込まれます。

A サービスと D サービスは新しい IDL で再生成され (次の図を参照)、 Extra フィールドが含まれるため、 id=2 フィールドを解析するときにこの Extra フィールドに書き込むことができ、ビジネスコードを通常どおり使用できます。

さらに、v0.7.0 では、「 シリアル化 なし」 (バイトストリームの直接コピー) を使用して、この機能のパフォーマンスの最適化も実行し、未知のフィールドのエンコードおよびデコードのパフォーマンスを約 6 ～ 7倍向上させました。

GLSに基づくセッション配信メカニズム

紹介する価値のあるもう 1 つの機能も、長いリンクに関連しています。

Byte 内では、LogID を使用して呼び出しチェーン全体を追跡します。これには、リンク内のすべてのノードが必要に応じてこのチケットを透過的に送信する必要があります。私たちの実装では、LogID はリクエスト本文には配置されませんが、メタデータの形式で透過的に送信されます。

リンク A -> B -> C を例に挙げます。A が B の A_Call_B メソッドを呼び出すと、受信した LogID は ctx B が C をリクエストするときに、これをメソッド ctx にのみ渡します。 client C.B_Call_C このようにして、LogID を渡すことができます。

しかし、実際の状況では、C サービスを要求するコードが複数のレイヤーでパッケージ化されていることが多く、 ctx の透過的な送信が簡単に見逃されます。C サービスの要求は サードパーティによって完了される ため、さらに厄介です。 library、およびそのライブラリのインターフェイスは受信コードをサポートしていません ctx 。そのようなコード変換は非常にコストがかかり、完了するには複数のチームの調整が必要になる場合があります。

この問題点を解決するために、GLS (ゴルーチンローカルストレージ) に基づくセッション転送メカニズムを導入しました。具体的な計画は次のとおりです。

Kitex サーバー側では、リクエストを受信した後、まず GLS 内のコンテキストをバックアップし、次にビジネスコードであるハンドラーを呼び出します。
ビジネスコードでクライアントを呼び出してリクエストを送信するときは、まず入力 ctx に予期したチケットが含まれているかどうかを確認し、含まれていない場合は GLS バックアップから取り出してリクエストを送信します。

具体的な例を次に示します。

例証します:

サーバーの初期化時に ContextBackup スイッチをオンにする
クライアントの初期化時に指定します backupHandler
各リクエストが行われる前に、このハンドラーが呼び出されて、入力パラメータに次のものが含まれているかどうかがチェックされます。 LogID
含まれていない場合は、バックアップから ctx 読み取り、現在の ctx バックアップにマージして返します (戻り useNewCtx = true 値は、Kitex がこの新しい ctx バックアップを使用してリクエストを送信する必要があることを意味します)

上記の設定をオンにすると、ビジネスコードで間違ったコンテキストが使用されている場合でも、リンク全体を直列に接続できるようになります。

最後に、サーバー初期化の async パラメーターを導入しましょう。これにより、ハンドラー内の新しい goroutine でリクエストを送信する問題が解決されます。これらは同じ goroutine ではないため、Local Storage を直接共有することはできません。pprof の goroutine の色付けメカニズムから学び、バックアップを ctx 新しい goroutine に渡すことで、 非同期 シナリオで 暗黙的にチケットを渡す 機能を実現します。

使いやすさ

高性能・豊富な機能に加え、Kitexの使いやすさの向上にも注力しています。

ドキュメント | ドキュメント

誰もが知っているように、プログラマーが最も嫌うことは 2 つあります。1 つはドキュメントを書くこと、もう 1 つはドキュメントを書かないことです。そのため、私たちはドキュメント作成の初期コストを削減することを重視し、ドキュメント構築の促進に努めます。

ByteDance 内では、Kitex のドキュメントは Feishu ナレッジベースの形式で編成されており、Feishu の検索にうまく統合でき、Feishu ドキュメントは更新が容易であり、公式 Web サイトのドキュメントよりもタイムリーに更新されるためです。新機能が開発されると、ドキュメントは最初に Feishu ナレッジベースに書かれることが多く、公式 Web サイトに同期されないものもあります。さまざまな理由により、内部ブランチと外部ブランチの間の差異が増大しています。

したがって、過去 2 四半期で、私たちはドキュメントの最適化作業の新たなラウンドを開始しました。ユーザーからのフィードバックに基づいて、すべてのドキュメントを再編成し、例を追加しました。すべてのドキュメントを英語に翻訳し、公式 Web サイトに同期しました。この作業は今年中に完了する予定です。タイムアウト制御、倹約、パニック処理など、いくつかの更新されたドキュメントがすでに公式 Web サイトでご覧になれます。ぜひ公式 Web サイトにアクセスして、バグの発見にご協力ください。

さらに、社内ドキュメントを公式 Web サイトに自動的に同期する仕組みも構築しており、将来的にはオープンソースユーザーも社内ユーザーと同様にタイムリーに更新されたドキュメントを入手できるようにしたいと考えています。

その他の最適化 |

ドキュメントに加えて、Kitex はその他のユーザビリティ関連の作業も行っています。

サンプルプロジェクト「Note Service」をリリースしました。このサンプルでは、ミドルウェア、電流制限、リトライ、タイムアウト制御などのさまざまな機能の使用法を示し、実際のプロジェクトコードを通じて、Kitex ユーザーにリファレンスを提供します。ここで例を確認してください: https://github.com/cloudwego/kitex-examples/tree/main/bizdemo/easy_note。

次に、トラブルシューティングの効率を向上させるために熱心に取り組んでいます。たとえば、毎日のオンコールのニーズに基づいて、より具体的なコンテキスト情報 (タイムアウトエラーの具体的な理由、パニックのメソッド名など) をエラーメッセージに追加しました。メッセージ、および thrift コーデックエラーメッセージなど) を使用して、特定の問題点を迅速に特定します。

さらに、Kitex コマンドラインツールは引き続き改良されています。

たとえば、多くの企業ユーザーは Windows 上で開発を行っていますが、以前は Windows では通常のコード生成ができなかったため、これらのユーザーを支援するために Linux 環境も必要でしたが、これらのユーザーのフィードバックに基づいて最適化を行いました。。
また、参照されていない構造を特定し、コード生成時に直接除外できる IDL クリッピングツールも実装しました。これは、行き詰まっている一部の古いプロジェクトに非常に役立ちます。

地域協力プロジェクト

昨年、CloudWeGo コミュニティの支援により、特に Dubbo の相互運用性と構成センターの統合という 2 つのプロジェクトで多くの成果を達成しました。

ダボ相互通 |ダボインターコミュニケーション

Kitex はもともと Thrift RPC フレームワークでしたが、そのアーキテクチャ設計は優れたスケーラビリティを備えています。図に示すように、新しいプロトコルを追加するときの中心的な作業は、Codec インターフェイスに従って対応するプロトコルコーデック (Codec または PayloadCodec) を実装することです。

Dubbo 相互運用性プロジェクトは、企業ユーザーのニーズから生まれ、サプライヤーが Dubbo Java を使用して実装したいくつかの周辺サービスを利用して、これらのサービスを要求し、プロジェクト管理コストを削減したいと考えています。

このプロジェクトは地域の学生から熱い支持を受けており、多くの学生がこのプロジェクトに参加しました。特に、中心的なタスクの 1 つを担当する @DMwangnima は、Dubbo コミュニティの開発者でもあるため、開発プロセスは多くの回り道をせずに済みました。

具体的な実施計画に関しては、ダボ公式とは異なる考え方を採用しました。 hessian2 プロトコルの分析によると、その基本的な型システムは基本的に Thrift と重複しているため、Thrift IDL に基づいて Kitex Dubbo-Hessian2 プロジェクトスキャフォールディングを生成しました。

最初のフェーズで機能を迅速に実装するために、シリアル化と逆シリアル化のために Dubbo-go フレームワークの hessian2 ライブラリを直接借用し、Dubbo 公式ドキュメントと Dubbo-Go ソースコードを参照して Kitex 独自の DubboCodec を実装しました。

10 月にコードの最初のバージョンが完成しました。プロジェクトのアドレスは https://github.com/kitex-contrib/codec-dubbo です。興味のあるユーザーは、上記のドキュメントに従って試してみてください。 Kitex と比較できます。 Thrift と同様に、Thrift IDL を作成し、kitex コマンドラインを使用してスキャフォールディングを生成し (プロトコルを hessian2 として指定する必要があることに注意してください)、クライアントとサーバーが初期化されるコードで DubboCodec を指定します。をクリックすると、ビジネスコードの作成を開始できます。

これにより、ユーザーのしきい値が下がるだけでなく、IDL を使用してインターフェイス関連の情報が管理されるため、保守性が向上します。

現時点では、 Kitexと Dubbo-Java、Kitex と Dubbo-Goの間の相互運用性を実現できています。

これからの計画：

1 つ目は、dubbo-java との互換性を向上させ、ユーザーが IDL アノテーションで対応する Java タイプを指定できるようにすることです。
2つ目は登録センターとの連携です。 Kitex には対応する登録センターモジュールがすでにありますが、特定のデータ形式が Dubbo と一致していないため、この領域はまだ修正が必要であり、関連する作業は間もなく完了します。
最後に、パフォーマンスの問題があります。現時点では、dubbo-go-hessian2 ライブラリは完全にリフレクションに基づいているため、パフォーマンスを最適化する余地がたくさんあります。エンコードとデコードのパフォーマンスのボトルネックを解決するために、Hessian2 の FastCodec を実装することが計画されています。

このプロジェクトの推進中に、Kitex は Dubbo コミュニティの成果を吸収し、上記の互換性とパフォーマンスのソリューションを改善できる領域も発見しました。ダボコミュニティにも利益をもたらすことが期待されています。

また、このプロジェクトを完了するために多くの空き時間を費やしてくれた、このプロジェクトのコミュニティ貢献者である @DMwangnima、@Lvnszn、@ahaostudy、@jasondeng1997、@VaderKai、および他の学生たちにも特別な感謝の意を表したいと思います。

構成センターの統合 | 構成センターの統合

コミュニティ協力のもう 1 つの重要なプロジェクトは、「構成センターの統合」です。

Kitex は、クライアントのタイムアウト、再試行、サーキットブレーカー、サーバーの電流制限など、動的に構成可能なサービス管理機能を提供します。

これらのサービスガバナンス機能は、Byte 内で頻繁に使用されます。マイクロサービス開発者は、Byte が独自に構築したサービスガバナンス構成プラットフォームでこれらの構成を編集でき、その粒度は準リアルタイムで有効になります。マイクロサービスの SLA を向上させるのに非常に役立ちます。

しかし、企業ユーザーとの対話の結果、これらの機能は通常、非常に使いやすく、粒度が粗く、適時性が低く、ハードコーディングされた指定された構成のみであるか、単純なファイルを介して構成されている可能性があり、有効にするには再起動が必要であることがわかりました。。

ユーザーが Kitex のサービスガバナンス機能をより効果的に使用できるようにするために、Kitex がユーザーの構成センターから サービスガバナンス構成を動的に取得し 、ほぼリアルタイムで有効になるように、構成センター統合プロジェクトを立ち上げました。

config-nacos の v0.1.1 バージョンをリリースしました (注: @whalecold の継続的な投資に感謝し、公開時点では v0.3.0 に更新されています)。既存の Kitex プロジェクトにクライアントを追加することで NacosClientSuite 、config-nacos がリリースされます。 Kitex は、 N acos から 対応するサービスガバナンス設定をロードし ます。

nacosクライアント自体が提供する監視機能を利用しているため、準リアルタイムで設定変更通知を受信できるため適時性も高く、サービスを再起動する必要がありません。

さらに、構成の細分性を変更する機能も予約されています。たとえば、デフォルトの構成の細分性は、Nacos のデータ ID をこの形式で入力するだけで、このデータ ID のテンプレートを指定することもできます。たとえば、コンピュータルーム、クラスタなどを追加して、これらの構成をより細かく調整します。

共通構成センターとの統合を完了する予定です。この号には詳細な手順が記載されています https://github.com/cloudwego/kitex/issues/973 をご覧ください。

現在の進捗状況は次のとおりです。

file、apollo、etcd、Zookeeper などのモジュールは PR を提出しており、審査中です。
領事の計画は提出されました。

興味のあるクラスメートも参加して、これらの拡張モジュールをレビュー、テスト、検証することができます。

今後の展望

最後に、私たちが現在試みている方向性のいくつかについてネタバレをさせてください。

マージデプロイメント

アフィニティの導入 | アフィニティの導入

以前の最適化のほとんどはサービス内で行われましたが、最適化ポイントの数が徐々に減少するにつれて、RPC リクエストのネットワーク通信オーバーヘッドの最適化など、他の目標を検討し始めました。

具体的な計画は以下のとおりです。

1 つ目は、アフィニティスケジューリングです。コンテナ化されたスケジューリングメカニズムを変更することで、クライアントとサーバーを同じ物理マシンにスケジュールしようとします。
したがって、同一マシン通信を使用してオーバーヘッドを削減できます。

現在、弊社が実装している同一台通信には以下の3種類があります。

Unix ドメインソケットは 標準の TCP ソケットよりもパフォーマンスが優れていますが、それほどではありません。
ShmIPC (https://github.com/cloudwego/shmipc-go) は、共有メモリに基づくプロセス間通信であり、シリアル化されたデータの送信を直接省略でき、受信者にメモリアドレスを伝えるだけで済みます。
最後に、「ブラックテクノロジ」である RPAL は、Run Process As Library の略称で、Byte のカーネルチームと協力して、特定の条件が満たされたときに、2 つのプロセスを同じアドレス空間に配置します。シリアル化を行う必要すらない場合もあります。

現在、100 以上のサービスでこの機能を有効にしており、パフォーマンスが向上しており、CPU を約 5 ～ 10% 節約し、時間の消費を 10 ～ 70% 削減できます。練習パフォーマンスは、パケットサイズなどのサービスのいくつかの特性に依存します。

コンパイル時サービスインラインマージ |

もう 1 つのアイデアは、コンパイル時のマージです。

このソリューションの出発点は、マイクロサービスはチームのコラボレーションの効率を向上させるものの、特にサービスのデプロイメント、リソースの占有、通信のオーバーヘッドなどの点で、システム全体の複雑性も増大させることを発見したことです。

したがって、私たちは、ビジネスをマイクロサービスの形で開発し、単一のサービスの形で展開できる、一般にその両方を備えたソリューションを実装したいと考えています。

そこで私たちはこの計画を思いつきました。2 つのマイクロサービスの git リポジトリをマージし、名前空間を通じて競合する可能性のあるリソースを分離し、デプロイメント用の実行可能プログラムにコンパイルできるツールを開発しました。

現在、ByteDance 内には数十のサービスが接続されており、最も効果的なサービスは CPU を約 80% 節約し、レイテンシを最大 67% 削減できます。もちろん、実際のパフォーマンスはリクエストなどのサービスの特性にも依存します。バッグのサイズ。

上記は親和性に対する私たちの試みです。

連載

連載に関しては、まだまだ努力と試みを続けています。

質素 - SSA バックエンド

1 つ目は Frugal です。前述したように、そのパフォーマンスは従来の Thrift エンコードおよびデコードコードよりも大幅に優れていますが、まだ改善の余地があります。

Frugal の現在の実装では、Go を使用して対応するアセンブリコードを直接生成します。また、よりコンパクトなコードの生成、分岐の削減など、特定の実装にいくつかの最適化手法を適用しました。ただし、既存のコンパイラ最適化テクノロジを自分で作成しただけでは、それを最大限に活用することはできません。

LLVM のコンパイル最適化機能を最大限に活用できるように、go struct に基づいて SSA 準拠の LLVM IR (中間表現) を生成するように Frugal を再構築する予定です。

この変換後は、パフォーマンスが少なくとも 30% 向上することが期待されます。

オンデマンド連載 | オンデマンド連載

もう 1 つの探求方向はオンデマンドの連載で、これは 3 つの部分に分けることができます。

1枚目はコンパイル前です。現在、参照されていない型を識別できる IDL クリッピングツールをリリースしていますが、たとえば、2 つのサービス A と B が同じ型に依存している場合でも、フィールドの 1 つは A である可能性があります。必須、Bは不要。このツールにユーザーアノテーション機能を追加して、ユーザーが不要なフィールドを指定できるようにして、シリアル化のオーバーヘッドをさらに削減することを検討しています。

2つ目はコンパイルです。そのアイデアは、実際にビジネスコードリファレンスに違反しているフィールドを取得し、コンパイラのコンパイルレポートに基づいてそれらを削除することです。具体的なスキームと正確性については、まだ検証が必要です。

最後に、コンパイル後の実行時に、企業は不要なフィールドを指定することもできるため、エンコードとデコードのオーバーヘッドが節約されます。

概要 | 概要

最後に、全体的な状況を確認してみましょう。

能力アップという意味では、

Kitex は、DynamicGo を通じて汎化呼び出しのパフォーマンスを最適化し、高性能 Frugal コーデックが安定化され、運用環境で使用できるようになりました。
昨年、企業がカスタマイズされたダウングレード戦略を実装しやすくするためにフォールバックが追加され、未知のフィールドとセッション配信メカニズムが長いリンク変換の問題を解決するために使用されました。
また、ドキュメントの最適化、デモプロジェクト、トラブルシューティングの効率向上、コマンドラインツールの強化を通じて、Kitex の使いやすさも向上しました。

地域社会との連携という点では、

私たちは、Kitex-Dubbo 相互運用性プロジェクトを通じて Dubbo の hessian2 プロトコルをサポートしています。このプロジェクトは、Dubbo Java および Dubbo-Go フレームワークと相互運用でき、その後の最適化も Dubbo コミュニティにフィードバックできます。
構成センター統合プロジェクトでは、ユーザー統合を促進するために Nacos 拡張機能をリリースし、現在、他の構成センターのドッキングを推進し続けています。

今後の探求の方向性はまだいくつかあります。

マージされたデプロイメントに関しては、アフィニティデプロイメントとコンパイルとマージを通じて、マイクロサービスの利点を維持できるだけでなく、サービスを提供しない一部のモノリスの利点も享受できます。
シリアル化に関しては、Frugal のさらなる最適化を継続し、コンパイル前、コンパイル中、コンパイル後のコンパイルのあらゆる側面を通じてオンデマンドのシリアル化機能を実現します。

以上、CloudWeGo 2 周年を記念した Kitex のレビューと展望でした。皆様のお役に立てれば幸いです。ありがとうございます。