データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

1. プロジェクトの背景

アーキテクチャのアップグレードが必要な理由

プロミスエージングは、カーネルエージング計算システム（システムの核となるのはエージング計算）とコンポーネントエージングシステム（システムの中核となるのは複雑な業務処理と複数のエージングビジネスの集約であり、ゴールデンプロセスフローを担う）の2つのサブシステムで構成されます。後者は前者に依存しており、それぞれ 2 つの技術チームのグループによってサポートされています。一部のビジネスの浸透により、2 つのシステム間の境界はますます不明確になってきています。一部の要件では、2 つの技術チームのグループの全面参加が必要です。研究開発チームはPRDのレビューからプロジェクトの立ち上げまで、多くの人的資源を消費します。
プロミス期限切れ計算のビジネスロジックは、長年の蓄積を経てますます複雑になり、期限切れ計算システムには多くのビジネスロジックが含まれているため、需要に応じてコンピューティングカーネルを頻繁に更新する必要があります。
適時性の計算は、予約と非予約、注文の前後、決済ページの適時性、ビジネス詳細ページの適時性に分けられます。共通点もありますが、相違点もあります。その結果、コア計算の一部を共有しながら大量の冗長な繰り返しコードが発生し、時間に敏感な計算のために 2 つのキャッシュされたデータを同時に保守および保存する必要があります。
さまざまなサービスがカーネルシステムから専用のインターフェイスを提供し、システムに深刻な破損を引き起こします。
RPC メソッドを使用しない依存関係がいくつかあるため、jar パッケージの依存関係とタイミング計算スイッチをコンポーネント化されたタイミングシステムで構成する必要があり、開発と共同デバッグの効率に影響を与えます。

要約すると、このテクノロジー主導の再構築には、システム内の既存の問題を解決するためにアーキテクチャのアップグレードが必要であると判断されました。

リファクタリングの目標

ビジネスの境界がより明確になる

再構築後の需要境界は製品側から決定でき、新しい倉庫物流適時性計算ルールを変更する必要がある場合、または新しいコア計算を追加する必要がある場合は、基本コンポーネントの適時性で他のビジネスの要件を変更することができます。

ビジネスロジックがさらに集約される

ビジネスロジックをコンポーネント化に統合します。

カーネルコンピューティングロジックはより純粋です

時間に敏感な計算キャッシュのセットにより、ハードウェアリソースコストの半分が節約されます。

システムの再利用性を高める 1つの計算モードで予約モードと非予約モードの両方をサポートし、注文前後の決済と交渉をサポートコアとなる計算ロジックコードのセットを特定の業務から切り離して維持し、コストを節約する詳細人事;

2. スキーム設計

カーネルコンピューティングビジネスのレビュー

既存のビジネスインターフェイス:

標準アップカレンダー: 注文管理、生産能力、バルクバンを考慮した標準アップカレンダー
ジンズンカレンダー：注文管理と生産能力を考慮し、ジンズンカレンダーの大量販売は禁止されています
自動運転車カレンダー：自動運転車カレンダー倉庫受け取り・無人運転車カレンダー
倉庫セルフピックアップカレンダー：倉庫セルフピックアップカレンダー、幹線を経由しない倉庫セルフピックアップ/自動運転車カレンダー
セルフピックアップカレンダー：セルフピックアップポイントの第4レベルの住所を取得し、カレンダーに合わせて注文管理、生産能力、バルク禁止基準を検討します。
VXPカレンダー：生産能力に関係なく、注文管理、休日、大量禁止を考慮し、固定最大日数とオプション日数の標準カレンダー
7フレッシュカレンダー：標準カレンダーの計算が完了した後、ストアウェーブに従ってカレンダーウェーブが標準カレンダーに置き換えられます。
グローバルショッピング税カレンダー: グローバルショッピング税準備バッファーを追加し、標準カレンダーを計算します。
B2B カレンダー: B2B カレンダーの計算
宝島カレンダー: 宝島カレンダーの計算

ビジネスの特性に応じて、独自の 8 種類のビジネス適時性計算インターフェイスを 3 つのコアの汎用コンピューティングインターフェイスに集約し、5 種類のビジネスの特殊な処理インターフェイスを排除します。新しいコアコンピューティングインターフェイスを再定義して設計します。Jingzenda の適時性、標準の適時性、および倉庫の集荷の適時性です。これにより、多くの重複コードが削減され、1 つの要件を変更するために多数の同じ場所を変更することが回避され、統合管理が容易になります。

新基幹システムの3つのコアインターフェース方式により、複数の業務システムにサービスを提供可能

