微服務(wù)這個(gè)詞已經(jīng)在軟件行業(yè)變的非常熱門(mén)仅偎，不了解微服務(wù)已經(jīng)不好意思說(shuō)自己是IT行業(yè)的從業(yè)人員跨蟹，筆者學(xué)習(xí)和踐行微服務(wù)也有一段時(shí)間士修，看了很多人的文章和參與了很多討論喘垂，每個(gè)人的理解和認(rèn)識(shí)都存在差異买鸽，最近一次在機(jī)場(chǎng)等待的時(shí)機(jī)重讀了Martin Fowler（微服務(wù)之父胰耗，他1999年的著作《重構(gòu)》在編碼界也是非辰拿桑火爆慌核，影響了很多從業(yè)者）的文章谈跛，收貨滿(mǎn)滿(mǎn)蜕猫，再結(jié)合最近幾年的實(shí)踐經(jīng)驗(yàn)箫措，對(duì)微服務(wù)的認(rèn)識(shí)有了新的提高腹备，對(duì)微服務(wù)的理解也更加深入。

正值新型冠狀病毒肆虐斤蔓，國(guó)務(wù)院延長(zhǎng)了春節(jié)假期植酥，可以抽時(shí)間總結(jié)分享出來(lái)，給需要的朋友弦牡。有條件的同學(xué)建議閱讀https://www.martinfowler.com/articles/microservices.html的英文原文友驮，這里是原汁原味的微服務(wù)理念介紹和經(jīng)驗(yàn)分享，相信讀者更能獲益驾锰。

1.微服務(wù)的定義

? ? ? ?在開(kāi)始討論之前卸留，首先明確微服務(wù)是一種架構(gòu)風(fēng)格，一種開(kāi)發(fā)方法椭豫。用來(lái)開(kāi)發(fā)一個(gè)軟件套件中的單個(gè)應(yīng)用的方法耻瑟；這種方法具有共同的特點(diǎn)，即——這單個(gè)的應(yīng)用運(yùn)行在獨(dú)立的進(jìn)程內(nèi)赏酥，和其他應(yīng)用采用輕量級(jí)的通信方式進(jìn)行通信（通常是HTTP）喳整，這些單個(gè)應(yīng)用程序圍繞業(yè)務(wù)功能構(gòu)建，獨(dú)立的開(kāi)發(fā)和完全自動(dòng)化的部署裸扶；這些應(yīng)用之間有最少限度的集中管理框都，可以采用不同的語(yǔ)言開(kāi)發(fā)，不同的存儲(chǔ)技術(shù)呵晨。

? ? ? 為了更好的理解微服務(wù)架構(gòu)瞬项，先認(rèn)識(shí)一下微服務(wù)流行之前的架構(gòu)蔗蹋，這種架構(gòu)我們稱(chēng)之為單體架構(gòu)風(fēng)格Monolithic，這種架構(gòu)構(gòu)建的應(yīng)用程序整體作為一個(gè)單元囱淋，通常包含三部分即客戶(hù)端界面程序、服務(wù)端應(yīng)用程序和數(shù)據(jù)庫(kù)餐塘⊥滓拢客戶(hù)端用戶(hù)界面包含HTML，CSS戒傻，Javascript等運(yùn)行在瀏覽器的程序税手；數(shù)據(jù)庫(kù)包含數(shù)據(jù)庫(kù)的表，視圖和存儲(chǔ)過(guò)程等用以存儲(chǔ)數(shù)據(jù)需纳；服務(wù)端應(yīng)用程序包含處理HTTP請(qǐng)求芦倒，處理業(yè)務(wù)邏輯和數(shù)據(jù)訪(fǎng)問(wèn)等，這個(gè)服務(wù)端的應(yīng)用程序就是個(gè)單體應(yīng)用不翩，系統(tǒng)的任何改變都將牽涉到重新構(gòu)建和部署服務(wù)端的一個(gè)新版本兵扬。

? ? ? ?這種單體應(yīng)用程序是最自然的構(gòu)建系統(tǒng)的方式，所有請(qǐng)求的處理都到單體應(yīng)用程序的進(jìn)程內(nèi)口蝠，采用應(yīng)用程序開(kāi)發(fā)語(yǔ)言的基本特性把它拆分成不同的包器钟、類(lèi)和函數(shù)中從而實(shí)現(xiàn)模塊化，可以在開(kāi)發(fā)者的便攜機(jī)上開(kāi)發(fā)和測(cè)試單體應(yīng)用妙蔗“涟裕可以采用部署流水線(xiàn)把測(cè)試后的應(yīng)用程序部署到生產(chǎn)環(huán)境中，可以增加更多負(fù)載均衡器后面的實(shí)例數(shù)量來(lái)水平的擴(kuò)展服務(wù)能力眉反。

