著者 | 楽東

導入

この記事では、検索・表示サービスの開発プロセスと、現在直面している 3 つの大きな課題 (研究開発の難易度の高さ、アーキテクチャ機能の不足、再利用性の低さ) を簡単に紹介し、最後にソリューションの中核となるアイデアと具体的なソリューションを提案します。皆様にもぜひご活用いただき、参考にしていただければ幸いです。

全文は 4736 ワードで、推定読了時間は 12 分です。

01 背景

Baidu 検索表示サービスの主な役割は、検索システムに結果の取得を要求し、テンプレートの選択、リアルタイムの概要の補足、データの適応、結果のレンダリングを順次実行して、検索結果をリッチかつ正確にユーザーに表示できるようにすることです。多様な形態。当初、このサービスは C 言語をベースに開発されており、反復効率が満足のいくものではありませんでした。製品の急速なイテレーションと継続的な事業の拡大に伴い、研究開発効率の問題が徐々に顕在化しており、このボトルネックを解決するために、検索および表示サービスは PHP によって開発され、HHVM によって実行されるサービスに進化しました。現在、検索表示サービスは数十の製品ラインと数百の研究開発RDによって共同開発されており、数百の洗練されたビジネス表示戦略を実行しています。しかし、検索ビジネスの複雑化と大規模な生成モデルの台頭により、検索表示サービスも研究開発の難しさの増大、アーキテクチャ能力の不足、再利用性の低さなどの複数の課題に直面し始めています。具体的な性能は以下の通りです。

[研究開発の難易度が高い]: 検索表示サービスは、複雑なロジックを備えたプロセス管理に基づいており、コードのさまざまな段階で複数のポリシーフレームワークが分散されています。管理の簡素化と使いやすさに対する複数のビジネスのニーズを満たすことができません。拡張された効率性の要件

[アーキテクチャ機能の欠如]: hhvm インフラストラクチャのメンテナンスは停止されており、非同期/マルチスレッドやその他の機能のサポートは比較的限定されています。ストリーミングの欠如機能のせいで生成要件を満たすことができなくなり、検索やその他のニーズがサービスの安定性や新製品需要の繰り返しの要件を満たすことができなくなります。

[再利用性が低い]: 検索プレゼンテーション層の主なサービスは、一般検索、垂直検索などです。現在、一般検索と垂直検索の間には合理的なアーキテクチャ設計が欠如しており、その結果、一般検索と垂直検索の両方で同じ要件が繰り返し開発されることになります。

02 ソリューション

2.1 全体設計

2.1.1 核となるアイデア

研究開発の難しさを軽減する: プレゼンテーション層の特性に従って、グラフ管理エンジンが設計および実装され、プレゼンテーション機能がオペレーターの粒度に分割されます。単一のオペレーターはシンプルかつ明確です。ビジネス側は、アプリケーション全体ではなく、機能 (オペレーター) と要件に重点を置いて作業を行います。同時に、検索および表示サービスのプロセスを DAG グラフ処理にアップグレードして、プロセス管理の複雑さを軽減します。。演算子→グラフ→要件の階層管理を実現することで、検索・表示サービスのプロセス研究開発モデルをプロセス指向から機能指向、ビジネス指向に推進する。

アーキテクチャ機能の向上: PHP+HHVM から GO に変換し、Baidu の内部 GO 開発フレームワークに基づいて検索および表示サービスを構築し、より優れたパフォーマンスとより高い同時処理能力を獲得します。同時に、非同期/コルーチン/ストリーミングインタラクション機能をサポートするコストが低くなります。

再利用性の向上: 抽象パブリック演算子と実装ベース Lib を共同構築することで、コードの再利用性と保守性が向上します。パブリックオペレーターは複数の検索および表示サービスで再利用できるため、繰り返しの開発とメンテナンスのコストを回避できます。 Basic Lib は、開発者がコードを迅速に開発および保守できるようにするための共通関数とツールクラスを提供し、開発とエラーが繰り返される可能性を軽減します。

△検索プレゼンテーション層のアーキテクチャ図

2.1.2 インフラストラクチャ

GDP (Go Develop Platform): Go をベースとした Baidu の社内ビジネス開発プラットフォーム。完全な RPC サーバーおよび RPC クライアント機能を備え、主に API、Web、バックエンドサービスの開発に使用されます。

ExGraph: Baidu 検索表示チームが独自に開発したグラフ実行エンジン。

