ガイド
オンライン配車ビジネス自体の複雑さと垂直ドメイン アーキテクチャの制約により、オンライン配車サーバーの技術チームは、ピア レンダリング ビジネス要件の反復プロセス中に一連の問題に遭遇し、効率に影響を及ぼしました。研究開発の。本稿では、こうした具体的な問題点から始まり、その原因を分析し、解決策のアイデアと計画、そして計画の構築と実行プロセスを紹介します。
1. サーバーアーキテクチャの進化のレビュー
ここ数年、さまざまなユーザーのパーソナライズされた旅行ニーズを満たすために、Didi は徐々により多くのカテゴリーと機能を立ち上げてきました。カテゴリと機能の継続的な増加に伴い、システムの複雑さも増しています。この課題に対処するために、配車サービスの技術チームは、社内でガルフストリーム プラットフォームとも呼ばれる「トラベル プラットフォーム」を構築しました。 。Gulfstream プラットフォームの進化は主に次の段階を経ました。
ガルフストリーム プラットフォーム 1.0 (2017-2018)
1.0段階では、Didiオンライン配車の主なビジネスの焦点は、カテゴリーを充実させ、自家用車、高級車、優待サービスなど、より多くの選択肢をユーザーに提供することです。現段階では、Gulfstream プラットフォームはまだ単一のサービスであり、主な課題は、新しいカテゴリを迅速に追加し、複数のカテゴリ間の差別化された開発をサポートする方法です。
これらの課題に対処するために、構成とプラグインを導入します。構成により、新しいカテゴリを迅速に起動して再利用できるため、開発効率が向上します。プラグインは、異なるカテゴリ間の差異ロジックを分離して、各カテゴリの独立性と柔軟性を確保できます。
ガルフストリーム プラットフォーム 2.0 (2018-2020)
2.0段階では、継続的なカテゴリの充実やパーソナライズ機能の増加に伴い、開発チームも成長を続け、システムの規模も徐々に拡大してきましたが、日々のイテレーション効率と安定性は大幅に低下しました。これらの問題を解決するために、私たちは Gulfstream プラットフォームを 2 つの方向から修正しました。
まず、ドメイン駆動設計 (DDD) の考え方に従って、単一のサービスを分割してシステム全体の複雑さを軽減すると同時に、オンラインの競合やキューイングの問題も解決します。チームメンバーの並行開発が可能になり、開発効率が向上します。
次に、ドメインサービス内で機能の集約・抽象化を行い、同様の機能を持つ業務を集約・抽象化することで、機能の重複開発を回避し、開発効率とコードの保守性をさらに向上させることができます。
Gulfstream プラットフォーム 3.0 (2020 ～現在)
3.0 段階では、API のビジネス ロジックを 2 つのレベルに分割する DuKang と呼ばれる一連のビジネス フレームワークを開発しました。1 つ目はプロセス層で、状態フローを接続し、一般的なプロセス実装を提供するために使用されます。さまざまなカテゴリが、それぞれのニーズに応じて独自のプロセスをカスタマイズして、差別化されたビジネス要件を満たすことができます。
2 つ目は機能コンポーネント層で、さまざまな垂直機能の実行を担当します。戦略パターンは、さまざまな動作を実装するためにコンポーネント内で使用されます。たとえば、プレイリスト コンポーネントは、遅延プレイリストやリアルタイム プレイリストなどのさまざまなメソッドを提供します。さまざまなカテゴリは、それぞれのニーズに応じて適切なメソッドを選択できます。同時に、コンポーネントはプラグイン メカニズムもサポートしており、カテゴリに独自のパターンを挿入できるようになります。
Dukang フレームワークを通じて、各サービス システムの実装を効果的に制限し、統一された仕様を維持し、異なるドメインのサービスが機能コンポーネントを再利用できるようにし、開発効率とコードの再利用性を向上させることができます。
Gulfstream プラットフォームの詳細な構築アイデアについては、以前の記事「滴滴出行プラットフォーム ビジネス アーキテクチャの進化」を参照してください。システム アーキテクチャの簡単な例は次のとおりです。
2. 新たな課題と課題
新しい問題の課題について議論する前に、いくつかの基本概念を統一しましょう。
ページ: アプリを開いたときに表示される乗客のホームページや、注文を受けてドライバーが到着するのを待つページなど、さまざまな UI コントロールを含む、ユーザーが端末上で見る領域全体を指します。
コンポーネント: ページ上に独立して表示される機能ブロック。通常は特定のビジネス属性を持ちます。たとえば、下図の小さなアシスタント コンポーネントは、主に現在のシナリオで重要なビジネス ヒントやマーケティング活動を表示するために使用されます。
テンプレート: コンポーネントの定義と存在に応じて、コンポーネント内のさまざまな UI 表示スタイル。
機能: フリートを保証する機能、車両を自動選択する機能など、いくつかの具体的なビジネス シナリオを示します。
データ ソース: コンポーネント レンダリング データを提供するバックエンド サービス インターフェイス。
Gulfstream プラットフォームの継続的な構築中、レンダリング要件の反復効率は改善されていません。さらに詳細な分析の結果、ドメイン サービスは機能層を通じて機能ロジックの再利用を実現できるものの、レンダリング ロジックを実行するときに、ピアの 何か問題が発生しました。異なる場所にあるコンポーネントは異なるドメインサービスを担当しており、ドメインサービスはそれぞれ独自の描画仕様を持っているため、同じ機能を異なるコンポーネントで表示したい場合は、コンポーネントの描画仕様に合わせて表示する必要があります。たとえば、一部のコンポーネントはインターフェイスを通じて直接レンダリング データを返す必要がありますが、他のコンポーネントはプラットフォーム上でのデータ構成を必要とするため、レンダリング ドッキングの機能に多大なコストがかかります。同時に、サーバー システムの内部の問題に加えて、外部の通信とコラボレーション、データ開発などの課題もいくつかあります。
以下の図は、システム内のレンダリング処理の現在の状況を示しており、具体的な問題については、以下の図と併せて議論することができます。
複数端末の問題
Didi は Android、iOS、アプレットなど複数の端末をカバーしています。異なるドメインにサービスを分割しているため、販売ドメインサービスはホームページの関連データを提供し、取引マッチングドメインサービスは待機画面の関連データを提供するなど、各ドメインサービスは関連する表示データを端末に直接提供する必要があります。ページなど ただし、これにより、すべてのドメイン サービスをすべての端末に同時に接続する必要が生じ、通信とコラボレーションのコストが増加し、反復効率に影響します。
一方で、オンライン配車製品では複数の端末での体験の一貫性が求められることが多いですが、各端末が独自に開発・実装されており、一元的に管理・制御する場所がないため、不整合が発生することが多くあります。 。たとえば、同じラベルの表示内容の長さが制限を超えた場合、iOS では切り詰めて表示されますが、Android ではマーキー表示などが使用されます。複数の端末の実装の不一致も反復効率に影響します。たとえば、製品がオンライン表示コンテンツを動的に置き換えたい場合、各端末の実装が異なるため、動的機能が不均一になり、製品は; 同じ機能を起動した後、両端の埋め込みポイントの実装が一貫していないため、収集されたデータが大きく異なり、その理由を毎回確認する必要があり、さらには異なるデータ分析戦略が必要ですさまざまな目的に合わせて策定されます。つまり、複数端末の一貫性は、製品エクスペリエンスと効率の向上に役立ちます。
レンダリングロジックの管理が難しい
端末上のコンポーネントの配置場所は限られていますが、機能は常に蓄積されているため、さまざまなビジネス シナリオに応じてコンポーネントに異なるコンテンツを表示する必要があります。統計によると、一部のホット コンポーネントには 40 ～ 50 の表示フォームと数百の表示シナリオがあり、このような複雑な状況に直面すると、トラフィックの分散と優先順位付けの管理は非常に複雑で、すべてのドメイン サービスを繰り返し実装する必要があります。論理的には、繰り返しの作業がたくさんあります。
プロセスをまたがる機能へのアクセスが困難
プロセス全体で認識する必要がある機能は数多くあります。たとえば、相乗り利用権カードは、バブリング、応答待ち、旅行の終了などのさまざまな段階で認識される必要があります。これらの段階のページは次のとおりです。異なるドメイン サービスによって処理されます。それらは異なるチームに属し、レンダリング アクセスに関して独自の独立した仕様セットを持っています。その結果、相乗り権限などの機能がプロセス間ディスプレイに接続されている場合、異なるドメイン サービスに接続する必要があります。ドメイン サービスを 1 つずつ適応させる必要があるため、アクセス コストが高くなります。
データが見にくい
各コンポーネントのフロントエンドとリアエンドは異なるチームの開発者によってカスタム実装されており、統一された仕様が欠如しています。次の図は相乗り権の例を示しています。各場所に埋め込まれたポイントがあるものの、人によって仕様は異なります。同様に、これらのデータをつなぎ合わせるのは非常に困難です。データを確認するたびに、開発と実装のためのデータ製品の要件を個別に引き上げる必要があります。サイクルは長く、コストも高いです。
上記は、レンダリングで遭遇した一連の問題です。上記の問題から、現在のアーキテクチャにおける中心的な問題は、システムのさまざまなレベル間で統一されたレンダリング標準と仕様が欠如していることであり、その結果、多くのエラーが発生することがわかります。反復的な作業と相互間のコミュニケーションの欠如は、主に次の 3 つの側面に要約できます。
フロントエンドとバックエンド: 統一されたコンポーネント認識を構築する方法、複数の端末の一貫性を確保する方法、および複数の端末のコラボレーション コストを削減する方法。
バックエンド: コンポーネント内の複雑な関数表示ロジックを管理する方法、およびプロセス全体が認識されたときに単一の関数に迅速にアクセスできるようにする方法。
データ、フロントエンド、バックエンド: 統合されたフロントエンドとバックエンドのデータ仕様を構築する方法、およびデータをすばやく明確に確認する方法
3. 解決策
これらの問題を解決するための中心的なアイデアは、標準化を実行し、さまざまなレベルの標準化を通じて統一されたクロスエンドレンダリングプラットフォームを形成することであり、具体的な解決策のアイデアは次のとおりです。
コンポーネントの標準化
コンポーネントの標準化の考え方は、機能モジュールに応じてページをさまざまなコンポーネントに分割し、それらのコンポーネントの UI 仕様とデータ対話プロトコルを統一し、その後、各エンドで統一された UI 仕様と対話プロトコルに従ってコンポーネントを開発することです。各端末のアーキテクチャを統一し、各端末のエクスペリエンスを可能な限り一貫させることができるように、プロセスと研究開発モデルを管理および制御します。Android と IOS は、複数端末の一貫性の問題を目的として、クロスターミナル技術などの方法も模索していますが、この記事では説明しません。
これらの多端末統一標準化コンポーネントにより、コンポーネントの再利用を実現し、端末とバックエンド間の通信・連携コストを削減するために、コンポーネント管理プラットフォームとレンダリングゲートウェイを構築しました。Terminal R&D は、管理プラットフォーム上のページ、構成ページにどのコンポーネントが存在するか、これらのコンポーネントがどのような形式でレイアウトされているか、コンポーネント データの取得元などを構成します。これらの構成では、端末がページ レンダリングを実行するときに、各コンポーネントのダウンストリーム サービスと対話するのではなく、レンダリング ゲートウェイと対話します。レンダリング ゲートウェイは、ページ ID に従って構成バックグラウンドで対応するページの構成を取得します。プロキシは下流のサービスを要求し、各コンポーネントのデータを取得して一元的に配信します。この形式により、端末と各バックエンド間の通信とコラボレーションのコストを効果的に削減できると同時に、この標準化されたコンポーネントをページ間で簡単に再利用して反復効率を向上させることができます。
コンポーネントの標準化は、開発に利益をもたらすだけでなく、製品ビジネスにも大きく役立ちます。以前の製品反復プロセスには一元的な処理が欠けていました。その結果、表示スタイルが以前の製品と似ていても、新しい機能を表示する必要があるたびに、以前の機能をチェックする場所がないため、引き続き UI の再設計、研究開発、再開発を検討する予定です。これは、コンポーネントの表示スタイルが急増する主な理由でもあります。標準化後、製品ビジネスは、プラットフォーム上のコンポーネントの現在の表示スタイルをすべて確認できるようになります。新しい機能では、研究開発の効率を向上させるために以前のテンプレートを再利用することを選択できます。同時に、コンポーネントとテンプレートを集中管理して、統一された表示スタイルを維持できます。経験。
コンポーネントの標準化により、全体的な要件開発モデルは次のような形式になります。
コンポーネント標準化構築プロセスは主にレンダリング ゲートウェイとコンポーネント管理プラットフォームの構築であり、以下ではこの 2 つの部分の詳細なソリューションを中心に紹介します。
レンダリングゲートウェイ
レンダリング ゲートウェイは主に、レイアウト インターフェイスとデータ インターフェイスの 2 つのインターフェイスを提供します。レイアウト インターフェイスは、ページの静的な構成やそこにあるコンポーネントなど、ページのレイアウト情報を配信する役割を担います。データ インターフェイスは、ページのレイアウト情報を取得する役割を担います。コンポーネントのレンダリングに必要なデータ。実際の実行プロセスでは、パフォーマンスとエクスペリエンスの問題を考慮して、レイアウト インターフェイスはコア コンポーネントのデータも返し、端末上でレイアウト データを取得した後にページをレンダリングできます。非同期的にロードされるコンポーネントの場合、端末はレイアウト データを受信した後、データ インターフェイスにこれらのコンポーネントのデータを取得するよう要求します。詳しいやり取りは以下の通りです。
コンポーネント管理プラットフォーム
コンポーネント管理プラットフォームは主に、コンポーネント関連のコンテンツを管理するための構成背景を提供します。主な機能は次のとおりです。
ページ管理、管理ページの識別、ページ コンポーネントの関係など、ページ管理で対応するページにどのコンポーネントが含まれるかを構成でき、コンポーネントの実験やグレースケール構成を実行でき、ページにはバージョン管理機能も提供されます。
コンポーネント管理、コンポーネントの定義、およびテンプレート UI 仕様、IDL 対話プロトコルなどを含むコンポーネント テンプレートの管理。
データ ソース管理、ダウンストリーム データ ソースの登録、パラメーター マッピング変換など。コンポーネントがページに登録されると、対応するデータ ソースが構成され、ゲートウェイが次に従ってコンポーネント データを取得するリクエストを直接プロキシできるようになります。構成。
コンポーネント パノラマ、製品ビジネス用に作成されたコンポーネント ビューです。ビジネスと製品は、現在のアプリにどのページがあるか、各ページがどのコンポーネントで構成されているか、各コンポーネントでどの表示スタイルがサポートされているかを追跡できます。また、どの機能がサポートされるかを確認することもできます。このコンポーネントの下に表示され、これらの機能のトラフィックがどのように割り当てられるかが表示されます。
管理プラットフォームは、上記のコア管理機能に加えて、Git に似たマルチブランチ並列構成の開発とテストを実現できるマルチバージョン機能、ゲートウェイ インターフェイス ドキュメントとモックなど、開発エクスペリエンスにおけるいくつかの機能も提供します。プロトコルはプラットフォーム上でホストされ、これに基づいてプラットフォームはインターフェイスドキュメントと下流コンポーネントデータの模擬機能を実現し、共同開発とデバッグの効率を向上させます。
機能アクセスの標準化
関数アクセスの標準化の主な考え方は、標準的なレンダリング処理ロジックのセットを統一し、異なる分野のサービスにアクセスして使用することです。レンダリング処理ロジックを統一するために、Dukang フレームワークをベースにレンダリング フレームワークの機能を拡張し、レンダリング プロセスをコンテキスト構築 -> 関数フィルタリング -> 関数決定 -> 関数レンダリングとして固定化しました。このうち、コンテキスト構築とはレンダリングに必要なコンテキストデータを組み立てること、機能フィルタリングとは現在のシーンに表示されていない機能を領域、時間、カテゴリなどのルールに従って除外すること、機能の意思決定とは優先順位付けを行うことである。残りの関数を選択し、最終的な表示関数を選択します。関数のレンダリングは、選択した関数でデータを埋めることです。レンダリング フレームワークに加えて、Kaicheng、ホワイトリスト、マテリアル管理などのいくつかの標準的な再利用可能な機能も蓄積しました。これらの機能の構成のために、集中管理のための機能管理プラットフォームを構築しました。
以下では、レンダリングフレームワークと機能管理プラットフォームの詳細な構築計画を紹介します。
レンダリングフレーム
レンダリング フレームワークの主なアイデアは、一連の統一された関数実行プロセスを通じて関数を標準化および制約することです。このフレームワークは、コンテキスト構築 -> 関数フィルタリング -> 関数決定 -> 関数レンダリングに従って関数の実行プロセスを制限します。フレームワークは実行プロセスを制約するだけで、特定のロジックは依然として関連関数の閉ループ実装です。例えば、機能フィルタリングであれば、単純なフィルタリングであれば、ビジネス側は標準のオープニング関数をそのまま利用できますが、抽象化できない複雑な戦略がある場合は、ビジネス側が独自のパッケージにコーディングすることができます。これにより、機能の標準化された定義を維持できるだけでなく、ビジネスの柔軟性も維持できます。
機能管理プラットフォーム
機能管理プラットフォームは主に機能管理機能を提供します。プラットフォームの主な機能は次のとおりです。
機能表示戦略設定都市、カテゴリ、シーンなどの蓄積された表示ルールと組み合わせて、さまざまな機能に対応した表示戦略を設定します
機能の優先順位の構成、コンポーネントの下の機能間の優先順位を構成します。優先順位は、異なる都市などの複数のグループをサポートします。優先順位は異なる場合があります。
機能的なコピーライティングマテリアルの構成、対応する機能の表示に必要なコピーライティングと関連マテリアルを構成します。この部分は、さまざまな機能の構成方法に大きな違いがあるため、内部の一般的な構成プラットフォームを組み合わせて、一般的な構成プラットフォームで、まず実際の要件に従って、機能のコピーライティングとマテリアルの構成テンプレートを開発し、機能管理プラットフォームを一般的な構成プラットフォームに接続し、対応する構成ページを統合して統合構成プラットフォームを形成します。
主に製品業務用途向けに提供されている機能フルリンクビュー 従来は仕様や降水量が統一されていないため、どこで機能が発現し、各箇所の効果がどのように変化するかを一元的に把握することが困難でした. . 標準化後は、機能のフルリンク ビューを提供し、各機能がどのコンポーネントで公開されているか、対応するトラフィック分布は何か、変換ファネルは何かなどを簡単に確認できるようになります。
データの標準化
コンポーネントや関数のアクセスを標準化した後は、データの標準化は当然のことであり、先に定義したページ、コンポーネント、テンプレート、関数などの固有識別子を各段階のログに記録し、データを公開するだけで済みます。統合されたデータレポート、収集、クリーニング、集計の仕様に従って、一連の標準的なデータソリューションを形成でき、その後の機能開発プロセスでは、追加のデータ開発は必要ありません。必要なコンポーネントまたは機能は、コンポーネントまたは機能のデータに従って確認できます。
埋め込みプロトコルの統合
埋め込みポイント プロトコルの統合の核心は、さまざまなサービスの埋め込みポイント情報の集約を可能にすることです。全員が一連の固定プロトコルを採用し、集約するフィールドについて合意し、データ収集とクリーニングの手順を経て集約する限り、データの一元化が実現できます。フロントエンドレポート、ゲートウェイ送信ログ、データソースサービスログなどの一連のプロトコルを策定し、ページ、コンポーネント、テンプレート、機能の識別を統一しました。SDKを利用したプラットフォームの一元的な管理・制御、埋め込みポイントの設定の一元化、各サービスによる埋め込みポイントの一元的なレポート作成など、全体的な考え方は以下の通りです。
データリンクがオープンされました
端末からバックエンド サービスへのデータ リンクを開き、標準プロトコルを通じてデータを統合データ ウェアハウスに集約し、統合データ ダッシュボードを形成します。主なデータリンク図は次のとおりです。
要約する
まとめると、コンポーネント、機能アクセス、データの標準化を通じ、クロスエンド統合レンダリングプラットフォーム全体の構築が完了しましたが、現在も引き続き構築と推進の途上にあります。は完成しましたが、機能管理基盤とデータ連携はまだ構築中です。現在、統合レンダリング プラットフォームは 20 ページ以上にアクセスでき、将来的にはすべてのレンダリング シナリオを引き続きカバーする予定です。
プラットフォームの全体的なシステム アーキテクチャ図は次のとおりです。
終わり
著者と所属の紹介
この記事の著者であるウー ジュン氏は、滴滴のオンライン配車トラベル テクノロジー チームの出身で、オンライン配車ビジネスの研究開発チームとして、トラベル テクノロジーはエンド ユーザー エクスペリエンス プラットフォーム、C エンド ユーザーの製品エコロジーを構築してきました。 、Bエンド輸送力供給エコロジー、旅行安全エコロジー、サービスガバナンスエコロジー、コア保証システム、安全、信頼性、効率的、便利、そしてユーザーの信頼性を備えた旅行プラットフォームを作成します。
求人情報
チームのバックエンドとテスト要件を募集しています。興味のあるパートナーはぜひご参加ください。下の QR コードをスキャンして履歴書を直接送信できます。ご参加をお待ちしています。
研究開発エンジニア
仕事内容：
1. ビジネスアーキテクチャの設計、開発、複雑さの制御、システムパフォーマンスと研究開発効率の改善など、関連ビジネスシステムの背景研究と開発を担当します。
2. ビジネス感覚を持ち、継続的な技術研究と革新を通じて、製品と運用とともにビジネスのコアデータを反復的に改善します。
テスト開発エンジニア
仕事内容：
1. オンライン配車事業に適用される品質保証システムを構築し、関連する高品質な技術ソリューションの策定と導入を推進し、事業品質を継続的に確保する。
2. ビジネスを深く理解し、ビジネス内のさまざまな役割とのコミュニケーションを確立し、ビジネス上の問題と問題点を要約し、総合的な方法でビジネスの価値を創造し、固定された境界線なく作業します。
3. 関連する品質インフラストラクチャを適用することで、ビジネス コードの品質と配信効率を向上させます。
4. 効率的なテスト ソリューションを考案し、他のビジネス分野へのアプリケーションの導入をサポートする汎用ソリューションを提供します。
5. ビジネス品質保証における困難な問題および複雑な技術的問題を解決する。
6. 高品質の技術分野における将来を見据えた探求。
