Web應(yīng)用架構(gòu)受系統(tǒng)用戶(hù)量、開(kāi)發(fā)人員組織方式影響嚴(yán)重。過(guò)去二十年互聯(lián)網(wǎng)迅速發(fā)展，Web架構(gòu)也從單體式演進(jìn)出微服務(wù)，背后還有比如 Martin Fowler 提出的理論支撐。雖然每個(gè)人都聽(tīng)說(shuō)過(guò)微服務(wù)，但是很多人并不太清楚為什么要這么做，應(yīng)該怎么做，怎么拆。要回答這個(gè)問(wèn)題我認(rèn)為需要從Web架構(gòu)的演化歷史的高度去理解這些架構(gòu)設(shè)計(jì)中的取舍。
首先我們改進(jìn)系統(tǒng)架構(gòu)的目的是為了滿(mǎn)足系統(tǒng)可靠性、并發(fā)量以及快速開(kāi)發(fā)的需求。所有的改進(jìn)方案都是為了解決這其中一個(gè)或多個(gè)問(wèn)題而產(chǎn)生的。
單體結(jié)構(gòu)
單體結(jié)構(gòu)
最開(kāi)始Web服務(wù)器、數(shù)據(jù)庫(kù)全部部署在同一臺(tái)服務(wù)器上，這也是最簡(jiǎn)單的應(yīng)用架構(gòu)，通常公司早期項(xiàng)目都采用這種方式。在很長(zhǎng)一段時(shí)間里單體結(jié)構(gòu)可以滿(mǎn)足系統(tǒng)快速開(kāi)發(fā)與并發(fā)量的需求。當(dāng)用戶(hù)量越來(lái)越大，通常會(huì)數(shù)據(jù)庫(kù)性能會(huì)成為系統(tǒng)瓶頸，此時(shí)可以將Web業(yè)務(wù)與數(shù)據(jù)庫(kù)部署在不同服務(wù)器上，增強(qiáng)數(shù)據(jù)庫(kù)服務(wù)器的配置并做讀寫(xiě)分離等提高系統(tǒng)的吞吐量與可用性。
與此同時(shí)也可以將業(yè)務(wù)系統(tǒng)等價(jià)部署在多臺(tái)服務(wù)器上來(lái)提高系統(tǒng)吞吐量，但整體上這仍然是一個(gè)單體應(yīng)用。
單體等價(jià)部署
隨著用戶(hù)、數(shù)據(jù)量進(jìn)一步增大，單體應(yīng)用的缺點(diǎn)會(huì)進(jìn)一步顯露出來(lái)，比如：
- 耦合嚴(yán)重、復(fù)雜度高、可靠性差 ：?jiǎn)误w應(yīng)用越來(lái)越來(lái)很多業(yè)務(wù)會(huì)耦合在一起，一但某些模塊出現(xiàn)Bug會(huì)影響整個(gè)系統(tǒng)正常運(yùn)行，業(yè)務(wù)代碼的耦合也會(huì)形成開(kāi)發(fā)人員的依賴(lài)造成新業(yè)務(wù)難以推進(jìn)
- 增加技術(shù)債、部署困難效率差 ：技術(shù)債越來(lái)越多容易會(huì)造成“不壞不修“的囧境，已完成的代碼難以被修改以防止系統(tǒng)某個(gè)地方意料之外的調(diào)用。同于由于代碼量大導(dǎo)致應(yīng)用全量部署困難
- 系統(tǒng)吞吐量受限、阻礙技術(shù)進(jìn)步 ：?jiǎn)误w應(yīng)用難以進(jìn)一步擴(kuò)展使系統(tǒng)吞吐量受限，同時(shí)單體應(yīng)用要求使用統(tǒng)一技術(shù)平臺(tái)或解決方案，要想引入新語(yǔ)言或框架會(huì)非常困難
拆分
應(yīng)用規(guī)模越來(lái)越大，首先遇到瓶頸的可能就是數(shù)據(jù)庫(kù)系統(tǒng)，面對(duì)數(shù)據(jù)庫(kù)壓力通常我們可以對(duì)數(shù)據(jù)庫(kù)做拆分把負(fù)載分擔(dān)到不同的服務(wù)器上來(lái)解決，通常數(shù)據(jù)庫(kù)拆分有兩種方案：
- 垂直拆分：對(duì)不同的業(yè)務(wù)系統(tǒng)如賬戶(hù)、搜索、推薦系統(tǒng)使用不同的數(shù)據(jù)庫(kù)
- 水平拆分：對(duì)于大表，比如十億百億級(jí)別的，進(jìn)行多表拆分
數(shù)據(jù)庫(kù)水平拆分與業(yè)務(wù)邏輯耦合緊密，需要具體問(wèn)題具體分析，通常這是一個(gè)非常復(fù)雜的問(wèn)題。后來(lái)人們引入 NoSQL、NewSQL 用分布式概念在數(shù)據(jù)庫(kù)層屏蔽掉數(shù)據(jù)庫(kù)的水平拆分，比如 NoSQL 的 MongoDB Sharding，NewSQL 的 TiDB。
同樣的在業(yè)務(wù)層上我們也可以通過(guò)垂直拆分和水平拆分將單體業(yè)務(wù)拆成不同的服務(wù)，服務(wù)之間通過(guò)約定好的協(xié)議通信，以提高人員開(kāi)發(fā)效率，實(shí)現(xiàn)多機(jī)部署冗余部署來(lái)提高系統(tǒng)可用性與吞吐量。
微服務(wù)
我們都知道微服務(wù)是一種提倡將單一服務(wù)拆分成一組小服務(wù)、服務(wù)之間相互協(xié)調(diào)、配合，提高開(kāi)發(fā)效率，最終為用戶(hù)提供價(jià)值的思路。說(shuō)到微服務(wù)那么這里面最重要的一個(gè)問(wèn)題就是服務(wù)應(yīng)該怎么拆。微服務(wù)作為 SOA（Service Oriented Architecture）思想的一種具體實(shí)踐我們首先想到的就是按照不同的業(yè)務(wù)系統(tǒng)做垂直拆分，如下圖所示：
SOA垂直拆分
按業(yè)務(wù)系統(tǒng)對(duì)單體應(yīng)用做垂直拆分，不同的業(yè)務(wù)線(xiàn)完全可以獨(dú)立配備產(chǎn)品經(jīng)歷與工程師同步開(kāi)發(fā)維護(hù)，將不同業(yè)務(wù)線(xiàn)解耦出來(lái)有不同團(tuán)隊(duì)維護(hù)。但上圖是一種理想情況，各系統(tǒng)拆分力度比較大，系統(tǒng)之間不需要更詳細(xì)的通信。如果是被拆除出了的子系統(tǒng)之間有大量的數(shù)據(jù)交互與調(diào)用，網(wǎng)關(guān)模式便不是一種很好的實(shí)踐，通常會(huì)將各業(yè)務(wù)子系統(tǒng)接入一個(gè)數(shù)據(jù)總線(xiàn)用 ESB（Enterprise Service Bus）模式來(lái)進(jìn)行數(shù)據(jù)交互，各子系統(tǒng)與數(shù)據(jù)總線(xiàn)進(jìn)行數(shù)據(jù)交換便需要對(duì)子系統(tǒng)做統(tǒng)一管理，這遍有了 服務(wù)治理 的概念，用一套統(tǒng)一的保準(zhǔn)來(lái)處理各子系統(tǒng)的注冊(cè)、權(quán)限、監(jiān)控等，目前有很多 ESB 開(kāi)源或閉源的解決方案，這里不再贅述。
垂直拆分將各業(yè)務(wù)子系統(tǒng)解耦出來(lái)，但是每次請(qǐng)求在不同階段遇到的瓶頸與負(fù)載是不一樣的，因此我們對(duì)可以使用水平拆分的思路對(duì)服務(wù)進(jìn)行拆分：
水平拆分
首先用戶(hù)請(qǐng)求通過(guò)http協(xié)議到達(dá)網(wǎng)關(guān)，網(wǎng)關(guān)將json數(shù)據(jù)格式轉(zhuǎn)為protobuf，通過(guò)tcp長(zhǎng)鏈接與服務(wù)層、數(shù)據(jù)層通信獲取目標(biāo)數(shù)據(jù)然后返回給用戶(hù)。這樣拆分加長(zhǎng)了用戶(hù)請(qǐng)求鏈路時(shí)延，但是如果服務(wù)全部部署在同一內(nèi)網(wǎng)，而且使用protobuf格式通信那么這個(gè)時(shí)延在幾十毫秒內(nèi)是完全可以接受的。業(yè)務(wù)層與數(shù)據(jù)層完全解耦便可以輕松將不同類(lèi)型的服務(wù)進(jìn)入冗余部署，同時(shí)在不動(dòng)業(yè)務(wù)層的同時(shí)修改它的數(shù)據(jù)存儲(chǔ)方式。
如果我們對(duì)系統(tǒng)即做垂直拆分也做水分拆分，那么就有了微服務(wù)的樣子,
水平拆分
每級(jí)服務(wù)只能調(diào)用比他低級(jí)別的服務(wù)，如果搜索服務(wù)層只能掉賬戶(hù)接口層服務(wù)而不能調(diào)賬戶(hù)服務(wù)層接口，這樣可以用來(lái)避免服務(wù)A調(diào)用服務(wù)B，而服務(wù)B同時(shí)又調(diào)用了服務(wù)A的循環(huán)調(diào)用問(wèn)題。但是這樣的拆分粒度仍然不夠的，比如搜索系統(tǒng)和推薦系統(tǒng)都要調(diào)用賬戶(hù)系統(tǒng)的一些基礎(chǔ)查詢(xún)、修改邏輯，那么需要在搜索與推薦的服務(wù)層兩次實(shí)現(xiàn)同樣的代碼嗎，這樣顯然是不合理了，任何不能復(fù)用的設(shè)計(jì)顯然都是有問(wèn)題的。如果通過(guò)編寫(xiě)SDK庫(kù)提供Jar包的模式去實(shí)現(xiàn)這個(gè)功能呢？，顯然也存在問(wèn)題比如推薦系統(tǒng)是Python實(shí)現(xiàn)，而搜索系統(tǒng)是JAVA實(shí)現(xiàn)的呢？所以這里我們將每個(gè)子系統(tǒng)可共用代碼部分也單獨(dú)抽取出來(lái)作為一個(gè)服務(wù)。
水平拆分2
這樣拆分后的系統(tǒng)可以靈活部署，獨(dú)立開(kāi)發(fā)，并且各模塊服務(wù)使用的技術(shù)棧相對(duì)獨(dú)立不受限制。但是同時(shí)拆分也將系統(tǒng)的網(wǎng)絡(luò)拓?fù)浔愕膹?fù)雜，運(yùn)維負(fù)擔(dān)加重，服務(wù)間的依賴(lài)使得服務(wù)接口的調(diào)整成本非常高。服務(wù)增多的同時(shí)對(duì)服務(wù)治理的要求也更高，需要專(zhuān)門(mén)做服務(wù)的發(fā)現(xiàn)、注冊(cè)、鑒權(quán)、監(jiān)控等系統(tǒng)功能。
