以下問答來自gitchat組織的關(guān)于spring cloud的討論會(huì)酬荞，由純潔的微笑回答，這里記錄一下塑荒，方便自己日后回顧忽妒。

1.多個(gè)微服務(wù)中相互獨(dú)立的數(shù)據(jù)庫如何合并，如做業(yè)務(wù)的聯(lián)合查詢等

Q: 如果每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫兼贸，那么管理系統(tǒng)做數(shù)據(jù)統(tǒng)計(jì)展示時(shí)段直，工作量是不是就需要連多個(gè)庫做合并，這樣工作量應(yīng)該會(huì)復(fù)雜很多溶诞。如果有兩個(gè)微服務(wù)鸯檬，一個(gè)需要生成數(shù)據(jù)寫入數(shù)據(jù)庫，另一個(gè)需要從數(shù)據(jù)庫來讀這些數(shù)據(jù)使用螺垢，這種情況一般怎么做好呢喧务？

A: 每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫赖歌，導(dǎo)致后臺(tái)關(guān)聯(lián)查詢業(yè)務(wù)實(shí)現(xiàn)起來比較復(fù)雜，是大家普遍都會(huì)遇到的一個(gè)問題功茴。主要解決方法有三種：

1）嚴(yán)格按照微服務(wù)的劃分來做庐冯，微服務(wù)相互獨(dú)立喇颁，各微服務(wù)數(shù)據(jù)庫也獨(dú)立五鲫，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來獲取對(duì)應(yīng)的數(shù)據(jù)塞淹，再進(jìn)行數(shù)據(jù)處理后展示出來玲昧，這是標(biāo)準(zhǔn)的用法栖茉，也是最麻煩的用法。（適合業(yè)務(wù)較為簡(jiǎn)單的小公司）

2）將業(yè)務(wù)高度相關(guān)的表放到一個(gè)庫中孵延，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來拆分吕漂，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺(tái)系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)尘应，是一個(gè)折中的方案惶凝。（適合在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司）

3）數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分菩收，以滿足業(yè)務(wù)高并發(fā)梨睁，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫中，在同步的過程中進(jìn)行數(shù)據(jù)清洗娜饵，用來滿足后臺(tái)業(yè)務(wù)系統(tǒng)的使用坡贺，推薦使用MongoDB、HBase等箱舞。（適合大型高并發(fā)的互聯(lián)網(wǎng)公司）

2.一條龍的自動(dòng)化測(cè)試和部署如何實(shí)現(xiàn)

Q: 關(guān)于自動(dòng)化部署遍坟，比如check in 到master上，就能自動(dòng)化測(cè)試和部署晴股，請(qǐng)問具體該如何操作愿伴？

A：現(xiàn)在他們公司的通用做法是：開發(fā)人員實(shí)現(xiàn)一個(gè)小需求，然后提交到Master分支电湘，然后運(yùn)維人員手動(dòng)點(diǎn)擊發(fā)布將代碼部署到生產(chǎn)環(huán)境隔节，利用的是jenkins。

另外寂呛，提交代碼后自動(dòng)測(cè)試并部署到生產(chǎn)環(huán)境是可以實(shí)現(xiàn)的怎诫，方案是這樣：
在提交代碼的時(shí)候可以觸發(fā)版本庫的Refresh，Refresh觸發(fā)一個(gè)提前編寫好的腳本去調(diào)用jenkins部署的接口贷痪，jenkins打包依賴于maven 幻妓，maven來做自動(dòng)化測(cè)試，只要junit測(cè)試成功才會(huì)進(jìn)行打包劫拢，打包成功后jenkins會(huì)自動(dòng)部署到目標(biāo)服務(wù)器肉津，以達(dá)到提交代碼强胰，自動(dòng)化測(cè)試、自動(dòng)部署的目的妹沙。

3: Spring Cloud 和 Dubbo 比較

Q：?jiǎn)误w應(yīng)用到微服務(wù)的重構(gòu)偶洋、業(yè)務(wù)拆分、技術(shù)棧更新初烘，Spring Cloud和Dubbo相比有什么優(yōu)勢(shì)涡真？中小型團(tuán)隊(duì)，技術(shù)儲(chǔ)備一般肾筐，哪種方式更有利于落地和降低計(jì)劃實(shí)施風(fēng)險(xiǎn)哆料？

A：先說Spring Cloud相比于Dubbo的優(yōu)勢(shì)：dubbo框架只是專注于服務(wù)之間的治理，而Spring Cloud幾乎考慮了服務(wù)治理的方方面面吗铐；dubbo已經(jīng)停止更新很多年（雖然最近又有了一次更新）东亦，Spring Cloud正在迅速的發(fā)展。一個(gè)比喻：dubbo是過去時(shí)唬渗，Spring Cloud的是將來時(shí)典阵。

再者，小公司的技術(shù)儲(chǔ)備一般建議選擇使用Spring Cloud镊逝，因?yàn)镾pring Cloud已經(jīng)幫我們集成了很多的組件壮啊。如果使用dubbo需要我們自己去集成各種開源的解決方案，難度有所增加撑蒜；建議先學(xué)習(xí)Spring Boot歹啼，部分項(xiàng)目使用，再熟悉Spring Boot 之后在引進(jìn)Spring Cloud座菠，項(xiàng)目改造也是分批進(jìn)行演化狸眼。

4.從Dubbo轉(zhuǎn)到Spring Cloud的建議，期間會(huì)有哪些坑

Q：我們目前的服務(wù)主要用的是Dubbo浴滴，如果想往Spring Cloud轉(zhuǎn)拓萌，希望老師能給些建議，以及遇到過哪些坑升略？

