單體應用微服務改造實踐

微服務的本質是彈性架構，動態適應業務規模增長，符合業務成長規律。在確定是否投資某一個業務領域或者產品的時候，剛開始都是探索、碰到各種問題，經過多輪迭代，做成一個可用的產品，隨著用戶使用的越來越多，產品迭代的持續推進，產品越做越好。評估一個單體應用是否值得采用微服務架構進行演進，首先需要確定其業務價值，如果業務價值成長預期大于可預見的投入，那么這個投資就是值得的。單體應用改造為微服務應用是個持續迭代，逐步成長的過程，本文遵循一個進度可控，持續迭代的邏輯，提供了一個單體應用向微服務演進的開發實踐參考。“持續迭代演進”是貫穿其中的核心哲學，碰到困難的時候，都會引用這個哲學思想。

1????? 自動測試服務：讓單體應用健康地運行起來

通常來講，單體應用都是一個WEB服務，用戶通過瀏覽器訪問單體應用。單體應用在線給用戶提供服務，如下圖：

這個系統經過大量的內部測試以及用戶使用，運行穩定，只是在應對更大規模的用戶請求的時候，無法達到預期的吞吐量，系統處于一種相對“健康”的狀態。

當我們需要對一個處于相對“健康”的服務進行改造的時候，這種相對狀態就被打破了。任何對于穩定系統的修改，都可能引入新的問題，導致系統失去健康狀態。改造的第一個步驟，就是需要提供應對措施，讓系統不至于失去健康狀態。

解決方案是開發自動測試服務，可以自動的請求單體業務系統，并對請求結果進行判斷，檢查單體應用的功能是否正常。如下圖：

在實際的實踐過程中，最困難的事情是自動測試服務測試哪些內容，如何設計測試步驟，對于一些特殊場景，通過自動測試服務測試非常復雜；還有就是隨著測試用例的增多，用例之間相互影響，出現問題難于定位等，這些困難讓大量的開發人員望而卻步，所以很多系統都沒有對應的自動測試服務。在這里，“持續迭代演進”的哲學思想被第一次提及。

·???????? 自動測試服務在開始構建的時候，可以只測試單體業務系統的核心接口，比如登錄、支付等核心流程。

·???????? 在日常開發過程中，培養良好的開發習慣，持續的完善自動測試服務。比如在發現BUG的時候，將早期錯漏的場景測試，補充進去；完成新的需求開發，把新功能的測試用例加入自動測試服務里面去。

·???????? 盡可能只增加測試用例，不修改、不刪除測試用例。在必須修改、刪除測試用例的時候，盡可能多做評估，保證修改、刪除是必須的，可以和團隊成員一起評審后再修改和刪除。測試代碼可以大量重復，不需要為了測試代碼的美觀，頻繁的重構測試用例，必要的時候，可以開發一個新的自動測試服務，兩個服務同時測試，不用廢棄老的測試服務。自動測試服務可以是多個測試服務，還可以是多個相互之間存在強邏輯關系的一組服務，完全取決于測試場景和設計。

·???????? 自動測試服務用例運行失敗，馬上修復，優先于功能開發。

·???????? 自動測試服務不需要盡善盡美，盡最大努力測試能夠測試的內容。隨著測試能力的積累，以及對于自動測試服務的測試思路的調整，后續寫測試用例會越來越簡單，能夠自動完成的測試點也越來越多。

遵循以上的原則，構建和維護測試用例會一天比一天輕松，即使對于非常棘手的測試用例運行失敗，分析也會變得簡單。因為測試用例一直都是正常穩定通過的，那么每次失敗，都是和新的改動有關，而每次改動量非常小，把思路對準修改的影響就很快識別出問題所在了。

2????? 網關服務：彈性架構的基礎

改造過程中，需要保證每天下班前系統都是處于相對“健康”的狀態，即構筑的測試用例能夠全部運行通過。由于每天修改的內容通常并不會很多，早期涉及到服務拆分、重新設計等場景的時候，保證健康狀態并不是一個容易的事情。為了讓微服務改造的過程更加的順暢，首先在原有的系統架構上，引入網關服務。

