バックグラウンド
マイクロサービス アーキテクチャは、すでに大規模で複雑なシステムに推奨されるアーキテクチャ方法です. 以下では、大規模で複雑なシステムにおけるマイクロサービスのアーキテクチャの実践を紹介する例として、大規模な電子商取引システムのアプリケーション シナリオを取り上げます.
コンテンツ
e コマース アーキテクチャの実践
e コマースは、プロモーション主導のシナリオであると同時に、価格競争主導のシナリオでもあります。毎年、618 とダブル 11 は典型的なプロモーション活動です。実際、それらはすべてユーザーを獲得し、市場シェアを拡大しています。このようなシナリオでは、フラッシュセールとスナップアップが非常に人気のある方法です。
システムへのプロモーションプルの課題は何ですか?
上の写真から次のことがわかります。
- 高可用性の要件は非常に高く、99.99% の高可用性が必要です。高速反復には高いシステム容量が必要です. 数万オーダーから数十万または数百万オーダーまで、アーキテクチャは高速反復に影響を与えることができないため、空中給油または高速道路でのタイヤ交換の話があります.
- また、瞬間的な大量アクセス（特にフラッシュセールのシナリオ）に対応するためには、システムのスケーラビリティ（急速な拡張と縮小）が必要であり、これらがシステムの要件です。
大規模電子商取引システムのアーキテクチャ
下から順に、データ レイヤー、埋め込みポイント データは、ユーザーの行動データとリアルタイム データを NoSQL、リレーショナル データベース、およびビッグ データ プラットフォームに格納します。
1. インフラ層
このレイヤーは実際には、MQ メッセージ、JOB デバッグ センター、SSO 共同ログイン、メッセージ送信、分散ファイル ストレージ、ユーザーによってアップロードされたいくつかの画像などを含むミドルウェアおよびサービスです。さらに、アプリケーション監視のシステム全体とフレームワークがあります。自動リリース サポート AB テスト。
2. 基本サービス層
上位レイヤーは基本的なサービス レイヤーであり、インフラストラクチャ レイヤーによって提供されるコンポーネントとサービス、およびいくつかのビジネス ロジックを実際に使用して、OMS、PMS 調達、貨物テンプレート、配送エリアなどを含むいくつかのパブリック サービスを構築します。これらは次のとおりです。電子商取引で最も一般的に使用される基本サービス。
3. ビジネスサービス層
ビジネス サービス層で見られるのは、たとえば、ショッピング カート、注文、ホームページなど、ユーザーがフロント デスクで見ることができるインターフェイスであり、それらがマイクロサービスであるかどうかにかかわらず、少なくともサービス指向です。 . このレイヤーは、あらゆる Web アプリケーションの心臓部です。また、サードパーティープラットフォームのAPIドッキングです。
4. その他
仮想カテゴリは「ラベル」に相当します.たとえば、通常のカテゴリは「生鮮食品」と「衣料品」と呼ばれ、一部の仮想カテゴリは「618セール」と呼ばれ、多くの商品が集約されます.表示用の label 。
上部に露出していることがわかります。これらは、H5、PC、公式 Web サイトなどのさまざまな端末であり、これが最終的に表示される端末です。
マイクロサービス アーキテクチャの設計
1. ステートレス アプリケーション
多くの Web サイトは最初はマイクロサービス指向ではないかもしれませんが、いくつかの初期のプロジェクトでは、高速なオンライン配信のためのモノリシック アプリケーションをいくつか作成します。注文量の増加に伴い、いわゆる「マイクロサービス」を開始しました.最初のステップは、いわゆる単一のアプリケーションをステートレスアプリケーションに変えることです.ログインSSOの観点から,それはソリューションです変換方法を非表示にします。トークンを取得し、訪問ごとにトークンを取得します。これは、いわゆるデステートメントです。その後、各アプリケーションは水平方向にスケーリングできます。大量の訪問がある場合、サーバーを追加することで水平方向のスケーリング機能を強化できます。
この種のアプリケーションはステートレスですが、構成ファイルはステートフルです。たとえば、アクセスするデータベースとノードは構成ファイルを介して行われます (構成は nacos を介して集中管理できます)。今回紹介した事例は基本的にSpring Boot for micro-servicesをベースとしており、関連技術フレームワークとしてはDubbo、ZK、Hystrix、RocketMQ、Elasticsearch、Redisなどがあります。
2. 単一出願の分割
アプリケーションをステートレスにした後、単一のアプリケーションの分割です。分割にはいくつかの次元があります。
- 1つはシステムの次元からのもので、分解する最も簡単な方法は、ショッピングカート、製品、検索、ホームページなどのフロントエンドとバックエンドを分解することです.フロントエンドに属し、バックエンドはウェブサイト運営者。
- また、機能の次元に応じて分割することもできます.ユーザーサービスについては、サービス層からテーブル構造まで、実際に独立して展開できる.これがマイクロサービスの概念です. 技術体制は組織体制を反映したもので、この体制の下で、開発チームはユーザーサービス開発グループ、価格開発グループ、製品開発グループなどに分かれています。
- また、読み取り次元と書き込み次元に従って分割することもできます。たとえば、検索とモールのインデックスは、2 つの独立したサービスでなければなりません。ユーザー登録と注文の支払いは、完全なビジネス プロセスです。これらは、いくつかのマイクロサービスで構成されています。
サービス アーキテクチャの構築
1. データの不均一性
大規模な電子商取引システムでサービス アーキテクチャを構築する経験とスキルは、まず異種データです.注文テーブルを例にとると、通常、注文は非常に大きく、テーブルとデータベースは通常、ID に従って分割されます. この方法では、すべてのオーダーのユーザーを照会する場合、各テーブルからデータを取得する必要があるため、ユーザー ディメンションによってテーブルが異種混合になる可能性があります。データの保存はホットデータ、コールドデータ、ウォームデータに分かれており、それぞれ別の場所に存在します。データも集計されます。一部の注文詳細ページでは、多数の AJAX リクエストが存在するため、リクエストのマージも必要になります。バックグラウンド サービスもマージする必要があります。
製品の詳細ページを例にとると、複数のインターフェースのデータ キャッシュが Redis でマージされ、集約されたデータが Redis から取得されます。これはデータ クローズド ループと呼ばれます。これは、ネットワーク リクエストを最適化するための一般的な方法です。
2.キャッシュ
キャッシングは、大規模な電子商取引システムで一般的に使用される最適化手法です。ブラウザー レベルのキャッシュは、応答ヘッダーによって設定されます。また、アプリ クライアントのキャッシュを使用して H5/CSS/JS/ 画像をパッケージ化し、それらを事前にクライアントにプルし、クライアントでプロキシ サーバーとして機能しますが、データを読み取らないため、ユーザー エクスペリエンスが向上します。 . キャッシングの使用は、CDN を使用したインターネットでも一般的に使用されています。アクセス レイヤーに入った後、ソフト ロードを使用すると、メモリ レベルのキャッシュも使用できます。
3. メッセージキューの応用
メッセージ キューの適用は、サービスの分離を行う良い方法です。また、メッセージの失敗と再試行のシナリオも考慮してください。データの損失を防ぐために、追加の補償を行う必要があります。もう 1 つのメカニズムは、データ チェックサム補正です。多くのシナリオで実現できるのは、結果整合性です。大規模な電子商取引システムと金融システムのシナリオは大きく異なります.これは、分散システムを設計する際の一般的な方法です. ほとんどの場合、電子商取引では、最終的な一貫性が達成されている限り.
可用性の高いアーキテクチャ設計
実際、電子商取引のための高可用性アーキテクチャ設計は、高可用性が最も基本的な要件です。プロモーション中に数千万人のユーザーが集客すると、ダウンタイムが大きな損失をもたらします。
1. サービスの低下、障害のグループ化と分離
マイクロサービス アーキテクチャに基づく e コマース システムの場合、高可用性ソリューションには次の部分があります。
- サービスのダウングレードを最初にサポートする必要があります。ダウングレードするスイッチは、通常、構成センターに書き込まれます。たとえば、大きなプロモーション中は、最初に注文をキャッシュに入れてから、ストレージなどの操作を実行します。
- 同時に、サービスのグループ化と障害の分離が必要です。たとえば、seckill 中は、seckill のアプリケーションは個別にデプロイされます.seckill のアプリケーションが中断された場合、サービスの分離により、他のサービスは影響を受けません。
- 同時に、多くのフレームワークでサポートされている制限付きフロー メカニズムが必要です。
2.交通管理
極端なシナリオでは、トラフィック管理を複数のレベルで実行する必要があります。たとえば、プロモーション当日は、クローラーとロボットのトラフィックが制限されます。通常、ボードは大きなプロモーションの前に閉じられます. 問題が発生した場合は、データ バージョンのロールバックなどのロールバックが行われます. データ構造を設定するときは、データ バージョン番号でロールバックをサポートする必要があります.
ビジネスデザイン
ビジネスデザインを考えています。図から、注文の支払いプロセスを見ることができます。設計する際には、アンチヘビー設計を考慮する必要があります.アンチヘビーキーまたはアンチヘビーテーブルソリューションを使用できますが、コストとコストが高く、ポイントなどのいくつかのシナリオで使用されます,控除およびその他の金銭関連のシナリオ。
ビジネス設計では、ステート マシンを考慮する必要があります。特に注文のフロー状態では、順方向と逆方向のプロセスを含むステート マシンの適用を実行し、結果を生成する必要があります。
大規模なモバイル e コマースのアーキテクチャ
1.動的ルーティング
下の図は、モバイル e コマースの完全なアーキテクチャです。アプリ側から見ると、主なことは静的ファイルとインテリジェントな動的ルーティングをキャッシュすることです。中国のネットワーク環境は非常に複雑で、アプリ側でインテリジェントな動的ルーティングを行う必要があります。一部の CDN にアクセスして、動的コンテンツのリンク最適化を行うことができます。ネットワーク環境を検出するメカニズムがいくつかあります。これは、CDN、ドメイン名、または IP が公開される可能性があります。
2. 埋もれたポイントとゲートウェイ
モバイル e コマースのアプリの場合、もう 1 つの非常に重要なポイントが埋没ポイントです。これは、完全なリンクの埋没ポイントを指します。アプリ内でのユーザーのすべての操作から、この操作はネットワーク、サービス層、およびミドルウェアを通過し、リンク全体を監視できる必要があります。これは、迅速なポジショニングの問題、特にモバイル e コマースのパフォーマンスの最適化に非常に役立ちます。最初のステップは、ポイントを埋めることです。
ネットワーク層には、ゲートウェイ アクセスもあります。電流制限、動的負荷など。ゲートウェイに追加されるロジックはそれほど多くなく、さまざまなアプローチがあります。サービスの場合、最も複雑なのはサービスの依存関係とガバナンスです。サービス間の呼び出しの最適化は、ショッピング カート サービス、価格の呼び出し、在庫、プロモーションなどのビジネス シナリオに基づく必要があります。価格が入手できないなど、依存するサービスが利用できない場合、依存関係を設計するときに、ショッピング カート サービスにキャッシュを作成してキャッシュを呼び出し、最終的な整合性を検証する必要があります。
フルリンク監視の実施には、基礎となる早期警告が必要です。データ監視依頼が来てから、シーンに応じた早期警戒計画を立てます。
やっと：
上記は、大規模な電子商取引システムにおけるマイクロサービスのアプリケーションです.多くの知識ポイントとアーキテクチャの使用法は、1つずつ説明されていません.興味のある読者は、これらの使用法の背後にある思考ロジックを掘り下げることができます.
おすすめ情報
前の章のチュートリアル
Architecture Thinking Growth チュートリアル シリーズ (4) - どのように「メッセージ」が複雑なシステムを分離するか
一連のチュートリアル
私のコラム
以上で、すべての紹介は終了です
-------------------------------
-------------------------------
私について(個人ドメイン名、私に関する詳細情報)
私のオープンソース プロジェクト コレクション Github
皆さんと一緒に学び、成長し、激励できることを楽しみにしています, O(∩_∩)O ありがとう
質問の交換へようこそ。個人的な QQ 469580884 を追加できます。
または、私のグループ番号 751925591を追加して、コミュニケーションの問題について一緒に話し合ってください
嘘について話さないで、ただ実行者になりなさい
話は安いです、コードを見せてください
