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

架構設計的條件

以下三個條件不適合做架構設計

對架構不感興趣，但又迫于需求;

入IT行業，年限小于4年的;

主觀能動性弱，又安于現狀的;

架構設計的優勢

更好的梳理業務的結構體系;

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

更好的適應企業業務靈活的推進;

更好的適應大數據的沖洗和應對;

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

架構設計時候需要注意的地方

架構設計需要注意的地方，不是怎么把架構搭建起來，而是必須根據業務需求，嚴格分析，實現該需求需要什么技術會更好及更長遠發展的考慮;

另外，構建好的架構雖然可以運行，但是性能需要跟起來，否則架構設計會適得其反，增加不必要的工作量，那么下面就詳細介紹下架構設計的策略。

平臺的需求

客戶需求

在線購物、在線支付或貨到付款;

購買商品后，客戶可以與客服溝通;

購買商品過程，物流的管理及跟蹤;

收取到商品后，商品、物流評價打分;

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

平臺的業務架構

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

1、業務拆分目的

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

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

分配專門的團隊，負責具體的子系統，***化工作效率安排;

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

2、業務的架構圖

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

平臺的技術架構

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

1、基本的架構設計

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

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

2、初級的架構設計

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

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

注意：

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

3、優化的架構設計

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

平臺架構的總結

這里主要總結的是優化架構，架構按層次結構羅列組織，共分為四層，層次分工明確，高拓展，低耦合，負載均衡、集群、分布式及緩存等技術的使用，架構如下：

好了，電商平臺的架構設計就介紹到這里。