グラフィック: シンプルなグラフ記述言語を設計しました。ツールを使用せずに、rd はモジュール実行ロジックの全体像を簡単に学習して理解できるため、引き継ぎの難しさを軽減できます。< /a i=0> a>

オペレーター: シンプルなインターフェイスを設計し、実装の詳細を保護します。オペレーターインターフェイスを実装した後に rd を実行できます

実行: 直列グループ、並列グループ、サブグラフ、条件演算子、スイッチ演算子、中断、待機、および複雑なビジネスプロセスに適応するその他のメカニズムの柔軟な設計

効率化ツール: コードジェネレーターやスキャフォールディングなどの効率化ツールを実装して、アプリケーションを迅速に作成します

データホールド: Baidu 検索表示チームが自社開発したデータマネージャー。主にモジュールデータ (構成、辞書など) の依存関係と読み込みの問題を解決します。次の能力を持っています:

ホットロードをサポートし、変更されたファイルをバックグラウンドで監視および解析し、使用するためにフォアグラウンドに切り替えます。ユニバーサル辞書、構成パーサーを提供し、カスタムファイルパーサーをサポートします。
構成を通じてデータオブジェクトの自動登録、ロード、解析をサポートし、大規模なサービスの構成/辞書を効果的に管理し、解析エラーなどに対するタイムリーなアラームを保証します。
研究開発段階での環境展開の効率を向上させるために、リモートデータに依存する rd オフライン環境モジュールのワンクリック展開をサポートします。

パブリックライブラリ: さらに、インフラストラクチャ層は、チームのパブリックライブラリを示すための udai (統合リモートデータアクセス cgo 拡張機能)、Baidu 独自の署名なども提供します。パブリックライブラリの構築には統一されたアクセス標準があり、車輪の再発明を回避し、研究開発の効率を向上させます。

2.1.3 公共事業者

検索表示の一般的なロジックをインターフェイスに抽象化し、グラフエンジンに基づいたパブリック演算子を提供し、一か所での開発を実現し、一般検索や垂直検索などの複数のアプリケーションを併用します。現在、サンプリング、適応、ダウングレード、電流制限、取得リクエスト、ランディングページのクリック、レンダリングなどの数十のパブリックオペレーターが実装されており、すぐに使用でき、新しい検索および表示アプリケーションの構築を迅速にサポートします。。

2.1.4 アプリケーション層

パブリックオペレーターと各サービス独自の表示オペレーターを通じて実行グラフを構築し、アプリケーションビジネスロジックを実装します。現在の検索表示サービスには、一般検索表示サービス、垂直検索表示サービス、生成検索表示サービスなどが含まれます。

2.2 詳細設計

ユニバーサル検索は垂直検索などのサービスに比べて複雑ですが、この章ではユニバーサル検索表示サービスを例に、Go の再構築と移行のための実装計画を詳しく紹介します。

_△ユニバーサル検索表示サービス再構築前後の比較表

再構築と移行のプロセス中に、私たちは主に 2 つの困難に直面します。

難易度 1: 前述したように、ユニバーサル検索表示サービスは、数十の製品ラインの 100 以上の RD によって共同開発されたモジュールです。表示戦略グループ 1、2、3 には、合計 600 以上のビジネスプレゼンテーション戦略、毎日平均 4 回以上の戦略イテレーションが開始されるリファクタリングと移行のプロセスで、最初に解決すべき問題は、移行を既存のビジネスイテレーションの効率と両立させるにはどうすればよいかということです。多くの事業分野の移行をどのように調整するか?

難易度 2: 検索および表示サービスのビジネスロジックは非常に複雑です。再構築プロジェクトでは、ユーザー効果、ビジネス収益、サービスの安定性をどのように確保しますか。

困難 1 は、主にアーキテクチャ上のビジネス分離とスムーズな移行メカニズムの 2 つの方法によって解決され、困難 2 は、研究開発、テスト、発売のプロセス全体の安定性を確保します。これら 2 つの部分については、次に詳しく紹介します。

2.2.1 ビジネスの分離とスムーズな移行

