分佈式架構設計之電商平臺

分佈式架構設計之電商平臺

何爲軟件架構？不同人的答案會有所不同，而我認爲一個好的軟件架構除了要具備業務功能外，還應該具備一定的高性能、高可用、高伸縮性及可拓展等非功能需求。而軟件架構是由業務架構和技術架構兩部分組成，因爲有了業務結構纔會催生出軟件架構，進而來滿足業務上的需求，所以，在做軟件架構設計時，需要分爲業務架構設計和技術軟件架構設計，二者不可分離哦！那麼，接下來就以本人實際工作中的電商平臺爲例，進行說明電商平臺架構設計，因爲不同行業產品系統不同業務不同，而催生的系統軟件的實現要求及架構設計就不同了！

l 架構設計的必要

l 電商平臺的需求

l 平臺的業務架構

l 平臺的技術架構

l 平臺架構的總結

一、架構設計的必要

架構師，我想很多人都知道，其實該職位頭銜在最早的IT領域是沒有的，它是近些年來由互聯網的發展所引發的需求，因爲現階段的數據量及高併發的活躍好動，引起了不少傳統的技術人員的力不從心，企業愈發關注到了系統架構的重要性，所以不同行業開始招募架構技術人員，架構師就誕生了。

1、架構設計的條件

我個人不建議具備下面條件的人員急着做架構，其實架構師的頭銜並沒有想象的那麼神祕，到底是什麼節點的同學：

A、對架構不感興趣，但又迫於需求；

B、入IT行業，年限小於4年的；

C、主觀能動性弱，又安於現狀的；

注意，上面只是個人的想法，不具有代表性，只要你能夠循序漸進，秒殺上面幾條不滿只是時間的問題。

2、架構設計的優勢

A、更好的梳理業務的結構體系；

B、更好的拓展、維護及性能優化；

C、更好的適應企業業務靈活的推進；

D、更好的適應大數據的沖洗和應對；

E、更好的穩定性、低成本及快速迭代；

3、架構設計的注意

架構設計需要注意的地方，不是怎麼把架構搭建起來，而是必須根據業務需求，嚴格分析，實現該需求需要什麼技術會更好及更長遠發展的考慮；另外，構建好的架構雖然可以運行，但是性能需要跟起來，否則架構設計會適得其反，增加不必要的工作量，那麼下面就詳細介紹下架構設計的策略。

二、電商平臺的需求

1、客戶需求

A、在線購物、在線支付或貨到付款；

B、購買商品後，客戶可以與客服溝通；

C、購買商品過程，物流的管理及跟蹤；

D、收取到商品後，商品、物流評價打分；

客戶的需求爲最高，也代表了企業的核心需求，當然，企業需求還包括其它很多非功能性需求，具體請查看需求梳理部分。

2、需求梳理

客戶需求	功能需求	非功能需求
在線購買商品	購物車、結算及會員管理	用戶體驗（性能、可用性）
在線與客服溝通	在線客服功能	即時通信能力
在線支付或貨到付款	多種支付方式，含在線支付或貨到付款	安全、加密、多種支付方式靈活切換
在線商品、物流評論打分	商品、物流評價打分	物流體系對接

上面只是對電商平臺需求的簡單列舉，還有很多需求未列出，這裏只是爲了分析和設計電商平臺架構做準備，具體的其它需求，可以參看京東、淘寶等商城。

三、平臺的業務架構

根據業務的需求進行子系統模塊劃分，可以劃分爲商品子系統、購物子系統、支付子系統、物流子系統、客服子系統、評論子系統；而非核心需求可拆分出客服子系統、評論子系統及接口子系統。另外，根據各個子系統的核心等級，可拆分出核心子系統和非核心子系統，前者包括商品子系統、購物子系統、支付子系統及物流子系統；後者，則包括評論子系統、客服子系統及接口子系統。需要注意的是一般大型電商平臺的物流系統是單獨分離出來的系統（入庫、出庫、庫存管理、配送管理及貨品管理），而這裏劃分爲子系統的主要目的是爲演示核心架構，本架構中物流子系統一般作爲對接和管理獨立子系統的對接模塊哦。

1、業務拆分目的

A、爲了解決各個模塊子系統間的耦合、維護及拓展性；

B、方便單獨部署子系統，避免集中部署導致一個出問題，全部不能用；

C、分配專門的團隊，負責具體的子系統，最大化工作效率安排；

D、應對大數據，高壓力時，保護核心子系統正常使用；

2、業務的架構圖

在上面的業務架構圖中，將核心和非核心業務進行拆分，同時每個系統都要獨立部署實現，做到大數據量壓下，各個系統獨立運作，提高可用性，必要時可以暫停掉非核心繫統的資源開銷，保證核心業務正常爲用戶服務。

