基于Dubbo服務(wù)治理模式的單體架構(gòu)改造

侯海平，李 龍

當(dāng)數(shù)據(jù)存儲的容量和速度不受約束時，各種數(shù)據(jù)中心規(guī)模呈爆炸式增長，移動互聯(lián)網(wǎng)的加速發(fā)展又進(jìn)一步推動各種基于數(shù)據(jù)的業(yè)務(wù)應(yīng)用快速發(fā)展.歷史上以往任何時期產(chǎn)生的數(shù)據(jù)、存儲的數(shù)據(jù)、使用的數(shù)據(jù)都沒有當(dāng)今這個時代的數(shù)據(jù)規(guī)模大，數(shù)據(jù)從服務(wù)端到客戶端或者從客戶端到服務(wù)端都需要龐大的業(yè)務(wù)架構(gòu)作為支撐，這些業(yè)務(wù)架構(gòu)中最為核心的架構(gòu)就是服務(wù)器架構(gòu)體系，好的服務(wù)器架構(gòu)可以保證業(yè)務(wù)和數(shù)據(jù)高速增長下，系統(tǒng)還具有良好的高并發(fā)性、高穩(wěn)定性以及高擴(kuò)展性.

1 傳統(tǒng)單體架構(gòu)

大多已有的服務(wù)架構(gòu)都是一種單體架構(gòu)，所謂單體應(yīng)用是指將一個完整的Web應(yīng)用程序部署在一臺服務(wù)器上.在軟件工程“高內(nèi)聚低耦合”的思想指引下，所有單體架構(gòu)Web應(yīng)用程序都會采用一種分層的思想，如傳統(tǒng)的“三層式架構(gòu)”或者“多層式架構(gòu)”.按照分層分職責(zé)的原則將軟件結(jié)構(gòu)劃分為：表現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層.或者再次將每個層次進(jìn)一步細(xì)化分層，做到層與層之間進(jìn)一步解耦.通常單體架構(gòu)分層如圖1所示.

圖1 單體架構(gòu)分層示意圖

common表示項目中通用類集合，通常如字符處理、通用正則表達(dá)式等.

config表示項目中基礎(chǔ)配置內(nèi)容，如加密方式配置信息處理、解密方式配置信息等.

controller表示MVC設(shè)計模式中Controller，可以是Struts2中的Action，也可以是SpringMVC中的Controller.

dao表示數(shù)據(jù)訪問的接口，是對數(shù)據(jù)訪問的基本約定，與具體數(shù)據(jù)庫無關(guān)，與具體數(shù)據(jù)庫ORM框架無關(guān)，可以對接Hibernate框架，也可以對接MyBatis框架.

dao.impl表示選擇某一種ORM框架對數(shù)據(jù)訪問接口的具體實現(xiàn).

dao.mapper表示ORM框架中需要映射描述文件.

entity表示業(yè)務(wù)中實體模型，也可以包括用于UI的視圖層數(shù)據(jù)模型.

interceptor表示webapp中攔截器，用于實現(xiàn)權(quán)限控制或者其他請求的預(yù)處理.

service表示對項目業(yè)務(wù)的基本抽象，是一個接口層次.

service.impl表示業(yè)務(wù)接口的實現(xiàn)層.

單體架構(gòu)在業(yè)務(wù)快速增長的背景下暴露出眾多問題：

（1）難以適用并發(fā)請求的彈性變化［1］.請求繁忙時，需要部署更多的Web應(yīng)用程序來應(yīng)對業(yè)務(wù)高速的增長；業(yè)務(wù)請求空閑時，如果部署過多的服務(wù)器也會造成閑時服務(wù)器的浪費.實際的業(yè)務(wù)量不會一直處在高峰期，需要有恰當(dāng)策略去應(yīng)對業(yè)務(wù)的波峰和波谷.

