Autohome 電子商取引システム アーキテクチャの進化とプラットフォーム アーキテクチャの実践

# 目次★

#まえがき02アーキテクチャの進化##03 4.1 新しい小売店の探索

01
	2.1 開始段階 2.2 マイクロサービス段階 2.3 マスターデータ段階 2.4 プラットフォーム アーキテクチャ段階
プラットフォーム アーキテクチャの実践	3.1 ビジネスの識別 ## 3.2 サービス オーケストレーション 3.3 ビジネス構成 3.4 開発ツール化 3.5 データ視覚化 3.6 知識の蓄積 04
#終了	4.2 アーキテクチャのアップグレード ## 序文 オートホーム e コマース システムは 2014 年に誕生し、2016 年から 2019 年にかけて成長しました。長年にわたってダブル 11 と 818 パーティーのピークテストを経験してきました。安定した信頼性の高い優れたオンライン取引機能を蓄積してきました。ビジネスミドルプラットフォーム構築の波の高まりに伴い、2019年にミドルプラットフォーム構築段階に入り、自動車電子商取引分野で5年間蓄積した能力を輸出し、自動車電子商取引業界の発展を支援する。 、企業のデジタルトランスフォーメーションを加速します！ アーキテクチャの進化 このパートでは、主に Autohome 電子商取引システムのアーキテクチャ開発プロセス、ビジネスの状況、技術的な課題、各段階での技術的なシステム対応戦略について説明します。 . . 初期段階 インターネット環境では、2011 年から 2011 年までに何千もの連隊戦と電子商取引が行われました。 2013 戦後‍[1] 電子商取引ビジネスは、広告モデルに加えて、インターネット トラフィックを収益化するもう 1 つの戦略的高台となりました。 2013 年の「ダブル イレブン」期間中、オートホームは自動車購入サービスを開始し、トランザクション リンクを重要な開発方向とみなしました[2]。ビジネスの初期段階では、技術的な要件は、製品の実現可能性を検証するために、迅速に繰り返してオンラインに移行することです。日々のビジネス ニーズに応えながらも、技術的なアーキテクチャについての思考は止まりません。将来の電子商取引システムの拡張性を考慮し、業界におけるアリババの技術体系を参考にして、2014年に技術スタックの開発を開始し、段階的に.NETシステムからJavaシステムに移行し、すべてのアプリケーションの切り替えが完了しました。 2015 年 5 月 30 日に、完全なオンライン自動車ショッピング プラットフォーム Car Mall を開始しました。 マイクロサービス段階 電子商取引ビジネスの急速な発展に伴い、技術スタッフの数が増加し、2016 年までに技術チームは数百人になりました。 。モノリシック アーキテクチャの苦痛が真っ向から襲いかかります。フロントエンド モールの Git プロジェクトに関しては、要件が満たされると、ほぼ 30 の Maven サブプロジェクトが並行して開発されます。コードのマージが競合し、要件がオンラインになるのを待ち、時間がかかります。オンライン開発が多くなり、SQLなどの問題により、システム全体の開発効率やシステムの安定性が低下してしまいます。 #現在、システム サポートは大きな課題に直面しており、システム アーキテクチャをアップグレードして進化させる必要があります。私たちは、元の単一システムを、高い凝集性と低い結合性を備えた複数の集中型システムに分割する、分散型戦略の開発を開始しました。すなわち、現在のユーザーセンター、商品センター、注文センター、プロモーションセンター、クーポンセンター、マーチャントセンターのそれぞれが独立したシステムを設計し、独立して受け取り、独立してリリースできるようになり、全体の研究開発効率とシステムの安定性が向上しました。ステップ。現段階で、 自動車電子商取引をサポートする1​​00万レベルの商品システム[3]、注文システム[4]、クーポンシステム[5]の構築が技術的に完了し、すべてのアプリケーションが完成しました。クラウド上 [6]、自動テスト プラットフォーム構築 [7]。 同時に、自動運転車の電子商取引モデル、オープンプラットフォームモデル、B2B2Cモデル、見積モデル、コンサルティングモデル、TPCCモデル、並行輸入車販売など、さまざまなビジネスモデルを模索してきました。 マスター データ ステージ e コマースの開発スピードは非常に速く、2019 年までに、同社はすでに旅行、旅行などのさまざまなオンライン トランザクション モデルを確立しています。自動車商品・アフターサービス・ポイント還元等開発戦略に基づいて、同社は電子商取引ミドルプラットフォームを構築することを決定し、一方では、会社の高品質な製品リソースと運営リソースを集中して、影響力のある垂直型電子商取引取引プラットフォームを構築することを目的としています。一方で、技術リソースを合理的に管理および制御し、電子商取引システムを実現することも目的としています。このような背景から、私のチームは電子商取引のミドルプラットフォームの構築に取り組みましたが、各システムのビジネス形態や技術アーキテクチャが大きく異なるため、どのようにトランザクションを実現するかが最初の課題でした。この目的を達成するために、私たちは一方では、さまざまなビジネスシナリオにおける取引システムの現状を理解し始めており、他方では、技術的な解決策についても考え、議論しています。最終的に私たちは、「データの正規化をベースに、標準化されたミドルエンドサービスを提供し、システムごとに下から上まで統合する」というソリューションを選択しました。 データ正規化 データは企業の中核資産であり、どのシステムでも、特にトレーディング システムにおいては、データが最も重要です。重要、重い。マスターデータの構築は、データモデルを統一してシステムの壁を打ち破ることができる一方で、一元化されたデータによる業務データの分析を行い、ビジネス上の意思決定の基礎を提供することもできるため、マスターデータの構築は重要であると考えています。システム統合の第一歩としてマスターデータを作成します。取引プロセスにおいて最も重要なデータは、加盟店、商品、注文、販促活動の4つの領域に集中しており、企業の取引シナリオの現状を踏まえ、この4つの領域のマスターデータを抽象化してモデル化します。可能な限り統一された方法で、ほとんどの取引シナリオに適しています。以下は、注文マスター データのコア データ モデル構造の概略図です。 #統合データ モデルが完成したら、次のステップは既存の異種データ モデルをインポートすることです。データをマスター データ モデルにインポートします。データベースでは、データ処理のためにデータベースのバイナリ ログ (mysql、sqlserver) を読み取る方法を使用して、初期データ同期インポートを完了します。これは、データへの侵入を最小限に抑えた最小かつ最速の実装ソリューションでもあります。ビジネス。 API標準化 マスターデータの構築が完了したら、次のステップでマスターデータを元にAPI標準化の構築を開始します。高品質の API は高品質のシステムを相互に接続でき、統合された API はシステムをある程度までクロージャすることができます。この目的のために、私たちは単一責任の原則に従い、ドメインごとに区別し、境界を明確にし、すべての基盤となる API 関数を細分化し、上流ユーザーが API を柔軟に組み立ててビジネス ロジックを完成できるようにするとともに、パラメーター構造を統一します。 APIとその応答結果の構造、エラーコードの統一、APIゲートウェイによる公開・呼び出しの統一、APIデータの統計監視・劣化・電流制限などにより、一元的な管理・制御を実現します。 API の読み取りと書き込みの切り替え 標準化された API では、ビジネス パーティが API の価値を反映するためにそれを使用するのが自然です。ビジネスの重要性と規模に基づいて、段階的に読み書きソリューションを採用し、ビジネスを 1 つずつ呼び出して切り替えました。この一見合理的な手順は、実際の実行プロセス中に多くの問題も明らかにしました。 1) 強い読み取り/書き込み依存関係の場合 シナリオ例: ユーザーが注文した後、すぐに注文の詳細にジャンプして注文を表示します。このとき、書き込み API の切り替えが完了していない場合、読み取り読み取り API によるデータの同期の遅れにより失敗します。現時点では、指示に従う方法はありません。最初に読み取り、次に書き込みを行い、段階的に切り替えます。最良の方法は、読み取りと書き込みを段階的に切り替えることです。同時。 2) 業務切り替えへの影響が最も少ない方法は、元のインターフェースのパラメータや戻り結果と互換性があるのは当然ですが、当社の標準APIに従って業務側に切り替えを強制すると、切り替えコストや無用な弊害が避けられません。ビジネス側へ。このとき、当然、相手の立場に立って何らかのトレードオフをしなければなりません。当社が採用する方法は、新旧プロトコルの変換のための標準 API の上にアダプテーション層を追加することで、ビジネス側はドメイン名とリクエスト URL を切り替えるだけでよく、他のロジックは変更されず、最大の効果を発揮します。ビジネス面にも優しい。 3) 私たちが提供する基盤となる API はすべてアトミックであるため、実際のシナリオ、特にフロントエンドとバックエンドが分離されているプロジェクトでは、フロントエンドは同じ結果を得るためにインターフェイスを複数回呼び出すことを望まない。バックエンドにファサード層を追加し、基盤となるアトミックAPIをベースに、ビジネスシナリオに応じたAPIを外部に提供し、差別化されたインターフェースロジックと適度な互換性を持たせています。 4) 読み書きの切り替えは一朝一夕に実現できるものではなく、その過程でデータ本体のAPIと独自の業務APIが混在する場面が必然的に発生しますが、APIの入口は全て弊社が提供するため、ルーティング機構も採用しております。ルーティング層 さまざまな場所が転送され、すべての API は呼び出し元に対して透過的です。 5) 実際のAPI切り替え処理は特殊なシナリオがあり、最終的にはシステムを統合する必要があるため、後から統合する機能のAPI切り替えを強制するのは実はリソースの無駄なので、こちらも前倒ししています。事前判断を行った後は、切り替えを適度に回避し、機能の統合を待ってから全体の機能を切り替えることができます。 システム機能の統合 APIの読み書き切り替えが完了すると、マスターデータに基づく機能の集約がほぼ完了しますので、この時点でシステム的に統合する必要があります。統合されたマーチャント管理バックエンド、統合された操作バックエンド、統合された C エンドのトランザクション エクスペリエンスなどの共通機能。システム レベルでの統合統合の目的は、ユーザーに統合された操作インターフェイスを提供し、プラットフォームの専門性を反映することです。システム統合の過程では、「共通性の析出と相違点のトレードオフ」の原則を採用し、製品リリースや注文リストなどの共通機能については、共通機能を抽象化し、統一的にユニット化して提供します。操作インターフェースは、さまざまなビジネスパーティの使用要件を満たします。ビジネスサイド独自の機能についてはビジネスサイドでの実装を推奨し、まだ汎用化できていないが将来汎用化する可能性のある機能については、小規模バージョンをオンラインで実装する最速の方法を用います。 MVP原則に従い、ビジネスの反復に伴い、機能の析出が継続的に実現されます。システム統合のプロセス全体では、元のシステムの機能を統合しながら新たな要件が必然的に発生するため、新旧システムを同時に開発することになり、コストが増加すると考えられます。システムは有益である一方で、ビジネスの発展に影響を与えず、技術統合によるビジネスの停滞を引き起こさない一方で、新システムの潜在的な問題点は、旧システムとシステムを比較することで発見できます。これは、新しい統合システムの機能を検証する最良の方法でもあります。システム統合作業のほとんどが完了した後、コアとなる電子商取引トランザクション リンクは運用可能となり、加盟店の参入、製品リリース、製品表示、発注、支払い、契約履行、アフターセールスに至るまでオンラインで長期検証を受けています。最終的な決着に至るまで、その過程で遭遇した問題も一つ一つ解決していきます。この段階で、社内の3大取引システムの統合が完了し、電子商取引プラットフォームのフラッシュセールシステム[8]の構造改修とクーポンの構造改修を実施しました。 818 の 2020 ～ 2021 年のフラッシュセールや、パーティー、ダブル 11、ダブル 12 などの大規模イベントのクーポン発行シナリオをサポートします。さらに、 ドメイン駆動モデル DDD の理論と業界の実践も積極的に調査し、請求書汎用データベース システム [9] の再構築に実装しました。これは、後続のプラットフォームにも情報を提供します。アーキテクチャのアップグレード、テクニカル サポート。 プラットフォーム アーキテクチャ段階 e コマース ビジネス センターをビジネスに「アプローチ」するプロセスでは、建設の難易度も指数関数的に増加し、一連の新たな問題が発生しています。 1) 建設ミドルプラットフォームプロジェクトの終了と人員の撤退に伴い、非常に多くのビジネスラインのロジックを統合した後、 ECビジネスのミドルプラットフォームは条件判定が多く、デマンド反復ごとの開発コストとテスト回帰コストが非常に高い 異なるビジネス間のロジックを分離し、ビジネス間の結合を減らすにはどうすればよいでしょうか? 2) 構築の重複を避けるために、電子商取引プラットフォームに接続されている複数の事業ラインの共通機能をどのように抽象化するか? 3) 新しいビジネスが e コマース ビジネス センターに接続された場合、迅速なビジネスの反復と革新をサポートするために、既存の機能とソリューションに基づいて迅速にビジネスを組み立て、立ち上げるにはどうすればよいでしょうか? 4) 製品運用における日常業務の効率を向上させるために、技術的手段をどのように使用できますか?まとめると、ECビジネスミドルプラットフォームの構築においては、事業ラインの共通機能の抽象化と、共通機能の再利用可能な設計と実装が特に重要であり、ビジネスミドルプラットフォームは、機能の再利用と柔軟性を実現する必要がある。建設は企業の開発プロセスにおいてコストを削減し、効率を高める役割を果たします。システム アーキテクチャをアップグレードする必要があり、これがプラットフォーム アーキテクチャの段階につながります。 プラットフォーム アーキテクチャの実践 プラットフォーム アーキテクチャとは何ですか?基本機能を各ビジネスパーティの特徴的なサービスから分離し、サービス間のロジックを分離する必要があります。プラットフォーム化の中核は、ビジネス抽象化モデリングとシステム アーキテクチャのオープン性であり、ビジネス抽象化により一般的な問題の 80% が解決され、システム アーキテクチャのオープン性により個別問題の 20% が解決されます。 ThoughtWorks[10] が提供する「モダン エンタープライズ アーキテクチャ ホワイト ペーパー」ソリューションと、業界のインターネット企業 Meituan[11] および Youzan[12] のミドルエンド ソリューションを参照した後では、Zhijia 電子商取引プラットフォームに適したソリューションを提供しました。ドメイン駆動モデリングを通じて、電子商取引ビジネスの複数の事業分野の共通機能を抽象化し、拡張ポイントを確保し、サービス オーケストレーションを使用して共通機能を結合します。 。原理は図のとおりです: 電子商取引ビジネスで実行される各ビジネスは、ビジネス ID、ビジネス プロセス、ルールとして理解できます。ビジネス プロセスはプロセス サービス オーケストレーションによって実現され、拡張ポイントはプロセス サービス オーケストレーションによって実現されます。拡張ポイント機構。取引プロセス全体において、B 側での加盟店の参入と製品リリースは比較的一般的です。さまざまなビジネスの主なプロセスの違いは、注文収集前と支払い後の注文履行に反映されます。これらのプロセスは、多くの場合、カスタマイズされた開発を必要とします。このため、ソリューション全体の核心はオーダー プラットフォーム アーキテクチャ設計にあります。 図に示すように、注文プラットフォームのアーキテクチャ全体は下から上に 4 つの層に分割されています。 インフラストラクチャ層: ストレージ、メッセージング、RPC などのミドルウェアを提供します。 基本サービス層: ドメインごとに編成された基本サービス。ドメイン サービスは、さまざまなビジネスの違いに対応する拡張ポイントを提供します。 ビジネス機能レイヤー: さまざまなドメイン サービスを接続して、注文、支払いなど、外部で使用できるビジネス機能を形成します。 ビジネス プロセス層: ビジネス機能を整理し、注文トランザクション プロセスを形成し、注文トランザクション プロセスを完了します。 ビジネス層: ビジネス ID、拡張ポイントの実装、ビジネス プロセス構成を開発して、さまざまなビジネスの違いを実現します。 注文プラットフォーム アーキテクチャのアップグレード実践プロセス全体は、次の点に要約されます。 ビジネス アイデンティティ ビジネス アイデンティティの概念は次のとおりです。最も初期のアリババは、ビジネス プラットフォームがさまざまなビジネスに同時にサービスを提供する場合、差別化されたパーソナライズされたサービスを提供するには、各ビジネス サービス リクエストのビジネス アイデンティティ要素を区別できる必要があると提案しました。企業の各事業のアイデンティティと特徴を確立し、モデル化して差別化し、その成果がビジネスアイデンティティとなります。ビジネス ID は一意であり、ID 番号に似ており、ビジネス全体で一意である必要があります。ビジネス アイデンティティを使用すると、ビジネス センターはビジネス プロセスとビジネス ルールを抽象化し、ビジネス アイデンティティに基づいてサービス ルーティングとビジネス モニタリングを実装できます。第 2 に、ビジネス ID は、SAAS システムのテナントの概念に似ています。さまざまなビジネス パーティがビジネス ID を使用して、ミドル オフィスのデータ権限を分離します。これにより、各ビジネスの運営は、自分のビジネス部分のデータのみを参照できるようになります。 たとえば、自動車電子商取引の分野では、人、物、分野の 3 つの側面を通じてビジネス アイデンティティを抽象化します。人間の次元には、メンバーシップを持っているかどうか、認定自動車所有者であるかどうか、どのような付加価値サービスが有効になっているかなどが含まれ、商品の次元には、製品タイプ (完成車、物理的な商品、仮想商品など)、配送方法 (代金引換、交換、4S 店舗配送) など。フィールドの次元には、オンライン注文、オフライン注文、注文が行われたオンライン モール、注文が行われた配送ストア、注文元が含まれます。製品の配送チャネルなどこれらの側面に基づいて一意のビジネス アイデンティティが決定されると、各トランザクションのビジネス プロセスが決定されます。 サービス オーケストレーション e コマース ビジネス センターは、全体としてマイクロサービス アーキテクチャを採用し、e コマース システム全体を分割します。マーチャントセンター、ユーザーセンター、製品センター、プロモーションセンター、トランザクションセンター、フルフィルメントセンター、アフターセールスセンターに。各センターは論理的に、ビジネス属性を持つ機能とビジネス属性のない基本機能の 2 つの層に分割されます。基本機能層は、ビジネス ニーズの調整によって変更されないドメイン モデルのエンティティ属性、動作、イベントに焦点を当て、業界の一般的な動作に焦点を当て、ビジネス モデルを統合し、基本サービスの安定性を確保します。ビジネス属性を備えた機能は、サービスの組み合わせやプロセス オーケストレーションなどの技術的手段を介した基本機能レイヤーに基づいて、ビジネス指向のソリューションを形成し、一般的なビジネスからパーソナライズされたビジネスへの変革を完了します。一般的なアプローチは 2 つあります。1 つはハード コーディングを使用することです。さまざまなビジネスラインのロジックが増加し続けるにつれて、各ビジネス機能が呼び出す基本機能は複雑かつ複雑になり、それらを構成して柔軟に実装することが困難になります。要件が変更されると、テスターが変更の影響範囲を評価することが難しく、回帰テストのコストサイクルが長くなり、真のアジャイル開発や迅速なビジネス対応を実現することが困難になります。 2 つ目は、サービス オーケストレーションを使用することです。既存のマイクロサービスのサービスオーケストレーションによりサービス構成を行い、フロントに必要な情報を一括して返します。さまざまなビジネスラインの機能によってさまざまなプロセスが実行され、グラフィカル、XML、および JSON オーケストレーション フレームワークを通じて、プロセスを明確にし、コードの詳細を保護できます。サービス分割のメリットについて詳しく説明する必要はありませんが、ビジネス価値を実現するには、単一のサービスの機能ではなく、すべてのサービスを調整して企業のエンドツーエンド ビジネスの成功を確実にすることが重要です。プロセス。ビジネス ミドル プラットフォームは、エンタープライズ ビジネスのための統合プラットフォームです。統合テクノロジは、プロセスを構成するアプリケーションとリソースを疎結合する必要があります。そうでない場合、プロセスのロジックは特定のテクノロジ プラットフォームにハードコーディングされ、変更が行われる可能性があります。コストがかかるため、ビジネス プロセスの再利用という目標全体に違反します。 サービス オーケストレーション フレームワーク サービス オーケストレーションの分野では、すでに多くの産業用ソリューションが存在します。ここでは、ワークフロー システム オーケストレーションに基づく API ゲートウェイに基づくサービス オーケストレーション [13] を参照します。マイクロサービス アーキテクチャ オーケストレーション フレームワークに基づくフレームワーク Flowable および Activiti[14]、Netflix Conductor[16]、および Zeebe[17]。 技術原則を分析した結果、それらにはすべて特定の欠陥があり、電子商取引ビジネス センターのサービス オーケストレーションには適用できないことがわかりました。最終的には、Apache Camel [18] を選択しました。サービスとして オーケストレーションの基礎となるエンジンは、二次カプセル化用に開発されています。 Apache Camel は 2007 年に誕生し、2009 年頃にトップレベルの Apache プロジェクトとなり、Apache Camel に改名され、最新バージョンは 3.0 です。 Apache Camel の利点は、リリース以来 10 年以上で 300 以上の拡張コンポーネントがあることです。拡張メカニズムも非常に便利で柔軟です。アプリケーション統合の問題は、すぐに利用できるベスト プラクティスによって解決されます。これはイベント駆動型アーキテクチャに基づいており、優れたパフォーマンスとスループットを備えています [19]。 以下は、単純なサービス プロセス オーケストレーションの例です: ビジネス ミドル オフィスは、サービス オーケストレーション テクノロジを使用しています。一方で、コンポーネントの視覚的なプレゼンテーションとしてトランザクション機能を自動的に識別して、機能マップを形成できます。これらの基本機能をベースにサービスプロセスを実装できるオーケストレーションは、ビジネスに適したトランザクションプロセスの全部または一部をドラッグ＆ドロップで素早く構築できるオーケストレーションは、ブロックを構築するのと同様に、基本コンポーネントを再利用し、それらを柔軟に組み合わせることで、再利用を実現しますe コマースのエンタープライズ レベルの機能を強化し、開発コストを節約し、ビジネス目標を迅速に実現します。 拡張ポイント フレームワーク 拡張ポイントの正式名は、サービス プロバイダー インターフェイス (略して SPI) です。これは、サードパーティ拡張機能のインターフェイス実装クラスをロードして実行するために Java によって提供される一連のメカニズムであり、通常、コンポーネントの置き換えやフレームワークの拡張のシナリオで使用されます。 SPI は、サービス インターフェイスとサービス実装を分離して、分離を実現し、アプリケーションのスケーラビリティを向上させます。プログラミングでは、特定の実装クラスの参照を持たないモジュール間でインターフェイス指向プログラミングが使用され、実装クラスを動的にロードすることでアプリケーション プラグインが実現されます。 COLA フレームワークは、Alibaba の技術専門家によって提案されたアプリケーション アーキテクチャの拡張ポイント フレームワークです [20]。 COLA フレームワークの拡張機能は、アノテーションを通じて実装されます。拡張機能のアノテーションは、ユース ケース (useCase)、ビジネス (bizId)、およびシナリオ (scenario) の 3 つの属性を使用して ID を識別します。 COLA フレームワークの拡張ポイントを使用すると、コード レベルでさまざまなビジネス ID の論理的分離をサポートできます。これは、さまざまなロジックがさまざまな実装クラスに分散されており、ソフトウェア設計の開始と終了の原則に準拠しているためです。アプリケーション Spring コンテキストが初期化されると、COLA フレームワークは拡張ポイント登録のための拡張アノテーションを持つ Bean のスキャンを開始します。これは Map 構造に格納されます。キーは useCase、bizId、および scenario を連結した文字列で、値は豆。実行時に、ビジネス ID を通じて拡張ポイント実装クラスが特定され、拡張ポイントによって実装されたロジックが実行されます。拡張ポイント実装を見つけるとき、3 層ルーティングをサポートします。まず、拡張ポイントは useCase bizId シナリオに従って検索されます。見つからない場合は、useCase bizId シナリオのデフォルト値に従って検索されます。が見つからない場合は、useCase bizId のデフォルト値シナリオのデフォルト値に従って検索されます。具体的な原則は図に示すとおりです。 #単純なビジネス シナリオの場合、アプリケーション システムの高い拡張性とビジネス分離のための非機能要件はそれほど多くありません。しかし、同じアプリケーション システムがより多くのビジネスをサポートし、ビジネス シナリオがより複雑になるにつれて、変化するビジネス ルールを強固にするためにアーキテクチャ レベルで統合された拡張ソリューションを提供する必要があります。これは、技術仕様の統一に役立つだけでなく、ハード コーディングの削減にも役立ちます。 . IF-ELSE、戦略パターンなどは、開発者レベルのばらつきにより、理解の複雑さや仕様の一貫性をもたらします。拡張ポイント メカニズムを通じて、ビジネス センターは、SAAS 管理テナントなどのビジネス ID およびフレームワーク レベルからさまざまなサービスを管理できます。さまざまなビジネス ID は、さまざまなシナリオで事前定義された拡張ポイントを拡張できます。アリババのビジネス ミドル オフィスも拡張ポイントの考え方に基づいており、コア ビジネス ロジックと技術的詳細の分離と切り離しを実現し、共有のビジネス ユニットがグループ内の数百のビジネス ラインをサポートできるようにします。 サービス オーケストレーション拡張ポイントの適用例 機能検証後、電子商取引システムのシナリオを分類し、まずユーザーの認知度が低く、たとえユーザーへの影響が少ないものから始めました。発生した問題が選択され、ノードは再構築試行を受けます。未払いの注文がタイムアウトになり、ユーザーが注文をキャンセルした場合、ノードは閉じられます。ユーザーが注文をキャンセルするシナリオを例に挙げると、変更前は、各業務のユーザーによる注文キャンセルのロジックは、注文ステータスをキャンセルステータスに変更してから同じ処理を実行するというもので、処理の実行順序が難しい 修正後の疑似コードは、各業務の特性に合わせて丁寧に整理されています。自動車事業ではクーポンを使用しないため、このリンクは必要ありません; ポイントの一般的な目的で、機能の面で万里通ポイントが拡張されます。疑似コードは図に示すとおりです。 旅行者ビジネス ラインのホテルおよび航空券ビジネスには、商品在庫という従来の概念がないため、商品の在庫を返す必要がありますが、サプライヤーの注文のキャンセルという新しい一般的な機能が抽象化されており、ホテルのサプライヤーの注文をキャンセルするためと航空券のサプライヤーの注文をキャンセルするための 2 つの拡張ポイントが事前に設定されています。疑似コードを次の図に示します。 システム全体のアプリケーション効果は明ら​​かで、主にパフォーマンスの向上と人間の効率の向上に反映されています。パフォーマンスの向上は主にシステムの応答時間の短縮に反映されており、修正後のオーダーキャンセルインターフェースの本番環境のTP99改善率は約30％となっている。人的効率の向上は主に、注文のキャンセルと新しいプロセス ノードの追加のテストにかかる時間の比較に反映されます。変更前は、各ビジネス プロセス間のコードは結合されています。新しいノードを追加するプロセスの変更には、コードの回帰テストが必要です。変更後は各事業の回帰テストを実施する必要がありません。 ビジネス構成 プラットフォームアーキテクチャの実践では、ビジネスフローに影響を与えるコア構成を一律に抽出し、ビジネスアイデンティティに応じた属性値を設定します。トランザクション プロセス リンク全体の統一された標準により、コア トランザクション リンク コードへの頻繁な変更が削減され、異なる属性値に基づいて、異なるビジネスが同じトランザクション プロセス内の異なるノード間で柔軟に切り替えることができるようになります。例: 製品が自動的にリソース プールにプッシュされるかどうか、注文に ID カードが必要かどうか、支払いが成功した場合に手がかりがプッシュされるかどうか、受け取りが N 日以上確認されていないかどうか、すべての設定項目は、設定管理のバックグラウンドを通じて統合されます。さらに、ビジネス ID を含む電子商取引プラットフォーム内のすべてのメタデータについても、構成管理バックエンドを通じて一元管理し、外部クエリ サービスを提供するための統合 API を提供しました。 開発ツール化 ビジネスとテクノロジーの多面的な側面から出発して、一般的なビジネス上の問題や、さまざまな分野で発生する技術的な問題に対して、さまざまな実用的で便利なツールを開発してきました。メッセージ配信および取得ツール、製品割引価格の迅速な計算ツール、製品表示価格の比較および監視ツール、キャッシュ管理ツール、ワンクリック ダウングレード ツールなどの小さなツールにより、作業効率が向上し、問題を迅速に特定できます。ツールに対する意識が高まるにつれ、このような小さなツールが続々と登場し、研究開発担当者にとって欠かせないツールボックスとなっています。 データの視覚化 電子商取引システムのパフォーマンス指標、リソース使用率指標、通話量、その他のシステム次元の指標は、会社のクラウド プラットフォームを通じて均一に監視できます。ビジネス データについても同様で、ビジネス関係者が適切な意思決定を行うための参考となる、統合されたビジネス データ視覚化ツールを提供する必要があります。そこで、当社では、事業内容、受注状況、地域などの多面的な観点から受注量の変化をリアルタイムかつオフラインで把握できる大画面受注可視化システムを開発しました。 。一定期間内の注文量の変動が事前に設定したしきい値を超えた場合、DingTalk メッセージが送信され、取引関係者に速やかに注意を通知します。 また、オフラインデータについては、日、週、月ごとに多次元で統計分析を行い、最終的にはフォームでお届けします。ビジネス側では、これらの方法の目的は、電子商取引データの視覚的な管理を実現し、電子商取引ビジネスの包括的な管理と制御を行うためのより便利なツールをビジネス ユーザーに提供することです。 知識の沈殿 私が所属しているチームは e コマース分野に属しています社内 長年にわたり技術と製品運用の経験を積んできたプロフェッショナルチームです。 ECミドルプラットフォームの構築過程においても、これらの経験や日々の課題の解決策を蓄積し続け、従来はWikiなどのドキュメント管理ツールを活用してまとめてきました。このナレッジから価値を生み出すために、独自の電子商取引ナレッジベース システムの構築にも着手しており、ナレッジの蓄積として使用できるすべてのコンテンツを分野ごとにナレッジ ベース システムに入力します。迅速な検索と位置決め機能は、技術担当者や製品操作担当者に役立ち、全員の知識蓄積の意識をさらに高め、全員の作業効率を向上させることができます。 ＃＃＃＃＃＃＃＃＃終わり＃＃＃＃＃＃ 20年前、中国で初めてインターネットが普及しました。情報は情報として表示され、オンライン取引はほとんどありませんでした。10年前、インターネットは急速に発展し、消費者はタオバオ、天猫、タオバオなどでインターネットを購入できるようになりました。必要な商品や気に入った商品をオンラインモールで購入できるオンライン取引、今ではさまざまなEC形態が登場し、コンテンツECなど百花繚乱のトレンドとなっています。小紅書、興味電子商取引Douyin Kuaishou、ソーシャル電子商取引WeChat Shang、Pinduoduoなど、会員型電子商取引Tmall 88vip、JD plusなど。これらのオンライン取引フォームは、電子商取引がインターネット分野でトラフィックを収益化する上で重要な部分を占めており、インターネット企業インフラの水、電気、石炭となっているということを完全に証明しています。電子商取引ミドルプラットフォームの構築は、技術システムの構築だけでなく、組織構造の再構築のプロセスでもあります。しかし、時間が経てば経つほど、ミドルオフィスの価値が伸びる余地はますます狭くなり、意識的にイノベーションポイントを探し、既存システムの枠を打ち破り、国境を越えた発想が必要となるため、私たちも取り組みを始めました。フロントオフィスビジネスに近づくため、新規ビジネスの探索と技術アーキテクチャのアップグレードを積極的に実行します。 新しい小売の探索 過去に自動車電子商取引のビジネス モデルを調査したところ、核心的な問題点は 4S ストアを迂回して小売りを行うことができないことであることがわかりました。サービスを提供します。近年、テスラや新たな国内自動車製造勢力が台頭し、新興の直販モデルは従来の自動車会社の4S流通システムのエコロジーを一気に打ち破り、国内の自動車購入層もますます若年化しており、オンラインでの車の注文とオフラインでの配送という新しい小売りのパターンが可能になりつつあります。電子商取引システムの既存機能をアップグレードすることで、製品はSKUの選択をサポートし、注文は大口と小口のデポジットの組み合わせ支払いと返金をサポートし、業界団体や自動車業界のカスタマイズカービジネスにサービスを提供するための新しい配送システムを追加しました。新規自動車小売オフライン店舗事業のサポート。今後も、新しいエネルギー オプション向けの業界に合わせた変動価格モデルと、オプションの製品パッケージ向けのサービス パッケージ モデルの作成を継続します。 アーキテクチャのアップグレード 元の電子商取引トランザクション注文プロセスでは、設計された外部サービスは比較的粒度の小さいアトミック サービスであり、その結果、ビジネス面は比較的高く、ユーザーエクスペリエンスはあまり良くありません。将来的には、BFF レイヤーの追加、コール チェーンの合理化、電子商取引アクセス スキャフォールディングなどの技術的手段を通じて、ビジネスの製品力と運用効率を向上させます。

以上がAutohome 電子商取引システム アーキテクチャの進化とプラットフォーム アーキテクチャの実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。