05 消息訂閱發布模式多線程(activemq和rabbitmq誰更適合java學習)

共用服務注冊中心為了方便開發測試，經常會在線下共用一個所有服務共享的服務注冊中心，這時，一個正在開發中的服務發布到服務注冊中心，可能會導致一些消費者不可用

解決方案：可以讓服務提供者開發方，只訂閱服務（開發的服務可能依賴其他服務），而不注冊正在開發的服務，通過直連測試正在開發的服務

它的工作原理如圖3-1所示

圖3-1只訂閱，不發布3

2直連提供者在開發和測試環境下，如果公共的服務注冊中心沒有搭建，消費者將無法獲取服務提供者的地址列表，只能做本地單元測試或使用模擬樁測試

還有一種場景就是在實際測試中，服務提供者往往多實例部署，如果服務提供者存在Bug，就需要做遠程斷點調試，這會帶來兩個問題：1）服務提供者多實例部署，遠程調試地址無法確定，調試效率低下

2）多個消費者可能共用一套測試聯調環境，斷點調試過程中可能被其他消費者意外打斷

解決策略：繞過注冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式將以服務接口為單位，忽略注冊中心的提供者列表

3

3多團隊進度協同假如前端Web門戶依賴后臺A、B、C和D4個服務，分別由4個不同的研發團隊負責，門戶要求新特性2周內上線

A和B內部需求優先級排序將門戶的優先級排的比較高，可以滿足交付時間點

但是C和D服務所在團隊由于同時需要開發其他優先級更高的服務，因此把優先級排的相對較低，無法滿足2周交付

在C和D提供版本之前，門戶只能先通過打測試樁的方式完成Mock測試，但是由于并沒有真實的測試過C和D服務，因此需求無法按期交付

應用依賴的服務越多，特性交付效率就越低下，交付的速度取決于依賴的最遲交付的那個服務

假如Web門戶依賴后臺的100個服務，只要1個核心服務沒有按期交付，則整個進度就會延遲

解決方案：調用鏈可以將應用、服務和中間件之間的依賴關系串接并展示出來，基于調用鏈首入口的交付日期作為輸入，利用依賴管理工具，可以自動計算出調用鏈上各個服務的最遲交付時間點

通過調用鏈分析和標準化的依賴計算工具，可以避免人為需求排序失誤導致的需求延期

3

4服務降級和Mock測試在實際項目開發中，由于小組之間、個人開發者之間開發節奏不一致，經常會出現消費者等待依賴的服務提供者提供聯調版本的情況，相互等待會降低項目的研發進度

解決方案：服務提供者首先將接口定下來并提供給消費者，消費者可以將服務降級同Mock測試結合起來，在Mock測試代碼中實現容錯降級的業務邏輯（業務放通），這樣既完成了Mock測試，又實現了服務降級的業務邏輯開發，一舉兩得

3

5協同調試問題在實際項目開發過程中，各研發團隊進度不一致很正常

如果消費者坐等服務提供者按時提供版本，往往會造成人力資源浪費，影響項目進度

解決方案：分布式服務框架提供Mock樁管理框架，當周邊服務提供者尚未完成開發時，將路由切換到模擬測試模式，自動調用Mock樁；業務集成測試和上線時，則要能夠自動切換到真實的服務提供者上，可以結合服務降級功能實現

3

6接口前向兼容性由于線上的Bug修復、內部重構和需求變更，服務提供者會經常修改內部實現，包括但不限于：接口參數變化、參數字段變化、業務邏輯變化和數據表結構變化

在實際項目中經常會發生服務提供者修改了接口或者數據結構，但是并沒有及時知會到所有消費者，導致服務調用失敗

解決方案：1）制定并嚴格執行《服務前向兼容性規范》，避免發生不兼容修改或者私自修改不通知周邊的情況

2）接口兼容性技術保障：例如Thrift的IDL，支持新增、修改和刪除字段，字段定義位置無關性，碼流支持亂序等

4

總結服務化之后，無論是服務化框架，還是業務服務，都面臨諸多挑戰，本章摘取了其中一些比較重要的問題，并給出解決方案和最佳實踐

對于本章節沒有列出的問題，則需要服務框架開發者和使用者在實踐中探索，找出一條適合自己產品的服務化最佳實踐

很赞哦!（9923）