移行と既存のビジネス反復の効率を確保し、複数の製品ラインと連携してビジネスプレゼンテーション戦略の移行を実行します。コアの意味: アーキテクチャとビジネスプレゼンテーションロジックの分離。アーキテクチャ移行部分は最初に Go に移行されます。ビジネスプレゼンテーション戦略はそのままです。アーキテクチャロジックの移行中、ビジネスの繰り返しをブロックしないようにし、php と go の両方のバージョンで同じビジネスロジックを同時に開発しないようにしてください。ビジネス表示戦略から Go ベースの検索表示サービスへのビジネス分野別の独立した移行をサポートするメカニズムを設計し、複雑な移行プロセス全体を 4 つの段階に分割して順序よく進め、最終的にプロジェクト全体の目標を達成します。

第 1 段階: アーキテクチャ部分のグラフィカルな移行 + サービスとしてのプレゼンテーション戦略

電流制限、パラメータ処理、取得リクエスト、広告取得リクエスト、httpヘッダーレンダリングなどのアーキテクチャロジックコードをGDP+Exgraphベースのgoに移行し、goベースの総合検索表示サービスが取得データの統一処理を完了した後、次に、PHP ベースのプレゼンテーション戦略サービスにビジネスプレゼンテーションロジックの実行を要求します。これにより、比較的反復頻度の低いアーキテクチャロジックを最初に Go に移行し、その後のプレゼンテーション戦略の移行の基礎を築くことができ、また、頻繁に反復するプレゼンテーション戦略も元の R&D モデルに従って反復し続けることができます。

フェーズ 2: 非同期ダイジェストリクエストの完全な移行

まず、非同期要約とは何かについて答えてください。

コンピューティングリソースと応答速度を考慮するため、検索システムは各サブシステム内にキャッシュを設定することがよくありますが、キャッシュの失敗時間は少なくとも数分、場合によっては数日に達します。動画の再生回数、記事の「いいね！」の数、検索結果の結果がユーザーに気に入ったかどうかなど、数秒で更新する必要がある一部の表示要素の場合、キャッシュはあまり使いやすくありません。そこで、非同期集計が生まれました検索リクエストが返された後、その検索結果をもとに高効率な集計サービスを依頼します集計リクエストは通常の表示戦略と非同期かつ並行して完了し、リアルタイム集計を実現するだけでなく補足するだけでなく、ユーザーの応答速度の低下も回避します。