網關服務提供一個代理，原來對于業務系統的直接訪問，都通過網關來訪問。增加網關服務具備如下的用途（需要具備如下功能特征）：

·???????? 將單體應用的功能隱藏在網關之后，當單體應用被拆分或者重構的時候，整個系統對外提供的功能保持不變。為了達到這個目的，網關服務需要能夠靈活的適配單體業務原來的通訊協議，同時要能夠適應拆分的微服務的新協議，并能夠根據用戶的請求，靈活的定制路由規則，將請求的流量按需轉移到拆分后的服務。

·???????? 網關服務能夠收集系統運行監控數據，比如接口的時延、用戶請求數、系統瓶頸等。這些數據是微服務拆分的依據。進行微服務拆分一般的依據有兩個：一是基于業務邏輯的劃分；一是基于運維數據的劃分。基于邏輯的劃分和微服務功能有關，實現不同功能的模塊可以獨立為一個微服務，比如用戶管理服務和訂單服務；基于運維數據的劃分更多的是性能考慮，比如將訪問頻繁的接口，單獨設計為一個微服務，以更好的給這個接口單獨分配更多的處理實例，或者將有狀態任務單獨拆分出來，提供更好的硬件資源來運行，提高單實例處理能力。

通過網關服務來適配內部服務的協議差異和定制化路由轉發，并收集系統的運行狀態，為微服務拆分、改造提供了技術基礎和改造依據。

3????? 服務拆分：基于業務邏輯和基于運維數據

構筑好測試體系和網關，就可以進行拆分了。微服務拆分可以逐步迭代的進行，拆分依據的輸入有兩個，首先是業務邏輯的需要，然后是運維數據揭示的性能優化的需要。對于一個單體應用，最快被識別出來的通常是和認證鑒權有關的功能，需要拆分出一個用戶管理服務。

有了網關的支持，實現用戶管理服務的功能可以分步驟迭代的進行。比如第一天實現login接口，當用戶訪問login接口的時候，就將請求路由到用戶管理服務上面來，其他請求仍然路由到單體業務系統，當所有測試用例都通過后，就可以逐步的刪除單體應用的相關接口。

微服務拆分的另外一個依據和觸發點，是運維數據來驅動的。比如用戶管理服務發現login接口訪問量巨大，而createUser等接口訪問量極小，那么可以將所有查詢相關的接口拆分為一個微服務，這個微服務進行無狀態設計，并且由于這個服務全部都是只讀接口，那么可以更好的使用緩存，避免對于數據庫的訪問。拆分后的服務具備更好的性能和適應能力。

通過網關路由調整，可以將查詢請求路由到查詢服務，修改、新增用戶等請求，路由到管理服務。查詢服務可以部署更多的微服務實例和更好的應用緩存，提升整體的吞吐量；管理服務由于寫操作可能存在并發訪問控制問題，擴容實例對于性能提升不明顯，可以選擇更好的硬件來運行這些服務。

隨著業務的規模擴大，拆分和優化會時刻發生，比如拆分數據庫解決數據庫瓶頸問題。自動化測試用例和網關服務為這些拆分提供了良好的保證。

4????? 使用CSE作為微服務化的開發框架

上面提供了一個“持續迭代演進”的方法學，CSE提供了一套開發框架，方便用戶能夠更好的應用這套方法學。使用CSE，能夠很好的進行測試服務的開發和多維度開發環境的管理。CSE的網關服務具備強大的性能統計數據，幫助用戶識別性能瓶頸；網關提供接口級別的兼容性轉發規則和基于URL匹配的轉發規則配置，能夠輕松的調整路由；同時還提供了強大的定制開發能力，嵌入認證、鑒權、重試等管控能力。

下面我們通過一個小項目，來演示CSE的這些能力。這個項目的地址：

