微服務改造設計參考

【摘要】 本文總結微服務改造相關的可行性分析、工作量評估、設計思路等問題，供選型參考。典型的場景包括將Servlet應用改造為CSE、Dubbo改造為CSE、Spring Cloud改造為CSE等。同時給開發者提供了一些開發建議，使得自己的業務系統能夠更好的切換開發框架。

本文總結微服務改造相關的工作量評估、設計思路等問題，供選型參考。典型的場景包括將Servlet應用改造為CSE、Dubbo改造為CSE、Spring Cloud改造為CSE等。本文主要描述一些通用性問題，不涉及具體的場景，但是在舉例的時候，會使用具體的場景作為例子。

關于不同框架改造的注意事項和案例文章：

1.Dubbo改造為CSE
案例一：https://github.com/huawei-microservice-demo/SpringCloudIntegration/tree/master/dubbo-migration

案例二：https://github.com/seanyinx/dubbo-to-servicecomb

2.Spring Cloud改造為CSE：

案例一：https://huaweicse.github.io/cse-java-chassis-doc/spring-cloud-using-cse/spring-cloud-using-cse.html

3.CloudSOP改造為CSE
案例一：http://3ms.huawei.com/km/groups/2912737/blogs/details/2509223

案例二：http://3ms.huawei.com/km/groups/3257141/blogs/details/5096421

工作量和可行性評估

業務需要將一個開發框架換成另外一個開發框架的時候，通常的期望是保留業務處理邏輯，而丟棄框架的運行時。最理想的情況，是業務邏輯代碼原封不動，不做任何修改，平滑的將運行時切換過來，比如將業務代碼的war包，從Tomcat容器切換到Jetty容器。

以war應用為例，可以看看war應用和容器之間的依賴關系：

采用一個框架，必然存在和框架功能有交互的地方，在這里的主要內容就是服務發布部分。由于Tomcat容器和Jetty容器服務發布都支持相關的協議和規范，因此業務代碼可以完全平滑的進行遷移。

對于其他業務代碼部分，比如處理流程、數據訪問等，需要考慮目標系統是否支持運行這些組件，如果支持，那么這些代碼不涉及修改，可以平滑遷移。

如果業務代碼使用了對應容器提供的工具API，那么像Tomcat容器遷移到Jetty容器的場景，也可能需要代碼改動，業務切換變得不平滑。

當出現目標框架不支持運行依賴的組件，或者服務發布方式沒有對等的方式、工具API沒有對等的API支持的時候，這種切換就會變得不可行。當然實際在選型分析的時候，非常難把握一些細節的不支持情況，不過倒不用悲觀，實現一個業務邏輯的方式是有多種可能性的，換一種實現思路去調整實現邏輯，也能夠解決單純從技術上看，無法對等改造的問題。

工作量評估

從上面以war應用在不同運行容器之間的改造可以看出，一個框架改造為另外一個框架的工作量可以從兩個維度進行評估：

改造前的業務代碼依賴于原來框架的程度。

目標框架本身對于業務代碼采用的技術的支持程度。

再看一下上面例子中，CSE框架的情況。

可以看到，和war應用對比，服務發布的方式變化了。提供的API變化了。將war應用切換為CSE的工作量主要包含兩部分：

將服務發布方式修改為CSE的服務發布方式，即將Servlet定義修改為Spring MVC或者JAX RS或者RPC的方式。

調用工具API的地方，需要分析CSE SDK是否有對等的替換方案，使用CSE SDK提供的API進行修改。

下面表格結合上面的分析，簡單的評估了一下各個框架切換CSE的難度對比。這個難易程度只是近似的評估，主要考察可能的改動點多少。工作量的評估的一個很重要要素是原來業務系統本身在處理平臺依賴上的成熟度（依賴的多少和程度），這個工作量不再這里評估，盡管這個可能是導致工作量最重要的因素。

當前框架目標框架難易程度（相對分數）

對開發者的建議

在上面的難易度評估矩陣中，有一個協議gRPC需要特別提到一下。在所有的框架中，將代碼切換到gRPC，都是最難的，但是將gRPC切換為其他框架，都是最容易的。一般的，如果一個框架滿足如下特性：

更加貼近業務代碼的書寫形式，比如采用RPC的方式對外發布服務；

更多的跨語言方面約束；

更少的平臺API

那么其他框架改造為這個框架會更加難，但是這個框架改造為其他框架更加容易。

因為特性1，在切換為其他框架的時候，只需要將接口以其他框架的形式包裝一次，不涉及任何代碼修改；

因為特性2，可以適配更多的接口約束和更多的序列化方式，支持的框架更多；

因為特性3，不涉及平臺API的整改和對等切換。

很多業務都會考慮對于平臺綁定的問題，特別是那種需要長期發展的業務。因為平臺技術日新月異，變化的場景驅動業務采用更加先進的架構技術改善業務的運行狀況，比如JAVA技術的從Osgi到J2EE到WEB到微服務框架。那么業務如何去適應這個變化了？上面3個特性實際上給了一個指引。另外就是還需要加上：

盡可能符合標準協議的約束。

這條規則和構造WEB應用選用那些功能一樣的。在書寫HTML的時候，盡可能的遵循HTML4、HTML5規范，能夠讓網站在更多的瀏覽器上精彩的呈現。

更好演進的另外一個方面，就是開發限制。這塊無疑會增加開發者的成本，需要學習更多的規范和培養更好的編碼技能。有些業務場景，還必須使用平臺特性去解決。這些復雜性都不會讓我們的代碼完美，總是在一個權衡和妥協中發展。

下面提供了一個代碼設計方面的模式，這種模式解決了發布形式的切換問題，而且業務是可以快速遵循的。業務代碼按照這樣的模式進行組織，并且在接口定義上盡可能考慮跨語言數據結構（主要指數據類型），那么這種業務代碼在配套平臺升級的時候，將會是最快速的。

邏輯結構：

代碼示例：

總結

結合上面的觀點，所有框架不會在各種方面都是完美的，CSE SDK在靈活性方面的折中做得非常的出色。通過提供業務代碼的書寫習慣支持大大減少了切換為CSE的工作量，同時后續如果將CSE遷移到其他框架，相對來講也是非常容易的。

更多精彩內容，盡在“微服務蜂巢”公眾號