? ? ? ?單體應(yīng)用程序可以做的很好昙啄，但人們也越來(lái)越發(fā)現(xiàn)問(wèn)題，尤其是把應(yīng)用程序部署到云上以后寸五。變更被捆綁在一起梳凛，單體應(yīng)用程序中一個(gè)小的改變都需要整個(gè)程序重新部署，時(shí)間長(zhǎng)了保持模塊化的架構(gòu)也會(huì)比較困難播歼，本應(yīng)影響一個(gè)模塊的變更也很難做到僅影響單個(gè)模塊伶跷。單個(gè)模塊的伸縮需要整個(gè)程序來(lái)伸縮，這也導(dǎo)致需要更多的資源秘狞。這些問(wèn)題就導(dǎo)致了人們自然而然地想到了微服務(wù)架構(gòu)叭莫，把程序構(gòu)建成一系列服務(wù)，每個(gè)服務(wù)可以獨(dú)立部署和伸縮烁试，每個(gè)服務(wù)也定義了清晰的邊界雇初，不同的服務(wù)可以采用不同的語(yǔ)言編寫(xiě)，不同的團(tuán)隊(duì)來(lái)維護(hù)减响。

? ? ? ?下圖來(lái)之martin fowler的官方網(wǎng)站靖诗，不同顏色和形狀的色塊代表了不同的功能郭怪，單體架構(gòu)把所有的功能放在一個(gè)程序中，微服務(wù)將每個(gè)功能放入一個(gè)一個(gè)微服務(wù)中刊橘，單體架構(gòu)需要整個(gè)程序部署多份以達(dá)到伸縮的目的鄙才，而單體應(yīng)用可以根據(jù)功能的使用情況再伸縮。

? ? ? ?正是單體架構(gòu)的這些問(wèn)題促绵，才使得微服務(wù)風(fēng)格的架構(gòu)得以發(fā)展攒庵，微服務(wù)除了服務(wù)是可獨(dú)立部署、可獨(dú)立擴(kuò)展的之外败晴，每個(gè)服務(wù)都提供一個(gè)固定的模塊邊界浓冒。甚至允許不同的服務(wù)用不同的的語(yǔ)言開(kāi)發(fā)，由不同的團(tuán)隊(duì)管理尖坤。下面文章探討一下微服務(wù)所具有的共同特征稳懒。

2.微服務(wù)架構(gòu)的特征

? ? ? ?微服務(wù)之父也無(wú)法給出微服務(wù)架構(gòu)風(fēng)格的一個(gè)正式定義，但他嘗試去描述該架構(gòu)的一些共性慢味。就這些共性來(lái)說(shuō)场梆，并非所有的微服務(wù)都具有這些共性，但我們期望大多數(shù)微服務(wù)都具備大多數(shù)特性贮缕。

2.1 通過(guò)服務(wù)的方式組件化

? ? ? ?在軟件開(kāi)發(fā)行業(yè)辙谜，長(zhǎng)期以來(lái)都渴望通過(guò)插拔、物理世界堆積木的方式實(shí)現(xiàn)組件化感昼，最近這幾十年各種語(yǔ)言通過(guò)庫(kù)的方式已經(jīng)有很大的進(jìn)步装哆，一些語(yǔ)言也一定程度地實(shí)現(xiàn)了可插拔的模塊化庫(kù)。在討論組件化的時(shí)候定嗓，不可避免的回到一個(gè)問(wèn)題蜕琴，什么是組件化，它的定義是什么宵溅？我們對(duì)組件化的定義是可以獨(dú)立替換和升級(jí)的軟件包凌简。

? ? ? 微服務(wù)架構(gòu)也會(huì)使用到現(xiàn)代編程語(yǔ)言提供的各種類(lèi)庫(kù)，但微服務(wù)實(shí)現(xiàn)組件化的方式是把業(yè)務(wù)拆分成不同的服務(wù)來(lái)實(shí)現(xiàn)的恃逻。我們把庫(kù)定義為鏈接到程序并使用內(nèi)存函數(shù)調(diào)用的組件雏搂，而服務(wù)是一種進(jìn)程外的組件，它通過(guò)WEB服務(wù)請(qǐng)求或RPC(遠(yuǎn)程過(guò)程調(diào)用)機(jī)制來(lái)通信寇损。

? ? ? 我們使用微服務(wù)做為組件化的原因是微服務(wù)可以獨(dú)立的部署凸郑，如果你的應(yīng)用程序在一個(gè)進(jìn)程內(nèi)包含了多個(gè)庫(kù)作為組件，這些組件中的任何一個(gè)變化都需要整個(gè)應(yīng)用程序重新部署矛市。如果是以微服務(wù)的方式實(shí)現(xiàn)組件化芙沥，那么僅對(duì)實(shí)現(xiàn)變化的這些微服務(wù)重新部署就可以了，不需要整個(gè)應(yīng)用重新部署。當(dāng)然這也不是絕對(duì)的而昨，一些變更將會(huì)導(dǎo)致服務(wù)接口變化救氯，這樣就導(dǎo)致多個(gè)服務(wù)發(fā)生變化，但一個(gè)好的微服務(wù)架構(gòu)的目的是通過(guò)高內(nèi)聚和按接口契約演進(jìn)機(jī)制來(lái)最小化變更歌憨∽藕可見(jiàn)微服務(wù)和庫(kù)的很大一個(gè)區(qū)別就是是否可以單獨(dú)部署。

