從單體架構遷移到微服務,8個關鍵的思考、實踐和經驗

隨着微服務架構的持續火熱,網絡上針對微服務和單體架構的討論也是愈來愈多。去年的時候,社區更多的關注點是在兩者的區別以及優缺點辨析上,而今年,愈來愈多的人開始關注如何從單體架構遷移到微服務上。毋庸置疑,微服務的理念正在席捲整個開發者社區,像Netflix、Uber這樣的公司都是很是成功的應用案例。程序員

但須要注意的是,實施微服務,也須要付出額外的代價,Martin曾經就說過,除非面對的是一個過於複雜以致於難於管理的單體應用,不然絕對不要考慮使用微服務。大多數的軟件系統應該構建爲獨立的單塊程序。確保注重單體應用自身的模塊化,而不要試圖把它們分離成單獨的服務。數據庫

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

InfoQ:就你目前的觀察來看,企業爲何要從單體式架構遷移到微服務架構?他們遇到的最大的問題是什麼?安全

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

一、團隊接手困難架構

8年前,我曾接手一個100萬行級別的項目,那段經歷算是一段噩夢:花了3個月的時間通讀一遍代碼;每次修改代碼心驚膽戰,修改一個Bug很可能帶來各類隱含的缺陷。框架

二、臃腫的部署前後端分離

單體應用每次功能或者缺陷的變動致使從新部署整個應用,這種部署方式影響大、風險高,決定了部署頻率低,致使兩次發佈之間有大量的功能或者缺陷須要進行變動,出錯機率增高。運維

三、侷限的彈性與擴展能力分佈式

單體應用做爲一個強耦合的總體,沒法根據業務功能伸縮,只能做爲一個總體進行擴展。這形成資源浪費,同時沒法針對不一樣業務模塊的特性進行有針對性的伸縮,好比計算密集型服務、IO密集型服務。

四、阻礙技術革新

團隊對新技術的渴望是不言而喻的,團隊士氣會由於持續的關注在巨石應用的技術棧而下降;單體式架構下的組織一般來講技術選型很是單一,團隊技術能力相對單薄,團隊的吸引力通常。

除此以外,對於服務等級、安全要求、業務監管等多個維度均須要針對不一樣的服務實現不一樣的治理,遷移到微服務架構成爲必然。

InfoQ:微服務有它固有的優點,但對企業的基礎設施以及團隊要求也比較高。你認爲在企業準備遷移到微服務架構前,須要作好哪些準備?

劉相:企業遷移到微服務架構前,零號原則就是對業務充分了解,大量企業因歷史緣由致使瞭解業務系統了的人屈指可數時,就試圖轉向微服務架構,即便採用最好的技術、工具、架構、團隊,最後都會摔得很痛(形成無休止的拆分與變動)。

在充分了解業務的前提下,我認爲向微服務遷移,還需在以下三個維度準備:

一、償還技術債務

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

二、新的架構設計原則

採用微服務架構,應用交付高度複雜化。架構設計原則須要從原來單體式架構下的關注功能、性能等維度向MVP(最小可用產品)、面向失敗的設計(擁抱失敗,而不是阻止失敗)、寬進嚴出(對請求寬進嚴出,對外的響應要嚴格規範化)、寧花機器一分,不花人工一秒(自動與自助、複雜重複的事情交給平臺工具去作,讓程序員去作更有價值的事情)、一切皆資源等設計原則轉變,造成架構漸進優化的設計風格。

三、團隊變革

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

InfoQ:在整個的架構改造過程當中,你以爲有哪些能夠遵循的規則?

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

一、先分離數據庫、後分離服務

數據模型可否完全分開,決定了微服務的邊界功能是否完全劃清。咱們已經見過太多直接從服務分離而形成屢次重構和返工的案例;

二、採用「絞殺者模式」

對於沒法修改的遺留系統,推薦採用絞殺者模式:在遺留系統外面增長新的功能作成微服務方式,而不是直接修改原有系統,逐步的實現對老系統替換;

三、創建統一的日誌規範

規範整個系統而非微服務的日誌體系,採用標準的日誌格式很是便於後續的日誌聚合檢索,便於總體的視角分析、監控、查看系統;

四、選擇成熟框架

同時作兩件不可控的事情(微服務改造、新技術的衝擊)註定項目成功機率較低,千萬避免本身重複發明輪子,儘可能選擇市面上成熟的開源技術框架進行支撐,好比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:整個改造過程當中,你認爲應該如何規避風險以保證平滑過分?

劉相:微服務架構遷移在業務上、技術上都充滿了挑戰。從規避風險的層面來說,給你們兩點建議:

一、重視運營平臺建設

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

二、從試點入手,逐步推動

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

InfoQ:結合你的實戰經驗,分享下你認爲的從單體式架構遷移到微服務架構過程當中的幾個關鍵點?

劉相:結合咱們自身的微服務實戰經驗,遷移過程能夠總結出三個關鍵點:

  1. 針對業務系統,從新梳理概念模型+數據模型,切分出鬆耦合、高內聚的微服務,保障項目組在作正確的事情;
  2. 制定微服務開發規範(包括技術架構,Spring Boot+Motan+etcd+RESTEasy+Elasticsearch+Docker+Kubernetes是咱們的技術架構選型),保障項目組按照統一的開發規範(技術架構)正確作事;
  3. 微服務拆分以後,最大的挑戰來自於運維、監控、故障處理,若是團隊沒有微服務運行的經驗,故障以後沒法快速定位、快速回復,會受到更大的業務壓力,所以後期的微服務運營平臺或者管理平臺(具體功能參見問題7中的第一部分)對團隊異常重要,須要配套設計及時跟上,支撐微服務的運行管理。

嘉賓介紹

劉相,來自普元,十年IT行業經驗,專一於企業軟件平臺。在SOA、分佈式計算、企業架構設計等領域有必定了解。著有《SpringBatch批處理框架》一書。

歡迎掃描二維碼加入由劉相主持的「普元雲計算研發開放羣」,討論更多微服務、DevOps、容器相關內容,加羣暗號「微服務」。

相關文章
相關標籤/搜索