但需要注意的是，實(shí)施微服務(wù),，也需要付出額外的代價(jià),，Martin曾經(jīng)就說(shuō)過(guò)，除非面對(duì)的是一個(gè)過(guò)于復(fù)雜以至于難于管理的單體應(yīng)用,，否則絕對(duì)不要考慮使用微服務(wù),。大多數(shù)的軟件系統(tǒng)應(yīng)該構(gòu)建為獨(dú)立的單塊程序。確保注重單體應(yīng)用自身的模塊化,，而不要試圖把它們分離成單獨(dú)的服務(wù),。

普元軟件產(chǎn)品部技術(shù)經(jīng)理劉相在微服務(wù)架構(gòu)上有很多的實(shí)踐和思考，InfoQ記者就單體應(yīng)用遷移到微服務(wù)的8個(gè)關(guān)鍵問(wèn)題對(duì)他進(jìn)行了專(zhuān)訪(fǎng),，內(nèi)容涵蓋傳統(tǒng)單體式架構(gòu)的挑戰(zhàn),、實(shí)施微服務(wù)架構(gòu)的鋪墊、改造原則,、數(shù)據(jù)庫(kù),、中間件、分布式事務(wù),、風(fēng)險(xiǎn)規(guī)避等,。

InfoQ：就你目前的觀(guān)察來(lái)看,，企業(yè)為什么要從單體式架構(gòu)遷移到微服務(wù)架構(gòu)？他們遇到的最大的問(wèn)題是什么,？

劉相：我所服務(wù)的企業(yè)多為傳統(tǒng)企業(yè),，代碼在100萬(wàn)行的項(xiàng)目比比皆是，龐大復(fù)雜的項(xiàng)目使得開(kāi)發(fā),、測(cè)試,、維護(hù)、運(yùn)維極度復(fù)雜,，在彈性,、擴(kuò)展性、可維護(hù)性方面也困難重重,。除此之外,，傳統(tǒng)單體式架構(gòu)遇到的問(wèn)題還有：

1、團(tuán)隊(duì)接手困難

8年前,，我曾接手一個(gè)100萬(wàn)行級(jí)別的項(xiàng)目,，那段經(jīng)歷算是一段噩夢(mèng)：花了3個(gè)月的時(shí)間通讀一遍代碼,；每次修改代碼心驚膽戰(zhàn),，修改一個(gè)Bug極可能帶來(lái)各種隱含的缺陷。

2,、臃腫的部署

單體應(yīng)用每次功能或者缺陷的變更導(dǎo)致重新部署整個(gè)應(yīng)用,，這種部署方式影響大、風(fēng)險(xiǎn)高,，決定了部署頻率低,，導(dǎo)致兩次發(fā)布之間有大量的功能或者缺陷需要進(jìn)行變更，出錯(cuò)概率增高,。

3,、局限的彈性與擴(kuò)展能力

單體應(yīng)用作為一個(gè)強(qiáng)耦合的整體，無(wú)法根據(jù)業(yè)務(wù)功能伸縮,，只能作為一個(gè)整體進(jìn)行擴(kuò)展,。這造成資源浪費(fèi)，同時(shí)無(wú)法針對(duì)不同業(yè)務(wù)模塊的特性進(jìn)行有針對(duì)性的伸縮,，比如計(jì)算密集型服務(wù),、IO密集型服務(wù)。

4,、阻礙技術(shù)革新

團(tuán)隊(duì)對(duì)新技術(shù)的渴望是不言而喻的,，團(tuán)隊(duì)士氣會(huì)因?yàn)槌掷m(xù)的關(guān)注在巨石應(yīng)用的技術(shù)棧而降低；單體式架構(gòu)下的組織通常來(lái)說(shuō)技術(shù)選型非常單一,，團(tuán)隊(duì)技術(shù)能力相對(duì)單薄,，團(tuán)隊(duì)的吸引力一般,。