? ? ?用微服務(wù)來(lái)實(shí)現(xiàn)組件化的一個(gè)另一個(gè)好處是务嫡，微服務(wù)之間有清晰的服務(wù)接口定義享扔；大多數(shù)語(yǔ)言沒(méi)有沒(méi)有提供定義發(fā)布接口的能力，只能通過(guò)文檔和原則來(lái)約定植袍，這就導(dǎo)致調(diào)用方很容易浸入到被調(diào)用的內(nèi)部或者具體實(shí)現(xiàn)上去，從而造成了過(guò)度耦合（例如JAVA的JAR包籽懦，我們提倡面向接口編程于个，但調(diào)用方也可以直接構(gòu)造實(shí)現(xiàn)類(lèi)）；微服務(wù)的接口定義方式很好的解決了這一問(wèn)題暮顺，調(diào)用方只能通過(guò)遠(yuǎn)程調(diào)用的方式訪(fǎng)問(wèn)服務(wù)提供者厅篓，不可能侵入到被調(diào)用方的內(nèi)部。 微服務(wù)的這種調(diào)用方式也有副作用捶码，遠(yuǎn)程的調(diào)用比進(jìn)程內(nèi)通信代價(jià)要高很多羽氮，因此微服務(wù)的調(diào)用方式接口粒度要比進(jìn)程內(nèi)調(diào)用粒度粗，也即一個(gè)請(qǐng)求盡可能多的獲取到所需的信息惫恼，而不是像進(jìn)程內(nèi)調(diào)用那樣档押，需要的時(shí)候獲取一小部分信息。

2.2 圍繞業(yè)務(wù)能力劃分微服務(wù)

? ? ? ? 當(dāng)想要把大型應(yīng)用程序拆分開(kāi)時(shí)祈纯，通常聚焦在技術(shù)層面令宿，導(dǎo)致劃分出UI團(tuán)隊(duì)、服務(wù)側(cè)團(tuán)隊(duì)腕窥、數(shù)據(jù)庫(kù)團(tuán)隊(duì)的劃分粒没。當(dāng)團(tuán)隊(duì)按這些技術(shù)線(xiàn)路劃分時(shí)，即使是簡(jiǎn)單的更改也會(huì)導(dǎo)致跨團(tuán)隊(duì)的協(xié)調(diào)簇爆。按照這個(gè)劃分癞松，有新需求UI團(tuán)隊(duì)會(huì)把邏輯放到UI層，服務(wù)器團(tuán)隊(duì)會(huì)放到服務(wù)器層入蛆。這就導(dǎo)致邏輯無(wú)處不在响蓉，這是康威法則在起作用的一個(gè)例子。

? ? ? ?有什么樣的組織結(jié)構(gòu)安寺，就會(huì)有什么樣的軟件架構(gòu)---?Melvyn Conway, 1967

? ? ? ?而微服務(wù)的方式劃分是不同的厕妖，圍繞業(yè)務(wù)能力劃分成不同的微服務(wù)，一個(gè)組織部門(mén)內(nèi)部包含1到多個(gè)微服務(wù)，這些微服務(wù)里面包含了全面的用來(lái)實(shí)現(xiàn)這些微服務(wù)技術(shù)棧的人員言秸，包含UI软能、服務(wù)器和數(shù)據(jù)庫(kù)存儲(chǔ)人員。這樣的一個(gè)團(tuán)隊(duì)是跨技術(shù)棧團(tuán)隊(duì)举畸，這個(gè)團(tuán)隊(duì)的成員能完成微服務(wù)的前后臺(tái)開(kāi)發(fā)查排、數(shù)據(jù)庫(kù)開(kāi)發(fā)及項(xiàng)目管理。

? ? ? ?如下圖所示抄沮，左邊的圖是微服務(wù)團(tuán)隊(duì)跋核，團(tuán)隊(duì)里面包含了微服務(wù)所需的技術(shù)人才，有UI叛买、服務(wù)器和數(shù)據(jù)庫(kù)等砂代，而圍繞技術(shù)能力劃分的團(tuán)隊(duì)，將團(tuán)隊(duì)劃分為UI團(tuán)隊(duì)率挣、服務(wù)器團(tuán)隊(duì)和數(shù)據(jù)庫(kù)團(tuán)隊(duì)刻伊。

? ? ? ?這里提到的微服務(wù)團(tuán)隊(duì)，很自然的問(wèn)題是微服務(wù)團(tuán)隊(duì)?wèi)?yīng)該由多大椒功，這里實(shí)際上并沒(méi)有一個(gè)清晰的定義捶箱，但根據(jù)業(yè)界實(shí)踐，亞馬遜建議最大不超過(guò)2個(gè)披薩动漾，也即1個(gè)團(tuán)隊(duì)2個(gè)披薩能夠喂飽丁屎，也意味著這個(gè)團(tuán)隊(duì)大小不超過(guò)12個(gè)人，也有的團(tuán)隊(duì)6個(gè)微服務(wù)用6個(gè)人來(lái)維護(hù)旱眯，也即1個(gè)人1個(gè)微服務(wù)晨川，這樣的粒度無(wú)疑太細(xì)了，我們不建議太細(xì)键思，但再大也不建議超過(guò)12個(gè)人础爬。

2.3 做產(chǎn)品而不是做項(xiàng)目

