dubbo系列1、dubbo背景介紹、微服務拆分

1、背景

隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

2、傳統應用到分佈式應用的演進過程

一、單體應用架構

當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。此時，用於簡化增刪改查工做量的數據訪問框架(ORM)是關鍵，例如SSM，Spring MVC，配合nginx作負載均衡使用已經知足業務須要。

二、多個垂直應用架構

當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。可是不一樣應用之間沒法高效的調用。

三、分佈式服務架構

當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提升業務複用及整合的分佈式服務框架(RPC)是關鍵，實現不一樣的應用之間的高效調用。

四、流動計算架構（soa服務化）

當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，動態更新調度策略，提升集羣利用率。此時，用於提升機器利用率的資源調度和治理中心(SOA)是關鍵。

3、微服務的需求

在大規模服務化以前，應用可能只是經過RMI或Hessian等工具，簡單的暴露和引用遠程服務，經過配置服務的URL地址進行調用，經過F5等硬件進行負載均衡。 

(1) 服務註冊與發現： 當服務愈來愈多時，服務URL配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大。 

此時須要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。 

並經過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，下降對F5硬件負載均衡器的依賴，也能減小部分紅本。 

(2) 服務依賴關係：當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。 

這時，須要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。 

(3) 服務監控與統計： 接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？ 

爲了解決這些問題，第一步，要將服務如今天天的調用量，響應時間，都統計出來，做爲容量規劃的參考指標。 

其次，要能夠動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程當中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。 

(4) 服務黑名單：規模繼續擴大，應用之間再也不是扁平的對應關係，開始分層，好比核心數據層，業務集成層等，就算沒有出現循環依賴，也不容許從低層向高層依賴，以避免後續被逼循環依賴。 

這時，須要在註冊中心定義架構體系，列明有哪些層的定義，每一個服務暴露或引用時，都必須聲明本身應用屬於哪一層，這樣註冊中心能更快的發現架構的腐化現象。 

(5) 服務文檔：服務多了，溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什麼約定？ 

這時就須要登記每一個服務都是誰負責的，並創建一個服務的文檔庫，方便檢索。 

(6) 服務安全：慢慢一些敏感數據也都服務化了，安全問題開始變得重要，誰能調該服務？如何受權？ 

這樣的服務可能須要一個密碼，訪問時需帶着此密碼，但若是用密碼，要改密碼時，就會很不方便，全部的消費方都要改，因此動態生成令牌(Token)可能會更好，提供方將令牌告之註冊中心，由註冊中心決定是否告之消費方，這樣就能在註冊中心頁面上作複雜的受權模型。 

(7) 服務限流：就算是不敏感的服務，也不是能任意調用，好比某服務忽然多了一個消費者，這個消費者的請求量直接把服務給拖跨了，其它消費者跟着一塊兒故障。 

首先服務提供方須要流控，當流程超標時，能拒絕部分請求，進行自我保護。 

其次，消費者上線前和提供者約定《服務質量等級協定(SLA)》，SLA包括消費者承諾天天調用量，請求數據量，提供方承諾響應時間，出錯率等，將SLA記錄在監控中心，定時與監控數據對比，超標則報警。 

(8) 服務路由：雖然有SLA約定，若是不能控制，就只是君子協定，如何確保服務質量？ 

好比：一個應用很重要，一個不那麼重要，它們調用同一個服務，這個服務就應該向重要應用傾斜，而不是一視同仁，當支撐不住時，應限制不重要應用的訪問，保障重要應用的可用，如何作到這一點呢。這時，就須要服務路由，控制不一樣應用訪問不一樣機器，好比： 
應用分離： 
consumer.application = foo => provider.host = 1,2,3 
consumer.application != foo => provider.host = 5,6 
讀寫分離： 
method.name = find*,get* => provider.host = 1,2,3 
method.name != find*,get* => provider.host = 5,6 

(9) 服務自動化測試  ：服務上線後，須要驗證服務是否可用，但因防火牆的限制，線下是不能訪問線上服務的，不得不先寫好一個測試Main，而後放到線上去執行，很是麻煩，而且容易忘記驗證。 

因此線上須要有一個自動運行的驗證程序，用戶只需在界面上填上要驗證的服務方法，以及參數值和指望的返回值，當有一個服務提供者上線時，將自動運行該用例，並將運行結果發郵件通知負責人。 

(10) 服務編排 ：服務應用和Web應用是有區別的，它是一個後臺Daemon程序，不須要Tomcat之類的Web容器。但因公司以前以Web應用爲主，規範都是按Web應用的，因此不得不把服務跑在一個根本用不上的Web容器裏，而搭一個這樣的Web工程也很是費事。 

因此須要實現一個非Web的容器，只需簡單的Main加載Spring配置便可，並提供Maven模板工程，只需mvn dubbo:generate 便可建立一個五臟俱全的服務應用。 

(11) 服務開發IDE  ：開發服務的人愈來愈多，更注重開發效率，IDE的集成支持必不可少。 

