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

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

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

l   架構設計的必要

l   電商平臺的需求

l   平臺的業務架構

l   平臺的技術架構

l   平臺架構的總結

一、架構設計的必要

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

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壓力而設計。按照位置的不同，可以分為本地緩存和分散式緩存兩種，本篇架構採用兩級緩存，一級緩存為本地緩存，二級緩存為分散式緩存。而一級緩存一般用來緩存基本不變或規律變化的數據，二級緩存用來緩存所有需要的數據信息，應用程式首先訪問一級緩存；如果一級緩存沒有需要的信息，那麼取訪問分散式緩存，如果分散式緩存也沒找到需要的信息，最後去訪問資料庫獲得數據。另外，根據業務需要，緩存分為自動過期和觸發過期，具體的架構圖如下：

3.6、服務抽象化

抽象化概念，可以很好的實現低耦合，高拓展作用，我們可以將各個子系統公用的功能或模塊抽取出來，封裝為共有的服務組件或介面，供各個現有子系統或是新增系統調用，這也是SOA架構的基礎思想，具體的架構如下：

五、平臺架構的總結

這裡主要總結的是優化架構，架構按層次結構羅列組織，共分為四層，分別為負載均衡代理層、應用集群系統層、分散式服務層及數據資源層，層次分工明確，高拓展，低耦合，負載均衡、集群、分散式及緩存等技術的使用，架構如下：

好了，電商平臺的架構設計就介紹到這裡，本篇主要是介紹架構設計的思路及應用的核心技術，供在架構設計的同學參考借鑒哦！由於作者水平有限，如有不對或是誤導的地方，請不吝指出討論（QQ群：497552060（新））。