【51CTO.com原創(chuàng)稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開(kāi)。此次峰會(huì)圍繞人工智能、大數(shù)據(jù)、物聯(lián)網(wǎng)、區(qū)塊鏈等12大核心熱點(diǎn)，匯聚海內(nèi)外60位一線專家，是一場(chǎng)高端的技術(shù)盛宴，也是***IT技術(shù)人才學(xué)習(xí)和人脈拓展不容錯(cuò)過(guò)的平臺(tái)。

在“微服務(wù)架構(gòu)設(shè)計(jì)”分會(huì)場(chǎng)，58到家CTO沈劍帶來(lái)了《58速運(yùn)微服務(wù)架構(gòu)解耦***實(shí)踐》的主題分享，會(huì)后，51CTO記者根據(jù)沈劍在WOT2018全球軟件與運(yùn)維技術(shù)峰會(huì)的演講內(nèi)容進(jìn)行了整理。

【講師簡(jiǎn)介】

58沈劍，互聯(lián)網(wǎng)架構(gòu)技術(shù)專家，“架構(gòu)師之路”公眾號(hào)作者。曾任百度高級(jí)工程師，58同城高級(jí)架構(gòu)師，58同城技術(shù)委員會(huì)主席。15年調(diào)至58到家任高級(jí)總監(jiān)，技術(shù)委員會(huì)主席，負(fù)責(zé)基礎(chǔ)架構(gòu)，技術(shù)平臺(tái)，運(yùn)維安全，信息系統(tǒng)等后端技術(shù)體系搭建。17年調(diào)至58速運(yùn)任CTO，負(fù)責(zé)58速運(yùn)技術(shù)體系的搭建。

業(yè)務(wù)發(fā)展需要微服務(wù)架構(gòu)

58速運(yùn)架構(gòu)包括三層結(jié)構(gòu)和三塊業(yè)務(wù)，如下圖所示。其中，三層結(jié)構(gòu)分別是PC/H***PP等端點(diǎn)，web站點(diǎn)應(yīng)用，數(shù)據(jù)存儲(chǔ)。三塊業(yè)務(wù)分別是to C，to 2小B，to大B。

58速運(yùn)架構(gòu)

架構(gòu)誕生了，耦合也隨之而來(lái)。耦合，是架構(gòu)中，本來(lái)不相干的代碼、模塊、服務(wù)、系統(tǒng)因?yàn)槟承┰蚵?lián)系在一起，各自獨(dú)立性差，影響則相互影響，變動(dòng)則相互變動(dòng)的一種架構(gòu)狀態(tài)。業(yè)務(wù)是一塊一塊發(fā)展起來(lái)的，而代碼不是一行一行寫(xiě)出來(lái)的，重復(fù)代碼的耦合就出現(xiàn)了。隨著業(yè)務(wù)的增長(zhǎng)，數(shù)據(jù)量越來(lái)越大，復(fù)雜性擴(kuò)散的耦合導(dǎo)致了被迫聯(lián)動(dòng)升級(jí)。此外還有數(shù)據(jù)庫(kù)耦合、服務(wù)耦合等等，如何消除?微服務(wù)是一種潛在的解決方案。

詳解微服務(wù)架構(gòu)

在服務(wù)化之前，互聯(lián)網(wǎng)的高可用架構(gòu)大致是這樣一個(gè)架構(gòu)：

(1)用戶端是瀏覽器或APP客戶端。

(2)后端入口是高可用的nginx集群，用于做反向代理。

(3)中間核心是高可用的web-server集群，研發(fā)工程師主要編碼工作就是在這一層。

(4)后端存儲(chǔ)是高可用的db集群，數(shù)據(jù)存儲(chǔ)在這一層。

更典型的，web-server層是通過(guò)DAO/ORM等技術(shù)來(lái)訪問(wèn)數(shù)據(jù)庫(kù)。

由此可以看到，最初的架構(gòu)沒(méi)有服務(wù)層，此時(shí)會(huì)出現(xiàn)以下痛點(diǎn)：代碼到處拷貝;復(fù)雜性擴(kuò)散;庫(kù)的復(fù)用與耦合;SQL質(zhì)量得不到保障，業(yè)務(wù)相互影響;瘋狂的DB耦合等等。

為了解決上面的諸多問(wèn)題，互聯(lián)網(wǎng)高可用分層架構(gòu)演進(jìn)的過(guò)程中，引入了“服務(wù)層”。

引入服務(wù)層的好處主要有調(diào)用方便;高度復(fù)用性，防止代碼拷貝;專注性屏蔽了底層復(fù)雜度;SQL質(zhì)量得到了保障;數(shù)據(jù)庫(kù)很方便的解耦;提供有限接口，擁有***性能等。

“微”到什么程度才合適?

隨著數(shù)據(jù)量、流量、業(yè)務(wù)復(fù)雜度的提升，微服務(wù)化架構(gòu)是架構(gòu)演進(jìn)中的必由之路，那么，微服務(wù)架構(gòu)多“微”才合適?

【粗粒度：一個(gè)服務(wù)層】

最粗獷的玩法，所有基礎(chǔ)數(shù)據(jù)的訪問(wèn)，都通過(guò)一個(gè)service訪問(wèn)，在業(yè)務(wù)不是特別復(fù)雜的時(shí)候還好，一旦業(yè)務(wù)變復(fù)雜了，這個(gè)service層會(huì)變得非常重，成為耦合點(diǎn)之一，以微信場(chǎng)景為例，假設(shè)有一個(gè)通用的服務(wù)層來(lái)訪問(wèn)基礎(chǔ)數(shù)據(jù)，這個(gè)服務(wù)層可能是這樣的：