? ? ? 產(chǎn)品和項(xiàng)目的最大區(qū)別在于項(xiàng)目是一次性的，目標(biāo)是交付軟件吼鳞，完成后的軟件被交接給維護(hù)組織看蚜，然后它的開(kāi)發(fā)團(tuán)隊(duì)就去干別的事情了，或者說(shuō)壓根解散了赔桌，而產(chǎn)品是長(zhǎng)期演進(jìn)的供炎，是不斷迭代演化的。微服務(wù)更傾向于避免項(xiàng)目的模式疾党，而是以產(chǎn)品的模式來(lái)運(yùn)作音诫，一個(gè)團(tuán)隊(duì)負(fù)責(zé)產(chǎn)品的整個(gè)生命周期。

? ? ? 亞馬遜的理念?“you build, you run it”?雪位，即誰(shuí)開(kāi)發(fā)誰(shuí)維護(hù)竭钝，開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé)軟件的整個(gè)產(chǎn)品周期。這使開(kāi)發(fā)者經(jīng)常接觸他們的軟件在生產(chǎn)環(huán)境如何工作，并增加與他們用戶(hù)的聯(lián)系香罐，因?yàn)樗麄儽仨毘袚?dān)至少部分的支持工作卧波。

? ? ? 這樣的“產(chǎn)品”理念，是與業(yè)務(wù)功能的聯(lián)動(dòng)綁定在一起的庇茫。它不會(huì)將軟件看作是一個(gè)待開(kāi)發(fā)的功能集合港粱，而是認(rèn)為這是一個(gè)持續(xù)迭代的、發(fā)展和演進(jìn)的產(chǎn)品旦签，即軟件如何能助其客戶(hù)來(lái)持續(xù)增進(jìn)業(yè)務(wù)功能查坪。

2.4?智能端點(diǎn)和啞管道

? ? ? ?在傳統(tǒng)的SOA架構(gòu)下，在不同的服務(wù)之間通信時(shí)宁炫，采用的方法是在其通信機(jī)制上增加了很多智能化偿曙，增加了不少業(yè)務(wù)邏輯處理。一個(gè)典型的例子就是ESB(Enterprise? Service Bus), ESB 往往包含很多高級(jí)的功能羔巢，比如消息路由遥昧、編排、消息轉(zhuǎn)化朵纷、和業(yè)務(wù)規(guī)則處理。

? ? ? 而微服務(wù)的則往往采用另一種替代方法永脓，智能的端點(diǎn)和啞管道袍辞，也即微服務(wù)在通信管道上不處理業(yè)務(wù)邏輯，僅作為通信方式存在常摧，業(yè)務(wù)邏輯在通信雙方的微服務(wù)上處理搅吁。構(gòu)建成微服務(wù)的目的是要做到高內(nèi)聚和低耦合，每個(gè)微服務(wù)擁有自己的領(lǐng)域邏輯落午，而且很像是UNIX的過(guò)濾器那樣工作谎懦，接受一個(gè)輸入請(qǐng)求，對(duì)其應(yīng)用業(yè)務(wù)邏輯溃斋，并產(chǎn)生一個(gè)響應(yīng)界拦。這些微服務(wù)之間通信，更傾向于采用簡(jiǎn)單的RESTFUL風(fēng)格協(xié)議而不是復(fù)雜的協(xié)議（如基于SOAP的web service梗劫，或者BPEL）享甸。

? ? ?微服務(wù)和十幾年前的SOA架構(gòu)看起來(lái)非常相似，很多理念也很類(lèi)似梳侨，但本質(zhì)上有很大差異蛉威，SOA架構(gòu)通常都有一個(gè)龐大、復(fù)雜的ESB總線(xiàn)走哺，各個(gè)單體應(yīng)用之間通過(guò)ESB來(lái)交換數(shù)據(jù)蚯嫌，ESB也承擔(dān)了很多業(yè)務(wù)邏輯轉(zhuǎn)換和處理的工作，但在微服務(wù)概念里面，沒(méi)有ESB择示，有的只是輕量級(jí)的消息通信機(jī)制束凑。

? ? 微服務(wù)建議采用2種方式來(lái)通信，一個(gè)是HTTP請(qǐng)求-響應(yīng)式的API对妄，第二個(gè)者輕量級(jí)的消息中間件通信湘今。第一種HTTP方式，正是構(gòu)建萬(wàn)維網(wǎng)使用的協(xié)議剪菱，通常使用的資源很容易被緩存起來(lái)摩瞎。第二種方式是通過(guò)輕量級(jí)消息中間件來(lái)通信，比較常見(jiàn)的是RabbitMQ, ZeroMQ, Kafka等孝常，這類(lèi)消息中間件僅提供一個(gè)可靠的異步通信機(jī)制旗们，不提供額外的功能，這也就是啞管道构灸，而智能部分在端點(diǎn)側(cè)上渴，也就是通信雙方微服務(wù)。