システム再構築に関わる業務は下図のとおりです。

主な変更点:

コアインターフェイスの集約、コンポーネントシステムの適応、事前情報の補足処理。
再構築前は、部品化された老朽化システムと基盤システムに受注制御インタフェースと生産能力ロジックの呼び出しが分散していましたが、再構築後は生産能力が新たなインタフェースとなり、受注制御インタフェースと生産能力ロジックが分離されます。コアシステムとコンポーネント化された古いシステムに集中化されます。
バルク商品、二次倉庫、世界的な購入通関、VXP 休日などのビジネスロジックがコンポーネント化されたシステムに移行され、メッセージサイズとシステム間のインターフェイスの複雑さが軽減されます。

システム再構築事業

3. プロジェクトの実施

コンポーネントベースの事業仕分け

生産能力を考慮する
制御命令を検討する
幹線回線の利用を検討する
バルクかどうかを判断する
グローバルショッピングの通関時間とバッファを追加
新しい容量ホワイトリストを追加
容量ホワイトリストのマーキングを追加しました
セルフピックアップ波形フォーマット変換を追加
新しい二次倉庫パラメータ情報の統合を追加しました
ドキュメントタイプへのコアとなる新しいインターフェイス
省エネ補助金のデフォルトバッファーを増加
フレッシュ7店舗のウェーブコンバージョン
グローバル買いロングポジションシールドロジックを追加

コンポーネントの経年変化に新しいインターフェースを適応させ、ボリュームスイッチで制御します

4. 安定性の保証

システム再構築の安全性と正確性を確保するにはどうすればよいでしょうか? オンラインにする前に再構築の前後で整合性を検証するには、主に 2 つの方法があります: シングルテストカバレッジとトラフィック再生検証です。オンラインになった後は、多次元カッティングスイッチを介して制御して、システムの安定性。

オンラインにする前に

単一のテストシナリオの範囲

1,700 を超えるテストケースで、ほとんどの単一ビジネスシナリオと一部の複合ビジネスシナリオをカバーします。

トラフィック再生の検証

オンライントラフィックをリアルタイムで迂回することで、再構築されたシステムに再生できます。トラフィックの再生中に相違点が発見され、特定の原因が分析され、複数のリファクタリングテストケースではカバーされない複雑なシナリオの問題が発見されました。

例：グローバルショッピング商品が都市流通を満たしており、通常の期限に変換され一括期限を採用するシナリオ：通常のロジックは、①グローバル購入商品が都市流通ロジックを満たす、②グローバル購入が都市流通期限やニーズをサポートしていない通常の制限時間に移行する; ③ 通常の制限時間に切り替えた後再び大きなビジネスシナリオにぶつかります。リファクタリングの際は、①から③へ進みました。都市分布の適時性とバルクの適時性は相互に排他的であるため、バルクの適時性に変換できません。変換ロジックを調整すると、リファクタリング前の適時性と矛盾します。このシナリオには多くの作業が含まれます。ビジネス構成は非常に困難ですが、テストケースをカバーすることで、トラフィックの再生検証は優れた検証ソリューションとなります。

トラフィック再生のカスタム比較の違い

システムアーキテクチャの調整と、新しいインターフェイスの設計と古いアーキテクチャの違いにより、調達、グローバル購買、注文管理などのビジネスシナリオで返される開始カレンダーの日付は一貫していません。実際に利用可能なカレンダーとウェーブは一貫しているため、データ内の差異により、トラフィック再生時の差異率が高くなり、ページ上で設定された無視されるフィールドはニーズを満たすことができません。

初めて、差分比較にカスタムスクリプトが使用され、並べ替えと無視項目の設定がカスタマイズされ、適時性に影響を与えない差分オブジェクトを無視し、差分の干渉を軽減します。

事業計画の確認

テストに不合格となったものやトラフィック再生の差異については、研究開発テストで別のリストが作成され、研究開発チーム、テストチーム、製品チームが連絡を取り合い、システムのステータスとビジネスへの影響範囲を確認し、最終的な解決策を決定します。

テスト中に発見された問題が検証および修復され、ビジネス要件とオンライン標準が満たされていることを確認した後、グレースケールバージョンを起動できます。

オンライン化後

グレースケールがリリースされると、トラフィックのごく一部のみがアクセスされ、オンラインログと監視アラームがタイムリーに追跡および分析され、ユーザーのフィードバックに従って問題がタイムリーに解決されます。新しいシステムが安定したら、オンラインログの追跡とアラームの監視を継続しながら、グレースケールのリリースとアクセストラフィックの範囲を徐々に増やします。