除此之外，對(duì)于服務(wù)等級(jí),、安全要求,、業(yè)務(wù)監(jiān)管等多個(gè)維度均需要針對(duì)不同的服務(wù)實(shí)現(xiàn)不同的治理，遷移到微服務(wù)架構(gòu)成為必然,。

InfoQ：微服務(wù)有它固有的優(yōu)勢(shì),，但對(duì)企業(yè)的基礎(chǔ)設(shè)施以及團(tuán)隊(duì)要求也比較高。你認(rèn)為在企業(yè)準(zhǔn)備遷移到微服務(wù)架構(gòu)前,，需要做好哪些準(zhǔn)備,？

劉相：企業(yè)遷移到微服務(wù)架構(gòu)前，零號(hào)原則就是對(duì)業(yè)務(wù)充分了解,，大量企業(yè)因歷史原因?qū)е铝私鈽I(yè)務(wù)系統(tǒng)了的人屈指可數(shù)時(shí),，就試圖轉(zhuǎn)向微服務(wù)架構(gòu)，即使采用最好的技術(shù),、工具,、架構(gòu)、團(tuán)隊(duì),，最后都會(huì)摔得很痛（造成無(wú)休止的拆分與變更）,。

在充分了解業(yè)務(wù)的前提下，我認(rèn)為向微服務(wù)遷移,，還需在如下三個(gè)維度準(zhǔn)備：

1,、償還技術(shù)債務(wù)

自動(dòng)化測(cè)試、持續(xù)集成與自動(dòng)化部署是向微服務(wù)架構(gòu)大規(guī)模遷移前必須補(bǔ)償?shù)募夹g(shù)欠債,。微服務(wù)架構(gòu)下,，團(tuán)隊(duì)管理大量服務(wù)，其復(fù)雜度和測(cè)試難度是幾何級(jí)增加,，利用自動(dòng)化測(cè)試能幫助團(tuán)隊(duì)快速有效的驗(yàn)證應(yīng)用,；持續(xù)集成與自動(dòng)化部署保障團(tuán)隊(duì)更快速、更容易的修改代碼,，缺少持續(xù)集成和自動(dòng)化部署,，向微服務(wù)架構(gòu)轉(zhuǎn)型過(guò)程會(huì)異常痛苦。

2,、新的架構(gòu)設(shè)計(jì)原則

采用微服務(wù)架構(gòu),，應(yīng)用交付高度復(fù)雜化。架構(gòu)設(shè)計(jì)原則需要從原來(lái)單體式架構(gòu)下的關(guān)注功能,、性能等維度向MVP（最小可用產(chǎn)品）,、面向失敗的設(shè)計(jì)（擁抱失敗，而不是阻止失敗）,、寬進(jìn)嚴(yán)出（對(duì)請(qǐng)求寬進(jìn)嚴(yán)出,，對(duì)外的響應(yīng)要嚴(yán)格規(guī)范化）、寧花機(jī)器一分,，不花人工一秒（自動(dòng)與自助,、復(fù)雜重復(fù)的事情交給平臺(tái)工具去做，讓程序員去做更有價(jià)值的事情）,、一切皆資源等設(shè)計(jì)原則轉(zhuǎn)變,，形成架構(gòu)漸進(jìn)優(yōu)化的設(shè)計(jì)風(fēng)格。

3,、團(tuán)隊(duì)變革

《Exploring the Duality Between Product and Organizational Architectures》書(shū)中給了一個(gè)很有意思的觀(guān)點(diǎn),，組織的耦合度與系統(tǒng)的模塊化成正比。即組織耦合度越高,，所開(kāi)發(fā)的產(chǎn)品耦合度越高,；組織耦合度越低，所開(kāi)發(fā)的產(chǎn)品耦合度也越低,。微服務(wù)架構(gòu)本質(zhì)上在強(qiáng)調(diào)松耦合的架構(gòu),，因此在微服務(wù)架構(gòu)遷移前，我們有必要對(duì)組織進(jìn)行微調(diào)（不要變革,，對(duì)組織影響很大）,，確保獨(dú)立的、小的團(tuán)隊(duì)交付一個(gè)微服務(wù),，同時(shí)小團(tuán)隊(duì)是微服務(wù)的Owner（除了負(fù)責(zé)開(kāi)發(fā)外,，同時(shí)負(fù)責(zé)測(cè)試和運(yùn)維）,。這會(huì)極大提供團(tuán)隊(duì)的責(zé)任感,，加速微服務(wù)的自治和交付能力。