? ? ? ?在單體應(yīng)用中喜颁，組件之間通過(guò)內(nèi)存中進(jìn)程內(nèi)的方法調(diào)用或者函數(shù)調(diào)用完成稠氮，把單體應(yīng)用拆分為微服務(wù)架構(gòu)的最大問(wèn)題就是通信方式的變化。簡(jiǎn)單的把進(jìn)程內(nèi)的方法調(diào)用轉(zhuǎn)換為RPC調(diào)用是十分錯(cuò)誤的半开，因?yàn)樵谶M(jìn)程內(nèi)調(diào)用開(kāi)銷(xiāo)非常小隔披，獲取的信息的粒度非常小，可以非常頻繁的通信寂拆，但轉(zhuǎn)換為微服務(wù)之間的調(diào)用之后奢米，就要切回為更大粒度的通信了。 例如：?jiǎn)误w應(yīng)用里面訂單信息和顧客信息在一個(gè)應(yīng)用內(nèi)纠永，訂單需要姓名鬓长，則調(diào)用訂單模塊的getName接口獲取，需要地址信息再調(diào)用getAddressInfo接口獲取尝江，但拆分成微服務(wù)之后涉波，就不能這么頻繁的調(diào)用，顧客信息應(yīng)該提供一個(gè)粗粒度的接口給訂單管理炭序，一次性提供顧客相關(guān)的姓名怠蹂、地址信息。

2.5?去中心化治理

? ? ? ?中心化治理帶來(lái)的結(jié)果是趨向于標(biāo)準(zhǔn)化到單一的技術(shù)少态、工具城侧、方法和流程，經(jīng)驗(yàn)顯示這種方法限制太多了彼妻，不是所有的問(wèn)題都是釘子嫌佑，也不是所有的解決辦法都是錘子豆茫，多樣性的世界和多樣性的業(yè)務(wù)更趨向于不同的事情采用不同的工具，雖然單體應(yīng)用也可以這么做屋摇，但這在單體應(yīng)用中并不常見(jiàn)揩魂。

? ? ? ?在將單體應(yīng)用拆分成微服務(wù)時(shí)，可以根據(jù)業(yè)務(wù)特點(diǎn)和需要選擇合適的技術(shù)炮温，報(bào)表頁(yè)面就用個(gè)簡(jiǎn)單的Node.js火脉，當(dāng)然可以，實(shí)時(shí)處理的需要用C++柒啤，當(dāng)然也可以倦挂，想采用特定類(lèi)型的數(shù)據(jù)庫(kù)來(lái)提高讀取性能，當(dāng)然也沒(méi)有問(wèn)題担巩。這里僅僅是說(shuō)可以這么做方援，但不代表應(yīng)該這么做。拆分成微服務(wù)后涛癌，不限制每個(gè)微服務(wù)采用的技術(shù)犯戏，但作為整個(gè)團(tuán)隊(duì)的一部分，技術(shù)還是應(yīng)該盡可能的統(tǒng)一拳话。

? ? ? ?采用微服務(wù)的方式不是說(shuō)就沒(méi)有標(biāo)準(zhǔn)要遵守了先匪，微服務(wù)的標(biāo)準(zhǔn)不是定義一堆預(yù)先選定的技術(shù)，而是微服務(wù)開(kāi)發(fā)風(fēng)格弃衍。大家共同的標(biāo)準(zhǔn)就是遵從微服務(wù)風(fēng)格胚鸯。每個(gè)微服務(wù)團(tuán)隊(duì)更傾向于采用對(duì)開(kāi)發(fā)有利的工具，這些工具可以給其他團(tuán)隊(duì)用笨鸡，當(dāng)在解決問(wèn)題時(shí)，也是優(yōu)先采用已有的工具坦冠，可能來(lái)自于公司內(nèi)部的開(kāi)源形耗，也可能來(lái)自于互聯(lián)網(wǎng)開(kāi)源。Netflix就是采用此哲學(xué)的很好的例子辙浑， 他們共享有用的激涤，完整測(cè)試的代碼，把這些代碼作為庫(kù)共享出來(lái)判呕，鼓勵(lì)其他開(kāi)發(fā)者用這些庫(kù)來(lái)解決問(wèn)題倦踢，當(dāng)然也鼓勵(lì)開(kāi)發(fā)者采用其他的方式來(lái)更好的解決。

? ? ?對(duì)微服務(wù)社區(qū)而言侠草，大家不愿意消耗太多的時(shí)間去做服務(wù)契約的管理辱挥，這不是說(shuō)不重視服務(wù)契約，相反边涕，非常重視服務(wù)的契約晤碘，有不同的方法來(lái)探索和嘗試管理服務(wù)契約褂微。如Tolerant Reader和消費(fèi)者驅(qū)動(dòng)型契約模式經(jīng)常應(yīng)用到微服務(wù)。這些模式有助于服務(wù)契約獨(dú)立進(jìn)化园爷。采用消費(fèi)者驅(qū)動(dòng)服務(wù)契約的方式不但可以給服務(wù)團(tuán)隊(duì)增加信心宠蚂，也能快速獲得微服務(wù)是否工作正常反饋的良好方式。有的團(tuán)隊(duì)童社，先定義服務(wù)契約求厕，之后再基于契約自動(dòng)生成編碼骨架，開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé)實(shí)現(xiàn)這些服務(wù)扰楼，不少團(tuán)隊(duì)采用這種方法呀癣，效果不錯(cuò)。

