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

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

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（新））。

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