有一個(gè)統(tǒng)一的service層，用戶信息，好友信息，群組信息，消息信息都通過(guò)這個(gè)service層來(lái)走。

細(xì)節(jié)：微信單對(duì)單消息是一個(gè)寫(xiě)多讀少的業(yè)務(wù)，故沒(méi)有緩存。

【一個(gè)子業(yè)務(wù)一個(gè)service】

如果所有的信息存儲(chǔ)都在一個(gè)service里，那么一個(gè)地方出bug，就將影響整個(gè)業(yè)務(wù)，所以更合理的做法是在服務(wù)層進(jìn)行細(xì)分，架構(gòu)如何細(xì)分?垂直拆分是個(gè)好的方案，將子業(yè)務(wù)一個(gè)個(gè)拆出來(lái)，那么微信的服務(wù)化架構(gòu)或許會(huì)變成這個(gè)樣子：

(1)用戶相關(guān)的子業(yè)務(wù)有user-service

(2)好友相關(guān)的子業(yè)務(wù)有friend-service

(3)群組相關(guān)的子業(yè)務(wù)有g(shù)roup-service

(4)消息相關(guān)的子業(yè)務(wù)有msg-service

這樣的話，一個(gè)service出問(wèn)題也不會(huì)影響其他service，同時(shí)數(shù)據(jù)層也按照業(yè)務(wù)垂直拆分開(kāi)了。

服務(wù)粒度變細(xì)之后，出現(xiàn)一個(gè)新的問(wèn)題，業(yè)務(wù)與服務(wù)的連接關(guān)系變復(fù)雜了，有什么好的優(yōu)化方案么?

常見(jiàn)的，加入一個(gè)高可用服務(wù)分發(fā)層集群，并在協(xié)議設(shè)計(jì)時(shí)加入服務(wù)號(hào)，可以減少蜘蛛網(wǎng)狀的依賴關(guān)系：

(1)調(diào)用方依賴分發(fā)層，傳入服務(wù)號(hào)

(2)分發(fā)層依賴服務(wù)層，通過(guò)服務(wù)號(hào)參數(shù)分發(fā)

【一個(gè)數(shù)據(jù)庫(kù)對(duì)應(yīng)一個(gè)service】

數(shù)據(jù)訪問(wèn)service最初是從DAO/ORM的數(shù)據(jù)訪問(wèn)需求過(guò)來(lái)的，所以有些公司也有一個(gè)數(shù)據(jù)表一個(gè)service的玩法。

一個(gè)子業(yè)務(wù)對(duì)應(yīng)一個(gè)service的玩法是：

(1)服務(wù)層，整個(gè)群業(yè)務(wù)是一個(gè)service

(2)存儲(chǔ)層，實(shí)際可能對(duì)應(yīng)了群信息、群成員、群消息等多個(gè)數(shù)據(jù)表

拆分成一個(gè)數(shù)據(jù)表一個(gè)service，則架構(gòu)會(huì)變成這樣：

群信息表，群成員表，群消息表等各個(gè)數(shù)據(jù)表之間也解耦開(kāi)了，不會(huì)相互影響了。

【一個(gè)接口對(duì)應(yīng)一個(gè)service】

微服務(wù)架構(gòu)中更極端的，甚至一個(gè)接口對(duì)應(yīng)一個(gè)微服務(wù)，這樣的話，架構(gòu)就從：

演化為：

(1)修改群信息服務(wù)

(2)增加群信息服務(wù)

(3)獲取群信息服務(wù)

多個(gè)服務(wù)操縱同一個(gè)數(shù)據(jù)表，使用同一片緩存，每個(gè)接口出問(wèn)題，都不會(huì)影響其他接口。

粒度粗細(xì)的優(yōu)劣

上文中談到的服務(wù)化與微服務(wù)，不同粒度的服務(wù)化各有什么優(yōu)劣呢?

總的來(lái)說(shuō)，細(xì)粒度拆分的優(yōu)點(diǎn)有：

(1)服務(wù)都能夠獨(dú)立部署

(2)擴(kuò)容和縮容方便，有利于提高資源利用率

(3)拆得越細(xì)，耦合相對(duì)會(huì)減小

(4)拆得越細(xì)，容錯(cuò)相對(duì)會(huì)更好，一個(gè)服務(wù)出問(wèn)題不影響其他服務(wù)

(5)擴(kuò)展性更好

(6)…

細(xì)粒度拆分的不足也很明顯：

(1)拆得越細(xì)，系統(tǒng)越復(fù)雜

(2)系統(tǒng)之間的依賴關(guān)系也更復(fù)雜

(3)運(yùn)維復(fù)雜度提升

(4)監(jiān)控更加復(fù)雜

(5)出問(wèn)題時(shí)定位問(wèn)題更難

(6)…

總的來(lái)說(shuō)，沈劍老師對(duì)服務(wù)化以及微服務(wù)粒度的看法是，以“子業(yè)務(wù)系統(tǒng)”粒度作為微服務(wù)的單位是比較合適的：

以上內(nèi)容是51CTO記者根據(jù)58到家CTO沈劍在WOT2018全球軟件與運(yùn)維技術(shù)峰會(huì)的采訪內(nèi)容整理，更多關(guān)于WOT的內(nèi)容請(qǐng)關(guān)注51cto.com。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】