架構師，我想很多人都知道，其實該職位頭銜在最早的IT領域是沒有的，它是近些年來由互聯網的發展所引發的需求，因為現階段的數據量及高並發的活躍好動，引起了不少傳統的技術人員的力不從心，企業愈發關註到了系統架構的重要性，所以不同行業開始招募架構技術人員，架構師就誕生了。
架構設計的條件
以下三個條件不適合做架構設計
對架構不感興趣，但又迫於需求；
入IT行業，年限小於4年的；
主觀能動性弱，又安於現狀的；
架構設計的優勢
更好的梳理業務的結構體系；
更好的拓展、維護及性能優化；
更好的適應企業業務靈活的推進；
更好的適應大數據的沖洗和應對；
更好的穩定性、低成本及快速叠代；
架構設計時候需要註意的地方
架構設計需要註意的地方，不是怎麽把架構搭建起來，而是必須根據業務需求，嚴格分析，實現該需求需要什麽技術會更好及更長遠發展的考慮；
另外，構建好的架構雖然可以運行，但是性能需要跟起來，否則架構設計會適得其反，增加不必要的工作量，那麽下面就詳細介紹下架構設計的策略。
平臺的需求
客戶需求
在線購物、在線支付或貨到付款；
購買商品後，客戶可以與客服溝通；
購買商品過程，物流的管理及跟蹤；
收取到商品後，商品、物流評價打分；
客戶的需求為最高，也代表了企業的核心需求，當然，企業需求還包括其它很多非功能性需求，具體請查看需求梳理部分。
平臺的業務架構
根據業務的需求進行子系統模塊劃分，可以劃分為商品子系統、購物子系統、支付子系統、物流子系統、客服子系統、評論子系統；而非核心需求可拆分出客服子系統、評論子系統及接口子系統。另外，根據各個子系統的核心等級，可拆分出核心子系統和非核心子系統，前者包括商品子系統、購物子系統、支付子系統及物流子系統；後者，則包括評論子系統、客服子系統及接口子系統。需要註意的是壹般大型電商平臺的物流系統是單獨分離出來的系統（入庫、出庫、庫存管理、配送管理及貨品管理），而這裏劃分為子系統的主要目的是為演示核心架構，本架構中物流子系統壹般作為對接和管理獨立子系統的對接模塊哦。
1、業務拆分目的
為了解決各個模塊子系統間的耦合、維護及拓展性；
方便單獨部署子系統，避免集中部署導致壹個出問題，全部不能用；
分配專門的團隊，負責具體的子系統，最大化工作效率安排；
應對大數據，高壓力時，保護核心子系統正常使用；
2、業務的架構圖
在上面的業務架構圖中，將核心和非核心業務進行拆分，同時每個系統都要獨立部署實現，做到大數據量壓下，各個系統獨立運作，提高可用性，必要時可以暫停掉非核心系統的資源開銷，保證核心業務正常為用戶服務。
平臺的技術架構
在上面業務架構圖基礎上，我們需要壹個技術架構的演變過程，壹切只為滿足用戶的體驗和支撐為前提，所以技術架構的搭建不是壹蹴而就的，而是隨著業務的不斷衍變，系統的架構會逐漸完善更新，以實現應對業務數據量的沖擊。
1、基本的架構設計
記得很早的時候，很多中小企業所采用的架構設計十分簡單，基本使用壹臺服務器來滿足壹切需求部署，比如：壹臺服務器同時用作應用部署、數據庫存儲以及圖片存儲等，不料的是待用戶數據達到50萬以上，系統出現很多性能問題，盡管對數據庫和程序做個各種性能優化，結果仍無明顯改善，架構如下：
後來，IT程序猿發現圖片的讀寫嚴重影響了系統性能，並將圖片單獨存放在獨立服務器中，並且在架構中引入了Cache中間件，比如：Memcache，這種做法是可取的，而且比原來性能提高了1-2個性能級別，架構設計如下：
2、初級的架構設計
前幾年，壹般的電商網站的做法是選用三臺服務器，壹臺部署應用，壹臺部署數據庫，壹臺部署NFS文件系統，做到將各個規模龐大並耗用性能的部分剝離到不同服務器設備，再配備必要的緩存中間件，基本可以滿足近1000萬的數據量，具體的架構圖如下：
但是，目前主流使用的網站架構已經不同，大多采用集群的方式來實現負載均衡和高可用性，架構可以是下面的樣子：
註意：
如果涉及到多臺網站服務器的話，就會存在Session如何同步的問題，壹般也是最為常用的做法，就是使用Cache中間件來存儲和管理Session信息。
3、優化的架構設計
這裏為解決高並發，高可用的大型電商網站的架構設計方案，主要采用了分布式、集群、負載均衡、反向代理、消息隊列及多級緩存技術。該架構設計方案，是現今比較流程的大型電商網站采用的架構模式，比如：淘寶、京東等，也許會有細微不同的地方，但大同小異哦！具體的架構圖方案如下：
平臺架構的總結
這裏主要總結的是優化架構，架構按層次結構羅列組織，***分為四層，層次分工明確，高拓展，低耦合，負載均衡、集群、分布式及緩存等技術的使用，架構如下：
好了，電商平臺的架構設計就介紹到這裏，本篇主要是介紹架構設計的思路及應用的核心技術，供在架構設計的同學參考借鑒哦！有想了解更多的可以關註我