Linux ハイパフォーマンス ネットワーク プログラミングに関する 10 のディスカッション

「Linux ハイパフォーマンス ネットワーク プログラミングに関する 10 の話」は、数か月にわたって書かれています。10 件の技術ブログが書かれています。過去数年間の私の仕事を振り返るために、要約を書こうと思いました。 Goose Factory での 2 つの経験が合計されます。もう 8 年近くになります。ネジの作業に多くの時間を費やしていますが、参加、最適化、開発に至るまで、高性能アーキテクチャの進化における経験から多くのことを学びました。アーキテクチャの最終設計。

1. 事前に設計するか、それともビジネスを進化させるか?

誰もがプロジェクトの 0 から 1 へのプロセスを経験したことがあると思います。質問したいのですが、多くの場合、アーキテクチャはビジネスとともに進化しますか、それとも事前に設計されていますか?

関連する建築関連の本を読んだことがある人もいるかもしれませんが、これらの本のほとんどは、建築はビジネスの発展とともに進化すると信じています。しかし、建築は事前に設計されるべきだと主張する建築家も多い。ここでは、ひとまず結論を出すのではなく、私自身の経験を通してアーキテクチャの進化を探っていきたいと思います。

2. PHP から C へ

2.1 シンプルな PHP アーキテクチャ

PHP はシンプルで便利な言語として、大きな工場のすべての部門に存在するはずです。当時、私は仕事で C 言語と PHP の 2 つの言語を使用していました。PHP を使用した関数の開発は非常に速く、成熟したライブラリが多数あるため、古典的な nginx
php-fpm memcache アーキテクチャを形成します。

php アーキテクチャ

現在のアーキテクチャでは、1 台の 8c8g マシンが 1000qps をサポートすることは大きな問題ではないため、ビジネスにとっては現在 1wqps 未満ですが、明らかに、さらに数台のマシンがサポートできることは明らかです。キャッシュ層の設計に関しては、redisがまだ十分に発達していなかった当時はmemcacheが主流のキャッシュコンポーネントであり、ビジネス的にもPHPとドッキングするにもシンプルなものでした。しかし、ビジネスの発展に伴い、その時点の計算曲線によれば 1 年以内に 5wqps に達する可能性があります。nginx
php-fpm memcache アーキテクチャを使用するのが妥当でしょうか? 議論の結果、目標は、そこで、サーバー側で高性能の発見の旅を始めました。

2.2 マルチプロセスフレームワーク

当時、高性能なサーバーサイドフレームワークを実現するために、PHPのプラグイン機能を利用してサーバー機能をスクリプト言語に統合するという解決策が検討されました。このアプローチにより、高いパフォーマンスという目標がある程度達成されます。たとえば、現在では PHP の swoole はこのメソッドの発展結果です。

php-サーバー

ただし、ここで解決しなければならない問題がいくつかあります:

• PHP 拡張機能の使用シナリオをよく理解し、落とし穴を避けてください
• PHP 自体の使用におけるメモリ リークの問題
• 問題発生時のトラブルシューティングのコスト。たとえば、問題が発生すると、PHP のソース コードを理解する必要がある場合がありますが、数十万行のコードに直面すると、このコストは非常に高くなります。
• PHP は使い方が簡単です。これは実際に比較的当てはまります。Docker の台頭により、スタンドアロンの時代は必然的に過ぎます。PHP エコシステムはそれをサポートできますか?
#…

上記のビジネス開発の考え方と分析に基づいて、実際にはサーバーを自社で実装するか、既存の C フレームワークを使用して一連のビジネス層サーバーを実装する方が合理的であるため、検討の結果、SPP を採用しました。社内のフレームワークのアーキテクチャは次のとおりです ：

SPP フレームワーク アーキテクチャ

SPP はマルチプロセス アーキテクチャであることがわかります。そのアーキテクチャは Nginx に似ており、プロキシ プロセスとワーカー プロセスに分かれています。

