目前國內盛行分散式與微服務結構設計，大小公司、電商、物聯網等行業都是緊隨這些概念在開展專案開發和運營，據我日前和一些架構師朋友討論過程中發現不但大多公司沒有把整體的方案落地，有些架構師甚至都不知道為什麼採用這一系列的服務就開始了開發工作，這對軟體行業來說是非常危險的。

談起來大型平臺架構都是採用什麼技術、什麼框架、什麼協議等等開頭，我認為大可以不必先著急去談論技術，我們不妨來倒推一下架構思維，先來談論一下大型平臺的核心要素，弄明白架構設計到底是根據什麼樣的需求來進行設計的，它有什麼樣的標準和特性。

一線城市上市公司技術總監、資深電商平臺首席架構師，浪躍學院創始人Mike-Wu系統梳理了自己的思考和理解，希望幫助更多程式設計師少走一些彎路。QQ群號：713331208。

首先，給大家講解下大型平臺的核心要素主要體現在哪幾個方面：

1效能：不管是什麼產品，效能永遠是客戶要求的第一感官，點個查詢要等10秒，跳轉個頁面總是載入不到資訊，架構設計再強大也無法讓使用者感知到你的努力，所以效能是產品第一個也是最重要的核心要素。

2可用性：如個人的信譽一般，大型平臺的可用性就是它的信譽，哪怕一分一秒的宕機也不可能被原諒，這是一個不用討論的硬指標，幾乎所有的大型網站都承諾7*24小時可用。

3伸縮性：大型平臺總是要跟隨人們的節奏在執行，就像中國人過春節一樣，平臺也會有高峰和低谷，這時候就是考驗一個平臺的伸縮性的時候，可以新增多少伺服器到叢集中，新增後是否能無差別的提供服務是重要的擴充套件指標。

4可擴充套件性：這是幾個核心要素中唯一一個關注功能性的指標，擴充套件性是說一個完整的平臺上線後面對新的業務發展和需求變更，是否可實現對現有產品透明無影響，不改動或很少的改動現有功能就可以上線新產品。

5安全性：沒有安全性，其它的都是笑談，針對不同的行業對安全級別要求也不同，咱們在這裡暫時提一下。

前面講了，我們需要討論一下這幾個核心要素，確定一下這幾個要素中間我們需要實現哪一些，具體的指標是什麼，再根據不同的指標要求來採取對應的技術方案就會非常明確了。

為了方便大家能更好的理解架構思維，那我以10張架構設計圖為大家闡述下阿里公司架構設計的主要發展歷程。

一、最開始的網站架構

    最初的架構，應用程式、資料庫、檔案都部署在一臺伺服器上，如圖：

LAMP Linux+Apache+PHP+Mysql，經典配置。太多經典案例都是這樣的架構設計，好處就是便易、方便、開發上線速度快、成本低。

二、應用、資料、檔案分離

 隨著業務的擴充套件，一臺伺服器已經不能滿足效能需求，故將應用程式、資料庫、檔案各自部署在獨立的伺服器上，並且根據伺服器的用途配置不同的硬體，達到最佳的效能效果。

三、利用快取改善網站效能

在硬體優化效能的同時，同時也要通過軟體進行效能優化，在大部分的網站系統中，都會利用快取技術改善系統的效能，使用快取主要源於熱點資料的存在，大部分網站訪問都遵循28原則（即80%的訪問請求，最終落在20%的資料上），所以我們可以對熱點資料進行快取，減少這些資料的訪問路徑，提高使用者體驗。

    快取實現常見的方式是本地快取、分散式快取。當然還有CDN、反向代理等。本地快取，顧名思義是將資料快取在應用伺服器本地，可以存在記憶體中，也可以存在檔案，OSCache就是常用的本地快取元件。本地快取的特點是速度快，但因為本地空間有限所以快取資料量也有限。分散式快取的特點是，可以快取海量的資料，並且擴充套件非常容易，在門戶類網站中常常被使用，速度按理沒有本地快取快，常用的分散式快取是Memcached、Redis。

四、使用叢集改善應用伺服器效能

    應用伺服器作為網站的入口，會承擔大量的請求，我們往往通過應用伺服器叢集來分擔請求數。應用伺服器前面部署負載均衡伺服器排程使用者請求，根據分發策略將請求分發到多個應用伺服器節點。

常用的負載均衡技術硬體的有F5，價格比較貴，軟體的有LVS、Nginx、HAProxy。LVS是四層負載均衡，根據目標地址和埠選擇內部伺服器，Nginx是七層負載均衡和HAProxy支援四層、七層負載均衡。如何選擇根據各自的需求和特點，我們通常根據報文內容選擇內部伺服器，因此LVS分發路徑優於Nginx和HAProxy，效能要高些。而Nginx和HAProxy則更具配置性，如可以用來做動靜分離效果更佳（根據請求報文特徵，選擇靜態資源伺服器還是應用伺服器）。

