為企業(yè)提供網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、網(wǎng)站優(yōu)化、全網(wǎng)營(yíng)銷推廣、競(jìng)價(jià)托管、品牌運(yùn)營(yíng)等營(yíng)銷獲客服務(wù)。創(chuàng)新互聯(lián)公司擁有網(wǎng)絡(luò)營(yíng)銷運(yùn)營(yíng)團(tuán)隊(duì)，以豐富的互聯(lián)網(wǎng)營(yíng)銷經(jīng)驗(yàn)助力企業(yè)精準(zhǔn)獲客，真正落地解決中小企業(yè)營(yíng)銷獲客難題，做到“讓獲客更簡(jiǎn)單”。自創(chuàng)立至今，成功用技術(shù)實(shí)力解決了企業(yè)“網(wǎng)站建設(shè)、網(wǎng)絡(luò)品牌塑造、網(wǎng)絡(luò)營(yíng)銷”三大難題，同時(shí)降低了營(yíng)銷成本，提高了有效客戶轉(zhuǎn)化率，獲得了眾多企業(yè)客戶的高度認(rèn)可！

本文首發(fā)胖波聊架構(gòu)界，微信公眾號(hào)：xiaobo2as

本文概要

• 導(dǎo)言

• 微服務(wù)拆分的四個(gè)維度

• 微服務(wù)應(yīng)該如何維護(hù)版本

• 如何從單體架構(gòu)平滑過(guò)渡到微服務(wù)

• 結(jié)語(yǔ)

一、導(dǎo)言

同程微服務(wù)從立項(xiàng)到實(shí)施推廣已經(jīng)走過(guò)了整整兩個(gè)年頭，從最初的簡(jiǎn)單粗糙到今天的精細(xì)完善，接入服務(wù)數(shù)量也實(shí)現(xiàn)了從1到10,000+的增長(zhǎng)。

微服務(wù)開(kāi)發(fā)團(tuán)隊(duì)和大家一起踩過(guò)了無(wú)數(shù)的坑，最終打造了今天的DSF2.0平臺(tái)?；仡櫯揽佑涗?，現(xiàn)整理一些爬坑心得體驗(yàn)供大家參考，也斗膽提出一些最佳實(shí)踐以拋磚引玉。

下文將從開(kāi)發(fā)者角度對(duì)微服務(wù)如何拆分， 版本管理和單體到微服務(wù)過(guò)渡等方面給出一些建議,  供大家斟酌。

二、微服務(wù)拆分的四個(gè)維度

從單體架構(gòu)到微服務(wù)，拆分粒度很難把握。理論方法莫衷一是，我們推薦快刀斬亂麻按照如下四個(gè)維度做拆分：

團(tuán)隊(duì)組織結(jié)構(gòu)

發(fā)布升級(jí)頻率

邏輯調(diào)用頻率

數(shù)據(jù)讀寫(xiě)分離

1.  團(tuán)隊(duì)組織結(jié)構(gòu)

按照康威定律的說(shuō)法，組織結(jié)構(gòu)一定會(huì)反映到系統(tǒng)架構(gòu)上，同程是樹(shù)形結(jié)構(gòu)+底層網(wǎng)狀結(jié)構(gòu)，那么服務(wù)之間一定是每個(gè)系統(tǒng)的架構(gòu)呈明顯的樹(shù)狀，但是系統(tǒng)之間會(huì)有多重的服務(wù)互訪。

微服務(wù)設(shè)計(jì)要充分考慮哪些是自用（inner），外部訪問(wèn)（outer）和混用（mix）服務(wù)，并盡可以能將其遷移對(duì)應(yīng)的服務(wù)組里。

2.  發(fā)布升級(jí)頻率

新老項(xiàng)目由于處于生命周期的不同階段，修改和發(fā)布頻率會(huì)有很大差別。應(yīng)該盡量將處于生命周期中不同階段的接口分割，避免高頻更新服務(wù)和低頻更新服務(wù)捆綁，避免向穩(wěn)定運(yùn)行的服務(wù)組添加新業(yè)務(wù)接口，而是應(yīng)該考慮在新的服務(wù)組中實(shí)現(xiàn)。

3.  調(diào)用頻率