InfoQ：在整個(gè)的架構(gòu)改造過(guò)程中,，你覺(jué)得有哪些可以遵循的規(guī)則,？

劉相：微服務(wù)架構(gòu)改造原則業(yè)界已經(jīng)總結(jié)非常多了，包括：基于業(yè)務(wù)進(jìn)行拆分,、采用自動(dòng)化文化,、去中心化、服務(wù)獨(dú)立部署,、服務(wù)完全自治,、隔離失敗、漸進(jìn)式拆分,、避免大規(guī)模改造原有代碼等原則,，這些原則相信關(guān)注微服務(wù)架構(gòu)的已經(jīng)相對(duì)清楚。結(jié)合我們具體的實(shí)踐，提供一些實(shí)際微服務(wù)化改造時(shí)經(jīng)驗(yàn)總結(jié)：

1,、先分離數(shù)據(jù)庫(kù),、后分離服務(wù)

數(shù)據(jù)模型能否徹底分開(kāi)，決定了微服務(wù)的邊界功能是否徹底劃清,。我們已經(jīng)見(jiàn)過(guò)太多直接從服務(wù)分離而造成多次重構(gòu)和返工的案例,；

2、采用“絞殺者模式”

對(duì)于無(wú)法修改的遺留系統(tǒng),，推薦采用絞殺者模式：在遺留系統(tǒng)外面增加新的功能做成微服務(wù)方式,，而不是直接修改原有系統(tǒng)，逐步的實(shí)現(xiàn)對(duì)老系統(tǒng)替換,；

3,、建立統(tǒng)一的日志規(guī)范

規(guī)范整個(gè)系統(tǒng)而非微服務(wù)的日志體系，采用標(biāo)準(zhǔn)的日志格式非常便于后續(xù)的日志聚合檢索,，便于整體的視角分析,、監(jiān)控、查看系統(tǒng),；

4,、選擇成熟框架

同時(shí)做兩件不可控的事情（微服務(wù)改造、新技術(shù)的沖擊）注定項(xiàng)目成功概率較低,，千萬(wàn)避免自己重復(fù)發(fā)明輪子,，盡量選擇市面上成熟的開(kāi)源技術(shù)框架進(jìn)行支撐，比如Spring Boot,、Spring Cloud,、Netflix、WildFly Swarm,、Docker,、Kubernetes等框架；

當(dāng)然還有很多的細(xì)節(jié)規(guī)范,，比如前后端分離原則,、采用全局唯一流水號(hào)原則實(shí)現(xiàn)全鏈路交易跟蹤、如何進(jìn)行服務(wù)的文檔化管理及服務(wù)測(cè)試Mock等,。

InfoQ：數(shù)據(jù)庫(kù)方面是不是有應(yīng)該做相應(yīng)的調(diào)整,？

劉相：這個(gè)話(huà)題非常有意義，微服務(wù)改造,，第一件事情就需要針對(duì)數(shù)據(jù)庫(kù)模型進(jìn)行拆分,，數(shù)據(jù)模型邊界劃清后，服務(wù)順利成章容易劃清界限,。我們實(shí)踐過(guò)程中強(qiáng)烈推薦的原則是一個(gè)微服務(wù)對(duì)應(yīng)一個(gè)庫(kù),。當(dāng)然,，隨著微服務(wù)規(guī)模壯大，可以針對(duì)性的做讀寫(xiě)分離,；如果單表數(shù)據(jù)龐大,，可以分表來(lái)解決。

InfoQ：如何解決分布式事務(wù)一致性呢,？