經過插件，能夠在Idea、Eclipse中直接運行服務，提供方能夠直接填入測試數據測試服務，消費方能夠直接Mock服務不依賴提供方開發。 

(12) 服務審批：由於暴露服務很簡單，服務的上線愈來愈隨意，有時候負責服務化的架構師都不知道有人上線了某個服務，使得線上服務魚龍混雜，甚至出現重複的服務，而服務下線比上線還困難。 

須要一個新服務上線審批流程，必須通過服務化的架構師審批過了，才能夠上線。 

而服務下線時，應先標識爲過期，而後通知調用方儘快修改調用，直到沒有人調此服務，才能下線。 

(13) 服務兼容性檢測：因服務接口設計的經驗一直在慢慢的積累過程當中，不少接口並不能一促而蹴，在修改的過程當中，如何保證兼容性，怎麼判斷是否兼容？另外，更深層次的，業務行爲兼容嗎？ 

能夠根據使用的協議類型，分析接口及領域模型的變動是否兼容，好比：對比加減字段，方法簽名等。 

而業務上，可能須要基於自動迴歸測試用例，造成Technology Compatibility Kit (TCK)，確保兼容升級。 

(14) 服務降級：隨着服務的不停升級，總有些意想不到的事發生，好比cache寫錯了致使內存溢出，故障不可避免，每次核心服務一掛，影響一大片，人心慌慌，如何控制故障的影響面？服務是否能夠功能降級？或者資源劣化？ 

應用間聲明依賴強度，哪些功能強依賴，哪些弱依賴，而後基於依賴強度，計算出影響面，並按期測試複查，增強關鍵路徑上的服務的優化和容錯，清理不應在關鍵路徑上的服務。 

提供容錯Mock數據，Mock數據也應能夠在註冊中心在運行時動態下發，當某服務不可用時，用Mock數據代替，能夠減小故障的發生，好比某驗權服務，當驗權服務所有掛掉後，直接返回false表示沒有權限，並打印Error日誌報警。 

另外，前端的頁面也應採用Portal進行降級，當該Portal獲取不到數據時，直接隱藏，或替換爲其它模塊展現，並提供功能開關，可人工干預是否展現，或限制多少流量能夠展現。 

(15) 服務調用鏈跟蹤 ：當已有不少小服務，可能就須要組合多個小服務的大服務，爲此，不得不增長一箇中間層，暴露一個新服務，裏面分別調其它小服務，這樣的新服務業務邏輯少，卻帶來不少開發工做量。 

此時，須要一個服務編排引擎，內置簡單的流程引擎，只需用XML或DSL聲明如何聚合服務，註冊中心能夠直接下發給消費者執行聚合邏輯，或者部署通用的編排服務器，全部請求有編排服務器轉發。 

(16) 服務使用狀況報告、服務權重動態調整 ：並非全部服務的訪問量都大，不少的服務都只有一丁點訪問量，卻須要部署兩臺提供服務的機器，進行HA互備，如何減小浪費的機器。 

此時可能須要讓服務容器支持在一臺機器上部署多個應用，能夠用多JVM隔離，也能夠用ClassLoader隔離。 

(17) 服務自動化部署：多個應用若是不是一個團隊開發的，部署在一臺機器上，頗有能夠誤操做，停掉了別人的服務。 

因此須要實現自動部署，全部的部署都無需人工干擾，最好是一鍵式部署。 

(18) 服務自動化調度：機器老是的閒時和忙時，或者冗餘機器防災，如何提升機器的利用率？ 

即然已經能夠自動部署了，那根據監控數據，就能夠實現資源調度，根據應用的壓力狀況，自動添加機器並部署。

若是你的應用是國際化的，有中文站，美國站之類，由於時差，美國站的機器晚上閒的時候，可能正是中文站的白天忙時，能夠經過資源調度，分時段自動調配和部署雙方應用。 

 

4、傳統服務拆分

一、傳統服務分爲MVC

• 視圖層：負責解析成頁面
• 控制層：負責業務邏輯關係
• 數據層：orm訪問數據庫

每一個模塊一個包，每一個包都有本身的MVC，項目迭代久了以後，包就會變得愈來愈大，業務、代碼交錯縱橫，管理混亂，大部分都共享一個庫。

二、常見微服務拆分

• 把相關性緊密的業務或模塊單獨拆分紅一個服務（代碼、數據庫單獨管理）。
• 公共模塊拆分紅一個服務，提供接口給其餘模塊調用。
• 使用dubbo分佈式服務框架進行服務間的遠程調用(消費者-生產者)

常見電商系統拆分：

 

三、微服務拆分優勢

• 解耦，這樣每一個子系統或者服務器均可以由專門的團隊去負責，解決模塊之間的耦合以及擴展性問題，即各個子系統都是相對獨立的。

• 容錯，每一個子系統都是單獨部署在服務器上的，若是集中部署在一個服務器上，當這臺服務器宕機了就會致使整個系統都不能使用。

• 集羣，同一個服務能夠部署部署多臺機器。
• 性能更好，拆分紅多個服務以後，至關於均分了單個系統應用的壓力，整個爲服務系統能承受更大的壓力。
• 微服務架構與語言工具無關，自由選擇合適的語言和工具，高效的完成業務目標便可