五、資料庫讀寫分離和分庫分表

隨著使用者量的增加，很快資料庫就會成為最大的瓶頸，改善資料庫效能常用的手段是進行讀寫分離以及分表，讀寫分離顧名思義就是將資料庫分為讀庫和寫庫，通過主備功能實現資料同步。分庫分表則分為水平切分和垂直切分，水平切換則是對一個數據庫特大的表進行拆分，例如使用者表。垂直切分則是根據業務不同來切換，如使用者業務、商品業務相關的表放在不同的資料庫中。

六、使用CDN和反向代理提高網站效能

假如我們的伺服器都部署在成都的機房，對於四川的使用者來說訪問是較快的，而對於北京的使用者訪問是較慢的，這是由於四川和北京分別屬於電信和聯通的不同發達地區，北京使用者訪問需要通過互聯路由器經過較長的路徑才能訪問到成都的伺服器，返回路徑也一樣，所以資料傳輸時間比較長。對於這種情況，常常使用CDN解決，CDN將資料內容快取到運營商的機房，使用者訪問時先從最近的運營商獲取資料，這樣大大減少了網路訪問的路徑。

  而反向代理，則是部署在網站的機房，當用戶請求達到時首先訪問反向代理伺服器，反向代理伺服器將快取的資料返回給使用者，如果沒有沒有快取資料才會繼續走應用伺服器獲取，也減少了獲取資料的成本。反向代理有Squid，Nginx。

七、使用分散式檔案系統

使用者一天天增加，業務量越來越大，產生的檔案越來越多，單臺的檔案伺服器已經不能滿足需求。需要分散式的檔案系統支撐。常用的分散式檔案系統有很多，例如FastDFS、NFS。

八、使用NoSql和搜尋引擎

對於系統產生的海量資料的查詢，我們使用nosql資料庫加上搜索引擎可以達到更好的效能。並不是所有的資料都要放在關係型資料中。常用的NOSQL有mongodb和redis，搜尋引擎有lucene、Sorl、ElasticSearch。

九、將應用伺服器進行業務拆分

隨著業務進一步擴充套件，應用程式變得非常臃腫，這時我們需要將應用程式進行業務拆分，如百度分為使用者、商品、訂單、圖片等業務。每個業務應用負責相對獨立的業務運作。業務之間通過訊息進行通訊或者同享資料庫來實現。

十、搭建分散式服務

如果以上的架構優化都不能承載系統的訪問時，就要考慮分散式服務或微服務處理框架了。這時架構師會發現各個業務應用都會使用到一些基本的業務服務，例如使用者服務、訂單服務、支付服務、安全服務，這些服務是支撐各業務應用的基本要素。我們將這些服務抽取出來利用分部式服務框架搭建分散式服務。淘寶的SOA體系中Dubbo架構或SpringCloud微服務框架都是不錯的選擇。

小結：

以上10張圖是ALI的架構演變史，非常簡明的圍繞最初我們定義的5個大型系統架構中的核心要素開展的系統升級。同時也再次印證了那句在架構圖中經久不衰的臺詞“不要試圖去設計一個大型系統架構”，因為現有的大型平臺架構都是一步步經過眾多的架構師的努力而演變而來的。試圖一口吃個胖子的架構是不可想象的，不要為了技術而技術，不要為了潮流而技術，適合你現在的業務需要的架構才是最好的架構。

在這裡，希望每一個看到這篇文章的朋友都能想想以上的話，在專案開發和系統設計中能更好的運用到其中。我會不定期的組織架構師朋友討論新技術落地實踐，企業應用框架協作開發與微服務技術落地等技術和專案實戰，有專案經驗基礎的朋友，也歡迎大家可以參與進來，QQ群號：713331208（零基礎朋友勿入）。我非常樂於分享自己在這十幾年的網際網路發展程序中接觸到的大型專案的一些經驗總結，包括銀行業，金融證券，物聯網，電商專案等行業，知識需要分享，更需要傳播，希望自己能幫助到更多的人一起進步，一起為這個時代的發展做出一點自己的貢獻。只要你夠出色，你的工作將不僅僅是一份工作，更是一種情懷，一種信仰，一種我們這個年代所急切需要的社會責任感，因為未來是屬於我們大家的！

更多高階技術內容請登陸：

https://ke.qq.com/course/249864

以上推文來自：浪躍學院。