四、平臺的技術架構

在上面業務架構圖基礎上，我們需要一個技術架構的演變過程，一切只爲滿足用戶的體驗和支撐爲前提，所以技術架構的搭建不是一蹴而就的，而是隨着業務的不斷衍變，系統的架構會逐漸完善更新，以實現應對業務數據量的衝擊。

1、基本的架構設計

記得很早的時候，很多中小企業所採用的架構設計十分簡單，基本使用一臺服務器來滿足一切需求部署，比如：一臺服務器同時用作應用部署、數據庫存儲以及圖片存儲等，不料的是待用戶數據達到50萬以上，系統出現很多性能問題，儘管對數據庫和程序做個各種性能優化，結果仍無明顯改善，架構如下：

後來，IT程序猿發現圖片的讀寫嚴重影響了系統性能，並將圖片單獨存放在獨立服務器中，並且在架構中引入了Cache中間件，比如：Memcache，這種做法是可取的，而且比原來性能提高了1-2個性能級別，架構設計如下：

2、初級的架構設計

前幾年，一般的電商網站的做法是選用三臺服務器，一臺部署應用，一臺部署數據庫，一臺部署NFS文件系統，做到將各個規模龐大並耗用性能的部分剝離到不同服務器設備，再配備必要的緩存中間件，基本可以滿足近1000萬的數據量，具體的架構圖如下：

但是，目前主流使用的網站架構已經不同，大多采用集羣的方式來實現負載均衡和高可用性，架構可以是下面的樣子：

注意：

如果涉及到多臺網站服務器的話，就會存在Session如何同步的問題，一般也是最爲常用的做法，就是使用Cache中間件來存儲和管理Session信息。

3、優化的架構設計

這裏爲解決高併發，高可用的大型電商網站的架構設計方案，主要採用了分佈式、集羣、負載均衡、反向代理、消息隊列及多級緩存技術。該架構設計方案，是現今比較流程的大型電商網站採用的架構模式，比如：淘寶、京東等，也許會有細微不同的地方，但大同小異哦！具體的架構圖方案如下：

3.1、應用集羣部署

3.2、分佈式

分佈式，即爲藉助互聯網環境連接不同服務器，並各個連接的服務器之間通信交互，提供服務異步調用和返回的通信機制。在這裏，主要就是實現商品評論、購物客服、支付接口及物流打分系統各自所在服務器間的通信化，我們可以通過RPC協議直接在他們之間交互通信即可，而上面優化的架構即爲分佈式架構。

3.3、集羣

集羣，分爲服務器集羣、數據庫集羣及緩存中間件集羣等，但這裏主要指的是數據庫的集羣設計。數據庫集羣，可以實現主備數據庫，做到讀寫分離以及高可用的實現。大型網站需要存儲大規模的數據量，需要實現高可用、高併發、高性能的系統設計，一般採用冗餘的方式進行系統設計，具體如下架構：

冗餘方式設計數據庫集羣，最爲常用的方式爲：讀寫分離和分庫分表了。主數據庫服務器只負責寫入數據，而備用服務器數據庫只負責讀取數據，可以做到降低數據庫的IO壓力；另外，如果業務系統比較龐大，可以進一步根據業務的關係度及增長頻率分庫，若庫中的但表數據量比較大，可進一步分表，具體的分庫分表可查看我的博客文章數據庫的分庫分表。

3.4、消息隊列

消息隊列，是分佈式系統的常用組合，其可以解決子系統或模塊間的異步通信，實現高可用，高性能的通信系統，比如：可以用在購物和配送環節，如下：

A、用戶下單後，寫入消息到隊列，並立即返回結果給客戶端；

B、庫存子系統，讀取消息隊列，完成消減庫存；

C、配送子系統，讀取消息隊列，並進行配送貨品；

目前常使用的MQ技術有：Rabbit MQ、Active MQ、Zero MQ及MS MQ，需要根據具體的使用場景進行選擇。具體的架構如下：

3.5、緩存策略

緩存，是一種緩解系統壓力的存儲技術，主要使用在緩存數據庫IO壓力而設計。按照位置的不同，可以分爲本地緩存和分佈式緩存兩種，本篇架構採用兩級緩存，一級緩存爲本地緩存，二級緩存爲分佈式緩存。而一級緩存一般用來緩存基本不變或規律變化的數據，二級緩存用來緩存所有需要的數據信息，應用程序首先訪問一級緩存；如果一級緩存沒有需要的信息，那麼取訪問分佈式緩存，如果分佈式緩存也沒找到需要的信息，最後去訪問數據庫獲得數據。另外，根據業務需要，緩存分爲自動過期和觸發過期，具體的架構圖如下：