四、微服務拆分缺點

• 依賴服務變動很難跟蹤，其餘團隊的服務接口文檔過時怎麼辦？依賴的服務沒有準備好，如何驗證開發的功能。

• 部分模塊重複構建，跨團隊、跨系統、跨語言會有不少的重複建設。

• 微服務放大了分佈式架構的系列問題，如分佈式事務怎麼處理？依賴服務不穩定怎麼辦？

• 運維複雜度陡增，如：部署物數量多、監控進程多致使總體運維複雜度提高。

上面這些問題咱們應該都遇到過，而且也會有一些解決方案，好比提供文檔管理、服務治理、服務模擬的工具和框架； 實現統一認證、統一配置、統一日誌框架、分佈式彙總分析； 採用全局事務方案、採用異步模擬同步；搭建持續集成平臺、統一監控平臺等等。

 五、四個拆分原則

1.AKF拆分原則

AKF擴展立方體（參考《The Art of Scalability》），是一個叫AKF的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，能夠將一個單體系統，進行無限擴展。

X 軸 ：指的是水平復制，很好理解，就是講單體系統多運行幾個實例，作個集羣加負載均衡的模式。

Z 軸 ：是基於相似的數據分區，好比一個互聯網打車應用忽然用戶量激增，集羣模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、四川等多建幾個集羣。

Y 軸 ：就是咱們所說的微服務的拆分模式，就是基於不一樣的業務拆分。

場景說明：好比打車應用，一個集羣撐不住時，分了多個集羣，後來用戶激增仍是不夠用，通過分析發現是乘客和車主訪問量很大，就將打車應用拆成了三個乘客服務、車主服務、支付服務。三個服務的業務特色各不相同，獨立維護，各自均可以再次按需擴展。

 

2.先後端分離

先後端分離原則，簡單來說就是前端和後端的代碼分離也就是技術上作分離，咱們推薦的模式是最好直接採用物理分離的方式部署，進一步促使進行更完全的分離。不要繼續之前的服務端模板技術，好比JSP ，把Java JS HTML CSS 都堆到一個頁面裏，稍複雜的頁面就沒法維護。這種分離模式的方式有幾個好處：

• 先後端技術分離，能夠由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗優化效果會更好。

• 分離模式下，先後端交互界面更加清晰，就剩下了接口和模型，後端的接口簡潔明瞭，更容易維護。

• 前端多渠道集成場景更容易實現，後端服務無需變動，採用統一的數據和模型，能夠支撐前端的web UI\ 移動App等訪問。

3.無狀態服務

 

 

 

對於無狀態服務，首先說一下什麼是狀態：若是一個數據須要被多個服務共享，才能完成一筆交易，那麼這個數據被稱爲狀態。進而依賴這個「狀態」數據的服務被稱爲有狀態服務，反之稱爲無狀態服務。

那麼這個無狀態服務原則並非說在微服務架構裏就不容許存在狀態，表達的真實意思是要把有狀態的業務服務改變爲無狀態的計算類服務，那麼狀態數據也就相應的遷移到對應的「有狀態數據服務」中。

場景說明：例如咱們之前在本地內存中創建的數據緩存、Session緩存，到如今的微服務架構中就應該把這些數據遷移到分佈式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移後，就能夠作到按需動態伸縮，微服務應用在運行時動態增刪節點，就再也不須要考慮緩存數據如何同步的問題。

4.Restful通訊風格

做爲一個原則來說原本應該是個「無狀態通訊原則」，在這裏咱們直接推薦一個實踐優選的Restful 通訊風格 ，由於他有不少好處：

• 無狀態協議HTTP，具有先天優點，擴展能力很強。例如須要安全加密是，有現成的成熟方案HTTPS可用。

• JSON 報文序列化，輕量簡單，人與機器都可讀，學習成本低，搜索引擎友好。

• 語言無關，各大熱門語言都提供成熟的Restful API框架，相對其餘的一些RPC框架生態更完善。

固然在有些特殊業務場景下，也須要採用其餘的RPC框架，如thrift、avro-rpc、grpc。但絕大多數狀況下Restful就足夠用了。

 

5、dubbo 介紹（角色、調用關係、特性）

一、節點角色說明

節點	角色說明
Provider	暴露服務的服務提供方
Consumer	調用遠程服務的服務消費方
Registry	服務註冊與發現的註冊中心
Monitor	統計服務的調用次數和調用時間的監控中心
Container	服務運行容器

二、調用關係說明

0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

三、dubbo特性

Dubbo 架構具備如下幾個特色，分別是連通性、健壯性、伸縮性、以及向將來架構的升級性。

一、連通性

• 註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小
• 監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現
• 服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷
• 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
• 註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
• 註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
• 註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
• 註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者

二、健壯性

• 監控中心宕掉不影響使用，只是丟失部分採樣數據
• 數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
• 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
• 註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

三、伸縮性

• 註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心
• 服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者