（2）系統(tǒng)整體性能脆弱.如果某一業(yè)務(wù)非常耗費時間，則會導(dǎo)致整個服務(wù)器癱瘓，所有應(yīng)用無法響應(yīng)，可謂是牽一發(fā)而動全身.單體架構(gòu)無法屏蔽某一業(yè)務(wù)對整體的影響，只能通過部署更多的服務(wù)器，將宕機的服務(wù)器從服務(wù)器組中剔除.

（3）架構(gòu)擴(kuò)展性差.業(yè)務(wù)不僅請求量會上升，而且業(yè)務(wù)本身也會發(fā)生變化.每個業(yè)務(wù)模塊往往需要快速迭代，然而業(yè)務(wù)之間的隔離性較差，業(yè)務(wù)依賴度較高，一個業(yè)務(wù)的修改需要其他業(yè)務(wù)模塊也隨之發(fā)生變化，從開發(fā)、測試到部署都需要整體進(jìn)行，大大拖慢了業(yè)務(wù)系統(tǒng)的迭代進(jìn)度.

2 Dubbo服務(wù)治理架構(gòu)

2.1 服務(wù)治理模式

大型互聯(lián)網(wǎng)系統(tǒng)中，業(yè)務(wù)規(guī)模發(fā)展迅速，系統(tǒng)模塊數(shù)量快速上升，在進(jìn)行單體架構(gòu)改造過程中會將業(yè)務(wù)模塊拆分成一個個獨立的服務(wù)組件.這些服務(wù)組件會獨立部署.在構(gòu)成應(yīng)用平臺時，他們相互之間既有邏輯上非常復(fù)雜的依賴關(guān)系，又保持相對的獨立性，這種關(guān)系就要求每一個服務(wù)組件必須獨立開發(fā)、獨立部署、獨立測試、統(tǒng)一授權(quán)、統(tǒng)一編排、統(tǒng)一配置，某一個服務(wù)迭代升級，同時又不能影響其他服務(wù)的正常運行，站在對其他服務(wù)角度來說是感覺不到當(dāng)前服務(wù)迭代的.這一情形下就需要有一套綜合的服務(wù)治理模式來應(yīng)對龐大的服務(wù)組件形成的依賴關(guān)系.如截止2017年“雙十一”，阿里巴巴在實際的生產(chǎn)環(huán)境中發(fā)布的服務(wù)數(shù)量超過23000，螞蟻金服使用SOFA中間件治理這些服務(wù)［2-4］.這套服務(wù)治理模式必須能夠解決服務(wù)注冊與發(fā)現(xiàn)、服務(wù)監(jiān)控、集群容錯、負(fù)載均衡等問題.

2.2 Dubbo框架解決問題的范圍

在業(yè)務(wù)快速迭代的大環(huán)境下，上述問題必須解決，激增的并發(fā)量、集群化部署、高擴(kuò)展性的系統(tǒng)已成為業(yè)務(wù)平臺需求的發(fā)展趨勢，Dubbo正是在這一情形下誕生.它是一個經(jīng)過阿里巴巴“雙十一”考驗的分布式服務(wù)架構(gòu)［2-4］，實施Dubbo框架對現(xiàn)有架構(gòu)進(jìn)行改造，就能較好地解決上述問題.Dubbo框架是基于RPC（Remote Procedure Call Protocol，遠(yuǎn)程過程調(diào)用協(xié)議）通信方式的服務(wù)框架，RPC無論是從接口標(biāo)準(zhǔn)化方面還是從性能方面都有很好的表現(xiàn).同時，近年來Dubbo框架又引入穩(wěn)定性較好和性能表現(xiàn)較好的Netty和Mina作為通信層面的基礎(chǔ)框架，大大保障了遠(yuǎn)程調(diào)用的性能.

在傳統(tǒng)架構(gòu)中引入Dubbo框架，可以解決：