劉相：微服務(wù)架構(gòu)下,，完整交易跨越多個(gè)系統(tǒng)運(yùn)行，事務(wù)一致性是一個(gè)極具挑戰(zhàn)的話(huà)題,。依據(jù)CAP理論,，必須在可用性（Avaliablitity）和一致性（Consistency）之間做出選擇。我們認(rèn)為在微服務(wù)架構(gòu)下應(yīng)選擇可用性,，然后保證數(shù)據(jù)的最終一致性,。在我們的實(shí)踐中總結(jié)出了三種模式：可靠事件模式、業(yè)務(wù)補(bǔ)償模式,、TCC模式,。

可靠事件模式：可靠事件模式屬于事件驅(qū)動(dòng)架構(gòu)，當(dāng)某件重要事情發(fā)生時(shí),，例如更新一個(gè)業(yè)務(wù)實(shí)體,，微服務(wù)會(huì)向消息代理發(fā)布一個(gè)事件，消息代理向訂閱事件的微服務(wù)推送事件,，當(dāng)訂閱這些事件的微服務(wù)接受此事件時(shí),，就可以完成自己的業(yè)務(wù)，可能會(huì)會(huì)引發(fā)更多的事件發(fā)布,。

業(yè)務(wù)補(bǔ)償模式：補(bǔ)償模式使用一個(gè)額外的協(xié)調(diào)服務(wù)來(lái)協(xié)調(diào)各個(gè)需要保證一致性的工作服務(wù),，協(xié)調(diào)服務(wù)按順序調(diào)用各個(gè)工作服務(wù)，如果某個(gè)工作服務(wù)調(diào)用失敗就撤銷(xiāo)之前所有已經(jīng)完成的工作服務(wù),。要求需要保證一致性的工作服務(wù)提供補(bǔ)償操作,。

TCC模式：一個(gè)完整的TCC業(yè)務(wù)由一個(gè)主業(yè)務(wù)服務(wù)和若干個(gè)從業(yè)務(wù)服務(wù)組成，主業(yè)務(wù)服務(wù)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng),，TCC模式要求從服務(wù)提供三個(gè)接口Try（負(fù)責(zé)資源檢查）,、Confirm（真正執(zhí)行業(yè)務(wù)）、Cancel（釋放Try階段預(yù)留的資源）,。

三種模式的詳細(xì)介紹可以參見(jiàn)同事田向陽(yáng)的微課堂文章：

• 微服務(wù)架構(gòu)下數(shù)據(jù)一致性保證（一）：http:///3TVFHs

• 微服務(wù)架構(gòu)下數(shù)據(jù)一致性保證（二）： http:///3TVHBW

• 微服務(wù)架構(gòu)下數(shù)據(jù)一致性保證（三）：http:///3TVJaB

InfoQ：中間件是否需要做調(diào)整，或者重新規(guī)劃很多新的中間件,？

劉相：對(duì)于現(xiàn)有中間件,，套用Gartner流行的一個(gè)詞“雙模”,，比如MySQL,、Redis等中間件適合作為微服務(wù)獨(dú)立出現(xiàn)；對(duì)于大塊頭Oracle、DB2數(shù)據(jù)庫(kù)或者諸如Queue的產(chǎn)品,，不適合作為獨(dú)立微服務(wù)出現(xiàn),，可以采用集成的方式工作。

微服務(wù)架構(gòu)需要和新的中間件平臺(tái)提供融合,，比如IaaS平臺(tái),、PaaS平臺(tái)等。當(dāng)然在微服務(wù)框架內(nèi)部,，有大量新的中間件的產(chǎn)品,，比如etcd、motan,、resteasy,、ELK等。

對(duì)于中間件的使用,，我們一直保持一個(gè)原則：業(yè)務(wù)邏輯放在服務(wù)中,，盡量保持中間件的簡(jiǎn)單。

InfoQ：整個(gè)改造過(guò)程中,，你認(rèn)為應(yīng)該如何規(guī)避風(fēng)險(xiǎn)以保證平滑過(guò)度,？