服務(wù)組中的不同服務(wù)調(diào)用頻率會(huì)有巨大差別，而高頻調(diào)用肯定會(huì)占據(jù)更多的資源，會(huì)出現(xiàn)個(gè)別接口耗盡資源導(dǎo)致同組接口一起失?。ㄙY源競(jìng)爭(zhēng)），需要對(duì)高頻訪問(wèn)的服務(wù)設(shè)置定制的運(yùn)行策略，如分配更多的CPU核心數(shù)和內(nèi)存， 調(diào)整部署使其盡可能靠近數(shù)據(jù)源等策略，但是如果將所有服務(wù)宿主都做成高配，會(huì)造成巨大的資源浪費(fèi)事實(shí)上也沒(méi)有必要，所以應(yīng)該將高低頻訪問(wèn)的服務(wù)分割以使其能為獲得更好的性能和可靠性做針對(duì)性優(yōu)化。

4.  數(shù)據(jù)讀寫(xiě)分離

上一維度其實(shí)已經(jīng)涵蓋了讀寫(xiě)分離的一部分，但是為了突出讀寫(xiě)分離的必要性，這里單獨(dú)列出。一般數(shù)據(jù)操作模式分為CQRS和CRUD兩種模式，各有優(yōu)缺點(diǎn)。 

從操作是否對(duì)數(shù)據(jù)本身造成影響來(lái)看，可以粗略的分為讀寫(xiě)兩類 ， 一般來(lái)說(shuō)寫(xiě)操作的頻率會(huì)大大低于讀操作，寫(xiě)操作經(jīng)常會(huì)有更嚴(yán)格的認(rèn)證授權(quán)機(jī)制，一般為內(nèi)部（inner）調(diào)用。這些和讀操作都有巨大差異性， 因此建議流量較大或較為核心的服務(wù)應(yīng)該做讀寫(xiě)分離，分拆為兩個(gè)服務(wù)組發(fā)布。

最后分享一個(gè)粒度控制的小技巧，大多數(shù)情況出現(xiàn)在系統(tǒng)里的每個(gè)名詞都會(huì)在存儲(chǔ)層面擁有一席之地，對(duì)應(yīng)一個(gè)獨(dú)立的數(shù)據(jù)表或庫(kù)，所以系統(tǒng)里出現(xiàn)的名詞都可能是一個(gè)潛在的微服務(wù)。 

三、微服務(wù)應(yīng)該如何維護(hù)版本

微服務(wù)治理中維護(hù)一個(gè)有序，直觀的版本會(huì)給系統(tǒng)開(kāi)發(fā)過(guò)程和服務(wù)依賴管理帶來(lái)巨大的便利，反之無(wú)版本或混亂的版本升級(jí)策略迷惑開(kāi)發(fā)和設(shè)計(jì)人員并帶來(lái)意想不到的依賴問(wèn)題。良好的微服務(wù)治理應(yīng)該包含一整套完整的版本升級(jí)策略，根據(jù)我們長(zhǎng)期的爬坑實(shí)踐我們推薦如下版本策略：

1.  使用標(biāo)準(zhǔn)語(yǔ)義化版本

具體參見(jiàn) 語(yǔ)義化版本 2.0.0  。使用標(biāo)準(zhǔn)的語(yǔ)義化版本能使大家保證對(duì)版本有統(tǒng)一的理解，應(yīng)盡量避免自行定義版本語(yǔ)義。DSF 版本推薦使用SemVer 約定，略有不同的是DSF推薦四位版本號(hào)（1.2.3.4），前兩位作為主版本（1.2）， SemVer版本一般為三位（x.y.z 對(duì)應(yīng)：主版本號(hào).次版本號(hào).修訂號(hào)）。

2.  面向契約設(shè)計(jì)

當(dāng)一個(gè)團(tuán)隊(duì)選擇微服務(wù)作為服務(wù)化實(shí)施平臺(tái)時(shí)必須明確微服務(wù)化有一個(gè)較高的門(mén)檻，需要團(tuán)隊(duì)自身已經(jīng)是一個(gè)較為成熟運(yùn)作體系，例如有實(shí)施前有完善的架構(gòu)設(shè)計(jì)，團(tuán)隊(duì)成員有明確的職責(zé)劃分，團(tuán)隊(duì)成員對(duì)服務(wù)內(nèi)聚和服務(wù)耦合有明確的認(rèn)知。