（1）服務(wù)組件之間通信.服務(wù)組件可以互為Provider（提供者）和Customer（消費者），Provider向注冊中心注冊登記服務(wù)的地址和名稱，注冊中心向Customer廣播Provider的地址和名稱.Cus?tomer通過獲取的地址和名稱向Provider發(fā)起調(diào)用服務(wù)的請求，Provider響應(yīng)請求.這一模式使集群部署成為可能.如圖2所示.

圖2 Dubbo框架的提供者和消費者通信方式

（2）服務(wù)組件的集群化部署與容錯.集群化部署是一種業(yè)務(wù)橫向擴(kuò)展能力，主要應(yīng)對于業(yè)務(wù)量的波峰與波谷變化，業(yè)務(wù)急速上升時，同一業(yè)務(wù)服務(wù)組件以更多服務(wù)器形式進(jìn)行集群部署，而并不是讓整個Web應(yīng)用程序進(jìn)行集群部署，大大提升了業(yè)務(wù)系統(tǒng)的穩(wěn)定性.對于其他服務(wù)消費者來說，并不需要關(guān)心某一業(yè)務(wù)是否進(jìn)行了集群部署，業(yè)務(wù)隔離性較好，這一操作方式也非常符合SOA（Service Oriented Architecture，面向服務(wù)的架構(gòu)）架構(gòu)要求［5-6］.如圖3所示.

集群容錯主要表現(xiàn)在其容錯策略：Failover，自動切換，可設(shè)置重試次數(shù)，失敗后連接其他服務(wù)器；Failfast，只發(fā)起一次，失敗則立即報錯；Failsafe，失敗直接忽略，計入日志；Failback，失敗自動恢復(fù)，定時重發(fā)；Forking，調(diào)用多個服務(wù)器，只要一個成功即可；Broadcast，對提供者服務(wù)器逐個調(diào)用，有一臺出錯就報錯.

（3）服務(wù)組件自動化管理.Dubbo框架還提供Dubbo Admin這一服務(wù)管理平臺用于開發(fā)人員和運維人員對服務(wù)進(jìn)行管理和控制.通過Dubbo Admin可以清晰地看到Dubbo服務(wù)框架中正在運行的提供者和消費者，并且了解負(fù)載均衡信息，也可以通過該后臺設(shè)置服務(wù)的提供者和消費者屬性、路由規(guī)則及權(quán)重參數(shù)等.

2.3 Dubbo框架服務(wù)治理方面的表現(xiàn)

應(yīng)用之間采用RPC方式通信是業(yè)務(wù)系統(tǒng)架構(gòu)服務(wù)化的基礎(chǔ).架構(gòu)服務(wù)化會帶來很多挑戰(zhàn)和管理問題，這就需要有一套針對大規(guī)模服務(wù)進(jìn)行治理的方案.Dubbo框架就是一套比較完整的服務(wù)治理方案.Dubbo在服務(wù)治理方面具備很多優(yōu)勢，這些優(yōu)勢表現(xiàn)在：

（1）Dubbo框架使用服務(wù)編排、調(diào)度中心管理這些服務(wù)，即使服務(wù)越來越多，由幾個模塊迅速擴(kuò)張為幾十個服務(wù)，甚至上百個服務(wù)，服務(wù)之間有高度依賴關(guān)系也能較好地應(yīng)對.

（2）每個服務(wù)需要有獨立的負(fù)載均衡管理方法，服務(wù)是上線運行還是下線停止，需要服務(wù)之間相互獨立，互不干擾.Dubbo框架提供了服務(wù)容器和容量評估模塊實現(xiàn)合理擴(kuò)容和減容.

俄羅斯專家表示，歐盟《機器人民事法律規(guī)則》里專設(shè)了“機器人憲章”，規(guī)定了機器人設(shè)計和研發(fā)過程中必須遵守的基本倫理原則，制定了機器人工程師道德行為守則，以及設(shè)計師的“許可”制度和用戶“許可”制度。這些都是俄羅斯在立法時需要參照的范本。

