|
互聯(lián)網(wǎng)在變,，架構(gòu)也在變。架構(gòu)的變遷亦是互聯(lián)網(wǎng)的變遷,。 何為架構(gòu),？往大了說(shuō)，宇宙有架構(gòu),，社會(huì)有架構(gòu),；往小了說(shuō)，建筑要有架構(gòu),，軟件要有架構(gòu),；說(shuō)玄乎一點(diǎn)，它由分工而來(lái),，回歸整體而去,；往實(shí)際了說(shuō)，架構(gòu)的核心就是為了解決問(wèn)題,，包括業(yè)務(wù)的問(wèn)題,、人的問(wèn)題。 立足互聯(lián)網(wǎng)行業(yè),，架構(gòu)通常指的是技術(shù)架構(gòu),，更具體一點(diǎn)的說(shuō)是系統(tǒng)架構(gòu)、軟件架構(gòu),，或者是最常見(jiàn)的網(wǎng)站架構(gòu),。 本文就來(lái)探討一下互聯(lián)網(wǎng)時(shí)代，技術(shù)架構(gòu)的演進(jìn)過(guò)程及其優(yōu)缺點(diǎn),。 為了方便表述,，我姑且把互聯(lián)網(wǎng)的架構(gòu)演進(jìn)過(guò)程分為三個(gè)時(shí)代：?jiǎn)螜C(jī)時(shí)代,、集群時(shí)代和分布式時(shí)代。三個(gè)時(shí)代并非按照時(shí)間發(fā)展順序排列,，更多的是由團(tuán)隊(duì)或產(chǎn)品所處的時(shí)期來(lái)決定,。 單機(jī)時(shí)代 互聯(lián)網(wǎng)早期，好比某個(gè)產(chǎn)品團(tuán)隊(duì)初創(chuàng)之時(shí),，資源有限,，人力不足，為了快速開(kāi)發(fā)一個(gè)產(chǎn)品,，或上線一個(gè)網(wǎng)站,，單機(jī)往往是一個(gè)不錯(cuò)的選擇。此時(shí)會(huì)將應(yīng)用程序,、文件服務(wù),、數(shù)據(jù)庫(kù)服務(wù)等資源集中在一臺(tái) Server 上。其中應(yīng)用程序通常整體打包和部署,，具體格式依賴于應(yīng)用的語(yǔ)言和框架,，例如 Java 的 WAR 文件、Rails 的目錄文件,，此種架構(gòu)通常稱為單體架構(gòu),。 單體架構(gòu) 其系統(tǒng)架構(gòu)圖往往長(zhǎng)這個(gè)樣子：
○ 優(yōu)點(diǎn)：如上文所述，簡(jiǎn)單快速,，易于開(kāi)發(fā),，易于測(cè)試，易于部署 ○ 缺點(diǎn)：也非常顯著,，只適合早期項(xiàng)目,，變大后不易維護(hù)，且存在單點(diǎn),，升級(jí)需要停服 分層架構(gòu) 明眼人會(huì)發(fā)現(xiàn),，此時(shí)的應(yīng)用程序架構(gòu)顯得雜亂無(wú)章。在早期的 Web 開(kāi)發(fā)中可能存在,，比如使用 JSP+JDBC,，ASP+ADO，這顯然不是一個(gè)友好的標(biāo)準(zhǔn)架構(gòu),，于是分層架構(gòu)應(yīng)運(yùn)而生。 分層架構(gòu)如下圖所示,，一般分為表現(xiàn)層（presentation）,、業(yè)務(wù)層（business）、持久層（persistence）和數(shù)據(jù)庫(kù)（database）,。這其實(shí)也是最常見(jiàn)的 MVC 架構(gòu),。 圖 -2: 單機(jī)時(shí)代 - 軟件架構(gòu) - 分層架構(gòu) 改造之后的系統(tǒng)架構(gòu)圖如下：
○ 優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單,，分工明確，分層測(cè)試,，如果你不知道用什么軟件架構(gòu)時(shí),，推薦用它 ○ 缺點(diǎn)：擴(kuò)展性差，迭代開(kāi)發(fā)效率低,，有時(shí)候?qū)哟芜^(guò)多導(dǎo)致流程復(fù)雜 數(shù)據(jù)分離 添加了分層架構(gòu),，應(yīng)用上好看點(diǎn)了，團(tuán)隊(duì)的開(kāi)發(fā)效率有了一定的提升,。此時(shí)業(yè)務(wù)量進(jìn)一步增大,，并且有了一定的用戶規(guī)模，逐漸發(fā)現(xiàn)一臺(tái)主機(jī)上應(yīng)用和數(shù)據(jù)資源爭(zhēng)奪的非常厲害,。因?yàn)槊糠N服務(wù)對(duì)硬件資源的要求是不同的,，應(yīng)用服務(wù)器需要更快的 CPU，文件服務(wù)器需要更大的硬盤,，數(shù)據(jù)庫(kù)服務(wù)器需要更大的內(nèi)存和硬盤,，于是決定把應(yīng)用和數(shù)據(jù)服務(wù)分離，形成了如下架構(gòu)：
○ 優(yōu)點(diǎn)：資源分散,，提高不同服務(wù)對(duì)硬件的利用率,，方便維護(hù) ○ 缺點(diǎn)：增加了資源消耗和網(wǎng)絡(luò)開(kāi)銷，同時(shí)還存在單點(diǎn) 緩存登場(chǎng) 產(chǎn)品有了一定的口碑,，用戶量持續(xù)增長(zhǎng),，訪問(wèn)開(kāi)始頻繁，想提升訪問(wèn)速度,，緩存必不可少，此時(shí)便閃亮登場(chǎng),。
服務(wù)端緩存又可以分為本地緩存和遠(yuǎn)程緩存,，各有優(yōu)劣，本地緩存訪問(wèn)速度快,，但數(shù)據(jù)量有限,，而且后續(xù)集群化不方便共享；遠(yuǎn)程緩存可以共享,，可以集群,，容量不受限制，但要注意緩存更新的問(wèn)題,。 ○ 優(yōu)點(diǎn)：簡(jiǎn)單有效,，減少對(duì) DB 的查詢 ○ 缺點(diǎn)：增加邏輯判斷,，不適合存儲(chǔ)大對(duì)象,，此架構(gòu)同樣有單點(diǎn) 讀寫分離 市場(chǎng)反響不錯(cuò),，業(yè)務(wù)也在持續(xù)增長(zhǎng)，但性能又有所下降,，分析整個(gè)架構(gòu)，發(fā)現(xiàn)數(shù)據(jù)庫(kù)讀寫非常頻繁,，甚至有些業(yè)務(wù),，讀大于寫，單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器又成了瓶頸,，此時(shí)就可以嘗試做讀寫分離和主從復(fù)制了,。
○ 優(yōu)點(diǎn)：降低數(shù)據(jù)庫(kù)單臺(tái)壓力,，從機(jī)的數(shù)量可以靈活變更 ○ 缺點(diǎn)：架構(gòu)開(kāi)始變得復(fù)雜,，維護(hù)難度加大 自此，單機(jī)時(shí)代的架構(gòu)已然成型,，“麻雀雖小五臟俱全”,，初期已經(jīng)能很好地支撐業(yè)務(wù)的運(yùn)轉(zhuǎn)。 但隨著業(yè)務(wù)的增長(zhǎng),，各個(gè)模塊還是可能出現(xiàn)瓶頸,。單機(jī)時(shí)代最大的問(wèn)題，就是整個(gè)架構(gòu)都存在單點(diǎn),，這個(gè)問(wèn)題將在集群時(shí)代一一解決,。 集群時(shí)代 單機(jī)時(shí)代，做了不少措施來(lái)緩解數(shù)據(jù)庫(kù)層的壓力,，包括服務(wù)器分離,、引入緩存、數(shù)據(jù)分離等,，但隨著訪問(wèn)量的猛增,，對(duì)高可用的要求越來(lái)越高，減輕應(yīng)用層壓力,、解決單點(diǎn)問(wèn)題成了當(dāng)務(wù)之急,，這就是集群時(shí)代需要做的事情。 負(fù)載均衡 代碼是架構(gòu)的基礎(chǔ),，但前期改造代碼的工作量較大,，如果人員變動(dòng)頻繁，那風(fēng)險(xiǎn)就更高了，所以提高服務(wù)器性能,，常用的手段還是先將應(yīng)用集群化，做負(fù)載均衡,。
○ 優(yōu)點(diǎn)：去除應(yīng)用層單點(diǎn),，可用性得到保證，性能有所提高 ○ 缺點(diǎn)：這時(shí)要注意應(yīng)用之間的一致性問(wèn)題,，比如對(duì)緩存的訪問(wèn),，對(duì) Session 的存儲(chǔ) 動(dòng)靜分離 希望進(jìn)一步降低應(yīng)用服務(wù)器的壓力，可以采用動(dòng)靜分離技術(shù),。 動(dòng)靜分離是讓動(dòng)態(tài)網(wǎng)站里的動(dòng)態(tài)網(wǎng)頁(yè),，根據(jù)一定規(guī)則把不變的資源和經(jīng)常變的資源區(qū)分開(kāi)來(lái)，動(dòng)靜資源做好拆分以后,，我們還可以根據(jù)靜態(tài)資源的特點(diǎn)將其做緩存操作,，以加快響應(yīng)速度。 在網(wǎng)易杭研,，常用做法還會(huì)將前后端分離,，后端應(yīng)用提供 API，根據(jù)前端的請(qǐng)求進(jìn)行處理,，并將處理結(jié)果通過(guò) JSON 格式返回至前端,。
○ 優(yōu)點(diǎn)：減輕應(yīng)用服務(wù)器壓力，緩存靜態(tài)文件,，加快響應(yīng)速度,，前后端分離，開(kāi)發(fā)可以并行,。 ○ 缺點(diǎn)：靜態(tài)文件緩存更新失效問(wèn)題,，前后端溝通成本提高 CDN 加速 內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network），簡(jiǎn)稱 CDN）,，可以進(jìn)一步加快網(wǎng)站響應(yīng),。其原理是將源內(nèi)容同步到全國(guó)各邊緣節(jié)點(diǎn)，配合精準(zhǔn)的調(diào)度系統(tǒng),，將用戶請(qǐng)求分配至最適合他的節(jié)點(diǎn),，使用戶可以以最快的速度取得所需內(nèi)容。
○ 優(yōu)點(diǎn)：解決網(wǎng)絡(luò)帶寬小,、用戶訪問(wèn)量大,、網(wǎng)點(diǎn)分布不均等問(wèn)題，提高用戶訪問(wèn)的響應(yīng)速度,，減輕應(yīng)用負(fù)載壓力,。 ○ 缺點(diǎn)：顯然成本上去了，CDN 服務(wù)一般是按流量計(jì)費(fèi)，同時(shí)也存在靜態(tài)文件緩存更新失效問(wèn)題,。 冗余集群 以上一個(gè)中型網(wǎng)站架構(gòu)基本成型,。當(dāng)中型網(wǎng)站繼續(xù)向大型網(wǎng)站演進(jìn)，最終的目標(biāo)是要保證“三高”：高并發(fā),、高性能,、高可用。 以上架構(gòu)基本可以滿足性能需求,，接下來(lái)更多地是關(guān)注“高可用”,，確保“無(wú)單點(diǎn)”,。 此時(shí),，就要對(duì)關(guān)鍵的服務(wù)，做冗余集群負(fù)載,。 理想情況下,，我們將以下服務(wù) / 應(yīng)用都集群化：
○ 優(yōu)點(diǎn)：去單點(diǎn)，高可用 ○ 缺點(diǎn)：數(shù)據(jù)有狀態(tài)問(wèn)題,、數(shù)據(jù)一致性問(wèn)題,，資源成本、人力維護(hù)成本都上去了 到此為止,，一個(gè)大型網(wǎng)站的架構(gòu)也基本成型了,。能“加機(jī)器”的地方都加完了，是不是就終結(jié)了,？當(dāng)然不是,！伴隨著 DT/ 分布式 時(shí)代的到來(lái)，大流量和大數(shù)據(jù)的場(chǎng)景的出現(xiàn),，對(duì)應(yīng)用提出了更高的要求,，接下來(lái)就需要對(duì)應(yīng)用程序開(kāi)刀了。 分布式時(shí)代 應(yīng)用拆分 在前面,，我們只是把應(yīng)用程序做了分層架構(gòu),，在創(chuàng)業(yè)初期或產(chǎn)品前期還是一個(gè)不錯(cuò)的選擇。雖然應(yīng)用也做了集群和負(fù)載均衡,，但應(yīng)用架構(gòu)層面還是“集中式”的,。隨著業(yè)務(wù)越來(lái)越復(fù)雜，網(wǎng)站的功能越來(lái)越多,，應(yīng)用拆分勢(shì)在必行了,。 ○ 優(yōu)點(diǎn)：應(yīng)用解耦，分拆團(tuán)隊(duì)負(fù)責(zé),，分而治之 ○ 缺點(diǎn)：架構(gòu)變復(fù)雜 應(yīng)用拆分之后,，還伴隨著一個(gè)相互依賴,、公共模塊的問(wèn)題，特別是依賴于相同的邏輯或功能代碼,。這時(shí)就可以考慮將這些共用的服務(wù)提取出來(lái),，獨(dú)立部署，統(tǒng)一治理,，提高重用度,，這就是面向服務(wù)的架構(gòu)（service-oriented architecture，縮寫 SOA）了,。 消息隊(duì)列 應(yīng)用拆分、服務(wù)獨(dú)立部署之后,，還是會(huì)出現(xiàn)一些通信或依賴問(wèn)題,，這時(shí)就可以引入消息隊(duì)列，提高吞吐量,。 ○ 優(yōu)點(diǎn)：異步,、解耦，提高吞吐量 ○ 缺點(diǎn)：消息消費(fèi)延遲等問(wèn)題 數(shù)據(jù)分庫(kù) 應(yīng)用拆分之后,，DB 分庫(kù)理所當(dāng)然,，否則多個(gè)應(yīng)用連接在單個(gè)數(shù)據(jù)庫(kù)上，連接數(shù),、QPS,、TPS、I/O 處理能力都非常有限,。 ○ 優(yōu)點(diǎn)：DB 分壓,，降低耦合 ○ 缺點(diǎn)：數(shù)據(jù)訪問(wèn)模塊冗余、復(fù)雜 提到分庫(kù),，不少人會(huì)想到分表,，這一塊我并未實(shí)踐過(guò)，不好下筆,。但想來(lái)會(huì)引入更復(fù)雜的數(shù)據(jù)架構(gòu)和數(shù)據(jù)一致性問(wèn)題,，而且市面上成熟開(kāi)源的分庫(kù)分表方案并沒(méi)有，保不準(zhǔn)又是一個(gè)深坑,。拆或不拆,，也是一個(gè)值得思考的問(wèn)題。 微服務(wù)架構(gòu) 微服務(wù)架構(gòu)（microservices architecture）一度成為熱點(diǎn),，在文章,、博客、大會(huì)演講上經(jīng)常被提及,。 微服務(wù)并不是憑空出現(xiàn),，有人說(shuō)，它是面向服務(wù)架構(gòu)（SOA）的升級(jí)，在此之前,，還有諸如集中式架構(gòu),、分布式的架構(gòu)等。這里借用一副抽象的圖來(lái)描述下常見(jiàn)的幾種架構(gòu)：
圖 -11: 分布式時(shí)代 - 微服務(wù)架構(gòu) - 抽象對(duì)比 微服務(wù)架構(gòu)由多個(gè)微小服務(wù)構(gòu)成,，每個(gè)服務(wù)就是一個(gè)獨(dú)立的可部署單元或組件,，它們是分布式的，相互解耦的,，通過(guò)輕量級(jí)遠(yuǎn)程通信協(xié)議（比如 REST）來(lái)交互,。每個(gè)服務(wù)可以使用不同的數(shù)據(jù)庫(kù)，而且是語(yǔ)言無(wú)關(guān)性的,。它的特征是彼此獨(dú)立,、微小、輕量,、松耦合,，又能方便地組合和重構(gòu)，猶如《超能陸戰(zhàn)隊(duì)》中的微型機(jī)器人,，個(gè)體簡(jiǎn)單,，但組合起來(lái)威力強(qiáng)大。
圖 -12: 分布式時(shí)代 - 微服務(wù)架構(gòu) ○ 優(yōu)點(diǎn)：擴(kuò)展性好,，服務(wù)之間耦合性低,，服務(wù)間相互獨(dú)立，容易部署,，易于開(kāi)發(fā),，方便測(cè)試每一個(gè)服務(wù) ○ 缺點(diǎn)：容易過(guò)度關(guān)注服務(wù)的大小，可能拆分地很細(xì),，導(dǎo)致系統(tǒng)依賴于大量的微服務(wù),，而服務(wù)之間的相互通信也會(huì)變得復(fù)雜，系統(tǒng)集成復(fù)雜度增加,，很難實(shí)現(xiàn)原子性操作 微服務(wù)之所以這么火,，另一個(gè)原因是因?yàn)?Docker 的出現(xiàn)，它讓微服務(wù)有一個(gè)非常完美的運(yùn)行環(huán)境,。Docker 的獨(dú)立性和細(xì)粒度非常匹配微服務(wù)的理念,，Docker 的優(yōu)秀性能和豐富的管理工具，讓大家對(duì)微服務(wù)有了一定的信心,，概括來(lái)說(shuō) Docker 有如下四點(diǎn)適合微服務(wù)：
當(dāng)然，好的架構(gòu)和技術(shù)要應(yīng)用于實(shí)踐,，需要用戶認(rèn)可才行,，這就需要在微服務(wù)架構(gòu)和 Docker 技術(shù)上有豐富的場(chǎng)景化應(yīng)用。網(wǎng)易蜂巢也在積極探索微服務(wù)架構(gòu)和容器云平臺(tái)的場(chǎng)景化服務(wù),，歡迎一起來(lái)實(shí)踐落地,。 至此，架構(gòu)變遷的三個(gè)時(shí)代介紹完成,?？偟膩?lái)說(shuō)架構(gòu)不是一成不變的，時(shí)間不停,，進(jìn)步不止，人如此,，架構(gòu)依然,。 |
|
|
來(lái)自： 萬(wàn)皇之皇 > 《IT互聯(lián)》
