隨著微服務架構的持續火熱，網路上針對微服務和單體架構的討論也是越來越多。去年的時候，社群更多的關注點是在二者的區別以及優缺點辨析上，而今年，越來越多的人開始關注如何從單體架構遷移到微服務上。毋庸置疑，微服務的理念正在席捲整個開發者社群，像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中的第一部分）對團隊異常重要，需要配套設計及時跟上，支撐微服務的執行管理。