https://github.com/huaweicse/cse-java-chassis-samples/tree/master/porter/porter_lightweight

開發者可以下載和使用這個項目。下面的功能說明，都是基于這個項目。

4.1????? 構筑自動測試服務能力

CSE提供了服務發現的能力，測試服務能夠自動發現網關服務和內部服務，它們都注冊在統一的服務中心。

這種發現能力的好處，使得自動測試服務，不僅可以以“黑盒”的視角從gateway訪問整個系統，還可以以“白盒”的視角直接測試內部的微服務。

通常微服務都提供了REST接口對外提供服務，以“黑盒”來測試內部服務，需要測試代碼，拼接HTTP消息，這樣測試代碼會顯得比較冗余。CSE提供了RPC和REST等多種書寫客戶端代碼的方式，能夠更加簡單的書寫客戶端代碼。

·???????? RPC方式訪問

@RpcReference(microserviceName???=?"hello",?schemaId?=???"hello") private?Hello???hello; System.out.println(hello.sayHi("Java???Chassis"));

·???????? Spring MVC RestTemplate格式

RestTemplate?template?=???RestTemplateBuilder.create(); template.postForEntity("cse://pojo/pojo/rest/dbgrinfo",???"test",?String.class)

·???????? 使用其他HTTP Client

此外，還可以使用第三方的工具，來調用。比如Apache Http Client等。

CSE作為一個微服務框架，自己的自動化測試體系也是基于CSE本身構建的。這些自動化測試的機制方式，開發者也可以在業務系統中參考。

ServiceComb的自動化測試服務?https://github.com/apache/servicecomb-java-chassis/tree/master/integration-tests

CSE的部分測試用例?https://github.com/huawei-microservice-demo/ServiceEngineIntegrationTest

4.2????? 分層的部署環境支持

為了更好的支持分層測試，一般會將測試環境分為Alpha、Beta、Gamma、Production等。每個環境測試的內容不同，環境穩定性不同。一些公共的中間件服務，可以不用針對每個環節都搭建，極大的減少環境搭建的時間。CSE提供了分層的邏輯隔離能力，不同環境的微服務可以同時注冊到一個服務中心，然后他們之間的訪問互不影響。

CSE提供的多環境支持可以參考

如何進行微服務的多環境開發部署?https://bbs.huaweicloud.com/forum/thread-11095-1-1.html

4.3????? 通過網關獲取監控數據

CSE提供了強大的監控數據能力，可以統計一個周期內的請求數，時延等信息，還能夠統計到處理環節的細節，比如發送請求和等待響應的時間等。這些數據對于性能分析非常關鍵。 下圖展現了少量的數據示例。

網關打開監控數據是非常簡單的，具體可以參考:

性能監控開發指導??https://docs.servicecomb.io/java-chassis/zh_CN/general-development/metrics.html

除了監控數據，網關還有access log，可以幫助識別調用失敗的環節。

0:0:0:0:0:0:0:1?-?-?Fri,?15?Feb???2019?11:06:15?CST?"POST?/api/user-service/v1/user/login?HTTP/1.1"???200?0?7 0:0:0:0:0:0:0:1?-?-?Fri,?15?Feb???2019?11:06:15?CST?"POST?/api/user-service/v1/user/login?HTTP/1.1"???200?0?8

AccessLog可以包含一個請求的trace id信息，詳細可以參考：

Access Log設計參考：?https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/access-log-configuration.html

4.4????? 通過網關管理路由規則

CSE網關路由管理能力非常強大，同時具備非常靈活的自定義能力。可以使用網關高效的處理使用CSE框架開發的微服務請求轉發，同時也能夠方便的擴展，將請求轉發到非CSE框架開發的微服務。

CSE在灰度發布支持上，能夠做到智能識別接口兼容性轉發，具體示例如下：

CSE能夠識別每個微服務實例包含哪些接口，當請求高版本接口的時候，能夠自動將請求轉發到高版本實例里面去。這樣的路由技術，可以很好的支持灰度升級，當provider/consumer都更新了部分新實例的時候，不用擔心由于新consumer請求到老provider而導致故障。

