我也要談談大型網站架構之系列（2）——縱觀歷史演變（下）

我也要談談大型網站架構之系列（2）——縱觀歷史演變（下）

 

　　這篇文章原本準備前幾天就得寫的，誰也沒想到這段時間公司的RC太多了，含酸苦逼的加班，加班。。。因此在大一點的公司上班，

寫代碼的責任心必定要強，或許就由於你的一些小bug，給公司帶來很多損失。。。這在之前公司真的沒多大致會的。

　　好了，繼續說說架構的演變，從第四代架構中能夠看到，咱們經過作應用程序層的負載均衡能夠比較完美的解決了在整個架構中讓應

用程序層再也不成爲瓶頸，經過A10，咱們可讓用戶的訪問請求分發到集羣中的任何一臺服務器上，當訪問量繼續膨脹的時候，咱們就可

以繼續在集羣中增長服務器來解決負載的壓力，達到系統的可伸縮性，如今咱們的業務規模像滾雪球同樣愈來愈大，用戶數暴增。。。這

時候咱們緩存中的數據也愈來愈多，雖然咱們用了緩存，可是大量的「緩存過時從新讀取」和「緩存不命中",致使數據庫壓力很是大，這時候

數據庫的壓力成爲了咱們架構中的瓶頸。

 

五： 第五代架構

　　 既然數據庫成爲了咱們第四代架構的瓶頸，這時候必須解決數據庫的壓力問題，最多見的作法也就是「讀寫分離」，將寫和讀的庫進行拆

分來緩解數據庫的壓力。

　　

如今咱們作了多個庫，寫的時候進主庫，而後數據庫分發到從庫中，而後應用程序在從庫中讀取，這裏爲了讓數據庫對應用程序更加

透明，咱們一般加一個「數據訪問層」，在攜程裏面就是在企業庫上進行了一層封裝以及安全性採用了all in one 模式，能夠看到第五代

架構對數據庫的壓力有了很大的緩解。

   通過幾個月業務噴井式的發展以後，咱們會發現數據庫檢索愈來愈慢，單表數據量已經差很少爆炸了。。。已經嚴重影響到系統性能，

用戶抱怨不斷，這時候「數據檢索」成爲了咱們系統的嚴重瓶頸。

 

六：第六代架構

  既然檢索成了瓶頸，咱們必須對數據庫進行拆分，儘量的減小檢索中的數據量規模以及儘量的優化算法。

  1：業務分庫

      咱們將不一樣的業務分攤到不一樣的業務服務器上，而不是將其耦合在一個數據庫裏面，從而創建起數據庫集羣，分流應用層對數

　　據庫的壓力。

  2：分表

　　能夠採用時間劃分，將三個月以後的數據放入到歷史表裏面，當前表只保存三個月以內的數據，而從極大提供單表的檢索能力。

  3：採用nosql

 　  nosql就是爲了web而生，分詞，系統日誌等等，同樣都讓很多nosql，並且nosql有其天生的負載均衡。

  4：優化算法

　    棧，隊列，二叉樹，哈希 等等變換和非變換的數據結構在這種大數據的場景下能夠獲得靈活運用，這也是區分高級程序員和低等

　　 碼農的一條參考標準。

      當你的架構到這個程度的時候，差不到公司的人數也過千了，這時候咱們的業務會分紅不少產品線的，好比：票事業部，酒店

事業部，旅遊度假事業部，攻略社區事業部，每一個事業部只會負責本身的產品架構，從而將咱們的架構再次細分，從技術角度看，這些

事業部又能夠提煉出公共的部門，好比登陸模塊，訂單處理等等這些可複用的模塊，能夠相應的成立公共平臺事業部和框架架構部，當

這個架構繼續往下發展的話，就有了如今的各類雲，也就成了各類變錢的工具了，就好比如今的博客園託管在阿里雲之上。。。

 

     終於在今天，結束了高層重視的IVR項目的全部事情，最後祭奠一下，自從豬豬俠拿到那些所謂的數據，致使咱們連續加班的日日夜夜。