? ? ? ?可能去中心化的最高境界就是亞馬遜提倡的“誰(shuí)開(kāi)發(fā)灭抑，誰(shuí)維護(hù)”的理念十艾，開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé)軟件的方方面面，包含安裝和運(yùn)維腾节，這種模式確實(shí)很難達(dá)到忘嫉，因?yàn)檫@會(huì)造成組織結(jié)構(gòu)的重大調(diào)整，一些崗位的消失案腺，開(kāi)發(fā)團(tuán)隊(duì)的壓力變大庆冕，這必然會(huì)帶來(lái)阻力，但越來(lái)越多的公司正在這么做劈榨，或者走在這么做的路上访递，典型的就是亞馬遜和? ? NETFLIX; 這種模式給開(kāi)發(fā)團(tuán)隊(duì)的壓力（晚上3點(diǎn)中被叫起來(lái)處理問(wèn)題），才會(huì)促進(jìn)開(kāi)發(fā)團(tuán)隊(duì)注重代碼的質(zhì)量同辣。這種模式和傳統(tǒng)的開(kāi)發(fā)團(tuán)隊(duì)開(kāi)發(fā)拷姿、運(yùn)維團(tuán)隊(duì)運(yùn)維想去甚遠(yuǎn)。

2.6去中心化的數(shù)據(jù)管理

? ? ?去中心化的數(shù)據(jù)管理通過(guò)幾個(gè)方面表現(xiàn)出來(lái)：

（1）最抽象的層次是系統(tǒng)之間的概念模型不同旱函，這會(huì)在大企業(yè)的系統(tǒng)集成帶來(lái)問(wèn)題响巢，銷(xiāo)售眼中的客戶(hù)和技術(shù)支持眼中的客戶(hù)是不同的，一些銷(xiāo)售眼中看到的屬性棒妨，在技術(shù)支持眼中可能完全沒(méi)有踪古，即使出現(xiàn)也可能具有不同的屬性，或者（更糟糕的）屬性相同券腔，但語(yǔ)義卻有細(xì)微的差別伏穆。 這個(gè)問(wèn)題在單體應(yīng)用之間很常見(jiàn)，在應(yīng)用內(nèi)部也時(shí)常發(fā)生纷纫，特別是應(yīng)用被劃分為多個(gè)模塊的時(shí)候枕扫，一個(gè)有用的方法是采用領(lǐng)域驅(qū)動(dòng)模型DDD，DDD是把一個(gè)復(fù)雜的領(lǐng)域劃分為多個(gè)有邊界的上下文辱魁，然后在這些有界上下文上做映射铡原，這個(gè)方法對(duì)單體應(yīng)用和微服務(wù)都有用偷厦，只是DDD劃分的邊界和微服務(wù)更為貼合。

（2）除了上述的概念模型去中心化燕刻，數(shù)據(jù)存儲(chǔ)也去中心化只泼，如下圖所示，單體應(yīng)用傾向于采用單一的數(shù)據(jù)存儲(chǔ)技術(shù)卵洗，比如Oracle來(lái)存儲(chǔ)數(shù)據(jù)请唱，而微服務(wù)讓每個(gè)微服務(wù)自己管理自己的數(shù)據(jù)，因此各個(gè)微服務(wù)采用的數(shù)據(jù)存儲(chǔ)技術(shù)也可以相差很大过蹂，各自管理各自的數(shù)據(jù)十绑，采用多數(shù)據(jù)庫(kù)來(lái)管理各自的數(shù)據(jù)。?

? ? ? ?去中心化的數(shù)據(jù)管理對(duì)微服務(wù)的數(shù)據(jù)更新有較大影響酷勺，在單體應(yīng)用中本橙，跨越多個(gè)資源的數(shù)據(jù)更新用數(shù)據(jù)庫(kù)的事務(wù)就可以保證一致性，但在微服務(wù)領(lǐng)域脆诉，由于每個(gè)微服務(wù)都單獨(dú)管理自己的數(shù)據(jù)庫(kù)甚亭，數(shù)據(jù)庫(kù)采用的管理軟件，存儲(chǔ)方式都不一樣击胜，所以這是一個(gè)很大的難點(diǎn)亏狰，分布式事務(wù)實(shí)現(xiàn)起來(lái)難度很大，帶來(lái)了很多的額外的復(fù)雜度偶摔，因此微服務(wù)架構(gòu)強(qiáng)調(diào)使用沒(méi)有事務(wù)的微服務(wù)之間的協(xié)調(diào)機(jī)制暇唾，這種方式明確的提出一致性只能是最終一致性來(lái)保證，可能產(chǎn)生的問(wèn)題只能通過(guò)補(bǔ)償機(jī)制來(lái)完成辰斋。

? ? ?這種去中心帶來(lái)的不一致問(wèn)題會(huì)給開(kāi)發(fā)團(tuán)隊(duì)帶來(lái)很大的挑戰(zhàn)策州，但這也是最符合實(shí)際的業(yè)務(wù)實(shí)質(zhì)。在實(shí)際的業(yè)務(wù)處理中為了快速應(yīng)對(duì)需求也會(huì)有一些不一致宫仗，往往通過(guò)逆向的流程來(lái)處理够挂。只要處理這種錯(cuò)誤的代價(jià)小于強(qiáng)一致性帶來(lái)的業(yè)務(wù)損失，這種取舍就是值得的锰什。

