同程旅游微服務(wù)最佳實(shí)踐-創(chuàng)新互聯(lián)

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

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

本文概要

• 導(dǎo)言

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

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

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

• 結(jié)語

一、導(dǎo)言

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

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

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

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

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

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

發(fā)布升級頻率

邏輯調(diào)用頻率

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

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

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

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

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

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

3.  調(diào)用頻率

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.  版本的兼容性

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

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

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

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

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

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

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

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

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

1.  培訓(xùn)先行

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

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

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

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

2.  絞殺者模式

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

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

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

3.  監(jiān)獄模式

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

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

五、結(jié)語

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

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

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

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

廣告

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