劉斌
(中郵科通信技術股份有限公司,福州350001)
電信業在近幾年得到了蓬勃的發展,業務更加復雜,關系更加緊密,數據更加多樣化。原先舊的綜合服務保障系統逐漸顯露出自身架構的缺陷:所有功能集中在一個項目中,邏輯復雜、模塊耦合、代碼臃腫,修改難度大,系統錯誤隔離性差、可用性差,任何一個模塊的錯誤均可能造成整個系統的宕機。加之為順應電信IT 系統的Paas 云平臺化改造,決定對現有綜合服務保障系統進行基于SpringCloud的微服務化改造[1]。
微服務是將原本單一型的應用分解為多個微服務,各個微服務獨立運行在自己的進程中,可分別有自己的數據庫。微服務之間使用REST 或者RPC 等協議進行通信。具有易于開發和維護、啟動更快便于部署、更寬的技術棧等優點。
綜合服務保障系統是一套在用系統,所以如果從頭構建全新的基于微服務的應用,充滿了風險,有可能導致失敗。相反,應當采取漸進式重構舊系統的策略,逐步構建一個由微服務構成的應用,與舊系統并行運行。隨著時間推移,原先由舊系統實現的功能不斷收縮,最后或者完全消失,或者轉變為微服務。轉化的實現策略包括以下幾個方面:
策略一:拆分前端和后端。將表示層與業務邏輯和數據訪問層分離。表示層是一個應用,業務和數據訪問邏輯是一個應用。表示層應用遠程調用業務邏輯層。
策略二:提取微服務。將舊系統內的模塊轉變為獨立的微服務。每當提取模塊將其轉化為服務,舊系統就會收縮。一旦轉化了足夠的模塊,舊系統或者徹底消失,或者縮小成為另一個微服務。
策略三:新增的業務模塊直接微服務化。使舊系統停止繼續變大,不再對舊系統開發新的功能,而把新的功能模塊開發成為獨立的微服務[2]。
SpringCloud 是一套基于SpringBoot 構建的通用工具集,非常適合用于快速地構建分布式系統。作為微服務的開發框架,其整合并增強了微服務架構中常用的組件,如Eureka、Zuul、Hystrix 等,具有功能齊全、開箱即用、適用于各種環境等特點。
Eureka 是一個基于REST 服務的服務注冊與發現組件,主要包含 Eureka Server 和 Eureka Client 兩個組件。SpringCloud 將其集成在子項目Spring Cloud Netflix 中。
各個微服務啟動時,會將自己的信息(如IP、端口、微服務名稱等)注冊到Eureka Server,Eureka Server 會存儲這些信息。Eureka Client 會周期性(默認30s)地向Eureka Server 發送心跳以續約自己的信息。Eureka Server 會檢查超過一定時間(默認90s)沒有續約的微服務,如有發現,則會注銷該微服務實例。每個Eureka Server 同時也是一個Eureka Client,多個Eureka Server 實例互相之間通過復制的方式實現注冊信息的同步[3]。
Ribbon 是一套基于HTTP 和TCP的客戶端負載均衡工具,由Netflix 發布。經由SpringCloud 封裝后,Ribbon 可以自動地從Eureka Server 中獲取服務提供者的地址列表,并基于負載均衡算法(如輪詢、隨機等),請求其中一個服務提供者實例,也可為Ribbon 實現自定義的負載均衡算法。
微服務架構的應用系統通常包含多個服務層,各服務之間存在一定的依賴關系。底層服務的故障有可能引發級聯故障,導致雪崩效應。要防止雪崩效應,必須有一個強大的容錯機制。
Hystrix 是有Netflix 開源的一個工具類庫,可以為網絡請求設置超時,使用斷路器模式,用于隔離訪問遠程系統、服務或者第三方庫,防止級聯失敗,從而提升系統的可用性和容錯性。
Zuul 是Netflix 開源的微服務網關,SpringCloud 對Zuul 進行了整合與增強,使其能夠與Eureka、Ribbon、Hystrix 等組件更方便地配合使用。
微服務網關是介于外部客戶端(如網頁端、手機APP 等)和服務器之間的中間層,所有客戶端來的請求都通過微服務網關到達后端的應用服務。作為一個邊界性質的應用程序,Zuul 底層利用各種過濾器實現了以下功能:身份認證與安全、動態路由、性能監控、壓力測試、負載分配、靜態相應處理等。

圖1 SpringCloud 架構圖
單體應用向微服務架構的重構是一個持續的過程,充滿了挑戰。實現這一過程不能一味地從頭開始重寫代碼,而是應該漸進式地將單體應用中的功能模塊轉換成微服務。隨著時間的推移,大量微服務逐步形成,舊單體應用的功能逐步下線,最終實現全部改造的目標。