1. 注文システムの概要
1.1 事業内容
サービス事業内容：速達、速達、中小型品、大型品、コールドチェーン、国際、B2B契約物流、CLPS、京西、スリーイン・スリーアウト（仕入、返品、割当、売り切り、供給撤回、割り当て切れ））待つ
1.2 注文中心値
1. デカップリング (システムの安定性の向上)
元のシステム:トランザクションと生産が結合されており、新しいビジネス要件には複数の上流および下流システムが関係します。ECLP、海外からの注文、運送状、ターミナルシステムなど 複数のビジネス ラインのロジックが結合されており、単一のビジネス ラインの要件が変更されると、元のシステム内の他のビジネス ラインもそれに関連して変換されます。
新しいシステム:トランザクションと生産業務の分離: トランザクション関連の需要は注文ドメイン内で解決され、生産側の需要は生産ドメイン内で解決され、上流と下流の相互作用が減少します。
ビジネスラインの結合: 異なるビジネスラインには異なるビジネスプロセスがあります。単一のビジネスラインの要件の変更は、特定のプロセスで反復的に更新されるだけであり、他のビジネスラインには影響しません。プロセス全体とビジネスの安定性を向上させます。
2. 新サービスのアクセス速度の向上
オーダー センターは、再利用可能な標準機能をフロント デスクに提供し、新しいビジネスの導入速度を向上させます。
オーダー センターは、元のシステムの大規模なアプリケーションを複数の小さなアプリケーションの組み合わせに分割および抽象化し、さまざまなシナリオでのビジネス プロセスのオンデマンド オーケストレーションをサポートします。中央プラットフォームの公開標準機能を再利用することで、新しい企業は注文センターに迅速にアクセスし、同じ機能の重複を避けることができます。
3. グローバルに統一されたデータモデルを提供する
独自システム：受注が外部発注、ECLP、大規模システムなど複数のシステムに属し、データベースが複数存在し、ビジネスセマンティクスが統一されていないため、データ構築が不便である。
新しいシステム:注文センターは注文の標準データ モデルを統一的に定義し、異なる企業からのデータを同じシステムに保存できるようにし、注文ドメインに関連する機能の重複を減らし、リソースの無駄を回避し、部門の壁を取り除きます。これにより、データとプロセスを一元管理して最適化し、グループのビジネス分析とJD.com の将来のイノベーション スペースの予測のための標準データを注文ドメインに提供できます。
2. アーキテクチャの紹介
2.1 全体的なアーキテクチャ設計
テクノロジーミドルエンドアーキテクチャアップグレードプロジェクトを通じて、取引システムはアクセス-トランザクション-パフォーマンス-実行の新しい4層アーキテクチャで再構築されます。トランザクション注文は、物流と顧客の間の物流サービス契約の文書フローを終了する責任があり、また、下流の OFC (注文履行層) に配布する責任もあります。
2.2 リアルタイムデータ層アーキテクチャの設計
2.2.1 システム相互作用図
システムの相互作用は次のとおりです。
オーダーセンターの標準インターフェースは上位層にドキュメントクローズがあり、データ層でも統一的なクローズを実現しました。
ビジネス アーキテクチャをデータから切り離し、分散データベース、キャッシュ、一貫性などの高可用性および高性能設計をビジネス アーキテクチャの範囲から分離することで、ビジネス アーキテクチャがビジネス自体に集中できるようにします。
永続化システム: 注文の受信、注文の変更、注文のキャンセル、注文の削除などのデータの永続化をサポートするために使用されます。
検索システム：注文内容照会、注文一覧照会、注文状況フロー照会、百川注文かどうかの判定などのサービスを提供します。
リレー システム: データ ハブ。消費メッセージ キューを通じて注文データを Elasticsearch、HBase、MySQL に書き込みます。
データ調整システム: 複数のストレージ ミドルウェア セットのデータの一貫性を比較して、データの最終的な一貫性を保証するために使用されます。
データ同期システム: 注文一覧照会に必要な照会条件や一覧表示項目を旧システムから注文センターに同期し、注文データが新旧システムに存在するためページングが困難になる問題を解決します。切断工程。
2.2.2 技術アーキテクチャ図
2.3 設計上の利点
2.3.1 高可用性
2.3.2 高性能
2.3.3 大規模なデータ処理
2.3.4 データのセキュリティ
機密情報は暗号化されて保存されます。ログ、Redis、ES、MySQL、HBase などはすべて暗号化されたストレージを使用します。「保存する人は暗号化し、使用する人は復号化します。」
3. 注文データモデル
3.1 PDMモデル
注文モデルの設計では、統一されたビジネス属性、抽象的な一般モデル、および共通エンティティの誘導の原則に基づいて、注文モデルは主に注文のメインファイル情報、注文の製品情報、物流サービス情報に分けられます。注文の内容、注文のマーケティング情報、注文モデル、財務情報、注文顧客チャネル情報、注文の受領および配達情報、注文の操作情報、注文の拡張情報など。
3.2 モデルのスケーラビリティ
3.2.1 標準モデルの拡張設計
注文には数十、数百もの識別フィールドがあり、毎回新しいフィールドを使用すると、注文のビジネス属性やデータモデルが大幅に拡張され、モデルが腐ってしまうと同時に、開発効率が低くなってしまうため、 KV形式は、それを引き受けて保存するために使用されます。識別を注文識別、製品識別、マーケティング識別などのさまざまなビジネス領域に分割します。
3.2.2 パーソナライズされたビジネスモデルの拡張性
パーソナライズされたビジネス向けに、構成可能なデータベース フィールド管理ソリューションのセットが提供されており、注文が送信、変更、クエリされるときに、いくつかのすぐに使用できる設定を通じて、ビジネス アイデンティティ + ビジネス タイプ + に基づいてさまざまなデータ モデルを見つけることができます。ビジネス フィールド、およびデータ拡張エンコーディング、つまり、どのテーブルとフィールドを格納するかを見つけることです。各テーブルには N 個の拡張属性が予約されており、同じ拡張属性でも、異なるビジネス ID とビジネス タイプは、拡張ストレージを実現するための異なる意味を表します。
4. 今後の展望と課題
4.1 注文のパーソナライズされた問い合わせ
ファジー クエリ、クエリ条件に基づくリアルタイム集計など、パーソナライズされたクエリの需要が増加しています。ES インデックスが同じクラスターに配置されている場合、クラスター全体の安定性に影響しますが、分割後はビジネス データは影響を受けません。他のビジネスと一緒に照会および表示できます。
4.2 ユニット化されたアーキテクチャ
現在のオーダー永続性 TP99 は 47ms、計算機室をまたがない場合の TP99 は 20ms であり、データの観点から計算機室をまたぐことはパフォーマンスに大きな影響を与えます。
ユニット化により、同じユーザーからの関連リクエストを 1 つのコンピューター ルーム内のすべてのサービスの「閉ループ」で完了できるようになり、「コンピューター ルーム間」のアクセスが排除されます。ユニット化された配備方式により、各コンピュータ室を任意のエリアに配備でき、いつでも新しいコンピュータ室を拡張できます。今後もユニット化により受注プラットフォームの基盤強化を図ってまいります。
4.3 ハードウェアのコスト管理
1日の平均注文量は増加を続けており、データ量はますます大容量化し、それに伴うハードウェアコストの増加が続いており、ハードウェアコストの増加をいかに抑制するかが現在および将来の課題となっています。当社では、データ アーカイブ、ホット データとコールド データの階層化、その他の方法を通じてデータ ストレージ コストを削減する予定です。
200元の罰金と100万元以上を没収 You Yuxi: 高品質の中国語文書の重要性 MuskのJDK 21用ハードコア移行サーバー Solon、仮想スレッドは信じられないほど素晴らしい！！！ TCP 輻輳制御によりインターネットが節約される OpenHarmony 用の Flutter が登場 Linux カーネルの LTS 期間が 6 年から 2 年に復元される Go 1.22 で for ループ変数エラーが修正される Svelte は「新しいホイール」を作成 - ルーン文字 Google が創立 25 周年を祝う著者: JD Logistics の Wang Weidong
出典：JD Cloud Developer Community Ziyuanqishuo Tech 転載の際は出典を明記してください