微服務(wù)是近年來比較熱門的服務(wù)架構(gòu)思想，本文根據(jù)個人理解聊聊微服務(wù)架構(gòu)，不足之處還請指正。

微服務(wù)概述

微服務(wù)，顧名思義微小的服務(wù)，當(dāng)傳統(tǒng)的單體應(yīng)用規(guī)模和復(fù)雜度達(dá)到一定程度的時候，應(yīng)用的管理、擴(kuò)展、可靠性等方面就會出現(xiàn)瓶頸，一個基本原則就是分而治之，把一個大的復(fù)雜應(yīng)用拆分成多個小的服務(wù)，讓每個小服務(wù)可以單獨進(jìn)行管理、擴(kuò)展，微服務(wù)由此演化而來。

微服務(wù)強調(diào)拆分后服務(wù)的獨立性，麻雀雖小，五臟俱全，每個微服務(wù)有自己獨立的數(shù)據(jù)庫，有自己的業(yè)務(wù)實現(xiàn)，各自運行在獨立的進(jìn)程中，對外提供設(shè)計好的接口，服務(wù)間去耦合，通過RPC、HTTP等標(biāo)準(zhǔn)協(xié)議進(jìn)行交互，服務(wù)內(nèi)部功能可以使用任意語言和框架實現(xiàn)，對外是不可見的。

微服務(wù)有點像KTV包廂，包廂之間是相互獨立的，每個包廂有自己的音響、點歌機(jī)，包廂之間僅通過過道和門連通。你可以在KTV包廂里面盡情歌唱都不會影響別人，就像你可以用Java、Python、go等多種語言實現(xiàn)多個微服務(wù)，只要接口明確，它們都能很好地協(xié)同。

微服務(wù)架構(gòu)特點

1、去中心化

傳統(tǒng)的單體應(yīng)用只有一個服務(wù)，這個服務(wù)就是系統(tǒng)的中心，而微服務(wù)架構(gòu)是去中心化的，把復(fù)雜的系統(tǒng)拆分成多個簡單的分布式組件，每個組件都是服務(wù)化的，能夠獨立部署獨立升級。

除了業(yè)務(wù)邏輯去中心化，數(shù)據(jù)同樣也要去中心化，微服務(wù)要有自己獨有的數(shù)據(jù)庫，每個服務(wù)只對自己的數(shù)據(jù)負(fù)責(zé)，也不允許直接讀寫別人的數(shù)據(jù)庫，就像自家的資產(chǎn)只能自己處置，別人不能隨便動。

去中心化有利于降低系統(tǒng)內(nèi)部服務(wù)冗余，使組件服務(wù)能夠靈活地擴(kuò)展和升級，比如有針對性地對系統(tǒng)某些高頻組件進(jìn)行擴(kuò)容，就能快速提升系統(tǒng)并發(fā)能力，節(jié)省成本。

2、專注做好一件事

微服務(wù)架構(gòu)的關(guān)鍵在于業(yè)務(wù)功能的合理拆分，以最終實現(xiàn)分布式系統(tǒng)的高內(nèi)聚、低耦合，如果拆分不合理還會導(dǎo)致后期代碼維護(hù)和功能擴(kuò)展越發(fā)困難。

通常架構(gòu)設(shè)計時盡可能使每個微服務(wù)專注做好一件事，合理劃分服務(wù)邊界，使數(shù)據(jù)結(jié)構(gòu)易于獨立，對外接口簡潔通用，一個好的設(shè)計理念就是領(lǐng)域驅(qū)動設(shè)計(Domain Driven Design)，根據(jù)領(lǐng)域的邊界設(shè)計服務(wù)范疇。

3、語言多樣性

單體應(yīng)用通常只能采用單一語言開發(fā)，但每種編程語言都有各自優(yōu)勢，協(xié)作團(tuán)隊中通常每個人都有各自擅長的語言框架，單體應(yīng)用限制了這種自由，而在微服務(wù)系統(tǒng)中沒有這些限制，各個服務(wù)相互獨立，每個服務(wù)都可以用不同的編程語言實現(xiàn)，每個人都可以發(fā)揮自己的特長。

事實上，技術(shù)的多樣性對一個系統(tǒng)的健壯性也大有裨益，除了可以發(fā)揮多種語言框架的優(yōu)勢，還可以逐步引入新技術(shù)，有利于系統(tǒng)的演進(jìn)升級。

4、RESTful無狀態(tài)

微服務(wù)架構(gòu)很好地實現(xiàn)了服務(wù)解耦和水平擴(kuò)展，服務(wù)接口做成RESTful無狀態(tài)的，業(yè)務(wù)邏輯與數(shù)據(jù)分離，服務(wù)間通過RESTful API交互，這樣服務(wù)實例就可以按需進(jìn)行彈性伸縮。

5、服務(wù)容錯保護(hù)

我們知道在分布式系統(tǒng)中，節(jié)點失效應(yīng)被視作常態(tài)而不是意外，即節(jié)點失效是一定會發(fā)生的，要實現(xiàn)系統(tǒng)高可用，必須要提前做好預(yù)備措施。微服務(wù)體系中，由于服務(wù)間錯綜復(fù)雜的依賴關(guān)系，對微服務(wù)進(jìn)行容錯保護(hù)是很有必要的，當(dāng)某個服務(wù)實例出錯時及時進(jìn)行降級、隔離，既能提高響應(yīng)速度，還能防止請求積壓造成雪崩。