Go がプレゼンテーション戦略で段階的に移行するのを避けるために、非同期の要約リクエスト時間を並列時間で短縮でき、バイパスシステムが導入されています。数十の非同期要約戦略があり、反復の頻度は通常の表示戦略よりも少ないです。リクエストは全体をまとめて移行することです。非同期要約リクエストはバイパスシステムに正常に書き込まれ、すべての通常の表示戦略が実行されます (実行用に移行されるか、php に保持されると、PHP ベースのポリシーサービスはバイパスシステムを通じてすべての非同期概要を取得し、リアルタイムの概要補足を実行します。バイパスシステムの導入自体にも通信オーバーヘッドが必要ですが、次の方法で削減できます。

サイドカーベースのバイパスサービスによりリモート通信のオーバーヘッドを削減
Go 表示サービスは非同期概要を解析しませんが、元のシリアル化結果をバイパスシステムに書き込み、解析用の PHP サービスに基づいてデータを取得します。 go/php でのデータの繰り返しの逆シリアル化によって生じるオーバーヘッドを効果的に回避できます。

フェーズ 3: 戦略の移行を実証する

各生産ラインと連携して、表示戦略グループ 1、表示戦略グループ 2、および表示戦略グループ 3 の Go ベースの検索および表示サービスへの移行を完了します。この段階では、ポリシーの粒度や中小企業のトラフィックに応じた製品ラインの移行がサポートされ、同時に、Go の検索表示サービスに基づいて新しい表示戦略 (非同期概要戦略を除く) を直接開発できます。

移行基準: 表示戦略に依存関係があるかどうかに従って移行します。共通シナリオへの依存: ポリシーの実行は、最初に実行される他の非ビジネス表示戦略に依存します。このシナリオは、最初に依存戦略によって移行する必要があります。戦略は内部的にアーキテクチャ機能に依存しますが、機能のこの部分は Go に移行されません。、など。

移行の優先順位:

(1) 依存関係のない表示戦略の移行を優先し、開発、実験、プロモーションを個別に移行できる

(2) 依存関係のある表示戦略の場合は、依存関係のあるパーティと協力して移行を完了します。

第 4 段階: 完全な移行

全体として、非同期の概要戦略の移行、レンダリング、タスク後の移行を完了します。

ロジックのこの部分は比較的頻繁に反復されません。事前に移行してみてはいかがでしょうか?

主な制限要因は応答速度です。 php ベースのプレゼンテーションストラテジーサービスが、タスクのレンダリングおよび後処理のために go ベースのプレゼンテーションサービスに送り返される場合、php->go によってシリアル化、逆シリアル化、および通信時間が追加され、速度低下の原因となります。 Go への移行後の速度の最適化によってパフォーマンスの低下を相殺することはできません。

2.2.2 プロセス全体の安定性の保証

ユニバーサル検索表示サービス再構築プロジェクトのユーザー効果、事業収益、サービスの安定性は、主にプロセス全体の安定性によって保証されます。プロセス全体の安定性には、主に研究開発、テスト、オンライン安定性保証が含まれます。

研究開発保証

移行プロセスは単なる機能移行ではなく、ユニバーサル検索・表示サービスは何十年にもわたって繰り返されており、データの冗長性、過大な履歴フライングロジック、低コード再利用など、多くの無理な設計が含まれています。、データ管理の実行、飛行ラインの負担のクリーンアップ、公共事業者の再抽象化と設計などを行います。これらにより、研究開発の品質に対する要求が高まっていますが、一方では単体テストや自動化されたパイプラインテスト (データ差分と UI-DIFF、テスト保証の導入) を通じてコードの品質が確保されていますが、他方では歴史的な負担が増大しています。ログ管理分析により事前にオフライン化を行い、不必要な移行を回避します。

テスト保証

機能テスト：

データ差分: QA と連携して自動化されたデータ差分機能を構築し、再生のためのオンラインリクエストを記録し、取得リクエスト、広告リクエスト、レンダリングへのデータ出力などの重要なデータを転送します。完全に自動化された日常的なデータの差分を実行し、データの差分を通じて潜在的な問題を発見し、合計で数万件のデータの差分を検出して削除します。

UI-Diff: 検索結果ページには、天気アラジン、株式アラジンなど、さまざまなタイプの結果があります。リソースタイプは数千あり、それぞれのリソースtype には独自の表示テンプレートがあります。効果回帰のコストは高く、困難です。リソース表示の量を優先し、ui-diff プラットフォーム (HTML ページのピクセルレベルの差分) を使用して、ベースラインおよび戦略ラインの自動化 ui-diff のオンラインクエリを自動的にマイニングし、差分に焦点を当てます。エフェクトの問題、合計 40 以上のエフェクトの問題がこの方法で発見され、修正されました。

エンドツーエンドテスト: データ差分と UI 差分の 2 つの自動テスト方法は、ほとんどの影響シナリオをすでにカバーできます。さらに、QA は主要なシナリオを検索します。たとえば、ランディングページのジャンプ、ページめくり、広告効果などの手動効果テストが戻ってきました。自動テスト+手動効果テストにより、再構築および変換後の表示効果を確認します。

安定性テスト: オンライントラフィックを迂回して長期ストレステストを実施し、オンライン動作環境をシミュレートし、サービスのオンライン安定性を確認します。

パフォーマンステスト: パフォーマンスフレームグラフを使用してシステムパフォーマンスのホットスポットを検出し、ポイントを最適化します。一般的なオンラインインスタンスのピーク QPS と極圧テストでパフォーマンステストを実行して、サービス制限 QPS を取得し、オンラインリソースの容量が十分であるかどうかを事前に推定します。応答データの劣化です。

オンライン保証

起動段階での安定性を確保する主な手段には、起動前のリソース/応答時間の推定、安定性のレビュー、監視と警報、ダウングレード、内部テスト、ネットワーク全体の小規模なトラフィックなどが含まれます。

03 まとめ

本稿では、検索表示サービスの開発プロセスと、現在直面している主な課題（研究開発の難易度の高さ、アーキテクチャ能力の不足、再利用性の低さ）を紹介し、グラフ実行エンジン＋公共事業者＋再構築・移行による手法を提案する。上記の問題を解決し、最後に、ユニバーサル検索表示サービスに基づいて、計画の実装について詳しく説明します。この記事は、検索表示サービスの再構築について皆さんの考えをお伝えすることを目的としていますので、ぜひ参考にしていただき、何かを得ていただければ幸いです、もちろん至らない点もあるかと思いますが、一緒に議論していきたいというメッセージを残していただければ幸いです。