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

微服務概述

微服務娇斑，顧名思義微小的服務，當傳統(tǒng)的單體應用規(guī)模和復雜度達到一定程度的時候材部，應用的管理毫缆、擴展、可靠性等方面就會出現(xiàn)瓶頸乐导，一個基本原則就是分而治之苦丁，把一個大的復雜應用拆分成多個小的服務，讓每個小服務可以單獨進行管理物臂、擴展旺拉，微服務由此演化而來。

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

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

微服務架構特點

1巩踏、去中心化

傳統(tǒng)的單體應用只有一個服務，這個服務就是系統(tǒng)的中心续搀，而微服務架構是去中心化的塞琼，把復雜的系統(tǒng)拆分成多個簡單的分布式組件，每個組件都是服務化的禁舷，能夠獨立部署獨立升級彪杉。

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

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

2、專注做好一件事

微服務架構的關鍵在于業(yè)務功能的合理拆分工坊，以最終實現(xiàn)分布式系統(tǒng)的高內(nèi)聚错沃、低耦合雀瓢，如果拆分不合理還會導致后期代碼維護和功能擴展越發(fā)困難玉掸。

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

3、語言多樣性

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

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

4悼沈、RESTful無狀態(tài)

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

5贮乳、服務容錯保護

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

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

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

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

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

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

7、擁抱容器技術

有人說容器和微服務簡直是天生一對捧请，容器的輕巧高效恰好匹配微服務的靈活多變凡涩，結合Docker容器技術和微服務架構有助于應用的持續(xù)集成、持續(xù)交付和持續(xù)部署疹蛉，目前備受追捧的云原生技術就是直接把微服務構建在容器基礎設施上活箕。

隨著Kubernetes等容器基礎設施的日趨成熟可款，容器逐漸成為微服務的標準載體育韩，在容器基礎設施上構建運行高可用、高可擴展的微服務將越來越簡單闺鲸。

微服務的挑戰(zhàn)

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

應用的挑戰(zhàn)

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

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

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

架構的挑戰(zhàn)

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

孟老夫子說過魚和熊掌不可兼得，則舍魚而取熊掌者也劫樟。在分布式系統(tǒng)中，分區(qū)容忍是必須要滿足的附较，所以一般在一致性和可用性之間進行權衡事示，要么舍棄部分一致性揉稚，追求高可用延塑；要么嚴格強調(diào)一致性宋雏，損失部分高可用磨总。

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

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

實際應用中要根據(jù)系統(tǒng)對高可用和一致性等各方面的要求程度玖院，做出適當?shù)臋嗪夂腿∩帷?/p>

是否采用微服務

對一個系統(tǒng)來講菠红，架構是逐步演進的，是否采用微服務架構要根據(jù)具體的團隊和業(yè)務情況來定难菌，一般來講试溯，如果團隊規(guī)模和業(yè)務復雜度達到一定程度，單體應用已經(jīng)力不從心的時候就該上微服務了郊酒。