現在、ストリーミングビデオ技術は、Youtube、Youku、iQiyi、Tencent Video、Douyin、Huajiao Live、Yizhibo、Xueersi Online School、TutorABCなどのさまざまな分野に適用されており、さまざまな業界のビデオ操作プラットフォームがすべて実現されています。大きな成功を収めましたが、これらのプラットフォームの基盤となるインフラストラクチャは、ビデオ公開テクノロジーと切り離すことができません。ビデオ公開テクノロジーは、これらのプラットフォームの運用を成功させるための中核的な技術サポートでもあります。
Youku チームでの長年にわたる製品開発の経験に基づいて、私の全体的な感想を話させてください。これは、ビデオ アプリケーションの分野で将来の起業家に役立つかもしれません。
まず、基礎となる技術アーキテクチャ
ビデオ公開プラットフォームの基盤となるインフラストラクチャは合理的に設計される必要があり、ここでは次の特性を考慮する必要があります。
安定性、高性能、拡張の容易さ、オープンスタンダード、互換性、技術の先見の明、災害復旧メカニズム。
安定性：
ビデオ ストリーミング メディア パブリッシング プラットフォームにおける主な技術リンクには、ビデオ エンコード、ビデオ前処理 (インターレース解除、ノイズ リダクション、ビデオ スケーリング、透かしオーバーレイ、ビデオ フィルタリング、黒エッジ除去、画像強調、キー フレーム抽出、顔の美化など) が含まれます。 、アクション認識）、ストリーミング メディアのマルチプロトコル リリース、ビデオのトランスコーディング、大規模なビデオのアップロード、マルチ端末のデコーディング、リアルタイム メッセージ サービス、各技術リンクの技術的実装は、アプリケーション プラットフォーム全体の運用効率に関連します。
これらの主要な技術的リンクの実現は、主にソフトウェア レベルの技術的実現に依存します。これらの主要なテクノロジは、C++、C#、Java、GO などのさまざまなコーディング言語を通じて実装できます。実装の容易さの点では C++ が最も実装が難しく、Java が最も簡単ですが、プログラムの安定性とパフォーマンスの点では C++ 言語が最も安定性とパフォーマンスが優れています。したがって、Youku プラットフォームの開発と実装では、主要なリンクに C++ 言語を使用します。
ハイパフォーマンス：
運用プラットフォームにとって、ソフトウェアのパフォーマンスはプラットフォームの大規模展開の運用コストに直接関係するため、非常に重要です。
したがって、コア技術リンクを実現するには、パフォーマンスの主要な技術指標を考慮する必要があります。
たとえば、ストリーミング メディア サーバーを開発していたとき、 Java言語を使用して実装しました。チーム内のチームは 4 か月で完全なストリーミング メディア サーバーを作成しましたが、オンラインで展開した後、Dell R720 (Shuangzhiqiang E5) -2650CPU+32GB メモリ) この構成のサーバーは、同時ユーザー アクセスを 500 までしかサポートできず、CPU 占有率は 90% に達し、メモリ リソース占有率は 70% に達します。Java 仮想マシンのメモリ ガベージ コレクション メカニズムには、深刻な問題。
逆に、チーム内の別のグループは、C++言語を使用してストリーミング メディア サーバーを実装するのに半年以上かかりました (基本的な機能は以前に実現されていました)。これは、同じハードウェア構成環境で2000 人の同時ユーザー訪問をサポートできます。 CPU使用率は40%、メモリリソース占有率は20%となっており、ソフトウェアレベルでの最適化の余地がまだ多くあることがわかります。
別の例として、チームが大規模なファイル アップロード サーバーを開発している場合、チームの 1 つは Github 上のオープン ソース PHP アップロード モジュールに基づいて開発します。サーバーは Nginx を使用し、サーバーも Dell R720 (Shuangzhiqiang E5-2650CPU+32GB) を使用します。テストの結果、単一サーバーは最大 200 ユーザーの同時アップロードをサポートでき、プラグインなしでは 4GB を超える大きなファイルをアップロードし、ブラウザ側でアップロードを再開することは不可能であることがわかりました。 。
別のチームは、非同期 I/O アーキテクチャに基づいた C++ 言語を使用したアップロード サーバーの開発に 5 か月を費やしました。同じサーバー ハードウェア構成を使用すると、帯域幅のボトルネックを考慮せずに 1 台のサーバーで 20,000 人の同時ユーザーをサポートできます。アップロードと HTML5 の使用ブラウザは、4 GB を超える大きなファイルのアップロードと再開可能なアップロードをサポートでき、ブラウザ側にプラグインをインストールする必要はありません。
別の例：ビデオトランスコーディングサーバーの実現において、チーム内のチームはビデオトランスコーディング機能を実現するためにオープンソースのFFMPEGを直接使用しましたが、FFMPEGのソフトウェア機能はすでに完成しているため、チームはトランスコーディングを実現するのに半年かかりましたサーバー モジュールですが、プロジェクトがオンラインになった後、このトランスコーディング サーバーは非常に不安定で、さまざまな奇妙なクラッシュやデッドロックが頻繁に発生することが判明しました。さらに、上記の構成の DELL R720 サーバーでは、1080P 高解像度ビデオのトランスコーディングが可能です。継続的な最適化の結果、倍速のトランスコーディング効率は最終的にトランスコーディング効率の 5 倍に達し、この状態が 2 年以上続きました。そのため、プラットフォームの急速な拡大段階では、プラットフォームは 2,000 台のトランスコーディング サーバーを導入し、ストリーミング サーバーは同等の数で導入されています。
別のチームは、C++ 言語に基づいたビデオ トランスコーディング テクノロジを独自に開発し、DELL R720 サーバーと 2 枚の Nvidia Tesla ビデオ カードの同じ構成に基づいて、20 倍の速度で 1080P H.264 トランスコーディングとビデオ トランスコーディング効率を実現しました。大幅に改善されました。
さらに、現在のビデオサービスプラットフォームでは、リアルタイムメッセージサービスもコア機能モジュールであり、主にライブブロードキャスト中のテキストインタラクションとビデオ再生中のリアルタイム弾幕リリースに使用されます。このインタラクティブメッセージサービスは高い同時実行性を備えているため、たとえば、Youku のプラットフォームでオンラインの同時ユーザーが 10,000 人いる場合、ユーザーがメッセージを公開するたびに、サーバーはそのメッセージを同時に 10,000 台の端末に転送する必要があります。同時に、サーバーは 1 秒あたり 100,000 のメッセージを処理する必要があります。この種のアプリケーションの場合、業界では通常、サーバー側として Node.js が使用され、クライアント ブラウザーは WebSocket を介してサーバー側との永続的な接続を確立します。ただし、この方法でテストした結果、Node.js サーバーは最大 2,000 の同時接続しか処理できないことが判明したため、数十万の同時接続を持つ Youku のようなアプリケーション プラットフォームでは、多数のメッセージ サーバーをデプロイする必要があります。 、投資が大きすぎます。
この問題を解決するために、研究チームは研究開発チームを立ち上げ、数万人の専門家を招いてこのメッセージ サービス プラットフォームを研究しました。 Apache Software Foundation を使用し、Scala を使用し、Java で書かれています。Kafka は、高スループットの分散パブリッシュ/サブスクライブ メッセージ システムであり、Hadoop の並列読み込みメカニズムを通じてオンラインとオフラインのメッセージ処理を統合し、クラスターを通じてリアルタイム メッセージ サービスも提供します。
他のソリューションと比較すると、Kafka は実際に現実的で実現可能なアプリケーション ソリューションであり、クラスター展開アプリケーションを実装します。しかし、Kafka ベースのメッセージ サービス プラットフォームが開始された後も、主に単一ノードのパフォーマンスのボトルネックに反映される多くの欠点が依然として露呈しました。このシステムのパフォーマンスは、有名な Bilibili チームによって変換された GOIM システムなど、一部の技術チームによって改善および最適化されています ( http://www.zhiboshequ.com/news/595.html )
)、しかし、このオープンソース プロジェクトに固有の欠陥は依然として解決できません。
Kafkaの欠点: Kafka は Scala と Java 言語に基づいて開発および実装されているため、実行には Java 仮想マシン環境に依存することになります。これにより、Java 仮想マシンの固有の弱点が発生します。つまり、同時処理のパフォーマンスが向上しません。あなたが書いたコードを最適化するためにできることは何もありません。Java はインタープリタ型言語であるため、まずコンパイラによって Java 独自のファイル タイプである .class タイプのファイルにコンパイルされ、次に仮想マシン (JVM) を介して .class ファイルから行が読み取られて解釈および実行されます。 C や C++ のように、1 回のコンパイル後にオペレーティング システムによって直接実行できるため、Java 言語に基づいて開発されたシステムは、C や C++ で開発されたプログラムよりも常に数桁効率が低くなります。 。
そこで同社は、運営コストを考慮し、改めて研究開発チームを編成し、この技術の技術研究を進める必要があった。
10年以上C言語開発に携わってきた社内数名の技術者（同社がこれまで使用してきた高性能ストリーミングメディアサーバーや高性能アップロードサーバーを開発）の協力を得て、このメッセージ サーバー システムはゼロから開発されており、アーキテクチャは依然として有名な非同期 I/O モデルを使用しており、Windows および Linux プラットフォームでのコンパイルと実行をサポートし、クロスプラットフォームの問題を解決しています。クライアントとサーバー間の通信モードはそのままです。長時間接続される WebSocket プロトコルを使用します。システムの実装後、実験室環境でテストした後、1 台の Dell R720 サーバーは500,000 の同時接続をサポートでき、他の多くのシステムとは異なり、テキスト メッセージの長さに制限はありません。メッセージの長さは 256 バイト未満である必要があります。
拡張が簡単:
この種の同時実行性の高いアプリケーション プラットフォームでは、プラットフォームのスケーラビリティが非常に重要です。単一サーバーと単一ノードクラスターでサポートされる同時ユーザー数の上限のため、プラットフォームは、大規模なパフォーマンスを実現するために、マルチサーバー負荷分散とマルチノード分散展開をサポートし、CDN (コンテンツ配信ネットワーク) 機能を提供する必要があります。全国をカバーする同時出願。
標準オープン：
インターネットベースのアプリケーションであるため、ビデオおよびオーディオのコーデック標準 (H.264/H.265/AAC)、ビデオ パッケージング標準 (MP4/TS/FLV) など、国際標準化機構によって策定された対応する標準に準拠する必要があります。 )、ストリーミング メディア プロトコル標準 (HTTP-FLV、HLS、RTMP、DASH、RTSP、UDP)。
互換性:
互換性は主に次の側面に反映されます。
- サーバープラットフォームの互換性
運用コストを削減し、特定のサーバー プラットフォームへの依存を減らすために、サーバー側のソフトウェア プラットフォームは、Linux および Windows オペレーティング システム プラットフォームと互換性があり、x86 ベースの CPU および ARM ベースの CPU の動作をサポートする必要があります。
- クライアントブラウザの互換性
この種のキャリア グレードのプラットフォームでは、エンド ユーザーがどのブラウザを使用する必要があるかを要求することはできないため、市場シェアが最も高い Chromimu カーネル ブラウザ (Chrome、Firefox、Opera、360) を含む、現在の主流のブラウザ カーネルのほとんどと互換性がある必要があります。 Speed ブラウザ、UC ブラウザ）、IE Core ブラウザ、Safari ブラウザ、QQ ブラウザ、WeChat ブラウザ、Aoyou ブラウザなど。したがって、プラットフォームで使用されるクライアント プレーヤーは、これらの主流ブラウザと互換性がある必要があります。現在の技術変化の傾向は、ユーザーがプラグインをダウンロードしてインストールする必要がなく、適切に動作する HTML5 標準と互換性のあるプレーヤーを使用することです。これらのブラウザに適応します。
- クライアントのデコード機能の互換性
この側面では、サーバー側プラットフォームは、コンテンツを出力するときに、ネットワーク TV、PC、主流の Android 携帯電話、Apple 携帯電話などのさまざまな端末のデコード機能を十分に考慮する必要があります。
- ストリーミング メディア トランスポート プロトコルの互換性
端末装置が異なればサポートできる送信プロトコルも異なるため、サーバーがクライアントにデータを送信する場合、端末装置の種類を自動的に検出し、端末が許容できる送信プロトコルを使用してデータを送信できる必要があります。
たとえば、Apple モバイル端末はストリーミング メディア データを送信するために HLS プロトコルのみをサポートし、PC 端末は IE8 より前のバージョンのブラウザ環境で再生するために Flash プレーヤーを呼び出すために RTMP プロトコルのみをサポートし、Webkit コアを備えたブラウザは HTTP-FLV をサポートできます。 HLS プロトコルと DASH プロトコルのため、サーバー側プラットフォームはこれらすべての主流プロトコルをサポートし、端末に自動的に適応する必要があります。
次に、ネットワーク層のアーキテクチャ
このような大規模な運用レベルのプラットフォームでは、プラットフォームのネットワーク層アーキテクチャも非常に重要です。ネットワーク層アーキテクチャが不合理であると、運用コストとプラットフォームの保守コストが増加するためです。
たとえば、Youku プラットフォームの運営チームは北京にありますが、プラットフォームのすべてのビジネス サーバーが北京のローカル IDC コンピューター ルームに配置されている場合、サーバー ホスティング コストが高く、帯域幅コストが高く、パフォーマンスが低いなど、多くの欠点が発生します。他県でのユーザーエクスペリエンス。そこで、運用チームはプラットフォーム構築の初期段階でこの問題を考慮し、国内大手通信事業者3社が3本柱で相互接続が貧弱であるという現実を組み合わせて、分散型ネットワークアーキテクチャモデルを設計しました。プラットフォーム、発信ステーションは北京にあり、チャイナネットの BGP コンピューター ルームでは、チャイナネットの 8 つのコア ノードに第 2 レベルのノード サーバー グループがそれぞれ展開されています。後期のユーザーの急速な増加に伴い、既存の8ノードではユーザーのニーズを満たせなくなり、特に華北、華東、華南ではユーザー数が急速に増加し、運用チームも拡大しています。これに基づいてプラットフォームをアップグレードし、ユーザー数の多い州の州都に第 3 層ノード サーバーを導入し、その後、経済的に発展した州の第 2 層都市にもサーバー ノードを導入しました。
さらに、大手通信事業者3社のIDCコンピュータルームにも導入しており、ユーザーの視聴体験の悪さや運用コストの高さの問題を大幅に解決しています。これらのサービス ノードは、最終的に、次の図に示すように、スター トポロジとツリー トポロジを組み合わせた CDN コンテンツ配信ネットワークを形成します。
繰り返しになりますが、コンテンツ ストレージ アーキテクチャです。
ご存知のとおり、Youku のようなオペレーティング プラットフォームでは、プログラムの数が非常に多く、各インターネット ノードのコンテンツ ストレージ コストが非常に高くなります。大容量のディスク ストレージ アレイをセントラル ノードに導入しましたが、同じディスク ストレージ アレイを他のすべてのノードに導入すると、運用コストが非常に高くなります。
この問題を解決するために、プラットフォームのコンテンツ ストレージ モードを変革し、コンテンツ ストレージ サーバーを分散方式で展開しました。ディスク アレイは中央ノードに展開され、プラットフォーム全体の完全なコンテンツ イメージが保存されます。次に、各地域ノードにディスク アレイを展開する代わりに、サーバーに 12 台の大容量ハードディスクを実装し、全国の数千台のサーバーのコンテンツ ストレージ コストを大幅に節約します。
ただし、Youku の規模のコンテンツ公開プラットフォームの場合、サーバーのローカル ディスクのストレージ容量は依然として非常に限られているため、どうすればよいでしょうか? チームによる検証を繰り返した結果、プラットフォーム上でほとんどのユーザーがアクセスするプログラムの数は約 10,000 であり、ローカル サーバーのストレージ容量は基本的にそのようなデータ量に対応できることがわかりました。そこで、コンテンツ人気ランキング統計システムの結果をもとに、人気上位10,000番組を各ノードのストリーミングメディアサーバーに配信し、人気ランキング10,000以上の番組をすべて削除します。プラットフォームのスケジューリング システムは、ユーザーをソース ステーションのノード サーバーに誘導してサービスを提供します。これは、ほとんどのユーザーのニーズを満たすだけでなく、個々のユーザーのニーズも満たします。ノード サーバーのストレージ コストは、大幅に減少し、効果的な制御が可能になります。
================================================= =======================
元のリンク:
https://blog.csdn.net/qq_1185116788/article/details/90718771