在做擴展滿(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)系客服