大型網站架構體系的演變（下）

    在作擴展知足了基本的性能需求後，咱們會逐漸關注「可用性」（也就是咱們一般聽別人吹牛時說的SLA、幾個9）。如何保證真正「高可用」，也是個難題。

幾乎主流的大中型互聯網公司，都會有用到相似的架構，只是節點數不一樣而已。

還 有一招用的比較多的，那就是動靜分離。能夠須要開發人員配合（把靜態資源放獨立站點下），也能夠不須要開發人員配合（利用7層反向代理來處理，根據後綴名 等信息來判斷資源類型）。有了單獨的靜態文件服務器以後，存儲也是個問題，也須要擴展。多臺服務器的文件怎麼保持一致，買不起共享存儲怎麼辦？分佈式文件 系統也派上用場了。

還有一項目前國內外用的很是廣泛的技術CDN加速。目前該領域競爭激烈，也已經比較便宜了。國內南北互聯網問題比較嚴重，使用CDN能夠有效解決這個問題。

CDN的基本原理並不複雜，能夠理解爲智能DNS+Squid反向代理緩存 ，而後須要有不少機房節點提供訪問。

截止目前爲止，都沒有怎麼去改動應用程序的架構，或者說通俗點，都不怎麼須要大面積的修改代碼。

若是上面那些手段都用光了，仍是支撐不住怎麼辦？不停的加機器也不是辦法啊？

隨着業務愈來愈複雜，網站的功能愈來愈多，雖然部署層面是採用的集羣，可是應用程序架構層面仍是「集中式」的，這樣會致使不少耦合，不便於開發、維護，並且容易「一榮俱損」。因此，一般會把網站拆分出不一樣的子站點來單獨宿主。

應用都拆了，因爲單個數據庫的鏈接，QPS，TPS，I/O處理能力都很是有限，DB層面也能夠去作垂直分庫操做

拆 分應用和DB以後，其實仍是會有不少問題。不一樣的站點，裏面可能會有相同邏輯和功能的代碼。固然，對於一些基礎的功能咱們能夠封裝DLL或者Jar包去到 處提供引用，可是這種強依賴也很容易形成一些問題（版本問題、依賴關係等處理起來很是麻煩）。這樣，傳說中的SOA的價值就獲得體現了。

應用、服務之間仍是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現了

最後，還介紹一個大型互聯網公司都用的絕技--分庫分表。我的經驗，不是業務發站和各方面很是迫切，不要輕易走這一步。

由於分庫分表誰都會幹，關鍵是拆完以後怎麼辦。目前，市面上尚未徹底開源免費的方案，能讓你一勞永逸地解決數據庫拆分問題。

      打一下純ad:歡迎你們關注微信公衆號:neihanrukou