劉斌

（中郵科通信技術(shù)股份有限公司，福州350001）

1 引言

電信業(yè)在近幾年得到了蓬勃的發(fā)展，業(yè)務(wù)更加復(fù)雜，關(guān)系更加緊密，數(shù)據(jù)更加多樣化。原先舊的綜合服務(wù)保障系統(tǒng)逐漸顯露出自身架構(gòu)的缺陷：所有功能集中在一個(gè)項(xiàng)目中，邏輯復(fù)雜、模塊耦合、代碼臃腫，修改難度大，系統(tǒng)錯(cuò)誤隔離性差、可用性差，任何一個(gè)模塊的錯(cuò)誤均可能造成整個(gè)系統(tǒng)的宕機(jī)。加之為順應(yīng)電信IT 系統(tǒng)的Paas 云平臺(tái)化改造，決定對(duì)現(xiàn)有綜合服務(wù)保障系統(tǒng)進(jìn)行基于SpringCloud的微服務(wù)化改造[1]。

2 微服務(wù)簡(jiǎn)介

微服務(wù)是將原本單一型的應(yīng)用分解為多個(gè)微服務(wù)，各個(gè)微服務(wù)獨(dú)立運(yùn)行在自己的進(jìn)程中，可分別有自己的數(shù)據(jù)庫(kù)。微服務(wù)之間使用REST 或者RPC 等協(xié)議進(jìn)行通信。具有易于開(kāi)發(fā)和維護(hù)、啟動(dòng)更快便于部署、更寬的技術(shù)棧等優(yōu)點(diǎn)。

3 微服務(wù)改造實(shí)踐

綜合服務(wù)保障系統(tǒng)是一套在用系統(tǒng)，所以如果從頭構(gòu)建全新的基于微服務(wù)的應(yīng)用，充滿(mǎn)了風(fēng)險(xiǎn)，有可能導(dǎo)致失敗。相反，應(yīng)當(dāng)采取漸進(jìn)式重構(gòu)舊系統(tǒng)的策略，逐步構(gòu)建一個(gè)由微服務(wù)構(gòu)成的應(yīng)用，與舊系統(tǒng)并行運(yùn)行。隨著時(shí)間推移，原先由舊系統(tǒng)實(shí)現(xiàn)的功能不斷收縮，最后或者完全消失，或者轉(zhuǎn)變?yōu)槲⒎?wù)。轉(zhuǎn)化的實(shí)現(xiàn)策略包括以下幾個(gè)方面：

策略一：拆分前端和后端。將表示層與業(yè)務(wù)邏輯和數(shù)據(jù)訪(fǎng)問(wèn)層分離。表示層是一個(gè)應(yīng)用，業(yè)務(wù)和數(shù)據(jù)訪(fǎng)問(wèn)邏輯是一個(gè)應(yīng)用。表示層應(yīng)用遠(yuǎn)程調(diào)用業(yè)務(wù)邏輯層。

策略二：提取微服務(wù)。將舊系統(tǒng)內(nèi)的模塊轉(zhuǎn)變?yōu)楠?dú)立的微服務(wù)。每當(dāng)提取模塊將其轉(zhuǎn)化為服務(wù)，舊系統(tǒng)就會(huì)收縮。一旦轉(zhuǎn)化了足夠的模塊，舊系統(tǒng)或者徹底消失，或者縮小成為另一個(gè)微服務(wù)。

策略三：新增的業(yè)務(wù)模塊直接微服務(wù)化。使舊系統(tǒng)停止繼續(xù)變大，不再對(duì)舊系統(tǒng)開(kāi)發(fā)新的功能，而把新的功能模塊開(kāi)發(fā)成為獨(dú)立的微服務(wù)[2]。

4 SpringCloud 簡(jiǎn)介

SpringCloud 是一套基于SpringBoot 構(gòu)建的通用工具集，非常適合用于快速地構(gòu)建分布式系統(tǒng)。作為微服務(wù)的開(kāi)發(fā)框架，其整合并增強(qiáng)了微服務(wù)架構(gòu)中常用的組件，如Eureka、Zuul、Hystrix 等，具有功能齊全、開(kāi)箱即用、適用于各種環(huán)境等特點(diǎn)。

4.1 Eureka

Eureka 是一個(gè)基于REST 服務(wù)的服務(wù)注冊(cè)與發(fā)現(xiàn)組件，主要包含 Eureka Server 和 Eureka Client 兩個(gè)組件。SpringCloud 將其集成在子項(xiàng)目Spring Cloud Netflix 中。

