微服務的優勢衆多，在現在如果有誰沒有聽過微服務架構，可以從這裏瞭解一下。本文主要聊一聊是否值得花時間將單體架構重構爲微服務架構？
微服務架構是一種架構風格，專注於軟件研發效能，主要包括單位時間內實現更多功能，或者軟件從想法到上線的整個持續交付的過程。在當前的互聯網環境中，業務變化迅速，也促使了微服務架構的普及。這種架構迫使團隊迅速反應，快速實施，在方案沒有過期之前已經上線運行，經受市場考察和考驗。
目前國內大多數公司正在運行的系統都是單體架構系統，不可否認，這些系統在公司發展過程中，發揮了不可替代的作用，保障了公司正常運行，創造了很多價值。但是，隨着系統的日漸膨脹，集成的功能越來越多，開發效率變得越來越低，一個功能從想法到實現，需要花費越來越長的時間。更嚴重的是，由於代碼模塊糾結在一起，很多已經老化的架構或者廢棄的功能，已經成爲新功能的阻礙。
衆所周知，單體架構隨着功能增多，不可避免的是研發效能的降低：研發週期變長、研發資源佔用增多。從而引發的情況是：新員工培訓時間增多、員工加班時間變長、員工要求漲薪或者跳槽。到了這種情況就說明，單體架構已經不能夠滿足企業發展需要，這個時候，需要升級架構來提升研發效能，比如微服務架構。
想要說明微服務架構的好處，可以來一個比喻。我們建了一個空間站，爲此，我們需要將人、貨物和設備運輸到空間站中，這個時候，運載火箭是表較好的選擇，儘管運載火箭造價也比較高，但是幾個月發射一次，也能夠滿足需求。隨着空間站的擴大，火箭發射的間隔變短，運輸成本高的離譜，而且越來越沒法滿足空間站運轉需求。這個時候，可以嘗試另外一種方式，比如，太空電梯。當然太空電梯的造價成本高於一次飛行的費用，但是隻要建成，以後的成本就降低了很多。
這個比喻也是說明了微服務帶來的美好期望，同時也說明一個問題，實施微服務架構會帶來巨大的投資。所以，我們在建造太空電梯之前需要想好，我們真的需要這種投入，否則是能是一種浪費。
to be or not to be
決定從單體架構升級爲微服務架構時，先問問自己下面幾個問題：
- 產品或系統是否經過市場考驗
- 是否需要超過一個團隊來保證產品發佈
- 系統是否對可靠性、可伸縮性有較高要求
微服務架構
什麼是微服務架構呢？Sam Newman認爲是：“一組圍繞業務領域建模的、小而自治的、彼此協同工作的服務。”
微服務架構中的服務，是根據業務能力抽取的業務模塊，獨立開發和部署，但是需要彼此配合完成整個業務功能。服務不是單純的數據存儲組件，那是數據庫。也不是單純的邏輯函單元，那是函數。只有同時包括數據+邏輯，纔是真正意義上的服務。
服務邊界
服務拆解過程中，DDD（領域驅動設計）可以作爲微服務架構的指導方針。因爲微服務是圍繞業務功能定義服務，根據服務定義團隊，這與DDD將業務域拆解爲業務子域、定義限定上下文的方法論如出一轍，於是DDD作爲微服務的指導方針，快速定義各個服務組件，完成從單體架構到微服務架構的遷移。
Alberto Brandolini提出識別服務上下文的方式叫做“Event Storming”。第一步是識別業務域中發生的事件，也就是說，我們的關注點是行爲，不是數據結構。這樣做的好處是，系統中不同服務之間是鬆散耦合關係，而且單個服務能夠自治。
定義好了服務邊間，還需要定義事務邊界。過去，我們的服務在一個進程中，後面掛着一個數據庫，事務可以選擇強一致性事務，也就是ACID。當服務增多，彼此配合，這個時候可以使用最終一致性事務，也就是BASE。不同於ACID，BASE更加靈活，只要數據在最終能夠保持一致就可以了。這個最終的時間範圍，根據不同的業務場景不同，可能是分鐘、小時、天，甚至是周或者月。
準備工作
微服務架構願景美好，屬於重型武器，優點衆多，缺點也很明顯。服務增多，運維難度增大，錯誤調試難度增大。所以需要自動化構建、配置、測試和部署，需要日誌收集、指標監控、調用鏈監控等工具，也就是需要DevOps實踐。實現DevOps的三步工作法中說明了實現DevOps文化的三個步驟。
除了上面提到的基礎，還需要在早期確定服務之間如何集成和彼此調用方式，還需要確定數據體系，包括事務一致性和數據可靠性方法。隨着服務增多，還需要配置管理、服務發現等衆多組件。具體需要的基礎組件可以參考微服務的基建工作。
這些基礎的服務和設計，最好在早起定義，否則，後期需要花費更多的資源才能夠完善架構。如果前期缺失，後期也沒有補足，造成的後果就是微服務架構遷移失敗，最後的系統也只是披着微服務外衣的單體架構。
進化還是革命？
定義好服務邊界之後，還有一個問題需要解決：是逐步進化更新系統、還是破釜沉舟重構整個系統。
第二種方式很誘人，比較符合大多數程序猿的思維，系統不行，推倒重來，名爲重構。但是在大多數情況下，這種方式不能被允許，因爲市場變化迅速、競爭激烈，大多數公司不會停止業務，去等待重構一個能夠運行、只是有些缺點的系統。所以，逐步提取更新系統纔是王道，大多數公司也能接受。這種方式又被稱爲絞殺模式。
Transformation
該如何逐步過渡到微服務架構？下面一步步進行展示：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-iMdUUCj7-1584889654137)(https://www.howardliu.cn/images/microservice/from_monolith_to_microservice_0.png)]
第一步，將用戶視圖層與服務層部分邏輯進行分離。業務邏輯委託給服務層，支持頁面展示的查詢定向到數據庫。這個階段，我們不修改數據庫本身。
第二步，用戶視圖層與數據庫完全分離，依賴於服務層操作數據庫。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Iiu0S778-1584889654138)(https://www.howardliu.cn/images/microservice/from_monolith_to_microservice_2.png)]
第三步，將用戶視圖層與服務層拆分爲不同服務，並在服務層創建一個API層，用戶視圖層與服務層之間通信。
第四步，拆分數據庫，將不同業務數據拆分到不同的數據庫中，同時對應業務服務層拆分到不同的服務。用戶視圖層通過API網關與不同業務服務層的API組件通信。這個時候需要注意，如果團隊沒有微服務開發經驗，可以首先抽取簡單業務域服務，因爲業務簡單，實現簡單，可以練手，積累經驗。
最後一步，拆分用戶視圖層。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-BjwOquVB-1584889654139)(https://www.howardliu.cn/images/microservice/from_monolith_to_microservice_5.png)]
絞殺模式的優勢就在於，我們可以隨着業務變化隨時調整方案，不會造成整個業務進化過程的停擺。
成功標準
當我們完成了整個升級過程，就需要檢查一下我們是否達到了預期的結果。引入微服務的目的首先是改善開發流程，我們可以通過簡單的指標來衡量：
- 開發週期：從概念到上線持續的時間
- 開發效能：單位時間內團隊或個人完成的功能或用戶故事
- 系統可伸縮性
- 平均維修時間：查找和排除故障所需時間
通過對比老架構和新架構的這些特性值，可以評估升級過程取得的效果。當然，升級過程中也要有這些指標的監控。
最重要的事
作爲攻城獅，我們爲能夠解決或改善周圍世界而自豪，着迷於提供解決方案。同時，我們也要意識到，我們付出的每一份努力，都要有回報。如果不能帶來任何回報的重構升級，都是浪費時間。
個人主頁: https://www.howardliu.cn
個人博文: 從單體架構到微服務架構
CSDN主頁: http://blog.csdn.net/liuxinghao
CSDN博文: 從單體架構到微服務架構