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