バックグラウンド
大規模な電子商取引サイトとは、1 日に数百万のユーザーがアクセスし、1 日に数千万または数億のページ ビューがある Web サイトを指し、この規模の電子商取引 Web サイトは中国にはあまりありません。
コンテンツ
アーキテクチャ設計は、アプリケーション アーキテクチャ設計とインフラストラクチャ設計の 2 つの部分に分けられます。
- アプリケーション アーキテクチャ設計: 電子商取引 Web サイト アーキテクチャ、サプライ チェーン システム アーキテクチャ、パーソナライズされたレコメンデーション エンジン アーキテクチャ、電子商取引検索エンジン アーキテクチャなど、ビジネスと最も密接に統合されたビジネス システム アーキテクチャ設計を指します。
- インフラ設計：ミドルウェアをサポートする基盤となるシステムのアーキテクチャ設計を指し、ビッグデータプラットフォームアーキテクチャ設計、クラウドプラットフォームアーキテクチャ設計、サービスガバナンスプラットフォームアーキテクチャ設計、分散ファイルストレージアーキテクチャ設計など、アプリケーションシステムはインフラストラクチャ上に構築されます
大規模ECシステムのアーキテクチャ設計
システム アーキテクチャ設計の目標と原則は、高可用性、簡単なスケーラビリティ、および低コストです。
このようなアーキテクチャ設計の目標と原則に基づいて、サービス指向と分散がこのアーキテクチャ設計の主なアイデアです。
- サービス化: すべてのコア ビジネスは、さまざまなビジネス システムで共有するためのさまざまなサービスを形成するために預け入れられます。インフラストラクチャ関連のリソースも、メッセージ、ファイル ストレージ、キャッシュなどのサービスの形で提供されます。
- 分散: システム アーキテクチャの各レイヤーとすべてのリソースが分散され、スムーズな水平展開をサポートします。
技術アーキテクチャの観点から、電子商取引 Web サイト システムは、アプリケーション層、コア サービス層、基本サービス層、データ アクセス層、およびデータ ソースの 5 つの層に分けることができます。写真が示すように
各層の役割と、そこに含まれる主なモジュールを紹介します。
- アプリケーション層: Web サイト ページ、ショッピング カート、決済センター、メンバー センター、オンライン カスタマー サービス、マーチャント プラットフォーム、サプライヤー プラットフォーム、運用など、顧客、マーチャント、従業員、およびその他の役割にプラットフォームを提供するユーザー指向のアプリケーション システムです。背景。アプリケーション システムは、コア サービスを呼び出すことによって、特定のビジネス ロジックを実装します。
- コア サービス レイヤー: コア ビジネス ロジックをカプセル化し、さまざまなアプリケーション システムによって呼び出されるサービスの形で提供します。コアサービスには、取引、決済、プロモーション、カテゴリー維持、商品管理、店舗装飾、在庫管理などがあります。
- 基本サービス層: アトミック ビジネスをカプセル化し、コア サービス層が呼び出すサービスの形で提供します. ここで注意すべきことは、一般に、アプリケーション層は基本サービス層を直接呼び出すことはできません。層を越えてサービスを呼び出すことはできません。コア サービス レイヤーが特定のビジネス ロジックをカプセル化する場合、基本サービス レイヤーの複数のインターフェイスを呼び出すことがよくあります。基本的なサービス層には、注文、在庫、価格、ユーザー、製品、ポイントなどが含まれます。
- データ アクセス レイヤー: データ アクセスを実現するミドルウェア レイヤーであり、その機能モジュールには、永続コンポーネント、トランザクション処理、接続プール、NoSQL クライアント、SQL 管理ツールボックスなどがあります。すべてのデータ アクセスはデータ アクセス レイヤーを通過する必要があり、データ アクセス レイヤーをバイパスしてデータベースに直接アクセスすることは許可されていません。
- データ ソース: Oralce、MySQL、Hadoop、Hbase、MangoDB などのデータベース クラスターを指します。データベースは通常、アクティブ/スタンバイ メカニズムと読み書きの分離を実装するためにクラスターにデプロイされます。
上記は、各レイヤーで行われることを説明しています. SOA はこのアーキテクチャで広く使用されているため、障害分離のサポート、グレースフル デグラデーション、完全なリクエスト ライフ サイクルの追跡など、サービスを管理するためのサービス ガバナンス プラットフォームが必要です.問題を特定し、すべてのサービスの依存関係を管理できます。
さらに、データの読み取りには、データ ソースへの要求の数を減らし、データベースへのプレッシャーを軽減し、シナリオに従って合理的にマルチレベル キャッシングとローカル キャッシングを使用するために、キャッシング ミドルウェアも必要です。ダーティデータの生成と悪用を防ぐためのパッシブ更新メカニズム。
同時に、ハードウェア、データベース、サービス、アプリケーション、コンテナー、およびミドルウェアを監視および警告するための完全な監視および早期警告メカニズムが必要です。ショッピング プロセスの通常の操作。
最後に、パフォーマンスの向上、アクセス速度の最適化、災害復旧を実現するために、Web サイト全体で複数のデータ センターの展開を実装できる必要があります。
前の章のチュートリアル
Architectural Thinking Growth Series チュートリアル (6) - サーバーレス アーキテクチャに関する予備調査
一連のチュートリアル
私のコラム
以上で、すべての紹介は終了です
-------------------------------
-------------------------------
私について(個人ドメイン名、私に関する詳細情報)
私のオープンソース プロジェクト コレクション Github
皆さんと一緒に学び、成長し、激励できることを楽しみにしています, O(∩_∩)O ありがとう
質問の交換へようこそ。個人的な QQ 469580884 を追加できます。
または、私のグループ番号 751925591を追加して、コミュニケーションの問題について一緒に話し合ってください
嘘について話さないで、ただ実行者になりなさい
話は安いです、コードを見せてください