• プロキシ プロセスは handle_init を使用して初期化を実行し、handle_route は実行用に指定されたワーカー処理プロセスに転送され、handle_input はリクエストの受信パケットを処理します。
ワーカー プロセスは handle_init を使用して初期化を実行し、handle_process がパッケージとビジネス ロジックを処理して
• を返します。

C アーキテクチャを使用した後、単一マシンのパフォーマンスは 6kqps に直接向上し、基本的にパフォーマンス要件を満たしています。同じマシン上でより多くのビジネスをサポートでき、アーキテクチャが安定するようです。

2.3 コルーチンの紹介

C を使用することでパフォーマンス要件は満たされていますが、Redis へのアクセスなど、開発効率に多くの問題があります。サービスの高いパフォーマンスを維持するために、コード ロジックは次のような非同期コールバックを使用します。

... int ret = redis->GetString(k, getValueCallback) ...

GetValueCallbackはコールバック関数です。io操作が多い場合、ここでのコールバックは非常に面倒です。同様の同期メソッドでカプセル化しても非常に扱いが面倒です。その際、std:: future と std::async は導入されませんでした。

一方、10~20w レベルに達する可能性のある後続の QPS に基づいて、コルーチンはマルチ IO サービス処理のパフォーマンスにおいてもより多くの利点を持つため、すべての IO の場所を置き換えてコルーチン メソッドの変換を開始しました。ビジネス開発の場合、Coroutine 呼び出しを使用すると、コードは次のようになります:

... int ret = redis->GetString(k, value) ...

値は直接使用できる戻り値です。コードに io が含まれると、最下層は io をコルーチンの API に置き換え、ブロックされたすべての io 操作が同期プリミティブになり、コード構造が開発効率が大幅に向上しました（コルーチンの具体的な実装については、連載記事「Linux ハイパフォーマンスネットワークプログラミング 10 話 | コルーチン」を参照してください）。

コルーチン

アーキテクチャにはまだ多くの変更はありません。マルチプロセス コルーチン手法は数年間ビジネス開発をサポートしてきました。パフォーマンスの指数関数的な成長はありませんが、高性能の探索と降下においてより多くの経験を積んできました。

3. クラウド ネイティブ

ビジネスは発展を続け、エンジニアは常に最先端のコンセプトを追い求めています。近年人気のテクノロジーポイントであるクラウドネイティブは当然無視されません。しかし、クラウドネイティブに入る前に、チームがDevOps 開発コンセプトを持っている場合、これは、アーキテクチャ設計とフレームワークの選択に関する技術的負債を返済する必要がある、骨の折れるプロセスになります。

3.1 DevOps コンセプトの実装

私は以前、アーキテクチャを行う際に高いパフォーマンスを考慮していました。アーキテクチャを理解するにつれて、高いパフォーマンスはアーキテクチャ設計のほんの一部にすぎないことがわかりました。良いアーキテクチャを構築したい場合は、より機敏なプロセスと、サービス ガバナンスの概念、具体的な考慮事項、次のように要約されます:

• 継続的インテグレーション: 開発者は 1 日に複数回コードを共有リポジトリに統合します。コードに対するすべての分離された変更はすぐにテストされ、統合の問題を検出して防止します
• 継続的デリバリー: 継続的デリバリー (CD) により、CI リポジトリでテストされたコードの各バージョンがいつでもリリースできるようになります
• 継続的デプロイメント: これには、グレースケール デプロイメント、Blue-Green リリースなどが含まれます。目的は、迅速に反復することです。比較的完全な統合テストの後、グレースケール検証を実行できます。
• サービスディスカバリ: サービスをマイクロサービスに変換し、サービス間の呼び出しを簡素化します
• RPC フレームワーク: 高性能を追求するサーバー フレームワークは、電流制限やサーキット ブレーカーなどの基本コンポーネントのサポートも考慮する必要があります。
監視システム: Promethues、OpenTracing、その他の機能を統合して、アジャイル開発プロセスにおけるオンラインの問題を迅速に発見します
コンテナ化: 環境を統一し、クラウドネイティブのシナリオを事前に検討するには、開発プロセスでコンテナ化が不可欠です
• #…