服務(wù)容錯保護(hù)和業(yè)內(nèi)常提的異地多活、Design For Failure 等思想一脈相承，一方面是服務(wù)提供方的多實例冗余，另一方面是服務(wù)消費方的容錯保護(hù)，都是為分布式系統(tǒng)的高可用所做的預(yù)備措施。

當(dāng)然任何系統(tǒng)都很難保證絕對可用，前不久就連AWS和Google Cloud都發(fā)生過服務(wù)中斷事件，這在互聯(lián)網(wǎng)系統(tǒng)中都是災(zāi)難性的，我們只能通過各種容錯手段盡量避免此類事件發(fā)生。

6、開發(fā)運維一體化

開發(fā)運維一體化即流行的DevOps，誰開發(fā)的誰運維，這樣開發(fā)人員能更快地響應(yīng)業(yè)務(wù)需求，更好地保障服務(wù)后續(xù)運行和升級，同時避免團(tuán)隊間大量的無效溝通和摩擦。

現(xiàn)在流行的各種CI/CD、自動化運維技術(shù)也在促進(jìn)開發(fā)運維一體化。

7、擁抱容器技術(shù)

有人說容器和微服務(wù)簡直是天生一對，容器的輕巧高效恰好匹配微服務(wù)的靈活多變，結(jié)合Docker容器技術(shù)和微服務(wù)架構(gòu)有助于應(yīng)用的持續(xù)集成、持續(xù)交付和持續(xù)部署，目前備受追捧的云原生技術(shù)就是直接把微服務(wù)構(gòu)建在容器基礎(chǔ)設(shè)施上。

隨著Kubernetes等容器基礎(chǔ)設(shè)施的日趨成熟，容器逐漸成為微服務(wù)的標(biāo)準(zhǔn)載體，在容器基礎(chǔ)設(shè)施上構(gòu)建運行高可用、高可擴(kuò)展的微服務(wù)將越來越簡單。

微服務(wù)的挑戰(zhàn)

微服務(wù)作為近年來流行的軟件架構(gòu)風(fēng)格，它能幫助我們實現(xiàn)系統(tǒng)的高可用和高可擴(kuò)展性，但微服務(wù)也會有各種挑戰(zhàn)。

應(yīng)用的挑戰(zhàn)

由于微服務(wù)將整個系統(tǒng)進(jìn)行拆分，所以系統(tǒng)的架構(gòu)、開發(fā)工作量和復(fù)雜度會增加不少；

原來的單體應(yīng)用變成一系列微服務(wù)，要管理和協(xié)調(diào)這些服務(wù)，系統(tǒng)的運維復(fù)雜度會增加不少；

原來調(diào)用的本地方法變成了服務(wù)間的遠(yuǎn)程調(diào)用，可能會使系統(tǒng)性能有所降低，這意味著要增加硬件投入。

架構(gòu)的挑戰(zhàn)

除了應(yīng)用中的挑戰(zhàn)，微服務(wù)架構(gòu)本身也面臨挑戰(zhàn)，根據(jù)CAP理論，在分布式系統(tǒng)中數(shù)據(jù)一致性(Consistency)、服務(wù)可用性(Availability)、分區(qū)容忍性(Partition tolerance)三者不可能同時滿足，最多只能實現(xiàn)其中兩點，那么如何根據(jù)業(yè)務(wù)特點做出最佳權(quán)衡和取舍，就是微服務(wù)架構(gòu)面臨的挑戰(zhàn)。

孟老夫子說過魚和熊掌不可兼得，則舍魚而取熊掌者也。在分布式系統(tǒng)中，分區(qū)容忍是必須要滿足的，所以一般在一致性和可用性之間進(jìn)行權(quán)衡，要么舍棄部分一致性，追求高可用；要么嚴(yán)格強調(diào)一致性，損失部分高可用。

到底是高可用重要還是一致性重要，這在服務(wù)注冊中心也對應(yīng)著兩種流派：一種是Eureka為代表的AP流派，強調(diào)高可用，弱化一致性；另一種是CP流派，典型的就是ZooKeeper這類注冊中心，更強調(diào)一致性，但會犧牲部分高可用。

一種常用的折中方案就是BASE原則，它是指基本可用（Basically Available）、軟狀態(tài)（Soft State）和最終一致性（Eventual Consistency），也就是犧牲強一致性，獲得較好的可用性，允許暫時的狀態(tài)或數(shù)據(jù)不一致，只要最終一致就行了。

實際應(yīng)用中要根據(jù)系統(tǒng)對高可用和一致性等各方面的要求程度，做出適當(dāng)?shù)臋?quán)衡和取舍。

是否采用微服務(wù)

對一個系統(tǒng)來講，架構(gòu)是逐步演進(jìn)的，是否采用微服務(wù)架構(gòu)要根據(jù)具體的團(tuán)隊和業(yè)務(wù)情況來定，一般來講，如果團(tuán)隊規(guī)模和業(yè)務(wù)復(fù)雜度達(dá)到一定程度，單體應(yīng)用已經(jīng)力不從心的時候就該上微服務(wù)了。