上述的這些方面都會(huì)促成一個(gè)結(jié)果： 使設(shè)計(jì)開(kāi)發(fā)的服務(wù)接口最終具有良好的抽象并體現(xiàn)出規(guī)劃性，最終能夠在服務(wù)實(shí)施前就能交付有良好兼容性的服務(wù)契約。實(shí)踐中體現(xiàn)為一個(gè)版本迭代新增、修改、刪除的任何部分都是經(jīng)過(guò)慎重思考并體現(xiàn)在服務(wù)契約里，實(shí)際開(kāi)發(fā)不輕易的修改和增添服務(wù)接口。 

3.  并行開(kāi)發(fā)中版本的維護(hù)

微服務(wù)化對(duì)開(kāi)發(fā)體系的一個(gè)重大影響就是開(kāi)發(fā)實(shí)踐的并行化，微服務(wù)使開(kāi)發(fā)者從單體架構(gòu)的調(diào)用叢林?jǐn)[脫出來(lái)，使開(kāi)發(fā)者能夠把視野聚焦到調(diào)用鏈中其中一環(huán)上而不用過(guò)多關(guān)心上下游的具體實(shí)現(xiàn)。

需要付出的成本就是如何避免重復(fù)實(shí)現(xiàn)以及代碼Merge時(shí)的更高頻的沖突問(wèn)題，有一個(gè)良好的版本管理習(xí)慣能夠解決絕大部分的Merge沖突問(wèn)題。

我們推薦在面向契約設(shè)計(jì)的基礎(chǔ)上進(jìn)一步延伸，通過(guò)團(tuán)隊(duì)內(nèi)溝通確定不對(duì)外暴露的核心部分由誰(shuí)來(lái)負(fù)責(zé)并約定在特定的版本實(shí)現(xiàn)，而負(fù)責(zé)使用該核心模塊的其他開(kāi)發(fā)者在該版本上遞增版本。 

被其他組件依賴較且可能頻繁改動(dòng)的內(nèi)核代碼獨(dú)占一個(gè)特定的版本區(qū)間(例如：v1.2.3.0~1.2.3.10作為核心模塊的獨(dú)占版本，依賴該組件的模塊必須大于v1.2.3.10)，能很好隔離并行開(kāi)發(fā)帶來(lái)的版本沖突問(wèn)題。

因?yàn)橐煤诵慕M件的上層實(shí)現(xiàn)彼此沒(méi)有太多聯(lián)系，總是能夠很好處理Merge帶來(lái)的沖突問(wèn)題。

4.  版本的兼容性

能根據(jù)版本號(hào)判斷服務(wù)是否向后兼容是服務(wù)依賴管理的一個(gè)很重要的方面，大多數(shù)時(shí)候做一個(gè)使服務(wù)不在向后兼容的決定是很難的事，但是不斷的向后兼容的結(jié)果往往是服務(wù)體量不可控制的增長(zhǎng)和系統(tǒng)復(fù)雜度的非線性上升。

開(kāi)發(fā)者需要慎重思考并在合適的時(shí)間做出服務(wù)不再向后兼容的決定，良好的版本策略能將服務(wù)是否向后兼容明確的表達(dá)出，顯式的告訴調(diào)用方這是一個(gè)不兼容的升級(jí)更新， 請(qǐng)務(wù)必確保仔細(xì)閱讀的新的契約文檔并做了足夠的測(cè)試。

對(duì)DSF來(lái)說(shuō)不兼容升級(jí)是很醒目的，只需觀察服務(wù)組的大版本號(hào)（版本號(hào)的前兩位，如v1.2.3.4，大版本號(hào)為1.2）是否增加，任何服務(wù)契約修改都被認(rèn)為是不兼容的升級(jí)，包括刪除接口、修改接口名稱/參數(shù)等，都必須升級(jí)大版本號(hào)， 而修改小版本號(hào)（版本號(hào)的后兩位，如v1.2.3.4，小版本號(hào)為3.4）則代表兼容性升級(jí)，如新增了服務(wù)接口，代碼邏輯優(yōu)化和Bug fix但是未修改服務(wù)契約。

四、如何從單體架構(gòu)平滑過(guò)渡到微服務(wù)

一旦決定在開(kāi)發(fā)實(shí)踐引入微服務(wù)架構(gòu)，如何將積累下來(lái)的龐大的巨無(wú)霸系統(tǒng)潤(rùn)物細(xì)無(wú)聲的的過(guò)渡到微服務(wù)架構(gòu)將是一個(gè)巨大的挑戰(zhàn)。

推倒重來(lái)激進(jìn)革命路線是要不得的，架構(gòu)師們最想通過(guò)微服務(wù)化取代的部分往往是公司的主要盈利核心，改造難度不亞于飛行中更換引擎。從業(yè)界公開(kāi)的信息來(lái)看還沒(méi)有哪家做到了完美升級(jí)， 更多的可能無(wú)外乎兩種：