DevOps

この時点で、シンプルな高性能サーバーがアーキテクチャの目標になっていることがわかります。そのため、DevOps コンセプトを適切に実装するには、アーキテクチャを再調査して設計する必要があります。

3.2 マルチスレッド

DevOps に基づいて、上記の C サーバー フレームワークと組み合わせると、マルチプロセスではアーキテクチャのニーズを満たせなくなることがわかりました。その理由は次のとおりです:

複数のプロセスは、Docker コンテナの単一プロセスの概念と一致しません

• 作業プロセスの負荷が不均一である場合、マルチコアを有効に活用する方法
• 監視システムとの効果的な連携
• ビジネス構成が繰り返し読み込まれるため、構成センターを再適応する必要がある
• ステートフル サービスを提供するために複数のプロセスを使用するのはあまり合理的ではありません
#…
• ビジネスも 100 万 QPS に成長しました。サービス管理とサービス コールのコストを改善するには、別のアーキテクチャを検討する必要があります:

(1)gRPCの研究

gRPC

gRPC はマルチスレッド RPC サーバーです。成熟したエコシステム、さまざまなミドルウェア、複数言語のサポートなどを備えています。0 から 1 へのビジネス開発には良い選択ですが、ビジネスの移行には課題に直面していますたとえば、独自のミドルウェア アダプテーション サービス ディスカバリ、構成センターなどの開発、カスタム エンコーディングおよびデコーディングに応じたプロトコルの変換、コルーチンの結合方法など。社内のコンポーネントの RPC

とより適切に統合されます。

(2)tRPCを使用する

たまたま社内で tRPC を開発していたところ、調査の結果、基本的にニーズを満たしていることがわかったので、開発の初期段階で tRPC の C バージョンを当社のシステムに適用することを試みました。変換に伴い、高性能 RPC フレームワークがビジネス システムに移行され、tRPC アーキテクチャが使用されました:

https://trpc.group/zh/docs/what-is-trpc/archtecture_design/

上記の検討と事業展開を踏まえ、今後の RPC の多様化シナリオに適応するため、高パフォーマンスをベースとした RPC サーバー フレームワークの統一を目指し、業務システムに適応した RPC セットを導入しました

サーバーの基本フレームワーク:

新しいアーキテクチャ

3.3、k8s に向けて

上記の選択と変換を経た後、k8s への移行中にサービスを段階的に接続できます。サービスはあまり多くの変換を行わずにそのプラットフォーム上で実行でき、接続されたプラットフォームも完成させることができます。

新しいテクノロジーを追求し、次のトレンドを待つだけでよいように思えますか? 実際、現時点ではさらに多くの課題があります。クラウドの利便性と、移行サービス アーキテクチャの無秩序な拡大により、ビジネス サービスと論理レベルはますます複雑になり、同時にサービスが依存する下流リンクはますます長くなります。私たちのフレームワークはリンク追跡をサポートしていますが、リンクが長くなると、サービスの制御性と安定性が低下します。多くの人員が日々の業務をサポートしています。

＃＃＃何をするか？…＃＃＃

ビジネス ロジックをマージしてアーキテクチャを簡素化する必要がありますか? ここでの問題は、ビジネス ロジックが複雑な場合、サイクルに時間がかかることが多く、コストが比較的高く、メリットがあまり大きくないことです

新しいアーキテクチャを再開発するのか、朽ち果てたものはそのままにするのか、それとも廃棄し、新しいアーキテクチャを使って次の開発に適応するのか。

以上がLinux ハイパフォーマンス ネットワーク プログラミングに関する 10 のディスカッションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。