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

在“微服務架構設計”分會場，58到家CTO沈劍帶來了《58速運微服務架構解耦***實踐》的主題分享，會后，51CTO記者根據沈劍在WOT2018全球軟件與運維技術峰會的演講內容進行了整理。

【講師簡介】

58沈劍，互聯(lián)網架構技術專家，“架構師之路”公眾號作者。曾任百度高級工程師，58同城高級架構師，58同城技術委員會主席。15年調至58到家任高級總監(jiān)，技術委員會主席，負責基礎架構，技術平臺，運維安全，信息系統(tǒng)等后端技術體系搭建。17年調至58速運任CTO，負責58速運技術體系的搭建。

業(yè)務發(fā)展需要微服務架構

58速運架構包括三層結構和三塊業(yè)務，如下圖所示。其中，三層結構分別是PC/H***PP等端點，web站點應用，數據存儲。三塊業(yè)務分別是to C，to 2小B，to大B。

58速運架構

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

詳解微服務架構

在服務化之前，互聯(lián)網的高可用架構大致是這樣一個架構：

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

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

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

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

更典型的，web-server層是通過DAO/ORM等技術來訪問數據庫。

由此可以看到，最初的架構沒有服務層，此時會出現以下痛點：代碼到處拷貝;復雜性擴散;庫的復用與耦合;SQL質量得不到保障，業(yè)務相互影響;瘋狂的DB耦合等等。

為了解決上面的諸多問題，互聯(lián)網高可用分層架構演進的過程中，引入了“服務層”。

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

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

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

【粗粒度：一個服務層】

最粗獷的玩法，所有基礎數據的訪問，都通過一個service訪問，在業(yè)務不是特別復雜的時候還好，一旦業(yè)務變復雜了，這個service層會變得非常重，成為耦合點之一，以微信場景為例，假設有一個通用的服務層來訪問基礎數據，這個服務層可能是這樣的：

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

細節(jié)：微信單對單消息是一個寫多讀少的業(yè)務，故沒有緩存。

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

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

(1)用戶相關的子業(yè)務有user-service

(2)好友相關的子業(yè)務有friend-service

(3)群組相關的子業(yè)務有group-service

(4)消息相關的子業(yè)務有msg-service

這樣的話，一個service出問題也不會影響其他service，同時數據層也按照業(yè)務垂直拆分開了。

服務粒度變細之后，出現一個新的問題，業(yè)務與服務的連接關系變復雜了，有什么好的優(yōu)化方案么?

常見的，加入一個高可用服務分發(fā)層集群，并在協(xié)議設計時加入服務號，可以減少蜘蛛網狀的依賴關系：

(1)調用方依賴分發(fā)層，傳入服務號

(2)分發(fā)層依賴服務層，通過服務號參數分發(fā)

【一個數據庫對應一個service】

數據訪問service最初是從DAO/ORM的數據訪問需求過來的，所以有些公司也有一個數據表一個service的玩法。

一個子業(yè)務對應一個service的玩法是：

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

(2)存儲層，實際可能對應了群信息、群成員、群消息等多個數據表

拆分成一個數據表一個service，則架構會變成這樣：

群信息表，群成員表，群消息表等各個數據表之間也解耦開了，不會相互影響了。

【一個接口對應一個service】

微服務架構中更極端的，甚至一個接口對應一個微服務，這樣的話，架構就從：

演化為：

(1)修改群信息服務

(2)增加群信息服務

(3)獲取群信息服務

多個服務操縱同一個數據表，使用同一片緩存，每個接口出問題，都不會影響其他接口。

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

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

總的來說，細粒度拆分的優(yōu)點有：

(1)服務都能夠獨立部署

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

(3)拆得越細，耦合相對會減小

(4)拆得越細，容錯相對會更好，一個服務出問題不影響其他服務

(5)擴展性更好

(6)…

細粒度拆分的不足也很明顯：

(1)拆得越細，系統(tǒng)越復雜

(2)系統(tǒng)之間的依賴關系也更復雜

(3)運維復雜度提升

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

(5)出問題時定位問題更難

(6)…

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

以上內容是51CTO記者根據58到家CTO沈劍在WOT2018全球軟件與運維技術峰會的采訪內容整理，更多關于WOT的內容請關注51cto.com。

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