在做擴展滿(mǎn)足了基本的性能需求后，我們會(huì )逐漸關(guān)注“可用性”（也就是我們通常聽(tīng)別人吹牛時(shí)說(shuō)的SLA、幾個(gè)9）。如何保證真正“高可用”，也是個(gè)難題。
幾乎主流的大中型互聯(lián)網(wǎng)公司，都會(huì )有用到類(lèi)似的架構，只是節點(diǎn)數不同而已。
還有一招用的比較多的，那就是動(dòng)靜分離?？梢孕枰_(kāi)發(fā)人員配合（把靜態(tài)資源放獨立站點(diǎn)下），也可以不需要開(kāi)發(fā)人員配合（利用7層反向代理來(lái)處理，根據后綴名等信息來(lái)判斷資源類(lèi)型）。有了單獨的靜態(tài)文件服務(wù)器之后，存儲也是個(gè)問(wèn)題，也需要擴展。多臺服務(wù)器的文件怎么保持一致，買(mǎi)不起共享存儲怎么辦？分布式文件系統也派上用場(chǎng)了。
還有一項目前國內外用的非常普遍的技術(shù)CDN加速。目前該領(lǐng)域競爭激烈，也已經(jīng)比較便宜了。國內南北互聯(lián)網(wǎng)問(wèn)題比較嚴重，使用CDN可以有效解決這個(gè)問(wèn)題。
CDN的基本原理并不復雜，可以理解為智能DNS+Squid反向代理緩存 ，然后需要有很多機房節點(diǎn)提供訪(fǎng)問(wèn)。
截止目前為止，都沒(méi)有怎么去改動(dòng)應用程序的架構，或者說(shuō)通俗點(diǎn)，都不怎么需要大面積的修改代碼。
如果上面那些手段都用光了，還是支撐不住怎么辦？不停的加機器也不是辦法??？
隨著(zhù)業(yè)務(wù)越來(lái)越復雜，網(wǎng)站的功能越來(lái)越多，雖然部署層面是采用的集群，但是應用程序架構層面還是“集中式”的，這樣會(huì )導致很多耦合，不便于開(kāi)發(fā)、維護，而且容易“一榮俱損”。所以，通常會(huì )把網(wǎng)站拆分出不同的子站點(diǎn)來(lái)單獨宿主。
應用都拆了，由于單個(gè)數據庫的連接，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作
拆分應用和DB之后，其實(shí)還是會(huì )有很多問(wèn)題。不同的站點(diǎn)，里面可能會(huì )有相同邏輯和功能的代碼。當然，對于一些基礎的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強依賴(lài)也很容易造成一些問(wèn)題（版本問(wèn)題、依賴(lài)關(guān)系等處理起來(lái)非常麻煩）。這樣，傳說(shuō)中的SOA的價(jià)值就得到體現了。
應用、服務(wù)之間還是會(huì )出現一些依賴(lài)問(wèn)題，這時(shí)候，高吞吐量的解耦利器出現了
最后，還介紹一個(gè)大型互聯(lián)網(wǎng)公司都用的絕技–分庫分表。個(gè)人經(jīng)驗，不是業(yè)務(wù)發(fā)站和各方面非常迫切，不要輕易走這一步。
因為分庫分表誰(shuí)都會(huì )干，關(guān)鍵是拆完之后怎么辦。目前，市面上還沒(méi)有完全開(kāi)源免費的方案，能讓你一勞永逸地解決數據庫拆分問(wèn)題。
聯(lián)系客服