各個(gè)微服務(wù)啟動(dòng)時(shí)，會(huì)將自己的信息（如IP、端口、微服務(wù)名稱(chēng)等）注冊(cè)到Eureka Server，Eureka Server 會(huì)存儲(chǔ)這些信息。Eureka Client 會(huì)周期性（默認(rèn)30s）地向Eureka Server 發(fā)送心跳以續(xù)約自己的信息。Eureka Server 會(huì)檢查超過(guò)一定時(shí)間（默認(rèn)90s）沒(méi)有續(xù)約的微服務(wù)，如有發(fā)現(xiàn)，則會(huì)注銷(xiāo)該微服務(wù)實(shí)例。每個(gè)Eureka Server 同時(shí)也是一個(gè)Eureka Client，多個(gè)Eureka Server 實(shí)例互相之間通過(guò)復(fù)制的方式實(shí)現(xiàn)注冊(cè)信息的同步[3]。

4.2 Ribbon

Ribbon 是一套基于HTTP 和TCP的客戶(hù)端負(fù)載均衡工具，由Netflix 發(fā)布。經(jīng)由SpringCloud 封裝后，Ribbon 可以自動(dòng)地從Eureka Server 中獲取服務(wù)提供者的地址列表，并基于負(fù)載均衡算法（如輪詢(xún)、隨機(jī)等），請(qǐng)求其中一個(gè)服務(wù)提供者實(shí)例，也可為Ribbon 實(shí)現(xiàn)自定義的負(fù)載均衡算法。

4.3 Hystrix

微服務(wù)架構(gòu)的應(yīng)用系統(tǒng)通常包含多個(gè)服務(wù)層，各服務(wù)之間存在一定的依賴(lài)關(guān)系。底層服務(wù)的故障有可能引發(fā)級(jí)聯(lián)故障，導(dǎo)致雪崩效應(yīng)。要防止雪崩效應(yīng)，必須有一個(gè)強(qiáng)大的容錯(cuò)機(jī)制。

Hystrix 是有Netflix 開(kāi)源的一個(gè)工具類(lèi)庫(kù)，可以為網(wǎng)絡(luò)請(qǐng)求設(shè)置超時(shí)，使用斷路器模式，用于隔離訪(fǎng)問(wèn)遠(yuǎn)程系統(tǒng)、服務(wù)或者第三方庫(kù)，防止級(jí)聯(lián)失敗，從而提升系統(tǒng)的可用性和容錯(cuò)性。

4.4 Zuul

Zuul 是Netflix 開(kāi)源的微服務(wù)網(wǎng)關(guān)，SpringCloud 對(duì)Zuul 進(jìn)行了整合與增強(qiáng)，使其能夠與Eureka、Ribbon、Hystrix 等組件更方便地配合使用。

微服務(wù)網(wǎng)關(guān)是介于外部客戶(hù)端（如網(wǎng)頁(yè)端、手機(jī)APP 等）和服務(wù)器之間的中間層，所有客戶(hù)端來(lái)的請(qǐng)求都通過(guò)微服務(wù)網(wǎng)關(guān)到達(dá)后端的應(yīng)用服務(wù)。作為一個(gè)邊界性質(zhì)的應(yīng)用程序，Zuul 底層利用各種過(guò)濾器實(shí)現(xiàn)了以下功能：身份認(rèn)證與安全、動(dòng)態(tài)路由、性能監(jiān)控、壓力測(cè)試、負(fù)載分配、靜態(tài)相應(yīng)處理等。

4.5 微服務(wù)架構(gòu)

圖1 SpringCloud 架構(gòu)圖

5 結(jié)語(yǔ)

單體應(yīng)用向微服務(wù)架構(gòu)的重構(gòu)是一個(gè)持續(xù)的過(guò)程，充滿(mǎn)了挑戰(zhàn)。實(shí)現(xiàn)這一過(guò)程不能一味地從頭開(kāi)始重寫(xiě)代碼，而是應(yīng)該漸進(jìn)式地將單體應(yīng)用中的功能模塊轉(zhuǎn)換成微服務(wù)。隨著時(shí)間的推移，大量微服務(wù)逐步形成，舊單體應(yīng)用的功能逐步下線(xiàn)，最終實(shí)現(xiàn)全部改造的目標(biāo)。