2.7 基礎(chǔ)設(shè)施自動(dòng)化

? ? ? 基礎(chǔ)設(shè)施自動(dòng)化在過(guò)去幾年有了長(zhǎng)足的發(fā)展，云計(jì)算的發(fā)展簡(jiǎn)化了構(gòu)建丁逝、部署和維護(hù)微服務(wù)的復(fù)雜度汁胆。很多產(chǎn)品和系統(tǒng)通過(guò)持續(xù)集成和持續(xù)交付構(gòu)建，采用這些方法的團(tuán)隊(duì)極大的利用了基礎(chǔ)設(shè)施自動(dòng)化霜幼，下面這張圖展示了構(gòu)建流水線(xiàn)的過(guò)程嫩码。

單體應(yīng)用能夠用持續(xù)集成和持續(xù)交付流程快速的部署到生產(chǎn)環(huán)境，只要單體應(yīng)用完成了這種自動(dòng)化構(gòu)建罪既，部署多個(gè)微服務(wù)也不會(huì)更復(fù)雜铸题，無(wú)非是單體應(yīng)用是單個(gè)少量的應(yīng)用铡恕，但微服務(wù)是多個(gè)應(yīng)用，1個(gè)和多個(gè)之間沒(méi)有太大的區(qū)別丢间。

2.8 失效設(shè)計(jì)

? ? ? ?采用微服務(wù)這種設(shè)計(jì)風(fēng)格探熔，應(yīng)用本身就應(yīng)該被設(shè)計(jì)成能容忍失效，任何服務(wù)調(diào)用都有可能因?yàn)槟繕?biāo)服務(wù)不可用而失效烘挫，調(diào)用方必須能夠盡可能優(yōu)雅的處理诀艰，從這一點(diǎn)上來(lái)說(shuō)，這相比單體應(yīng)用引入了額外的復(fù)雜性饮六。所以微服務(wù)團(tuán)隊(duì)要考慮微服務(wù)的失效其垄，如何影響到用戶(hù)體驗(yàn)。Netflix 通過(guò)自生產(chǎn)環(huán)境里面注入微服務(wù)卤橄、數(shù)據(jù)中心故障來(lái)測(cè)試應(yīng)用的韌性和應(yīng)用的監(jiān)控能力绿满。這種一周繁忙工作結(jié)束后在生產(chǎn)環(huán)境的自動(dòng)化測(cè)試足以讓很多的開(kāi)發(fā)團(tuán)隊(duì)不寒而栗，需要很強(qiáng)大的勇氣和技術(shù)實(shí)力作為保障窟扑。

? ? ? ?當(dāng)然這不是說(shuō)單體架構(gòu)就不能做這種類(lèi)型的失效設(shè)計(jì)喇颁，只是不像微服務(wù)架構(gòu)風(fēng)格這么常見(jiàn)。因?yàn)槲⒎?wù)可能在任何時(shí)候失效辜膝，所以快速的發(fā)現(xiàn)這些失效的微服務(wù)无牵，并恢復(fù)它們（如果可能）至關(guān)重要。微服務(wù)架構(gòu)在服務(wù)的監(jiān)控上需要花費(fèi)更多的精力厂抖，需要監(jiān)控架構(gòu)指標(biāo)（如數(shù)據(jù)庫(kù)每分鐘處理多少請(qǐng)求）和業(yè)務(wù)指標(biāo)（每分鐘接收到多少訂單）茎毁，這種指標(biāo)層面的監(jiān)控可以給開(kāi)發(fā)團(tuán)隊(duì)告警，從而讓開(kāi)發(fā)團(tuán)隊(duì)去跟進(jìn)和調(diào)查忱辅。這種微服務(wù)的監(jiān)控七蜘，在單體應(yīng)用的設(shè)計(jì)中可以而且也應(yīng)該被監(jiān)控記錄下來(lái)，但單體應(yīng)用往往在單個(gè)進(jìn)程里面墙懂，因此某個(gè)單體應(yīng)用中的組件橡卤，連接不上、失效的價(jià)值就沒(méi)有微服務(wù)這么大了损搬。

? ? ? 現(xiàn)在越來(lái)越多的更高級(jí)的監(jiān)控工具和日志工具已經(jīng)被開(kāi)發(fā)出來(lái)碧库，很多是開(kāi)源使用的，在這些監(jiān)控工具下巧勤，可以在管理面板上看到各個(gè)微服務(wù)的運(yùn)行狀態(tài)嵌灰、吞吐量和業(yè)務(wù)指標(biāo)，熔斷狀態(tài)颅悉、延遲等我們關(guān)注的一系列指標(biāo)沽瞭。

2.9 演進(jìn)式設(shè)計(jì)

? ? ? ?微服務(wù)的實(shí)踐者，通常具有演進(jìn)式的設(shè)計(jì)思路剩瓶，把服務(wù)拆分作為一種工具來(lái)控制變更驹溃，而不是降低變更的速度城丧。控制變更不是說(shuō)減少變更豌鹤，用正確的工具和態(tài)度亡哄，不但可以頻繁、快速的傍药，而且可以良好的控制變更磺平。

