如今，很多企業都在進行微服務架構重構，問題是微服務到底是不是最佳選擇？如果選擇沒有問題，微服務在什么時候用?重構之后的技術路線和之前是怎樣一種關系？我們應該以什么樣的方式，把之前和之后的技術結合起來……相信，這些都是很多開發者在微服務重構過程中，必然會遇到的問題。
在筆者看來，企業在部署架構的時候，看似是遇到問題，解決問題， 但其實要秉承一個原則，那就是“以始為終”，在開始出發前就要知道終點在哪里。具體到微服務架構重構，根本目的是要解決當前架構的問題，最終能讓系統支撐業務高質量發展。
重構不可避免
首先，開發者需要明確的一點是，重構不可避免。不管是復雜的應用系統，還是任意一個App，甚至是類似于office這樣的軟件，都有自己的生命周期。在漫長的生命周期里，業務和需求都在不斷變化，最后的需求和最開始的設計，已經完全不一樣，當系統現狀和大家的認知有嚴重沖突的時候，不重構系統，軟件就難以繼續維護開發下去。另外，技術開發本身也在不斷變化，比如：在代碼層需要不斷引入新代碼，加入了很多冗余的內容，變得僵硬、脆弱、難以維護，需要開發周期越來越長，Bug越來越多，所以重構成為必然結果。
以具體微服務實踐為例，隨著長時間、多地輾轉，功能越做越大，已經沒人了解最初的設計思路和項目初衷；但有一個有意思的現象是，大家在開發新功能的時候，都喜歡把功能放在這個微服務里，開發迭代速度逐漸變慢，Bug環比穩中有升。換言之，隨著功能的增加，該微服務退化成了單體架構。
雖然，我們今天都在談微服務，但其實不管是單體架構還是微服務，都各有優缺點。比如:單體架構雖然不夠靈活，但好處是緊湊，你想要什么變量，直接調用對象就可以了，內存是共享狀態，使得功能開發變得簡單。既然這樣，為什么要重構呢？答案是，業務發展是最大推動力！當業務方準備進行一次較大規模的新業務嘗試，新業務形式上有很大變化，不過核心業務功能變化不大，但研究團隊發現服務復用很困難。
用領域驅動設計驅動系統重構
那么，我們到底以什么樣的方式去設計我們的系統？
當項目簡單的時候，有兩種開發方式：一種是CRUD Design，增刪改查，有什么做什么；另一種DomAIn Driven Design，就是我們常說的DDD領域驅動設計。項目簡單的時候，CRUD開發成本更低，而DDD設計模式需要把業務領域分析清楚以后，做合適的服務分析，做合適的對象設計，進而通過合適的領域設計去完成。
值得一提的是，CRUD和DDD會有一個交叉點，而業務最終的演進方向一定會向復雜的方向發展。尤其是互聯網項目，開始只是做一些簡單的業務邏輯實現，之后隨著業務的發展，會變得越來越復雜，傳統開發方式就會變得艱難。
所以，在使用微服務之前，一定不要指望微服務能做什么，微服務不是靈丹妙藥，也不是尚方寶劍，不能解決一切問題。
微服務重構復盤
通過微服務進行系統重構，大概需要六個步驟：
第一，把當前系統設計與問題匯總討論。比如：架構與代碼混亂，需求迭代困難，部署麻煩，Bug頻率逐漸升高等等，都匯總在一起。
第二，針對問題分析具體原因。微服務A太龐大，微服務B和C職責不清，團隊內業務理解不一致，內部代碼設計不良，硬編碼和耦合太多……尋找這些問題的具體原因。
第三，重新梳理業務流程，明確業務術語，進行DDD戰略設計。比如：活動圖，子域分解，限界上下文設計等等，理解這些專業用語，用于戰略設計。
第四，針對當前系統實現和DDD設計不匹配的地方設計微服務重構方案。
第五，DDD戰術設計與技術驗證，比如：聚合、實體、值對象設計、打樣代碼開發。
第六，任務分解與持續重構，在不影響業務開發的前提下，按照戰略與戰術設計，將重構開發和業務迭代有機結合。
需要重點強調的是，不管是微服務，還是單體服務，任何技術都一樣，都是解決特定問題的一個具體方法。而其中，微服務的正確解法是，先分析問題，再找合適的方案。大體來看，微服務的真正難點不是技術，而是業務。技術問題解決起來非常容易，但業務問題不好梳理。企業需要先解決業務問題，重新梳理業務，再找合適的工具和方法。