劉相：微服務(wù)架構(gòu)遷移在業(yè)務(wù)上、技術(shù)上都充滿(mǎn)了挑戰(zhàn),。從規(guī)避風(fēng)險(xiǎn)的層面來(lái)講,，給大家兩點(diǎn)建議：

1、重視運(yùn)營(yíng)平臺(tái)建設(shè)

在實(shí)施微服務(wù)改造前,，建議先行搭建好運(yùn)營(yíng)支撐平臺(tái),，平臺(tái)至少提供微服務(wù)的編譯、集成,、打包,、部署、配置等工作,；如果有能力建議采用PaaS平臺(tái),，解決微服務(wù)從開(kāi)發(fā)到運(yùn)行的全生命周期管理，同時(shí)提供異構(gòu)環(huán)境管理,、容器資源隔離與互通,、服務(wù)伸縮漂移、服務(wù)升級(jí)與回退,、服務(wù)熔斷與降級(jí),、服務(wù)注冊(cè)與發(fā)現(xiàn)。平臺(tái)幫助開(kāi)發(fā)人員解決更多的技術(shù)問(wèn)題,，開(kāi)發(fā)人員專(zhuān)注在業(yè)務(wù)功能的拆分上,。

2,、從試點(diǎn)入手，逐步推進(jìn)

為企業(yè)的業(yè)務(wù)應(yīng)用分級(jí),，先從外圍應(yīng)用試點(diǎn)開(kāi)始,；待經(jīng)驗(yàn)豐富后，進(jìn)行核心應(yīng)用當(dāng)前遷移和大規(guī)模的改造,。

InfoQ：結(jié)合你的實(shí)戰(zhàn)經(jīng)驗(yàn),，分享下你認(rèn)為的從單體式架構(gòu)遷移到微服務(wù)架構(gòu)過(guò)程中的幾個(gè)關(guān)鍵點(diǎn)？

劉相：結(jié)合我們自身的微服務(wù)實(shí)戰(zhàn)經(jīng)驗(yàn),，遷移過(guò)程可以總結(jié)出三個(gè)關(guān)鍵點(diǎn)：

1,、針對(duì)業(yè)務(wù)系統(tǒng)，重新梳理概念模型+數(shù)據(jù)模型,，切分出松耦合,、高內(nèi)聚的微服務(wù)，保障項(xiàng)目組在做正確的事情,；

2,、制定微服務(wù)開(kāi)發(fā)規(guī)范（包括技術(shù)架構(gòu)，Spring Boot+Motan+etcd+RESTEasy+Elasticsearch+Docker+Kubernetes是我們的技術(shù)架構(gòu)選型）,，保障項(xiàng)目組按照統(tǒng)一的開(kāi)發(fā)規(guī)范（技術(shù)架構(gòu)）正確做事,；

3、微服務(wù)拆分之后,，最大的挑戰(zhàn)來(lái)自于運(yùn)維,、監(jiān)控、故障處理,，如果團(tuán)隊(duì)沒(méi)有微服務(wù)運(yùn)行的經(jīng)驗(yàn),，故障之后無(wú)法快速定位、快速回復(fù),，會(huì)受到更大的業(yè)務(wù)壓力,，因此后期的微服務(wù)運(yùn)營(yíng)平臺(tái)或者管理平臺(tái)（具體功能參見(jiàn)問(wèn)題7中的第一部分）對(duì)團(tuán)隊(duì)異常重要，需要配套設(shè)計(jì)及時(shí)跟上,，支撐微服務(wù)的運(yùn)行管理,。

劉相，來(lái)自普元,，十年IT行業(yè)經(jīng)驗(yàn),，專(zhuān)注于企業(yè)軟件平臺(tái)。在SOA,、分布式計(jì)算,、企業(yè)架構(gòu)設(shè)計(jì)等領(lǐng)域有一定了解。著有《SpringBatch批處理框架》一書(shū),。

,。