? ? ? ?如論什么時(shí)候，開(kāi)始拆分系統(tǒng)的時(shí)候拐辽，都面臨如何劃分的問(wèn)題拣挪，這里一個(gè)簡(jiǎn)單的原則即可了獨(dú)立替換、可獨(dú)立升級(jí)原則俱诸，這也就說(shuō)我們可以重寫(xiě)整個(gè)微服務(wù)而不用影響微服務(wù)之間的協(xié)作菠劝。事實(shí)上有的團(tuán)隊(duì)更進(jìn)一步，認(rèn)為服務(wù)從長(zhǎng)遠(yuǎn)來(lái)看更傾向于走向消亡而不是長(zhǎng)期演進(jìn)睁搭。

? ? ? 英國(guó)衛(wèi)報(bào)網(wǎng)站是一個(gè)單體應(yīng)用向微服務(wù)演進(jìn)很好的例子赶诊，單體應(yīng)用還是網(wǎng)站的核心部分，但新增加的功能和特性就采用微服務(wù)調(diào)用單體API的方式實(shí)現(xiàn)园骆，這種方式對(duì)一些天生就是臨時(shí)性的服務(wù)特別有用舔痪，比如處理某個(gè)體育時(shí)間的專(zhuān)題頁(yè)，這種一次性的專(zhuān)題頁(yè)锌唾，可以通過(guò)快速開(kāi)發(fā)的方式锄码，采用快速開(kāi)發(fā)語(yǔ)言開(kāi)發(fā)出一些服務(wù)出來(lái)，在事件結(jié)束后再?gòu)U棄掉晌涕。這種方式在財(cái)經(jīng)機(jī)構(gòu)的服務(wù)里面也很常見(jiàn)滋捶，快速的開(kāi)發(fā)出服務(wù)，幾個(gè)月以后再?gòu)U棄掉余黎。

? ? ?這里強(qiáng)調(diào)可替換性重窟，是更通用的模塊化設(shè)計(jì)的一個(gè)特殊場(chǎng)景，我們總應(yīng)該讓變更同一個(gè)時(shí)間發(fā)生在一個(gè)模塊內(nèi)部惧财，不希望是跨越多個(gè)模塊的巡扇，如果你發(fā)現(xiàn)兩個(gè)服務(wù)總是同時(shí)一起改動(dòng)，那么這就是這兩個(gè)微服務(wù)應(yīng)該合并的信號(hào)垮衷。把組件組合成一個(gè)服務(wù)可以形成更粗粒度的版本發(fā)布計(jì)劃厅翔，單體應(yīng)用需要整個(gè)應(yīng)用全部的構(gòu)建和發(fā)布一遍，但微服務(wù)架構(gòu)風(fēng)格下帘靡，僅需要構(gòu)建和替換修改的這個(gè)微服務(wù)知给，這可以簡(jiǎn)化和加速發(fā)布過(guò)程瓤帚，缺點(diǎn)是不得不考慮單個(gè)服務(wù)升級(jí)對(duì)服務(wù)的調(diào)用方的影響描姚，傳統(tǒng)的做法是采用版本的概念來(lái)管理涩赢，但在微服務(wù)架構(gòu)風(fēng)格下，版本僅作為最后不得已的手段轩勘，我們?cè)谠O(shè)計(jì)微服務(wù)時(shí)筒扒，應(yīng)該盡可能的考慮能容忍被調(diào)用方的變化。

2.10 微服務(wù)是未來(lái)的主流趨勢(shì)嗎

? ? ? ?微服務(wù)是未來(lái)的主流趨勢(shì)嗎绊寻，這個(gè)問(wèn)題沒(méi)有人能給出確定的答案花墩，文章本身也是聚焦在闡述微服務(wù)的主要特點(diǎn)以及和單體應(yīng)用的不同，就連微服務(wù)之父也不能確定的說(shuō)微服務(wù)就是未來(lái)的主流趨勢(shì)澄步，他也承認(rèn)需要更多的時(shí)間來(lái)觀(guān)察冰蘑，盡管當(dāng)前微服務(wù)帶給我們的積極的正向的影響要多于負(fù)面的影響，但可以肯定的是微服務(wù)是當(dāng)前重要的一種架構(gòu)風(fēng)格村缸，值得我們?nèi)ド羁炭紤]和投資祠肥，有一些先驅(qū)已經(jīng)踐行這種風(fēng)格，并且應(yīng)用的非常成功梯皿，國(guó)外的比如亞馬遜仇箱、Netflix、英國(guó)衛(wèi)報(bào)东羹、英國(guó)政府等剂桥，國(guó)內(nèi)的阿里巴巴、騰訊属提、網(wǎng)易权逗、以及筆者供職的華為也都大量的采用了微服務(wù)這種架構(gòu)風(fēng)格，還有很多的這樣的企業(yè)正在是使用這種風(fēng)格的架構(gòu)來(lái)構(gòu)建自己的企業(yè)IT系統(tǒng)垒拢。