CSE還提供了基于服務名和URL前綴的路由轉發規則，通過配置文件即可啟用。還提供了實例隔離、錯誤重試等可靠性保障措施。可以通過參考開發指南：

負載均衡管理參考??https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html

結合這些能力，可以輕松的實現：

升級零中斷?https://bbs.huaweicloud.com/blogs/72a312f09c8911e89fc57ca23e93a89f

4.5????? 專注于業務功能開發

除了上面的一些特性，來支持單體改造，CSE還提供了大量的平臺功能，讓業務能夠專注于業務邏輯開發，而不需要開發可靠性、服務管理、服務運維等方面的功能。下面挑選一些代表性的功能。

·???????? 高性能和高可靠

CSE提供了非常高效的REST通信實現，目前是開源微服務框架里面最高效的REST實現，在普通的4U8G虛擬機，單實例能夠到達5萬以上的吞吐量。

CSE運行框架在實例發現保護、實例隔離、錯誤隔離和重試、線程池隔離等方面也提供了強大的保護能力，通常用戶不需要開發任何代碼，系統默認就集成了這些健壯性特性，即使用戶需要定制，一般也只需要簡單的修改配置項就能夠實現。比如實例隔離的配置項：

cse: ??loadbalance: ????isolation: ??????enabled:?true ????????enableRequestThreshold:?5 ????????singleTestTime:?60000 ????????continuousFailureThreshold:?2

該配置項定義了隔離的條件，以及隔離的時間。再比如重試配置項：

cse: ??loadbalance: ????retryEnabled:???false ????retryOnNext:?0 ????retryOnSame:?0

配置項定義了是否開啟錯誤重試以及重試策略。CSE的大部分策略，不僅可以全局配置，還可以針對微服務配置，只對微服務生效。有些配置項還支持對具體的接口配置，只對接口生效。

cse: ??executors: ????Provider: ??????[servicename:schemaid.operationId]:???cse.executor.reactive

該配置對微服務servicename的schemaid（class對應的類）的operatioinId（對應方法名）配置了單獨的線程池，避免其他服務的運行對這個接口的執行產生影響，起到了故障隔離的作用。

·???????? 在線的中間件服務

下圖展現了CSE開發SDK的內部功能及其和云上服務之間的關系。業務通常只需要使用SDK開發業務服務，注冊發現、集中配置、運維監控等能力，都可以直接使用云上服務，完全開通即用，省去了開發者的部署、運維成本。

云上服務都提供了高可用設計。注冊發現、集中配置等服務，還通過API Gateway進行了能力開放，開發者可以在云下連接和使用這些服務，這樣用戶可以在本地進行微服務應用開發。

·???????? 微服務治理管控平臺

登錄華為CSE平臺:

CSE平臺?https://console.huaweicloud.com/cse

該平臺可以對CSE SDK開發的微服務進行在線管理、監控和治理。

微服務治理管控平臺的主要功能是服務治理，該功能可以在線對微服務進行動態策略調整。包括動態調整限流策略、負載均衡策略等。通過應用這些策略，可以在不升級微服務的情況下，應對一些常見的突發業務。比如在某個大型活動過程中，通過對非關鍵業務的限流來保障關鍵業務的平穩運行。

微服務管控平臺還提供了其他重要的功能，包括一鍵式購買微服務引擎、微服務目錄，儀表盤等功能。

·???????? DevOps支持

ServiceStage?https://console.huaweicloud.com/servicestage

ServiceStage提供了一站式DevOps平臺。通過ServiceStage可以托管源碼，創建流水線，部署應用，管理用戶網絡、計算和存儲資源。ServiceStage還集成了容器、虛機能力，可以管理應用的動態擴縮容。可以通過“體驗中心”來了解ServiceStage功能，這里不再詳細介紹。

微服務引擎 CSE 微服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。