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

原文出處： 丁碼農的博客  

在做擴展滿足了基本的性能需求后，我們會逐漸關注“可用性”（也就是我們通常聽別人吹牛時說的SLA、幾個9）。如何保證真正“高可用”，也是個難題。

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

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

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

CDN的基本原理并不復雜，可以理解為智能DNS+Squid反向代理緩存 ，然后需要有很多機房節點提供訪問。

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

如果上面那些手段都用光了，還是支撐不住怎么辦？不停的加機器也不是辦法啊？

隨著業務越來越復雜，網站的功能越來越多，雖然部署層面是采用的集群，但是應用程序架構層面還是“集中式”的，這樣會導致很多耦合，不便于開發、維護，而且容易“一榮俱損”。所以，通常會把網站拆分出不同的子站點來單獨宿主。

應用都拆了，由于單個數據庫的連接，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作

拆分應用和DB之后，其實還是會有很多問題。不同的站點，里面可能會有相同邏輯和功能的代碼。當然，對于一些基礎的功能我們可以封裝DLL或者 Jar包去到處提供引用，但是這種強依賴也很容易造成一些問題（版本問題、依賴關系等處理起來非常麻煩）。這樣，傳說中的SOA的價值就得到體現了。

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

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

因為分庫分表誰都會干，關鍵是拆完之后怎么辦。目前，市面上還沒有完全開源免費的方案，能讓你一勞永逸地解決數據庫拆分問題。