從單體架構遷移到微服務

随着微服務架構的持續火熱，網絡上針對微服務和單體架構的讨論也是越來越多。去年的時候，社群更多的關注點是在二者的差別以及優缺點辨析上，而今年，越來越多的人開始關注如何從單體架構遷移到微服務上。毋庸置疑，微服務的理念正在席卷整個開發者社群，像Netflix、Uber這樣的公司都是非常成功的應用案例。

但需要注意的是，實施微服務，也需要付出額外的代價，Martin曾經就說過，除非面對的是一個過于複雜以至于難于管理的單體應用，否則絕對不要考慮使用微服務。大多數的軟體系統應該建構為獨立的單塊程式。確定注重單體應用自身的子產品化，而不要試圖把它們分離成單獨的服務。

普元軟體産品部技術經理劉相在微服務架構上有很多的實踐和思考，InfoQ記者就單體應用遷移到微服務的8個關鍵問題對他進行了專訪，内容涵蓋傳統單體式架構的挑戰、實施微服務架構的鋪墊、改造原則、資料庫、中間件、分布式事務、風險規避等。

InfoQ：就你目前的觀察來看，企業為什麼要從單體式架構遷移到微服務架構？他們遇到的最大的問題是什麼？

劉相：我所服務的企業多為傳統企業，代碼在100萬行的項目比比皆是，龐大複雜的項目使得開發、測試、維護、運維極度複雜，在彈性、擴充性、可維護性方面也困難重重。除此之外，傳統單體式架構遇到的問題還有：

1、團隊接手困難

8年前，我曾接手一個100萬行級别的項目，那段經曆算是一段噩夢：花了3個月的時間通讀一遍代碼；每次修改代碼心驚膽戰，修改一個Bug極可能帶來各種隐含的缺陷。

2、臃腫的部署

單體應用每次功能或者缺陷的變更導緻重新部署整個應用，這種部署方式影響大、風險高，決定了部署頻率低，導緻兩次釋出之間有大量的功能或者缺陷需要進行變更，出錯機率增高。

3、局限的彈性與擴充能力

單體應用作為一個強耦合的整體，無法根據業務功能伸縮，隻能作為一個整體進行擴充。這造成資源浪費，同時無法針對不同業務子產品的特性進行有針對性的伸縮，比如計算密集型服務、IO密集型服務。

4、阻礙技術革新

團隊對新技術的渴望是不言而喻的，團隊士氣會因為持續的關注在巨石應用的技術棧而降低；單體式架構下的組織通常來說技術選型非常單一，團隊技術能力相對單薄，團隊的吸引力一般。

除此之外，對于服務等級、安全要求、業務監管等多個次元均需要針對不同的服務實作不同的治理，遷移到微服務架構成為必然。

InfoQ：微服務有它固有的優勢，但對企業的基礎設施以及團隊要求也比較高。你認為在企業準備遷移到微服務架構前，需要做好哪些準備？

劉相：企業遷移到微服務架構前，零号原則就是對業務充分了解，大量企業因曆史原因導緻了解業務系統了的人屈指可數時，就試圖轉向微服務架構，即使采用最好的技術、工具、架構、團隊，最後都會摔得很痛（造成無休止的拆分與變更）。

在充分了解業務的前提下，我認為向微服務遷移，還需在如下三個次元準備：

1、償還技術債務

自動化測試、持續內建與自動化部署是向微服務架構大規模遷移前必須補償的技術欠債。微服務架構下，團隊管理大量服務，其複雜度和測試難度是幾何級增加，利用自動化測試能幫助團隊快速有效的驗證應用；持續內建與自動化部署保障團隊更快速、更容易的修改代碼，缺少持續內建和自動化部署，向微服務架構轉型過程會異常痛苦。

2、新的架構設計原則

采用微服務架構，應用傳遞高度複雜化。架構設計原則需要從原來單體式架構下的關注功能、性能等次元向MVP（最小可用産品）、面向失敗的設計（擁抱失敗，而不是阻止失敗）、寬進嚴出（對請求寬進嚴出，對外的響應要嚴格規範化）、甯花機器一分，不花人工一秒（自動與自助、複雜重複的事情交給平台工具去做，讓程式員去做更有價值的事情）、一切皆資源等設計原則轉變，形成架構漸進優化的設計風格。

3、團隊變革

《Exploring the Duality Between Product and Organizational Architectures》書中給了一個很有意思的觀點，組織的耦合度與系統的子產品化成正比。即組織耦合度越高，所開發的産品耦合度越高；組織耦合度越低，所開發的産品耦合度也越低。微服務架構本質上在強調松耦合的架構，是以在微服務架構遷移前，我們有必要對組織進行微調（不要變革，對組織影響很大），確定獨立的、小的團隊傳遞一個微服務，同時小團隊是微服務的Owner（除了負責開發外，同時負責測試和運維）。這會極大提供團隊的責任感，加速微服務的自治和傳遞能力。

InfoQ：在整個的架構改造過程中，你覺得有哪些可以遵循的規則？

劉相：微服務架構改造原則業界已經總結非常多了，包括：基于業務進行拆分、采用自動化文化、去中心化、服務獨立部署、服務完全自治、隔離失敗、漸進式拆分、避免大規模改造原有代碼等原則，這些原則相信關注微服務架構的已經相對清楚。結合我們具體的實踐，提供一些實際微服務化改造時經驗總結：

1、先分離資料庫、後分離服務

資料模型能否徹底分開，決定了微服務的邊界功能是否徹底劃清。我們已經見過太多直接從服務分離而造成多次重構和返工的案例；

