目前國內盛行分布式與微服務結構設計，大小公司、電商、物聯網等行業都是緊隨這些概念在開展項目開發和運營，據我日前和一些架構師朋友討論過程中發現不但大多公司沒有把整體的方案落地，有些架構師甚至都不知道為什么采用這一系列的服務就開始了開發工作，這對軟件行業來說是非常危險的。
談起來大型平台架構都是采用什么技術、什么框架、什么協議等等開頭，我認為大可以不必先着急去談論技術，我們不妨來倒推一下架構思維，先來談論一下大型平台的核心要素，弄明白架構設計到底是根據什么樣的需求來進行設計的，它有什么樣的標准和特性。
一線城市上市公司技術總監、資深電商平台首席架構師，浪躍學院創始人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
以上推文來自：浪躍學院。