這篇文章本來準備前幾天就得寫的，誰也沒想到這段時間公司的RC太多了，含酸苦逼的加班，加班。。。所以在大一點的公司上班，
寫程式碼的責任心一定要強，或許就因為你的一些小bug，給公司帶來不少損失。。。這在以前公司真的沒多大體會的。
好了，繼續說說架構的演變，從第四代架構中可以看到，我們通過做應用程式層的負載均衡可以比較完美的解決了在整個架構中讓應
用程式層不再成為瓶頸，通過A10，我們可以讓使用者的訪問請求分發到叢集中的任何一臺伺服器上，當訪問量繼續膨脹的時候，我們就可
以繼續在叢集中增加伺服器來解決負載的壓力，達到系統的可伸縮性，現在我們的業務規模像滾雪球一樣越來越大，使用者數暴增。。。這
時候我們快取中的資料也越來越多，雖然我們用了快取，但是大量的“快取過期重新讀取”和“快取不命中",導致資料庫壓力非常大，這時候
資料庫的壓力成為了我們架構中的瓶頸。
五： 第五代架構
既然資料庫成為了我們第四代架構的瓶頸，這時候必須解決資料庫的壓力問題，最常見的做法也就是“讀寫分離”，將寫和讀的庫進行拆
分來緩解資料庫的壓力。
現在我們做了多個庫，寫的時候進主庫，然後資料庫分發到從庫中，然後應用程式在從庫中讀取，這裡為了讓資料庫對應用程式更加
透明，我們通常加一個“資料訪問層”，在攜程裡面就是在企業庫上進行了一層封裝以及安全性採用了all in one 模式，可以看到第五代
架構對資料庫的壓力有了很大的緩解。
經過幾個月業務噴井式的發展之後，我們會發現資料庫檢索越來越慢，單表資料量已經差不多爆炸了。。。已經嚴重影響到系統效能，
使用者抱怨不斷，這時候“資料檢索”成為了我們系統的嚴重瓶頸。
六：第六代架構
既然檢索成了瓶頸，我們必須對資料庫進行拆分，儘可能的減少檢索中的資料量規模以及儘可能的優化演算法。
1：業務分庫
我們將不同的業務分攤到不同的業務伺服器上，而不是將其耦合在一個資料庫裡面，從而建立起資料庫叢集，分流應用層對數
據庫的壓力。
2：分表
可以採用時間劃分，將三個月之後的資料放入到歷史表裡面，當前表只儲存三個月之內的資料，而從極大提供單表的檢索能力。
3：採用nosql
nosql就是為了web而生，分詞，系統日誌等等，一樣都讓不少nosql，而且nosql有其天生的負載均衡。
4：優化演算法
棧，佇列，二叉樹，雜湊 等等變換和非變換的資料結構在這種大資料的場景下可以得到靈活運用，這也是區分高階程式設計師和低等
碼農的一條參考標準。
當你的架構到這個程度的時候，差不到公司的人數也過千了，這時候我們的業務會分成很多產品線的，比如：機票事業部，酒店
事業部，旅遊度假事業部，攻略社群事業部，每個事業部只會負責自己的產品架構，從而將我們的架構再次細分，從技術角度看，這些
事業部又可以提煉出公共的部門，比如登入模組，訂單處理等等這些可複用的模組，可以相應的成立公共平臺事業部和框架架構部，當
這個架構繼續往下發展的話，就有了現在的各種雲，也就成了各種變錢的工具了，就比如現在的部落格園託管在阿里雲之上。。。
終於在今天，結束了高層重視的IVR專案的所有事情，最後祭奠一下，自從豬豬俠拿到那些所謂的資料，導致我們連續加班的日日夜夜。