ホワイトリストの検証

オンラインになった後にホワイトリストユーザーを使用して検証します。

フロースイッチング制御

システムがオンラインになった後は、スムーズな移行を実現するために、測定およびグレースケール検証のためのユーザー PIN の割合がサポートされます。

コンポーネントスイッチ

新旧のロジックコンポーネントをワンクリックで切り替えられ、問題が見つかった場合はすぐに元のロジックに切り替えて損失を迅速に阻止し、オンラインシステムのセキュリティを確保します。

5. プロジェクトの価値

システムの最適化

プロジェクトの期待どおり、純粋に時間に敏感な新しいカーネルコンピューティングインターフェイスが実装されており、カーネルシステムの再利用性が向上しています。
コンポーネント化されたシステム内の一部のロジックを再編成し、フローティングビジネスロジックを追加します。システムロジックがより集約され、可読性が向上し、システムメンテナンスコストが削減されます。
オンラインリスクを軽減し、ビジネス境界を再形成した後、対話型システムロジックがより集中化され、相互依存する構成が減少し、リスクの制御が容易になります。
リファクタリング、テストケースの修復、および転用の検証中に、システムの安定性を確保および向上させるために複数のオンラインバグが発見および修正されました。

テストケースでは 5 つのバグが見つかり、エッジビジネスロジックの欠落や処理ロジックエラーなどの問題が修正されました。

トラフィック再生で7件のバグが見つかり、530マークや北京ずんだ熟成型などのオンラインバグが修正されました。

40 以上のテストケースを修正しました。

当面の問題

システム再構築は、技術的な課題だけでなく、どの解決策がより合理的であるかを考える必要があるだけでなく、整理の難しいビジネスロジックに直面し、製品、研究開発、システムを一新しなければならないなど、常に印象深いものです。過去を回想したり、歴史の「バグ」を見つけたりして、「修正」すべきか迷ったり、非常に時間がかかります。

1. トラフィックの再生段階では、出力パラメータデータの充填方法が変更されたため、比較が不可能になりますが、これはスクリプトをカスタマイズすることで解決できます。

2. セルフピックアップ時間制限のある複数倉庫シナリオの新しいアーキテクチャはサポートできません。製品やビジネスと連携して、独自の複数倉庫シナリオの処理方法を最適化することで、問題を解決するだけでなく、オンライン処理ロジックも最適化します。

プロジェクト概要

リファクタリングはプロジェクトの堅牢性と効率化に役立ちます。日常生活では、「小さなステップで速く歩く」というリファクタリングの良い習慣を身につけ、画一的なリファクタリングの考え方を保持しないように努める必要があります。多くの技術的負債を蓄積すると、多くのエネルギーと時間がかかり、リスクもはるかに大きくなります。リファクタリング作業が困難な場合は、事前に反復計画を立てる必要があり、リファクタリング計画の設計の初めに、どのように段階的に実装するかを検討する必要があります。建設現場で足場を組むのと同様のリスクコントロールであり、許容範囲内で有効な手段。「明日の価値」にもっと注目してください。良いデータ構造、良いアイデア、さらには変数名やメソッド名を見つけたら、以前に書いたコードを書き直します。

リファクタリングを行うタイミングは「 3 つのルール」に従うのが最適です。何かを 1 回か 2 回実行する必要がある場合は、リファクタリングについて心配する必要はありませんが、3 回以上繰り返す必要がある場合は、リファクタリングを検討する必要があります。システムをクリーンに保つための健康状態。

同社のビジネスは急速に発展しており、システム再構築中は、ビジネスニーズの反復速度を維持し続け、適切に人員を増強する必要があります。

システム再構築前に業務（エッジ業務含む）に精通している必要があり、再構築中は再構築されたコードを見るのと同じ状況に遭遇する可能性がありますが、実際のコードの実行順序は業務の依存関係や優先度に影響し、複雑なビジネスプロセスでは問題を発見するのが困難です。

オンラインになったら、実際のパフォーマンスの変化、リソース消費、システムの安定性を追跡します。再構築の際に、システム内に同様の業務処理ロジックが存在することが判明し、都市物流関連のロジックが複雑すぎることが判明し、次のステップとして商品ビジネスとのコミュニケーションを効率化できるかどうか、再構築して終わりではありませんが、むしろ出発点のようなものです。

著者: JD Logistics Cui Haijun

出典：JD Cloud Developer Community Ziyuanqishuo Tech 転載の際は出典を明記してください

約束の適時性アーキテクチャアップグレード計画の実装と実行 | JD Logistics 技術チーム