（3）每個服務(wù)可以通過Dubbo框架的授權(quán)中心和服務(wù)路由模塊進(jìn)行服務(wù)使用者身份鑒定，確保服務(wù)調(diào)用的合法性.

（4）Dubbo包含服務(wù)監(jiān)控模塊，可以對服務(wù)的調(diào)用情況進(jìn)行實時監(jiān)控和統(tǒng)計，最終幫助用戶掌握服務(wù)使用情況.

3 傳統(tǒng)單體架構(gòu)的Dubbo框架化改造設(shè)計

3.1 充分理解單體架構(gòu)內(nèi)層與層之間關(guān)系

單體架構(gòu)中的包主要是為了對Web應(yīng)用程序進(jìn)行分層隔離，做到業(yè)務(wù)邏輯、數(shù)據(jù)讀寫、UI表現(xiàn)之間的解耦.通常一個SSH和SSM框架下的Web程序擁有如圖4所示的層與層之間的關(guān)系.

圖4 單體架構(gòu)下層關(guān)系

步驟1：當(dāng)用戶發(fā)起請求時，Java Servlet容器中的Interceptor首先攔截用戶請求.如果用戶滿足Interceptor的要求則繼續(xù)轉(zhuǎn)發(fā)請求給Controller.

步驟2：Controller根據(jù)業(yè)務(wù)特點調(diào)用相關(guān)的Service接口，根據(jù)Spring注入的Service實例來進(jìn)行業(yè)務(wù)服務(wù)調(diào)用.

步驟2.1：表示Service接口將會選擇相關(guān)的實現(xiàn)類來執(zhí)行具體的業(yè)務(wù)邏輯.

步驟3：Service的實現(xiàn)類中涉及到數(shù)據(jù)的讀寫操作是通過調(diào)用Dao接口來完成.

步驟3.1：Spring會將Dao接口對應(yīng)的具體實例注入到Service實現(xiàn)類中.

步驟3.2：將相關(guān)數(shù)據(jù)庫操作的ORM映射關(guān)系抽取成立一個單獨的層，便于數(shù)據(jù)庫操作相對獨立，并提供給Dao.Impl來進(jìn)行調(diào)用.

步驟4：數(shù)據(jù)模型、通用方法、配置信息提供給整個應(yīng)用程序.

步驟5：所有調(diào)用完成，將結(jié)果反饋給用戶.

3.2 根據(jù)“職責(zé)單一”原則拆分業(yè)務(wù)包為獨立項目

“職責(zé)單一”原則要求每一個類獨立完成一個功能.為了進(jìn)一步細(xì)粒度化業(yè)務(wù)模型單元，將業(yè)務(wù)模塊進(jìn)一步細(xì)分和拆解成更小的單位.將那些高頻調(diào)用的業(yè)務(wù)組件、業(yè)務(wù)變更較快的業(yè)務(wù)組件獨立出來.這里假定所有業(yè)務(wù)系統(tǒng)中都有用戶中心服務(wù)組件，對于大多數(shù)系統(tǒng)中也都包含用戶中心模塊，用戶中心模塊通常包括用戶登錄、注冊、認(rèn)證、注銷、管理等功能，以下步驟以“用戶中心”模塊為例.

步驟1：使用maven對拆分后的項目進(jìn)行構(gòu)建、安裝、部署管理.所有項目都使用maven進(jìn)行構(gòu)建.

步驟2：拆分后的系統(tǒng)架構(gòu)分為10個組成部分.具體如圖5所示.

圖5 使用Dubbo框架改造后的服務(wù)治理模型

步驟3：建立WebApp-Parent項目，maven的項目類型為pom類型.該項目作為其余9大項目的父項目存在.作用是將所有項目的依賴管理配置在此項目中，并且在此項目中對所有其他項目進(jìn)行version（版本）管理.

