微服務架構是當前IT行業最流行的架構設計方案。微服務確實解決了軟體開發中的一部分問題。服務自治，職責單一，可獨立交付的特點也契合了敏捷開發的思想。

設計一個全新的系統可以考慮用微服務架構，歷史遺留系統也有必要逐步往微服務架構演進，來提升整個架構和產品的競爭力。

筆者參與了對一個歷史系統部分模組做服務化改造的專案。接下來談一談改造過程中的思考和策略。

簡單說一下專案背景，筆者加入的開發團隊維護著兩套系統，一套是web系統，一套是單機桌面工具。隨著業務的發展，後面桌面工具的功能要往web系統上遷移；同時單機工具也有它的應用場景，短期不會下線。考慮到相同的功能在web系統再實現一次，後續維護兩套系統成本很高，決定對桌面工具的部分功能做服務化改造。改造後的微服務既可以部署在linux伺服器上供web系統呼叫，也可以隨桌面工具的安裝盤打包部署到客戶的window筆記本上使用。Web系統是用java開發，桌面工具是用c#。

在設計服務化改造方案時筆者考慮了這幾個方面:1:開發語言的選擇。2: 服務部署形態。3:開源元件選型。4:服務改造計劃。5:服務劃分。6: 團隊協作。這個系統不涉及資料的遷移。

一、選擇開發語言

選擇開發語言時主要考慮了兩方便：一是歷史遺留系統採用什麼開發語言，二是當前開發人員的技能。新服務跟歷史系統採用相同的開發語言好處是有大段的邏輯程式碼可以複用，不用全部重寫。但如果歷史系統採用的是比較落後的開發語言，或者說跟當前已有的微服務平臺不相容則需要切換。

由於web系統已經是用java開發了，所以改造這部分也準備用java來重寫。

二、服務部署形態

改造後的服務要同時支援伺服器叢集部署和單機工具部署兩種方式。這兩方的要求不一樣，部署的環境有差異，所以設計了兩套介面，通過url來區分。介面下面的具體實現是一樣的，邏輯程式碼是重用的。

在伺服器部署時發到docker容器，通過swarm叢集排程。部署在window單機桌面時服務隨客戶端工具一起釋出，安裝包帶一個jre。啟動程式時把jar啟起來，關閉時殺程序。

在伺服器部署時客戶層通過域名遠端呼叫restful介面，在單機部署時通過localhost呼叫rpc介面。

三、開源元件選型

已有的微服務都是用spring boot搭建的，新服務沿用。

四、服務改造計劃

對歷史系統做服務化改造相當於架構級的重構，複雜度和風險都非常大。通常老系統還線上支撐業務，服務化改造的過程不能中斷業務。老系統還在維護，還有新需求納進來，服務化改造的同時還要實現新需求。

在一段時間內團隊會面臨雙線作戰，壓力非常大。這種情況下做好改造計劃很重要。飯得一口一口吃，我們先把一些功能比較獨立的模組拿出來改造，如資料清洗，工程管理等，這部分功能前後依賴關係比較小，而且是改造完後兩邊的系統都能立馬用得上。具體改造哪一部分還得看需求，看業務。

五、服務劃分

服務劃分既要考慮業務特性，也要考慮部署形態。如果我們只考慮伺服器部署，根據服務的職責單一要求會劃分出多個微服務，但是考慮到改造後的微服務還要給單機工具使用。單機工具資源有限，服務太多，佔用的記憶體，部署複雜度都會很大。最終決定將多個功能的實現放在了一個服務中，編譯成一個jar包。

在這種情況下做好開發檢視的隔離很重要，筆者的做法是在同一個JAVA工程裡面建不同的package做隔離，按功能特性分為資料清洗，工程管理，資料匯入加common這幾塊。每塊下面都有自己獨立的controller，service，model，mapper。程式碼做好隔離，相互不影響，後面交給了不同人開發。公共的東西放到common下面。

資料庫建表時給表名加上字首來區分是領域的還是公共的。如:tbl_project_xxx，tbl_common_xxx等。

這樣做保證後面如果還需要拆分，可以很方便。拆分時只要帶上自己的東西加common模組就可以了。

六、團隊協作

我們吸收了老系統的部分開發人員投入到服務化改造中。服務化改造除了需要解決技術問題，還要需要考慮團隊管理的問題。業務面臨轉型，老技術更新，如何激發團隊也是要考慮的。在筆者經歷的專案中，老系統是用c#開發，很多開發人員對java不熟，但是他們是業務專家，趟過很多雷，填過很多坑，懂客戶需求，是真正的老司機。服務化改造離不開他們。

如何把老員工的力量利用起來很關鍵。筆者的做法是先自己搭建好java微服務框架，給他們講解spring boot如何使用，如何用jenkins部署，如果在kabana上檢索日誌定位bug。他們都是老程式設計師，也願意學新技術，很快就掌握了。程式碼的規範性在開發過程中隨時糾正一下。公司有程式設計規範文件，發給大家學習。

在制定介面過程中要求大家制定每一個介面都要考慮在服務端如何呼叫，在單機工具如何呼叫。介面成熟後，全部切換到調新服務介面，原有的c#程式碼就不維護了。這樣保證大家儘快吃上自己的狗糧，有問題能及時發現。同時做到只維護一份程式碼，減輕了維護壓力。

老系統服務化改造是對開發團隊，管理者，技術骨幹的考驗。也考驗公司領導的決心，畢竟從使用者層面看不到重構帶來的價值。但服務化改造本身的價值是毋庸置疑的，提升了軟體的擴充套件性，維護性。

是否做服務化改造還是要看軟體系統自身的定位。如果是做一次性的專案，能用就行，沒必要花大力氣去改造。如果是做產品，軟體系統生命週期很長，這個投入是值得的。