第一種改造后茍延殘喘，研發(fā)疲于奔命；

另一種則是改造中就直接休克。  

因此為使微服務(wù)能順利的應(yīng)用，架構(gòu)師從不應(yīng)該幻想一蹴而就，無(wú)數(shù)次的碰壁后我們給出如下的爬坑建議：

1.  培訓(xùn)先行

工作技術(shù)人都很善于把面臨的問(wèn)題變成技術(shù)問(wèn)題，然后在自己最擅長(zhǎng)的領(lǐng)域里取解決掉。這就造成一個(gè)悖論：能用技術(shù)解決的問(wèn)題就不是問(wèn)題，真正的問(wèn)題在受限的情景下僅靠技術(shù)是解決不了的，實(shí)施微服務(wù)大的攔路虎也不是技術(shù)本身。

從我們的實(shí)踐來(lái)看，大的問(wèn)題不是如何做好微服務(wù)，而是就微服務(wù)應(yīng)該是什么達(dá)成一個(gè)一致的看法。

正所謂林子大了什么鳥(niǎo)都有，對(duì)于微服務(wù)100個(gè)人可能就有100種理解，這個(gè)不是說(shuō)我們都是用dubbo或者都是用spring boot就能解決的。

我們的推薦做法就是實(shí)施前通過(guò)多數(shù)人參與的大討論和培訓(xùn)，讓多數(shù)人能達(dá)成一致的認(rèn)識(shí)，微服務(wù)是什么，微服務(wù)不是什么？ 運(yùn)用在哪些場(chǎng)景是適合，應(yīng)用在哪些場(chǎng)景里是不適合的？ 結(jié)果不要跑的太偏就行， 和編碼規(guī)范中命名規(guī)范一樣，使用那種命名方法不重要，重要的是大家都使用同一種命名方法。

2.  絞殺者模式

絞殺者模式指對(duì)于無(wú)法通過(guò)修繕者模式改進(jìn)的系統(tǒng)通過(guò)在系統(tǒng)外重新構(gòu)建新功能的方式逐步剝離重構(gòu)，對(duì)功能服務(wù)逐個(gè)絞殺。

好處是不影響原來(lái)的環(huán)境，一旦條件成熟就能快速切換。

不好的方面則是可能需要有一段時(shí)間同時(shí)維護(hù)兩套系統(tǒng)，付出額外的開(kāi)發(fā)維護(hù)成本。

3.  監(jiān)獄模式

還有一種同程內(nèi)部稱之為監(jiān)獄模式的做法，允許一些短期無(wú)力改動(dòng)的系統(tǒng)通過(guò)監(jiān)獄窗口（MicroProxy）接入微服務(wù)平臺(tái)并委托Proxy將其暴露成微服務(wù)， 單體架構(gòu)往往擁有龐大的服務(wù)接口梳理， 往往需要開(kāi)多個(gè)監(jiān)獄窗口。

每個(gè)監(jiān)獄窗口都會(huì)被包裝分割成微服務(wù)，條件成熟了能很方便的替換成原生微服務(wù)，稱為刑滿釋放。

五、結(jié)語(yǔ)

市面上微服務(wù)的理論和討論鋪天蓋地，其中不乏侃侃而談的大塊文章，深入閱讀確常常發(fā)現(xiàn)大都是新瓶裝舊酒或者拼湊篇幅之作。特點(diǎn)是在務(wù)虛處濃墨重彩，高談理論，于實(shí)踐處則一筆帶過(guò)，仔細(xì)探究則實(shí)無(wú)一物。

所以如果發(fā)現(xiàn)有些技術(shù)書(shū)籍晦澀難懂，滿篇的高大上，讀完頭腦發(fā)脹，確無(wú)所進(jìn)益可能不是您水平不夠，更可能是作者故弄玄虛。最近讀書(shū)有感，書(shū)于此，博君一曬。 

當(dāng)前標(biāo)題：同程旅游微服務(wù)最佳實(shí)踐-創(chuàng)新互聯(lián)
文章位置：http://www.rwnh.cn/article40/iipho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動(dòng)態(tài)網(wǎng)站、商城網(wǎng)站、定制網(wǎng)站、網(wǎng)站營(yíng)銷、全網(wǎng)營(yíng)銷推廣、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)