步驟4：抽取原有common包建立WebApp-Common項目，抽取config包建立WebApp-Com?mon-Config項目，抽取原有Dao包下有關(guān)數(shù)據(jù)庫底層輔助訪問類建立WebApp-Common-Core項目，抽取Dao包建立WebApp-Dao-User（以“用戶中心”模塊為例），抽取Entity包建立We?bApp-Entity-User項目，這些項目maven項目類型為jar，將成為其他項目的依賴項.

步驟5：抽取Service包建立WebApp-Ser?vice-User項目和 WebApp-Service-Impl-User項目，其中WebApp-Service-User項目將成為We?bApp-WebPortal項目和 WebApp-Service-Im?pl-User項目的依賴項.WebApp-Service-User項目為服務(wù)提供者和消費者都需要的服務(wù)接口.

步驟6：抽取Controller和Interceptor包建立WebApp-Common-Web項目和 WebApp-Web?Portal項目，其中WebApp-Common-Web項目是WebApp-WebPortal項目的依賴項.

步驟7：最終拆分成10個獨立項目.

3.3 安裝注冊中心，構(gòu)建和部署服務(wù)

（1）安裝注冊中心.設(shè)置注冊中心，在服務(wù)器上安裝ZooKeeper項目，ZooKeeper也是Dubbo官方推薦的注冊中心［7-9］.服務(wù)提供者和服務(wù)消費者都需要使用ZooKeeper進(jìn)行首次通信，服務(wù)提供者向ZooKeeper注冊登記服務(wù)，服務(wù)消費者向ZooKeeper訂閱提供者信息.

（2）構(gòu)建和部署服務(wù).服務(wù)的部署往往需要考慮是否能夠快速實現(xiàn)，過程是否復(fù)雜或者能否自動化，同時兼顧部署過程中能否適應(yīng)正在運行的服務(wù)，不能干擾已有服務(wù).針對這一情形，Dub?bo框架給出服務(wù)部署的三種做法：

①使用Servlet容器運行Dubbo服務(wù)組件.運維人員可以通過Tomcat或者Jetty等服務(wù)器程序來運行Servlet容器，然后把Dubbo服務(wù)當(dāng)成一個獨立的Servlet容器來運行.這種方式操作起來比較簡單，但是需要分配好端口，且每一個Servlet都需要浪費更多的內(nèi)存資源.

②自定義程序入口，建立main入口方法運行Spring容器，通過Spring加載Dubbo服務(wù)，解決了內(nèi)存資源浪費的問題，但是由于沒有使用Dubbo優(yōu)雅關(guān)機等高級特性，在服務(wù)的調(diào)用上缺少一定的處理能力.

③使用Dubbo框架提供的com.alibaba.dub?bo.container.Main方法加載Spring容器，再由Spring框架加載服務(wù)組件.既能夠較好地利用內(nèi)存資源，又能夠使用Dubbo提供的優(yōu)秀特性.如某一服務(wù)接收到關(guān)閉指令，而同時又有服務(wù)消費者在消費該服務(wù)，則會等待該服務(wù)調(diào)用完畢后關(guān)閉.

結(jié)合上述每種做法的特點，選擇第三種方式來構(gòu)建和部署服務(wù).

4 結(jié)束語

Dubbo框架已經(jīng)成為服務(wù)治理框架中較為成熟的框架之一.在服務(wù)通信、服務(wù)管理、服務(wù)部署等方面都有不錯的表現(xiàn).

本文針對Dubbo框架特點進(jìn)行分析，探討了一種改造傳統(tǒng)單體架構(gòu)的方法和實現(xiàn)路徑.想要提高改造的成功率，首先應(yīng)充分了解當(dāng)前單體架構(gòu)的業(yè)務(wù)特點，理清原有業(yè)務(wù)間關(guān)系；其次要靈活運用Dubbo框架的實施策略.本文重點以“用戶中心”模塊為例，闡明了改造單體架構(gòu)的方法和步驟.