A：第一微王，先學(xué)習(xí)Spring Boot技術(shù)，在部分項(xiàng)目上實(shí)踐品嚣；

第二骂远，再學(xué)習(xí)Spring Cloud相關(guān)技術(shù)，部分服務(wù)進(jìn)行切換腰根；

第三，根據(jù)組內(nèi)成員的情況來控制演化的節(jié)奏拓型；

在切換之前需要對(duì)服務(wù)進(jìn)行分類额嘿，通常分四種：基礎(chǔ)服務(wù)瘸恼、業(yè)務(wù)服務(wù)、組合服務(wù)册养、前置服務(wù)东帅。不同服務(wù)遷移的優(yōu)先級(jí)不同，優(yōu)先在基礎(chǔ)服務(wù) 或者 新上線的項(xiàng)目中使用球拦。

至于遇到的坑：

1.建議盡量不要使用Jsp靠闭，內(nèi)嵌Tomcat部署Jsp項(xiàng)目會(huì)偶現(xiàn)龜速訪問的情況，頁面開發(fā)推薦使用Thymeleaf坎炼；

2.使用服務(wù)編排可以降低項(xiàng)目之間的相互依賴度愧膀。

3.Spring Cloud生態(tài)的技術(shù)有很多，并不是每一種技術(shù)方案都需要用上谣光，適合自己的才是最好的檩淋。

5.Spring Cloud學(xué)習(xí)經(jīng)驗(yàn)

Q：Spring Cloud的體系很大，應(yīng)該怎樣學(xué)習(xí)呢萄金？有什么學(xué)習(xí)路線蟀悦，方式推薦？

A：學(xué)習(xí)Spring Cloud的前提是掌握Spring Boot氧敢，因此第一個(gè)建議是先學(xué)習(xí) Spring Boot日戈。剛開始學(xué)習(xí)的Spring Cloud的時(shí)候，建議只關(guān)注服務(wù)的注冊(cè)和發(fā)現(xiàn)孙乖。當(dāng)使用的深度慢慢增加浙炼，后面再考慮，熔斷的圆、監(jiān)控其它技術(shù)鼓拧。另外實(shí)踐是最好的學(xué)習(xí)方式，建議先使用Spring Boot/Cloud 搭建幾個(gè)小項(xiàng)目 或者模仿的去做一些小例子越妈。

6.Spring Boot和Spring Cloud的關(guān)系

Q：Spring Boot和Spring Cloud的關(guān)系季俩？Spring Boot構(gòu)建的單一服務(wù)，如果進(jìn)一步擴(kuò)展梅掠，需要考慮微服務(wù)酌住？

A：Spring Cloud基于Spring Boot來實(shí)現(xiàn)的云應(yīng)用開發(fā)工具；另外阎抒，Spring boot專注于快速酪我、方便集成的單個(gè)個(gè)體，Spring Cloud是關(guān)注全局的服務(wù)治理框架且叁；Spring Boot構(gòu)建的單一服務(wù)都哭，當(dāng)單個(gè)服務(wù)越來越多，相互的調(diào)用關(guān)系也會(huì)成指數(shù)增長，因此在演進(jìn)到一定程度需要Spring Cloud進(jìn)行服務(wù)治理欺矫。

7.微服務(wù)中分布式事務(wù)的處理

Q：請(qǐng)問在事務(wù)處理這一塊纱新，尤其是訂單場(chǎng)景的事務(wù)處理，有什么好的實(shí)踐或者建議嗎穆趴？

A：分布式事務(wù)Spring Boot可以集成 Atomikos來解決脸爱，但是我個(gè)人不建議在微服務(wù)架構(gòu)中使用，因?yàn)槭褂梅植际绞聞?wù)會(huì)降低服務(wù)整體的響應(yīng)速度未妹。建議采取消息補(bǔ)償機(jī)制來做最終一致性檢查簿废。

8.微服務(wù)拆分的顆粒度經(jīng)驗(yàn)

Q：關(guān)于服務(wù)拆分的顆粒度這塊，請(qǐng)問依照哪些維度拆分比較好络它？

A：服務(wù)拆分有以下幾個(gè)原則：

1）橫向拆分族檬。按照不同的業(yè)務(wù)域進(jìn)行拆分，例如訂單酪耕、營銷导梆、風(fēng)控、積分資源等迂烁。形成獨(dú)立的業(yè)務(wù)領(lǐng)域微服務(wù)集群看尼。

2）縱向拆分。把一個(gè)業(yè)務(wù)功能里的不同模塊或者組件進(jìn)行拆分盟步。例如把公共組件拆分成獨(dú)立的原子服務(wù)藏斩，下沉到底層，形成相對(duì)獨(dú)立的原子服務(wù)層却盘。

這樣一縱一橫狰域，就可以實(shí)現(xiàn)業(yè)務(wù)的服務(wù)化拆分。另外服務(wù)拆分的大與小 是相對(duì)的黄橘。

比如在初期兆览，我們把交易拆分為一個(gè)微服務(wù)，但是隨著業(yè)務(wù)量的增大塞关，可能一個(gè)交易系統(tǒng)已經(jīng)慢慢變得很大抬探，并且并發(fā)流量也不小，為了支撐更多的交易量帆赢，我會(huì)把交易系統(tǒng)小压，拆分為訂單服務(wù)、投標(biāo)服務(wù)椰于、轉(zhuǎn)讓服務(wù)等怠益。

所以服務(wù)的拆分是根據(jù)業(yè)務(wù)的規(guī)模動(dòng)態(tài)調(diào)整的。