十張圖讓你瞭解阿里公司架構設計的發展變化史

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

 

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

 

 

一線城市上市公司技術總監、資深電商平臺首席架構師，浪躍學院創始人Mike-Wu系統梳理了本身的思考和理解，但願幫助更多程序員少走一些彎路。QQ羣號：713331208。

 

首先，給你們講解下大型平臺的核心要素主要體如今哪幾個方面：

1性能：無論是什麼產品，性能永遠是客戶要求的第一感官，點個查詢要等10秒，跳轉個頁面老是加載不到信息，架構設計再強大也沒法讓用戶感知到你的努力，因此性能是產品第一個也是最重要的核心要素。

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

3伸縮性：大型平臺老是要跟隨人們的節奏在運行，就像中國人過春節同樣，平臺也會有高峯和低谷，這時候就是考驗一個平臺的伸縮性的時候，能夠添加多少服務器到集羣中，添加後是否能無差異的提供服務是重要的擴展指標。

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

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

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

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

 

1、最開始的網站架構

    最初的架構，應用程序、數據庫、文件都部署在一臺服務器上，如圖：

 

 

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

 

2、應用、數據、文件分離

 隨着業務的擴展，一臺服務器已經不能知足性能需求，故將應用程序、數據庫、文件各自部署在獨立的服務器上，而且根據服務器的用途配置不一樣的硬件，達到最佳的性能效果。

 

 

3、利用緩存改善網站性能

在硬件優化性能的同時，同時也要經過軟件進行性能優化，在大部分的網站系統中，都會利用緩存技術改善系統的性能，使用緩存主要源於熱點數據的存在，大部分網站訪問都遵循28原則（即80%的訪問請求，最終落在20%的數據上），因此咱們能夠對熱點數據進行緩存，減小這些數據的訪問路徑，提升用戶體驗。

    緩存實現常見的方式是本地緩存、分佈式緩存。固然還有CDN、反向代理等。本地緩存，顧名思義是將數據緩存在應用服務器本地，能夠存在內存中，也能夠存在文件，OSCache就是經常使用的本地緩存組件。本地緩存的特色是速度快，但由於本地空間有限因此緩存數據量也有限。分佈式緩存的特色是，能夠緩存海量的數據，而且擴展很是容易，在門戶類網站中經常被使用，速度按理沒有本地緩存快，經常使用的分佈式緩存是Memcached、Redis。

 

4、使用集羣改善應用服務器性能

    應用服務器做爲網站的入口，會承擔大量的請求，咱們每每經過應用服務器集羣來分擔請求數。應用服務器前面部署負載均衡服務器調度用戶請求，根據分發策略將請求分發到多個應用服務器節點。

經常使用的負載均衡技術硬件的有F5，價格比較貴，軟件的有LVS、Nginx、HAProxy。LVS是四層負載均衡，根據目標地址和端口選擇內部服務器，Nginx是七層負載均衡和HAProxy支持四層、七層負載均衡。如何選擇根據各自的需求和特色，咱們一般根據報文內容選擇內部服務器，所以LVS分發路徑優於Nginx和HAProxy，性能要高些。而Nginx和HAProxy則更具配置性，如能夠用來作動靜分離效果更佳（根據請求報文特徵，選擇靜態資源服務器仍是應用服務器）。

 

5、數據庫讀寫分離和分庫分表

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

 

6、使用CDN和反向代理提升網站性能

假如咱們的服務器都部署在成都的機房，對於四川的用戶來講訪問是較快的，而對於北京的用戶訪問是較慢的，這是因爲四川和北京分別屬於電信和聯通的不一樣發達地區，北京用戶訪問須要經過互聯路由器通過較長的路徑才能訪問到成都的服務器，返回路徑也同樣，因此數據傳輸時間比較長。對於這種狀況，經常使用CDN解決，CDN將數據內容緩存到運營商的機房，用戶訪問時先從最近的運營商獲取數據，這樣大大減小了網絡訪問的路徑。

  而反向代理，則是部署在網站的機房，當用戶請求達到時首先訪問反向代理服務器，反向代理服務器將緩存的數據返回給用戶，若是沒有沒有緩存數據纔會繼續走應用服務器獲取，也減小了獲取數據的成本。反向代理有Squid，Nginx。

 

7、使用分佈式文件系統

用戶一每天增長，業務量愈來愈大，產生的文件愈來愈多，單臺的文件服務器已經不能知足需求。須要分佈式的文件系統支撐。經常使用的分佈式文件系統有不少，例如FastDFS、NFS。

 

8、使用NoSql和搜索引擎

對於系統產生的海量數據的查詢，咱們使用nosql數據庫加上搜索引擎能夠達到更好的性能。並非全部的數據都要放在關係型數據中。經常使用的NOSQL有mongodb和redis，搜索引擎有lucene、Sorl、ElasticSearch。

 

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

隨着業務進一步擴展，應用程序變得很是臃腫，這時咱們須要將應用程序進行業務拆分，如百度分爲用戶、商品、訂單、圖片等業務。每一個業務應用負責相對獨立的業務運做。業務之間經過消息進行通訊或者同享數據庫來實現。

 

10、搭建分佈式服務

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

 

小結：

以上10張圖是ALI的架構演變史，很是簡明的圍繞最初咱們定義的5個大型系統架構中的核心要素開展的系統升級。同時也再次印證了那句在架構圖中經久不衰的臺詞「不要試圖去設計一個大型系統架構」，由於現有的大型平臺架構都是一步步通過衆多的架構師的努力而演變而來的。試圖一口吃個胖子的架構是不可想象的，不要爲了技術而技術，不要爲了潮流而技術，適合你如今的業務須要的架構纔是最好的架構。

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

 

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

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

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