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衣類リムーバー

Video Face Swap
完全無料の 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 にアップグレードする方法について説明します。

あなたが経験豊富な PHP 開発者であれば、すでにそこにいて、すでにそれを行っていると感じているかもしれません。あなたは、運用を達成するために、かなりの数のアプリケーションを開発し、数百万行のコードをデバッグし、大量のスクリプトを微調整してきました。

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

JWTは、JSONに基づくオープン標準であり、主にアイデンティティ認証と情報交換のために、当事者間で情報を安全に送信するために使用されます。 1。JWTは、ヘッダー、ペイロード、署名の3つの部分で構成されています。 2。JWTの実用的な原則には、JWTの生成、JWTの検証、ペイロードの解析という3つのステップが含まれます。 3. PHPでの認証にJWTを使用する場合、JWTを生成および検証でき、ユーザーの役割と許可情報を高度な使用に含めることができます。 4.一般的なエラーには、署名検証障害、トークンの有効期限、およびペイロードが大きくなります。デバッグスキルには、デバッグツールの使用とロギングが含まれます。 5.パフォーマンスの最適化とベストプラクティスには、適切な署名アルゴリズムの使用、有効期間を合理的に設定することが含まれます。

このチュートリアルでは、PHPを使用してXMLドキュメントを効率的に処理する方法を示しています。 XML(拡張可能なマークアップ言語)は、人間の読みやすさとマシン解析の両方に合わせて設計された多用途のテキストベースのマークアップ言語です。一般的にデータストレージに使用されます

文字列は、文字、数字、シンボルを含む一連の文字です。このチュートリアルでは、さまざまな方法を使用してPHPの特定の文字列内の母音の数を計算する方法を学びます。英語の母音は、a、e、i、o、u、そしてそれらは大文字または小文字である可能性があります。 母音とは何ですか? 母音は、特定の発音を表すアルファベットのある文字です。大文字と小文字など、英語には5つの母音があります。 a、e、i、o、u 例1 入力:string = "tutorialspoint" 出力:6 説明する 文字列「TutorialSpoint」の母音は、u、o、i、a、o、iです。合計で6元があります

静的結合(静的::) PHPで後期静的結合(LSB)を実装し、クラスを定義するのではなく、静的コンテキストで呼び出しクラスを参照できるようにします。 1)解析プロセスは実行時に実行されます。2)継承関係のコールクラスを検索します。3)パフォーマンスオーバーヘッドをもたらす可能性があります。

PHPの魔法の方法は何ですか? PHPの魔法の方法には次のものが含まれます。1。\ _ \ _コンストラクト、オブジェクトの初期化に使用されます。 2。\ _ \ _リソースのクリーンアップに使用される破壊。 3。\ _ \ _呼び出し、存在しないメソッド呼び出しを処理します。 4。\ _ \ _ get、dynamic属性アクセスを実装します。 5。\ _ \ _セット、動的属性設定を実装します。これらの方法は、特定の状況で自動的に呼び出され、コードの柔軟性と効率を向上させます。