2、采用“絞殺者模式”

對于無法修改的遺留系統，推薦采用絞殺者模式：在遺留系統外面增加新的功能做成微服務方式，而不是直接修改原有系統，逐漸的實作對老系統替換；

3、建立統一的日志規範

規範整個系統而非微服務的日志體系，采用标準的日志格式非常便于後續的日志聚合檢索，便于整體的視角分析、監控、檢視系統；

4、選擇成熟架構

同時做兩件不可控的事情（微服務改造、新技術的沖擊）注定項目成功機率較低，千萬避免自己重複發明輪子，盡量選擇市面上成熟的開源技術架構進行支撐，比如Spring Boot、Spring Cloud、Netflix、WildFly Swarm、Docker、Kubernetes等架構；

當然還有很多的細節規範，比如前後端分離原則、采用全局唯一流水号原則實作全鍊路交易跟蹤、如何進行服務的文檔化管理及服務測試Mock等。

InfoQ：資料庫方面是不是有應該做相應的調整？

劉相：這個話題非常有意義，微服務改造，第一件事情就需要針對資料庫模型進行拆分，資料模型邊界劃清後，服務順利成章容易劃清界限。我們實踐過程中強烈推薦的原則是一個微服務對應一個庫。當然，随着微服務規模壯大，可以針對性的做讀寫分離；如果單表資料龐大，可以分表來解決。

InfoQ：如何解決分布式事務一緻性呢？

劉相：微服務架構下，完整交易跨越多個系統運作，事務一緻性是一個極具挑戰的話題。依據CAP理論，必須在可用性（Avaliablitity）和一緻性（Consistency）之間做出選擇。我們認為在微服務架構下應選擇可用性，然後保證資料的最終一緻性。在我們的實踐中總結出了三種模式：可靠事件模式、業務補償模式、TCC模式。

可靠事件模式：可靠事件模式屬于事件驅動架構，當某件重要事情發生時，例如更新一個業務實體，微服務會向消息代理釋出一個事件，消息代理向訂閱事件的微服務推送事件，當訂閱這些事件的微服務接受此事件時，就可以完成自己的業務，可能會會引發更多的事件釋出。

業務補償模式：補償模式使用一個額外的協調服務來協調各個需要保證一緻性的工作服務，協調服務按順序調用各個工作服務，如果某個工作服務調用失敗就撤銷之前所有已經完成的工作服務。要求需要保證一緻性的工作服務提供補償操作。

TCC模式：一個完整的TCC業務由一個主業務服務和若幹個從業務服務組成，主業務服務發起并完成整個業務活動，TCC模式要求從服務提供三個接口Try（負責資源檢查）、Confirm（真正執行業務）、Cancel（釋放Try階段預留的資源）。

三種模式的詳細介紹可以參見同僚田向陽的微課堂文章：

• 微服務架構下資料一緻性保證（一）：http://dwz.cn/3TVFHs
• 微服務架構下資料一緻性保證（二）： http://dwz.cn/3TVHBW
• 微服務架構下資料一緻性保證（三）：http://dwz.cn/3TVJaB

InfoQ：中間件是否需要做調整，或者重新規劃很多新的中間件？

劉相：對于現有中間件，套用Gartner流行的一個詞“雙模”，比如MySQL、Redis等中間件适合作為微服務獨立出現；對于大塊頭Oracle、DB2資料庫或者諸如Queue的産品，不适合作為獨立微服務出現，可以采用內建的方式工作。

微服務架構需要和新的中間件平台提供融合，比如IaaS平台、PaaS平台等。當然在微服務架構内部，有大量新的中間件的産品，比如etcd、motan、resteasy、ELK等。

對于中間件的使用，我們一直保持一個原則：業務邏輯放在服務中，盡量保持中間件的簡單。

InfoQ：整個改造過程中，你認為應該如何規避風險以保證平滑過度？

劉相：微服務架構遷移在業務上、技術上都充滿了挑戰。從規避風險的層面來講，給大家兩點建議：

1、重視營運平台建設

在實施微服務改造前，建議先行搭建好營運支撐平台，平台至少提供微服務的編譯、內建、打包、部署、配置等工作；如果有能力建議采用PaaS平台，解決微服務從開發到運作的全生命周期管理，同時提供異構環境管理、容器資源隔離與互通、服務伸縮漂移、服務更新與回退、服務熔斷與降級、服務注冊與發現。平台幫助開發人員解決更多的技術問題，開發人員專注在業務功能的拆分上。

2、從試點入手，逐漸推進

為企業的業務應用分級，先從外圍應用試點開始；待經驗豐富後，進行核心應用目前遷移和大規模的改造。

InfoQ：結合你的實戰經驗，分享下你認為的從單體式架構遷移到微服務架構過程中的幾個關鍵點？

劉相：結合我們自身的微服務實戰經驗，遷移過程可以總結出三個關鍵點：

1. 針對業務系統，重新梳理概念模型+資料模型，切分出松耦合、高内聚的微服務，保障項目組在做正确的事情；
2. 制定微服務開發規範（包括技術架構，Spring Boot+Motan+etcd+RESTEasy+Elasticsearch+Docker+Kubernetes是我們的技術架構選型），保障項目組按照統一的開發規範（技術架構）正确做事；
3. 微服務拆分之後，最大的挑戰來自于運維、監控、故障處理，如果團隊沒有微服務運作的經驗，故障之後無法快速定位、快速回複，會受到更大的業務壓力，是以後期的微服務營運平台或者管理平台（具體功能參見問題7中的第一部分）對團隊異常重要，需要配套設計及時跟上，支撐微服務的運作管理。