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 エコシステムはそれをサポートできますか? #…
SPP フレームワーク アーキテクチャ
- プロキシ プロセスは handle_init を使用して初期化を実行し、handle_route は実行用に指定されたワーカー処理プロセスに転送され、handle_input はリクエストの受信パケットを処理します。 ワーカー プロセスは handle_init を使用して初期化を実行し、handle_process がパッケージとビジネス ロジックを処理して
- を返します。
2.3 コルーチンの紹介
C を使用することでパフォーマンス要件は満たされていますが、Redis へのアクセスなど、開発効率に多くの問題があります。サービスの高いパフォーマンスを維持するために、コード ロジックは次のような非同期コールバックを使用します。
... int ret = redis->GetString(k, getValueCallback) ...
一方、10~20w レベルに達する可能性のある後続の QPS に基づいて、コルーチンはマルチ IO サービス処理のパフォーマンスにおいてもより多くの利点を持つため、すべての IO の場所を置き換えてコルーチン メソッドの変換を開始しました。ビジネス開発の場合、Coroutine 呼び出しを使用すると、コードは次のようになります:
... int ret = redis->GetString(k, value) ...
コルーチン
3. クラウド ネイティブ
ビジネスは発展を続け、エンジニアは常に最先端のコンセプトを追い求めています。近年人気のテクノロジーポイントであるクラウドネイティブは当然無視されません。しかし、クラウドネイティブに入る前に、チームがDevOps 開発コンセプトを持っている場合、これは、アーキテクチャ設計とフレームワークの選択に関する技術的負債を返済する必要がある、骨の折れるプロセスになります。3.1 DevOps コンセプトの実装
私は以前、アーキテクチャを行う際に高いパフォーマンスを考慮していました。アーキテクチャを理解するにつれて、高いパフォーマンスはアーキテクチャ設計のほんの一部にすぎないことがわかりました。良いアーキテクチャを構築したい場合は、より機敏なプロセスと、サービス ガバナンスの概念、具体的な考慮事項、次のように要約されます:
- 継続的インテグレーション: 開発者は 1 日に複数回コードを共有リポジトリに統合します。コードに対するすべての分離された変更はすぐにテストされ、統合の問題を検出して防止します
- 継続的デリバリー: 継続的デリバリー (CD) により、CI リポジトリでテストされたコードの各バージョンがいつでもリリースできるようになります
- 継続的デプロイメント: これには、グレースケール デプロイメント、Blue-Green リリースなどが含まれます。目的は、迅速に反復することです。比較的完全な統合テストの後、グレースケール検証を実行できます。
- サービスディスカバリ: サービスをマイクロサービスに変換し、サービス間の呼び出しを簡素化します
- RPC フレームワーク: 高性能を追求するサーバー フレームワークは、電流制限やサーキット ブレーカーなどの基本コンポーネントのサポートも考慮する必要があります。 監視システム: Promethues、OpenTracing、その他の機能を統合して、アジャイル開発プロセスにおけるオンラインの問題を迅速に発見します
- コンテナ化: 環境を統一し、クラウドネイティブのシナリオを事前に検討するには、開発プロセスでコンテナ化が不可欠です
- #…
この時点で、シンプルな高性能サーバーがアーキテクチャの目標になっていることがわかります。そのため、DevOps コンセプトを適切に実装するには、アーキテクチャを再調査して設計する必要があります。
3.2 マルチスレッド
DevOps に基づいて、上記の C サーバー フレームワークと組み合わせると、マルチプロセスではアーキテクチャのニーズを満たせなくなることがわかりました。その理由は次のとおりです:
複数のプロセスは、Docker コンテナの単一プロセスの概念と一致しません
- 作業プロセスの負荷が不均一である場合、マルチコアを有効に活用する方法
- 監視システムとの効果的な連携
- ビジネス構成が繰り返し読み込まれるため、構成センターを再適応する必要がある
- ステートフル サービスを提供するために複数のプロセスを使用するのはあまり合理的ではありません #…
- ビジネスも 100 万 QPS に成長しました。サービス管理とサービス コールのコストを改善するには、別のアーキテクチャを検討する必要があります:
gRPC
gRPC はマルチスレッド RPC サーバーです。成熟したエコシステム、さまざまなミドルウェア、複数言語のサポートなどを備えています。0 から 1 へのビジネス開発には良い選択ですが、ビジネスの移行には課題に直面していますたとえば、独自のミドルウェア アダプテーション サービス ディスカバリ、構成センターなどの開発、カスタム エンコーディングおよびデコーディングに応じたプロトコルの変換、コルーチンの結合方法など。社内のコンポーネントの RPC
(2)tRPCを使用する
https://trpc.group/zh/docs/what-is-trpc/archtecture_design/
サーバーの基本フレームワーク:
新しいアーキテクチャ
3.3、k8s に向けて
新しいテクノロジーを追求し、次のトレンドを待つだけでよいように思えますか? 実際、現時点ではさらに多くの課題があります。クラウドの利便性と、移行サービス アーキテクチャの無秩序な拡大により、ビジネス サービスと論理レベルはますます複雑になり、同時にサービスが依存する下流リンクはますます長くなります。私たちのフレームワークはリンク追跡をサポートしていますが、リンクが長くなると、サービスの制御性と安定性が低下します。多くの人員が日々の業務をサポートしています。
###何をするか?…###ビジネス ロジックをマージしてアーキテクチャを簡素化する必要がありますか? ここでの問題は、ビジネス ロジックが複雑な場合、サイクルに時間がかかることが多く、コストが比較的高く、メリットがあまり大きくないことです
新しいアーキテクチャを再開発するのか、朽ち果てたものはそのままにするのか、それとも廃棄し、新しいアーキテクチャを使って次の開発に適応するのか。
以上がLinux ハイパフォーマンス ネットワーク プログラミングに関する 10 のディスカッションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











PHP 8.4 では、いくつかの新機能、セキュリティの改善、パフォーマンスの改善が行われ、かなりの量の機能の非推奨と削除が行われています。 このガイドでは、Ubuntu、Debian、またはその派生版に PHP 8.4 をインストールする方法、または PHP 8.4 にアップグレードする方法について説明します。

ファイルのアップロードを行うには、フォーム ヘルパーを使用します。ここではファイルアップロードの例を示します。

CakePHP は、PHP 用のオープンソース フレームワークです。これは、アプリケーションの開発、展開、保守をより簡単にすることを目的としています。 CakePHP は、強力かつ理解しやすい MVC のようなアーキテクチャに基づいています。モデル、ビュー、コントローラー

Visual Studio Code (VS Code とも呼ばれる) は、すべての主要なオペレーティング システムで利用できる無料のソース コード エディター (統合開発環境 (IDE)) です。 多くのプログラミング言語の拡張機能の大規模なコレクションを備えた VS Code は、
