到底有什么區(qū)別？一文講透底層邏輯與工程實(shí)踐)
0. 先給結(jié)論很多人把面試掛在了這一題上先從不少開(kāi)發(fā)者都經(jīng)歷過(guò)的一個(gè)場(chǎng)景說(shuō)起。面試官問(wèn)“你做過(guò)微服務(wù)項(xiàng)目那你說(shuō)說(shuō)分布式和微服務(wù)有什么區(qū)別”很多人的第一反應(yīng)是“微服務(wù)就是分布式的一種落地方式。”然后面試官接著問(wèn)“那分布式系統(tǒng)的 CAP、事務(wù)、冪等、注冊(cè)中心這些和微服務(wù)到底是什么關(guān)系”這時(shí)候不少人就開(kāi)始含糊了。這不是個(gè)別現(xiàn)象。在實(shí)際工作中很多團(tuán)隊(duì)把“微服務(wù)”掛在嘴邊但真正遇到問(wèn)題時(shí)討論的卻是分布式系統(tǒng)的話題某個(gè)接口超時(shí)了、某個(gè)節(jié)點(diǎn)掛了、數(shù)據(jù)在兩個(gè)服務(wù)之間不一致了、某個(gè)接口被大量重復(fù)調(diào)用了。這些問(wèn)題的背后其實(shí)都是分布式系統(tǒng)的經(jīng)典問(wèn)題只是恰好發(fā)生在微服務(wù)架構(gòu)里。所以分布式和微服務(wù)到底是什么關(guān)系我的判斷是這兩個(gè)詞根本不在同一個(gè)維度上機(jī)械地比較“誰(shuí)包含誰(shuí)”意義不大。分布式描述的是“多臺(tái)機(jī)器協(xié)作”的系統(tǒng)形態(tài)微服務(wù)描述的是“如何組織業(yè)務(wù)代碼”的架構(gòu)風(fēng)格。一個(gè)系統(tǒng)可以同時(shí)是分布式的和微服務(wù)化的也可以是分布式但不是微服務(wù)甚至可以是微服務(wù)架構(gòu)但部署在一臺(tái)機(jī)器上雖然這不常見(jiàn)也有點(diǎn)奇怪。這篇文章想做的不是給兩個(gè)概念下定義就結(jié)束而是把它們的底層邏輯、適用場(chǎng)景、常見(jiàn)誤區(qū)和實(shí)際工程中的映射關(guān)系一次說(shuō)清楚。無(wú)論你是準(zhǔn)備面試還是真的要從單體架構(gòu)演進(jìn)到分布式架構(gòu)這篇文章都值得讀完。1. 一個(gè)核心判斷它們是兩個(gè)維度的東西先把最關(guān)鍵的觀點(diǎn)放在前面。1.1 分布式描述的是系統(tǒng)形態(tài)“分布式”這個(gè)詞核心意思是一個(gè)系統(tǒng)由多個(gè)節(jié)點(diǎn)組成這些節(jié)點(diǎn)通過(guò)網(wǎng)絡(luò)通信協(xié)作完成業(yè)務(wù)功能。判斷一個(gè)系統(tǒng)是不是分布式不看它的業(yè)務(wù)代碼怎么組織只看它是否滿(mǎn)足兩個(gè)條件多個(gè)獨(dú)立的計(jì)算節(jié)點(diǎn)物理機(jī)、虛擬機(jī)、容器共同參與。節(jié)點(diǎn)之間通過(guò)網(wǎng)絡(luò)進(jìn)行消息傳遞、數(shù)據(jù)同步或任務(wù)協(xié)作。節(jié)點(diǎn)之間怎么通信、數(shù)據(jù)怎么保持一致、某個(gè)節(jié)點(diǎn)掛了怎么辦這些才是分布式系統(tǒng)的核心問(wèn)題。換句話說(shuō)分布式是從“物理形態(tài)”和“系統(tǒng)拓?fù)洹苯嵌让枋鰡?wèn)題。1.2 微服務(wù)描述的是業(yè)務(wù)組織方式“微服務(wù)”這個(gè)詞核心意思是把業(yè)務(wù)系統(tǒng)拆分成一組小而自治的服務(wù)每個(gè)服務(wù)圍繞特定業(yè)務(wù)能力構(gòu)建獨(dú)立開(kāi)發(fā)、獨(dú)立部署、獨(dú)立擴(kuò)展。判斷一個(gè)系統(tǒng)是不是微服務(wù)看的是它的架構(gòu)風(fēng)格服務(wù)是否按業(yè)務(wù)邊界拆分。服務(wù)是否獨(dú)立開(kāi)發(fā)、獨(dú)立部署。服務(wù)之間是否通過(guò)輕量級(jí)通信協(xié)議通常是 HTTP/REST 或消息隊(duì)列交互。每個(gè)服務(wù)是否擁有自己獨(dú)立的數(shù)據(jù)庫(kù)或數(shù)據(jù)存儲(chǔ)。微服務(wù)是從軟件工程方法和架構(gòu)組織角度解決問(wèn)題。1.3 兩者最本質(zhì)的區(qū)別用一個(gè)類(lèi)比來(lái)幫助理解。假設(shè)你要建一棟辦公樓“分布式”描述的是這棟樓有多個(gè)樓層每層都有獨(dú)立的承重結(jié)構(gòu)、獨(dú)立的水電系統(tǒng)樓層之間通過(guò)電梯和管道連通。這是物理結(jié)構(gòu)層面的描述?！拔⒎?wù)”描述的是把這棟樓按功能分區(qū)一層做接待、二層做研發(fā)、三層做財(cái)務(wù)每個(gè)區(qū)域由不同的團(tuán)隊(duì)獨(dú)立使用和管理。這是功能組織層面的描述。這兩者當(dāng)然有關(guān)系但直接問(wèn)“分布式和微服務(wù)有什么區(qū)別”就像問(wèn)“多層建筑和功能分區(qū)有什么區(qū)別”一樣——它們說(shuō)的是兩件事。但這個(gè)類(lèi)比還有一個(gè)關(guān)鍵補(bǔ)充大多數(shù)微服務(wù)架構(gòu)在物理部署上確實(shí)是分布式的。因?yàn)槲⒎?wù)的價(jià)值之一就是獨(dú)立擴(kuò)展、獨(dú)立部署這天然要求服務(wù)運(yùn)行在不同的節(jié)點(diǎn)上。于是微服務(wù)架構(gòu)就同時(shí)具備了兩個(gè)維度的問(wèn)題既是分布式的也是微服務(wù)化的。所以實(shí)際工程中這兩件事經(jīng)常攪在一起。這也正是很多人問(wèn)不清楚、答不明白的根本原因。2. 再談分布式它要解決什么代價(jià)是什么2.1 分布式系統(tǒng)解決的根本問(wèn)題分布式系統(tǒng)的出現(xiàn)本質(zhì)上是三個(gè)字扛不住。流量大了一臺(tái)機(jī)器 CPU 飆到 99%數(shù)據(jù)庫(kù)連接池被打滿(mǎn)接口超時(shí)。這時(shí)候最直接的想法是再加一臺(tái)機(jī)器把流量分?jǐn)偟?。于是有了?fù)載均衡為了故障轉(zhuǎn)移還要做高可用兩臺(tái)機(jī)器的數(shù)據(jù)要同步于是有了主從復(fù)制、緩存、消息隊(duì)列。這些手段組合起來(lái)就是一個(gè)典型的分布式系統(tǒng)。分布式系統(tǒng)解決的核心問(wèn)題是用一堆普通機(jī)器換來(lái)單機(jī)無(wú)法提供的性能、容量和可用性。但代價(jià)是巨大的。2.2 分布式引入的三大經(jīng)典問(wèn)題把系統(tǒng)從單機(jī)改造成分布式之后會(huì)立刻面對(duì)幾個(gè)在單機(jī)時(shí)代根本不存在的問(wèn)題。第一數(shù)據(jù)一致性。單機(jī)數(shù)據(jù)庫(kù)有事務(wù)ACID 保證數(shù)據(jù)要么全部提交要么全部回滾。分布式環(huán)境下多個(gè)節(jié)點(diǎn)各自持有數(shù)據(jù)一個(gè)業(yè)務(wù)操作橫跨多個(gè)節(jié)點(diǎn)怎么保證這些數(shù)據(jù)最終一致這就是分布式事務(wù)問(wèn)題的來(lái)源?，F(xiàn)實(shí)中的解決思路包括兩階段提交、TCCTry-Confirm-Cancel、Saga 事務(wù)、最大努力通知等。Seata 這個(gè)中間件大家應(yīng)該不陌生它解決的問(wèn)題就是分布式事務(wù)。它支持 AT 模式、TCC 模式、Saga 模式和 XA 模式其中最常用的 AT 模式核心思想是通過(guò)代理數(shù)據(jù)源記錄 SQL 執(zhí)行前后的鏡像在全局事務(wù)提交時(shí)對(duì)比鏡像判斷是否沖突再?zèng)Q定回滾還是提交。這套機(jī)制本質(zhì)上就是給分布式環(huán)境下的多節(jié)點(diǎn)操作加了一個(gè)“協(xié)調(diào)層”。第二網(wǎng)絡(luò)不可靠。單機(jī)系統(tǒng)里方法調(diào)用是進(jìn)程內(nèi)的要么成功要么拋出異常。分布式環(huán)境下A 服務(wù)調(diào)用 B 服務(wù)如果超時(shí)了A 怎么知道 B 到底有沒(méi)有執(zhí)行成功重試嗎如果 B 其實(shí)已經(jīng)執(zhí)行成功了重試就可能導(dǎo)致重復(fù)操作。這時(shí)就需要冪等設(shè)計(jì)接口要支持重復(fù)調(diào)用而不產(chǎn)生副作用。Redis 分布式鎖解決的就是分布式環(huán)境下的并發(fā)控制問(wèn)題。比如一個(gè)訂單處理服務(wù)多個(gè)節(jié)點(diǎn)同時(shí)處理同一筆訂單如果不加鎖就會(huì)出現(xiàn)重復(fù)扣減庫(kù)存、重復(fù)發(fā)放優(yōu)惠券等問(wèn)題。Redisson 提供的分布式鎖就是經(jīng)典方案通過(guò) Redis 的 SETNX 或 Lua 腳本保證鎖的原子性通過(guò)看門(mén)狗機(jī)制自動(dòng)續(xù)期。第三故障處理復(fù)雜度上升。單機(jī)系統(tǒng)掛了重啟就行。分布式環(huán)境下一個(gè)節(jié)點(diǎn)掛了其他節(jié)點(diǎn)不能掛系統(tǒng)要能感知到這個(gè)故障把流量切換到健康的節(jié)點(diǎn)上。更麻煩的是“部分失敗”B 服務(wù)掛了A 服務(wù)還在運(yùn)行A 調(diào)用 B 超時(shí)A 的線程被卡住最終 A 的線程池被打滿(mǎn)A 也跟著掛。這就是分布式系統(tǒng)里常見(jiàn)的“雪崩效應(yīng)”。2.3 分布式系統(tǒng)的核心理論這部分內(nèi)容在面試中極為高頻建議至少掌握以下幾組概念。CAP 定理。一個(gè)分布式系統(tǒng)在一致性Consistency、可用性Availability、分區(qū)容錯(cuò)性Partition Tolerance三者之間最多只能同時(shí)滿(mǎn)足兩個(gè)。關(guān)鍵理解是網(wǎng)絡(luò)分區(qū)是不可避免的所以 P 必須保證。真正需要選擇的是當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)系統(tǒng)是選擇 C 還是選擇 A。選擇 CP犧牲部分可用性保證數(shù)據(jù)一致。典型如 ZooKeeper、etcd。選擇 AP保證服務(wù)可用數(shù)據(jù)可能暫時(shí)不一致。典型如 Eureka、Cassandra。BASE 理論。這是對(duì) CAP 中 AP 方案的一個(gè)補(bǔ)充核心思想是Basically Available基本可用。Soft state軟狀態(tài)。Eventually consistent最終一致性。實(shí)際工程中絕大多數(shù)微服務(wù)業(yè)務(wù)場(chǎng)景追求的都不是強(qiáng)一致而是最終一致。比如用戶(hù)下單后訂單狀態(tài)和庫(kù)存扣減通常采用異步消息 重試機(jī)制最終對(duì)齊。2.4 常見(jiàn)的分布式技術(shù)組件在實(shí)際項(xiàng)目中分布式系統(tǒng)往往會(huì)依賴(lài)以下組件解決方向代表技術(shù)說(shuō)明服務(wù)注冊(cè)與發(fā)現(xiàn)Nacos、Eureka、Consul服務(wù)實(shí)例上下線自動(dòng)感知配置管理Nacos Config、Apollo配置集中管理動(dòng)態(tài)刷新網(wǎng)關(guān)路由Spring Cloud Gateway、Nginx統(tǒng)一入口路由轉(zhuǎn)發(fā)過(guò)濾器遠(yuǎn)程調(diào)用OpenFeign、Dubbo、gRPC服務(wù)間 RPC 調(diào)用負(fù)載均衡Ribbon、LoadBalancer減少單點(diǎn)壓力分布式事務(wù)Seata跨服務(wù)事務(wù)一致性分布式鎖Redis Redisson、ZooKeeper跨節(jié)點(diǎn)互斥控制消息隊(duì)列RocketMQ、Kafka、RabbitMQ異步解耦、削峰填谷鏈路追蹤SkyWalking、Zipkin跨服務(wù)調(diào)用鏈分析分布式緩存Redis Cluster熱點(diǎn)數(shù)據(jù)加速這里需要強(qiáng)調(diào)的是出現(xiàn)這些組件是因?yàn)橄到y(tǒng)是分布式的而不是因?yàn)橄到y(tǒng)是微服務(wù)的。即使是兩個(gè)用 Go 寫(xiě)的獨(dú)立服務(wù)只要它們通過(guò)網(wǎng)絡(luò)通信、共享同一份數(shù)據(jù)它們就是一個(gè)分布式系統(tǒng)同樣需要面對(duì)上述問(wèn)題。3. 再談微服務(wù)它要解決什么代價(jià)是什么3.1 微服務(wù)出現(xiàn)的歷史背景微服務(wù)不是憑空出現(xiàn)的。它之所以成為主流是因?yàn)閱误w應(yīng)用在業(yè)務(wù)復(fù)雜度上升到一定程度后暴露出明顯的不可持續(xù)問(wèn)題。一個(gè)典型的單體應(yīng)用代碼量達(dá)到幾十萬(wàn)行甚至上百萬(wàn)行模塊邊界模糊所有人的代碼都往同一個(gè)工程里提交。每次發(fā)版哪怕只改了一行代碼整個(gè)應(yīng)用都要重新構(gòu)建、重新部署。某個(gè)模塊內(nèi)存泄漏可能導(dǎo)致整個(gè)應(yīng)用 OOM所有功能不可用。想擴(kuò)容只能整個(gè)應(yīng)用一起擴(kuò)容無(wú)法只針對(duì)熱點(diǎn)模塊擴(kuò)容。微服務(wù)的思路是按業(yè)務(wù)能力拆分把原來(lái)龐大的單體切割成一組小型服務(wù)。每個(gè)服務(wù)可以獨(dú)立演進(jìn)、獨(dú)立部署、獨(dú)立擴(kuò)容。服務(wù)之間通過(guò)接口通信彼此的實(shí)現(xiàn)細(xì)節(jié)對(duì)外部不可見(jiàn)。3.2 微服務(wù)的核心特征按照 Martin Fowler 對(duì)微服務(wù)的經(jīng)典定義加上工程實(shí)踐中的補(bǔ)充微服務(wù)架構(gòu)通常具備以下特征按業(yè)務(wù)能力拆分服務(wù)邊界由業(yè)務(wù)領(lǐng)域決定而不是由技術(shù)分層決定。比如訂單服務(wù)、用戶(hù)服務(wù)、庫(kù)存服務(wù)。獨(dú)立部署每個(gè)服務(wù)有獨(dú)立的構(gòu)建產(chǎn)物和部署流程可以單獨(dú)上線、回滾。獨(dú)立數(shù)據(jù)存儲(chǔ)每個(gè)服務(wù)擁有自己的數(shù)據(jù)庫(kù)或數(shù)據(jù)表不允許其他服務(wù)直接訪問(wèn)。輕量級(jí)通信服務(wù)間通過(guò) HTTP/REST、gRPC 或消息隊(duì)列通信不共享進(jìn)程內(nèi)存。技術(shù)異構(gòu)不同服務(wù)可以用不同的語(yǔ)言和技術(shù)棧。故障隔離一個(gè)服務(wù)掛掉不影響其他服務(wù)正常運(yùn)行。3.3 微服務(wù)拆分帶來(lái)新的復(fù)雜度微服務(wù)不是銀彈它的代價(jià)同樣巨大。從架構(gòu)層面看原本單體應(yīng)用內(nèi)部的方法調(diào)用變成了跨服務(wù)的網(wǎng)絡(luò)調(diào)用。一次業(yè)務(wù)操作可能涉及三四個(gè)服務(wù)每個(gè)服務(wù)調(diào)用都有超時(shí)和失敗的可能。原來(lái)一個(gè)事務(wù)能解決的數(shù)據(jù)一致性問(wèn)題現(xiàn)在要引入分布式事務(wù)。從運(yùn)維層面看一個(gè)單體應(yīng)用部署一套環(huán)境而一個(gè)微服務(wù)系統(tǒng)可能要同時(shí)運(yùn)維幾十個(gè)服務(wù)每個(gè)服務(wù)又有多個(gè)實(shí)例。這就催生了對(duì)容器化、服務(wù)編排、自動(dòng)化監(jiān)控、日志聚合的強(qiáng)需求。Kubernetes 之所以成為微服務(wù)部署的主流選擇正是因?yàn)樗鉀Q了大規(guī)模服務(wù)編排的問(wèn)題。從團(tuán)隊(duì)協(xié)作層面看微服務(wù)拆分后如果沒(méi)有清晰的接口契約和合理的領(lǐng)域邊界服務(wù)之間的調(diào)用關(guān)系會(huì)迅速變成一團(tuán)亂麻形成“分布式單體”的尷尬局面——名義上是微服務(wù)實(shí)際上是離不開(kāi)彼此的一組進(jìn)程。3.4 微服務(wù)和分布式的關(guān)系再進(jìn)一步現(xiàn)在可以再回答一次開(kāi)頭的那個(gè)問(wèn)題了。微服務(wù)和分布式的關(guān)系可以從兩個(gè)層面看。第一個(gè)層面微服務(wù)通常運(yùn)行在分布式環(huán)境下。微服務(wù)要獨(dú)立部署、獨(dú)立擴(kuò)展這意味著它們大概率運(yùn)行在不同的機(jī)器或容器中。所以一個(gè)微服務(wù)系統(tǒng)通常也是一個(gè)分布式系統(tǒng)需要處理網(wǎng)絡(luò)通信、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、分布式事務(wù)、分布式鎖等分布式問(wèn)題。第二個(gè)層面微服務(wù)不是分布式的必要條件。一個(gè)系統(tǒng)可以不是微服務(wù)架構(gòu)但仍然是分布式的。最典型的例子一個(gè)單體應(yīng)用 MySQL 主從復(fù)制讀寫(xiě)分離應(yīng)用部署在多臺(tái)機(jī)器上負(fù)載均衡。這個(gè)系統(tǒng)是分布式的但不是微服務(wù)。Hadoop 集群的 NameNode 和 DataNodeHDFS 的存儲(chǔ)節(jié)點(diǎn)分布在不同機(jī)器上。這是分布式存儲(chǔ)系統(tǒng)但不是微服務(wù)。所以更準(zhǔn)確的理解是微服務(wù)架構(gòu)是一種組織業(yè)務(wù)代碼的方式它通常會(huì)落在分布式環(huán)境中因此同時(shí)繼承了分布式系統(tǒng)的所有特點(diǎn)和復(fù)雜度。4. 何時(shí)需要“分布式”何時(shí)需要“微服務(wù)”很多開(kāi)發(fā)者在做架構(gòu)選型時(shí)會(huì)糾結(jié)一個(gè)問(wèn)題我到底要不要上微服務(wù)要不要搞分布式這里先把兩者的觸發(fā)條件分開(kāi)來(lái)看。4.1 觸發(fā)“分布式”需求的信號(hào)分布式系統(tǒng)的引入本質(zhì)上是被業(yè)務(wù)指標(biāo)倒逼的。出現(xiàn)以下信號(hào)時(shí)可以考慮從單機(jī)架構(gòu)走向分布式性能瓶頸單臺(tái)服務(wù)器的 CPU、內(nèi)存、磁盤(pán) IO 已經(jīng)無(wú)法支撐業(yè)務(wù)流量且優(yōu)化代碼、加緩存、加索引的手段已經(jīng)用盡?？捎眯砸髽I(yè)務(wù)要求 7x24 小時(shí)可用不允許單點(diǎn)故障。一臺(tái)機(jī)器掛掉服務(wù)中斷時(shí)間不可接受。數(shù)據(jù)容量超限單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)容量達(dá)到上限或者單庫(kù)的讀寫(xiě)壓力過(guò)高。計(jì)算量巨大一次任務(wù)需要處理海量數(shù)據(jù)單臺(tái)機(jī)器無(wú)法在規(guī)定時(shí)間內(nèi)完成計(jì)算需要多臺(tái)機(jī)器并行處理。4.2 觸發(fā)“微服務(wù)”需求的信號(hào)微服務(wù)解決的不是性能問(wèn)題而是工程復(fù)雜度和團(tuán)隊(duì)協(xié)作問(wèn)題。出現(xiàn)以下信號(hào)才值得考慮微服務(wù)架構(gòu)代碼規(guī)模失控單體應(yīng)用代碼量巨大模塊邊界模糊開(kāi)發(fā)效率明顯下降。團(tuán)隊(duì)規(guī)模變大多個(gè)團(tuán)隊(duì)同時(shí)在一個(gè)代碼庫(kù)上協(xié)作合并沖突頻繁發(fā)布互相影響。發(fā)布頻率不均不同模塊的發(fā)布節(jié)奏差異大有的模塊一周發(fā)幾十次有的模塊一個(gè)月發(fā)一次。單體應(yīng)用把所有模塊綁在一起發(fā)布導(dǎo)致低頻率模塊拖累高頻率模塊。擴(kuò)展需求不均衡系統(tǒng)的不同模塊負(fù)載差異明顯。比如用戶(hù)服務(wù)是熱點(diǎn)而日志服務(wù)很閑。單體應(yīng)用無(wú)法針對(duì)熱點(diǎn)模塊單獨(dú)擴(kuò)容。4.3 避坑建議不是越分布式越好也不是越微服務(wù)越好這是很多團(tuán)隊(duì)容易走偏的地方。先說(shuō)分布式。如果業(yè)務(wù)流量很小一個(gè)小型單體應(yīng)用加一臺(tái)數(shù)據(jù)庫(kù)機(jī)器就能穩(wěn)定運(yùn)行沒(méi)有必要引入 Redis Cluster、消息隊(duì)列、分布式事務(wù)中間件。這些組件會(huì)大幅提高運(yùn)維復(fù)雜度和故障排查成本。再說(shuō)微服務(wù)。如果團(tuán)隊(duì)人數(shù)不到十人業(yè)務(wù)正處于驗(yàn)證階段強(qiáng)行拆微服務(wù)往往得不償失。微服務(wù)的最低開(kāi)銷(xiāo)包括服務(wù)注冊(cè)發(fā)現(xiàn)、配置中心、網(wǎng)關(guān)、鏈路追蹤、日志收集、容器化部署。光把這些基礎(chǔ)設(shè)施搭建起來(lái)就需要不小的學(xué)習(xí)成本和時(shí)間投入。一個(gè)務(wù)實(shí)的路線是先用模塊化單體把代碼按業(yè)務(wù)邊界拆成清晰的 package 或 module當(dāng)團(tuán)隊(duì)規(guī)模和業(yè)務(wù)復(fù)雜度增長(zhǎng)到單體內(nèi)無(wú)法協(xié)調(diào)時(shí)再逐步把模塊抽取為獨(dú)立服務(wù)。不要為了微服務(wù)而微服務(wù)。5. 從代碼視角看一個(gè)業(yè)務(wù)在兩種架構(gòu)下的差異概念講得再多不如看代碼。下面用一個(gè)最小化的訂單創(chuàng)建場(chǎng)景來(lái)演示單體架構(gòu)和微服務(wù)架構(gòu)在代碼組織和部署上的差異。5.1 單體架構(gòu)實(shí)現(xiàn)下單操作涉及用戶(hù)校驗(yàn)、商品庫(kù)存扣減、訂單創(chuàng)建三個(gè)邏輯。在單體應(yīng)用中這些邏輯都在同一個(gè)進(jìn)程內(nèi)完成通過(guò)直接方法調(diào)用協(xié)作。// 單體應(yīng)用OrderService.java Service public class OrderService { Autowired private UserMapper userMapper; Autowired private StockMapper stockMapper; Autowired private OrderMapper orderMapper; Transactional public Order createOrder(Long userId, Long productId, Integer quantity) { // 校驗(yàn)用戶(hù) User user userMapper.selectById(userId); if (user null) { throw new BusinessException(用戶(hù)不存在); } // 扣減庫(kù)存 Stock stock stockMapper.selectById(productId); if (stock.getAvailable() quantity) { throw new BusinessException(庫(kù)存不足); } stock.setAvailable(stock.getAvailable() - quantity); stockMapper.updateById(stock); // 創(chuàng)建訂單 Order order new Order(); order.setUserId(userId); order.setProductId(productId); order.setQuantity(quantity); order.setStatus(OrderStatus.CREATED); orderMapper.insert(order); return order; } }這段代碼最顯著的特點(diǎn)是所有業(yè)務(wù)邏輯在同一個(gè)事務(wù)中執(zhí)行數(shù)據(jù)庫(kù)要么全部提交要么全部回滾。Transactional就能保證一致性不需要分布式事務(wù)。5.2 微服務(wù)架構(gòu)實(shí)現(xiàn)微服務(wù)架構(gòu)下用戶(hù)、庫(kù)存、訂單被拆分為三個(gè)獨(dú)立的服務(wù)各自擁有獨(dú)立的數(shù)據(jù)庫(kù)。此時(shí)createOrder的邏輯分布在不同服務(wù)的接口中。代碼結(jié)構(gòu)變?yōu)閛rder-service/ src/main/java/com/example/order/ OrderController.java OrderService.java OrderMapper.java user-service/ src/main/java/com/example/user/ UserController.java UserService.java UserMapper.java stock-service/ src/main/java/com/example/stock/ StockController.java StockService.java StockMapper.java訂單服務(wù)創(chuàng)建訂單時(shí)需要通過(guò)遠(yuǎn)程調(diào)用訪問(wèn)用戶(hù)服務(wù)和庫(kù)存服務(wù)// order-service 中的遠(yuǎn)程調(diào)用代碼 Service public class OrderService { Autowired private UserClient userClient; Autowired private StockClient stockClient; Autowired private OrderMapper orderMapper; public Order createOrder(Long userId, Long productId, Integer quantity) { // 遠(yuǎn)程調(diào)用 user-service 校驗(yàn)用戶(hù) UserDTO user userClient.getUserById(userId); if (user null) { throw new BusinessException(用戶(hù)不存在); } // 遠(yuǎn)程調(diào)用 stock-service 扣減庫(kù)存 boolean deducted stockClient.deductStock(productId, quantity); if (!deducted) { throw new BusinessException(庫(kù)存不足); } // 本地創(chuàng)建訂單 Order order new Order(); order.setUserId(userId); order.setProductId(productId); order.setQuantity(quantity); order.setStatus(OrderStatus.CREATED); orderMapper.insert(order); return order; } }// order-service 中定義的 Feign 客戶(hù)端接口 FeignClient(name stock-service) public interface StockClient { PostMapping(/stock/deduct) Boolean deductStock(RequestParam(productId) Long productId, RequestParam(quantity) Integer quantity); }把這段代碼和單體版本對(duì)比立刻就能看出幾個(gè)關(guān)鍵差異第一事務(wù)邊界變了。單體版本的Transactional可以包住整個(gè)下單流程。微服務(wù)版本中庫(kù)存扣減是遠(yuǎn)程調(diào)用本地事務(wù)管不到遠(yuǎn)程那邊。一旦訂單創(chuàng)建失敗庫(kù)存已經(jīng)扣了數(shù)據(jù)就不一致了。此時(shí)需要引入 Seata 這類(lèi)分布式事務(wù)中間件或者改成“先預(yù)扣庫(kù)存異步確認(rèn)訂單超時(shí)回補(bǔ)庫(kù)存”的最終一致性方案。第二調(diào)用方式變了。單體版本是進(jìn)程內(nèi)方法調(diào)用微服務(wù)版本是網(wǎng)絡(luò)調(diào)用。網(wǎng)絡(luò)調(diào)用有超時(shí)、有重試、有服務(wù)不可用。上文代碼里的deductStock如果超時(shí)了到底扣沒(méi)扣成功需要設(shè)計(jì)冪等接口客戶(hù)端也要有合理的重試策略。第三部署形態(tài)變了。單體應(yīng)用部署在一個(gè)進(jìn)程里三個(gè)服務(wù)各自部署。訂單服務(wù)擴(kuò)容只影響訂單服務(wù)庫(kù)存服務(wù)擴(kuò)展能力不足可以單獨(dú)增加庫(kù)存服務(wù)的實(shí)例。但這也意味著要引入服務(wù)注冊(cè)中心讓調(diào)用方知道庫(kù)存服務(wù)有哪些可用實(shí)例。從這兩段代碼可以直觀感受到同樣的業(yè)務(wù)從單體變成微服務(wù)后代價(jià)是分布式系統(tǒng)帶來(lái)的收益是微服務(wù)的架構(gòu)彈性帶來(lái)的。兩者在這個(gè)案例中被緊密聯(lián)系在一起但也不是同一件事。6. 微服務(wù)和分布式的高頻實(shí)踐鎖、事務(wù)、配置這部分內(nèi)容在熱搜詞里出現(xiàn)頻率很高也確實(shí)是最常出問(wèn)題的領(lǐng)域。分別展開(kāi)一下。6.1 分布式鎖從 synchronized 到 Redis 鎖單體應(yīng)用時(shí)代多個(gè)線程并發(fā)訪問(wèn)共享資源用synchronized或ReentrantLock就能解決。微服務(wù)部署多個(gè)實(shí)例后兩個(gè)實(shí)例上的線程同時(shí)操作同一份數(shù)據(jù)JVM 級(jí)別的鎖互不感知必須引入分布式鎖。Redis 分布式鎖的常見(jiàn)實(shí)現(xiàn)方式// 使用 Redisson 實(shí)現(xiàn)分布式鎖 Configuration public class RedissonConfig { Bean public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer().setAddress(redis://127.0.0.1:6379); return Redisson.create(config); } }Service public class StockService { Autowired private RedissonClient redissonClient; public boolean deductStock(Long productId, Integer quantity) { String lockKey lock:stock: productId; RLock lock redissonClient.getLock(lockKey); try { // 嘗試加鎖最多等待 5 秒鎖自動(dòng)釋放時(shí)間 30 秒 if (lock.tryLock(5, 30, TimeUnit.SECONDS)) { // 檢查庫(kù)存并扣減 Stock stock stockMapper.selectById(productId); if (stock.getAvailable() quantity) { return false; } stock.setAvailable(stock.getAvailable() - quantity); stockMapper.updateById(stock); return true; } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { // 只有持有鎖的線程才能釋放鎖 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } return false; } }分布式鎖的難點(diǎn)不在加鎖而在鎖的可靠性。常見(jiàn)的坑包括鎖自動(dòng)過(guò)期導(dǎo)致臨界區(qū)并發(fā)執(zhí)行、鎖被其他線程釋放、Redis 主從切換時(shí)鎖丟失。Redisson 的看門(mén)狗機(jī)制解決的是第一個(gè)問(wèn)題但可靠的分布式鎖設(shè)計(jì)仍然需要結(jié)合具體業(yè)務(wù)場(chǎng)景仔細(xì)評(píng)估。在生產(chǎn)環(huán)境還要注意一個(gè)問(wèn)題真正需要鎖保護(hù)的代碼執(zhí)行時(shí)間不能超過(guò)鎖的過(guò)期時(shí)間否則鎖自動(dòng)釋放后其他線程就能進(jìn)入臨界區(qū)。如果業(yè)務(wù)邏輯特別耗時(shí)應(yīng)該評(píng)估并發(fā)沖突的概率或者改造業(yè)務(wù)流程而不是一味地延長(zhǎng)鎖超時(shí)時(shí)間。6.2 分布式事務(wù)從 ACID 到最終一致事務(wù)處理是分布式系統(tǒng)里最復(fù)雜的問(wèn)題之一。單體時(shí)代一個(gè)Transactional就解決的問(wèn)題微服務(wù)架構(gòu)下需要單獨(dú)引入 Seata 或采用其他事務(wù)方案。Seata 的核心概念包括Transaction Coordinator (TC)全局事務(wù)協(xié)調(diào)者維護(hù)全局事務(wù)狀態(tài)。Transaction Manager (TM)事務(wù)管理器負(fù)責(zé)開(kāi)啟全局事務(wù)、提交或回滾。Resource Manager (RM)資源管理器管理各分支事務(wù)的資源。AT 模式下Seata 通過(guò)攔截 SQL 執(zhí)行記錄數(shù)據(jù)變更前后的鏡像。全局提交時(shí)對(duì)比前后鏡像判斷是否有并發(fā)沖突全局回滾時(shí)根據(jù)鏡像數(shù)據(jù)生成反向 SQL 恢復(fù)數(shù)據(jù)。向項(xiàng)目中引入 Seata 的基本步驟如下# application.yml 中關(guān)鍵配置 spring: cloud: alibaba: seata: tx-service-group: my_test_tx_group seata: registry: type: nacos nacos: server-addr: 127.0.0.1:8848 tx-service-group: my_test_tx_group service: vgroup-mapping: my_test_tx_group: default// 分布式事務(wù)入口方法 GlobalTransactional public void createOrderWithSeata(Long userId, Long productId, Integer quantity) { // 遠(yuǎn)程調(diào)用庫(kù)存服務(wù)扣減庫(kù)存 stockClient.deductStock(productId, quantity); // 本地創(chuàng)建訂單 orderMapper.insert(order); }GlobalTransactional注解標(biāo)記的方法就是全局事務(wù)的入口。方法內(nèi)的所有遠(yuǎn)程調(diào)用都會(huì)自動(dòng)納入 Seata 的全局事務(wù)管理。其中一個(gè)分支事務(wù)失敗整體回滾。但也有大量業(yè)務(wù)場(chǎng)景不需要強(qiáng)一致更適合采用“本地消息表 消息隊(duì)列”的最終一致性方案本地事務(wù)中寫(xiě)入業(yè)務(wù)數(shù)據(jù)和消息記錄然后異步把消息投遞到消息隊(duì)列消費(fèi)者消費(fèi)消息完成后續(xù)操作配合重試機(jī)制和冪等消費(fèi)來(lái)保證最終一致。6.3 配置中心從本地文件到動(dòng)態(tài)配置微服務(wù)實(shí)例數(shù)量多且分散如果每個(gè)實(shí)例都維護(hù)一份本地配置改一個(gè)配置就要把所有實(shí)例重新部署一遍顯然不可接受。所以需要引入配置中心。Nacos 是 Java 微服務(wù)生態(tài)中最常用的配置中心和服務(wù)注冊(cè)中心。引入后的核心變化是// 動(dòng)態(tài)刷新配置的代碼示例 RefreshScope RestController public class ConfigController { Value(${order.timeout:1000}) private Integer orderTimeout; GetMapping(/config) public String getConfig() { return 當(dāng)前訂單超時(shí)時(shí)間: orderTimeout; } }# 在 Nacos 配置中心維護(hù)的配置 order.timeout3000通過(guò)RefreshScope注解Nacos 中的配置變更后服務(wù)無(wú)需重啟即可刷新配置。這在多實(shí)例部署場(chǎng)景下價(jià)值極高——不用再為了改一個(gè)參數(shù)而滾動(dòng)重啟所有實(shí)例。7. 面試角度這道題到底想考什么既然這是高頻面試題就站在面試官視角分析一下答題時(shí)怎么組織思路。7.1 面試官提問(wèn)的真實(shí)意圖面試官問(wèn)“分布式和微服務(wù)有什么區(qū)別”通常不是想聽(tīng)一個(gè)標(biāo)準(zhǔn)定義。他真正想了解的是候選人有沒(méi)有真正做過(guò)分布式系統(tǒng)還是只是在簡(jiǎn)歷上寫(xiě)了微服務(wù)。候選人能不能區(qū)分“部署形態(tài)”和“架構(gòu)風(fēng)格”這兩個(gè)不同維度。候選人是否清楚分布式系統(tǒng)引入了哪些復(fù)雜性以及這些復(fù)雜性在微服務(wù)架構(gòu)中是如何體現(xiàn)的。如果把這道題當(dāng)成定義背誦大概率會(huì)掛在一連串追問(wèn)上。常見(jiàn)的追問(wèn)包括你們項(xiàng)目中的某個(gè)業(yè)務(wù)如何保證數(shù)據(jù)一致性服務(wù)調(diào)用超時(shí)了你會(huì)怎么處理重試要考慮什么問(wèn)題多個(gè)微服務(wù)實(shí)例同時(shí)更新同一份數(shù)據(jù)怎么控制并發(fā)你們注冊(cè)中心用的是 Nacos原理是什么為什么不用 ZooKeeper這些問(wèn)題每一個(gè)都在考察分布式系統(tǒng)的實(shí)戰(zhàn)理解。7.2 推薦回答思路可以采用“結(jié)論先行分層展開(kāi)”的答題結(jié)構(gòu)先亮出核心判斷分布式描述的是系統(tǒng)部署形態(tài)微服務(wù)描述的是業(yè)務(wù)組織架構(gòu)兩者不是同一個(gè)維度。分別解釋兩個(gè)概念分布式解決的是多節(jié)點(diǎn)協(xié)作問(wèn)題核心挑戰(zhàn)包括一致性、網(wǎng)絡(luò)不可靠、故障處理微服務(wù)解決的是單體應(yīng)用復(fù)雜度問(wèn)題核心特征是服務(wù)拆分、獨(dú)立部署、獨(dú)立擴(kuò)展。指出兩者的關(guān)系微服務(wù)通常運(yùn)行在分布式環(huán)境中因此微服務(wù)系統(tǒng)同時(shí)是分布式系統(tǒng)但分布式系統(tǒng)不一定是微服務(wù)。落到工程實(shí)踐結(jié)合自己的項(xiàng)目說(shuō)明在微服務(wù)架構(gòu)中遇到了哪些分布式問(wèn)題比如分布式事務(wù)、分布式鎖、配置管理以及自己是怎么解決的。強(qiáng)調(diào)權(quán)衡選擇微服務(wù)不是因?yàn)樗案呒?jí)”而是因?yàn)闃I(yè)務(wù)復(fù)雜度和團(tuán)隊(duì)規(guī)模已經(jīng)到了單體應(yīng)用無(wú)法協(xié)調(diào)的程度選擇分布式同樣是為了解決具體的性能和可用性問(wèn)題。按照這個(gè)思路回答既能展示概念理解也能展示工程經(jīng)驗(yàn)。8. 常見(jiàn)誤區(qū)與避坑清單圍繞分布式和微服務(wù)實(shí)踐中存在不少誤區(qū)。列幾個(gè)最典型的。8.1 誤區(qū)一把微服務(wù)和 SOA 混為一談SOA面向服務(wù)架構(gòu)是微服務(wù)的前身。兩者的區(qū)別在于SOA 偏向于企業(yè)級(jí)服務(wù)重用服務(wù)往往由 ESB企業(yè)服務(wù)總線統(tǒng)一編排微服務(wù)強(qiáng)調(diào)去中心化治理服務(wù)之間直接通信。SOA 服務(wù)粒度更大通常按系統(tǒng)模塊劃分微服務(wù)的粒度更小按業(yè)務(wù)能力劃分。SOA 的通信協(xié)議以 WebService/SOAP 為主微服務(wù)以 HTTP/REST、gRPC 和消息隊(duì)列為主。面試中能說(shuō)出這層演進(jìn)關(guān)系會(huì)展示出你理解技術(shù)演進(jìn)的動(dòng)因而不只是背名詞。8.2 誤區(qū)二以為拆成微服務(wù)就一定要用 Spring CloudSpring Cloud 是 Java 生態(tài)里最主流的微服務(wù)解決方案但不是唯一方案。技術(shù)選型要看團(tuán)隊(duì)技術(shù)棧和業(yè)務(wù)復(fù)雜度Java 技術(shù)?？梢赃x擇 Spring Cloud AlibabaNacos Sentinel Seata社區(qū)活躍中文文檔完善。Go 技術(shù)棧可以選擇 go-micro、go-zero、Kratos。如果服務(wù)數(shù)量少團(tuán)隊(duì)規(guī)模小用輕量級(jí)方案同樣可行比如 Nginx 反向代理 多個(gè)獨(dú)立服務(wù)進(jìn)程也能達(dá)到微服務(wù)的效果。關(guān)鍵詞里提到的“若依微服務(wù)plus”就是一個(gè)基于 Spring Cloud Alibaba 的開(kāi)源腳手架適合作為學(xué)習(xí)微服務(wù)架構(gòu)的入手項(xiàng)目。但要在真實(shí)項(xiàng)目中使用還需要結(jié)合業(yè)務(wù)場(chǎng)景評(píng)估它的擴(kuò)展性和維護(hù)成本。8.3 誤區(qū)三只拆服務(wù)不考慮數(shù)據(jù)最常見(jiàn)的失敗微服務(wù)改造是代碼拆了數(shù)據(jù)庫(kù)沒(méi)拆。所有微服務(wù)共用一個(gè)數(shù)據(jù)庫(kù)看起來(lái)是微服務(wù)實(shí)際只是把一個(gè)單體應(yīng)用拆成了多個(gè)部署單元數(shù)據(jù)耦合依然存在。真正的微服務(wù)要求服務(wù)之間不能直接訪問(wèn)對(duì)方的數(shù)據(jù)庫(kù)表。服務(wù)間的數(shù)據(jù)交換只能通過(guò)接口或消息。所以做微服務(wù)拆分的前提往往是對(duì)數(shù)據(jù)庫(kù)做領(lǐng)域建模和拆分規(guī)劃。這一步比拆代碼難得多也是很多團(tuán)隊(duì)改造失敗的核心原因。8.4 誤區(qū)四分布式鎖、分布式事務(wù)一上來(lái)就全上分布式鎖和分布式事務(wù)都是有代價(jià)的。分布式鎖會(huì)引入鎖等待和鎖超時(shí)問(wèn)題分布式事務(wù)會(huì)顯著降低吞吐量并增加實(shí)現(xiàn)復(fù)雜度。實(shí)際工程中的原則是能用樂(lè)觀鎖解決的不用分布式鎖能通過(guò)流程設(shè)計(jì)規(guī)避的不用分布式事務(wù)能異步最終一致的不強(qiáng)求強(qiáng)一致。比如庫(kù)存扣減如果業(yè)務(wù)可以接受超賣(mài)后在財(cái)務(wù)層面校正使用 Redis 原子減操作 異步對(duì)賬就可以如果業(yè)務(wù)要求絕對(duì)不超賣(mài)才需要引入分布式鎖或數(shù)據(jù)庫(kù)行鎖。搞清楚業(yè)務(wù)真正的要求比堆組件更重要。9. 從理論到落地給不同階段讀者的建議不同技術(shù)階段的讀者可以從這篇文章里拿走不同層次的東西。9.1 如果你是在校生或剛?cè)胄械某跫?jí)開(kāi)發(fā)建議先把單體應(yīng)用寫(xiě)熟練把 Spring Boot、MySQL、Redis 這些基礎(chǔ)技術(shù)掌握扎實(shí)。然后找個(gè)開(kāi)源項(xiàng)目實(shí)際部署一個(gè)微服務(wù)框架比如基于 Spring Cloud Alibaba 的腳手架自己跑通服務(wù)注冊(cè)發(fā)現(xiàn)、配置中心、網(wǎng)關(guān)路由、遠(yuǎn)程調(diào)用這一整條鏈路。關(guān)鍵詞里提到的“eclipse 搭建微服務(wù)架構(gòu)保姆級(jí)教程”“使用 idea、springcloud、nacos 從零搭建微服務(wù)框架”這類(lèi)資料的實(shí)操價(jià)值就在這里。不過(guò)需要提醒的是搭建微服務(wù)框架是一回事理解它為什么這樣設(shè)計(jì)是另一回事。跑通之后一定要追問(wèn)為什么需要注冊(cè)中心為什么需要配置中心如果去掉這些組件系統(tǒng)會(huì)有什么問(wèn)題9.2 如果你是有經(jīng)驗(yàn)的 Java 開(kāi)發(fā)重點(diǎn)不是學(xué)組件而是構(gòu)建問(wèn)題分析能力。微服務(wù)系統(tǒng)出問(wèn)題現(xiàn)象往往在業(yè)務(wù)層根因可能在網(wǎng)絡(luò)層、基礎(chǔ)設(shè)施層或數(shù)據(jù)一致性層。比如一個(gè)訂單服務(wù)偶發(fā)超時(shí)排查思路應(yīng)該是先看調(diào)用鏈定位超時(shí)發(fā)生在哪個(gè)環(huán)節(jié)再看目標(biāo)服務(wù)的負(fù)載、GC 情況、數(shù)據(jù)庫(kù)慢查詢(xún)?nèi)缓蠓治鍪欠袷蔷W(wǎng)絡(luò)抖動(dòng)、線程池耗盡或者依賴(lài)服務(wù)異常。這個(gè)排查流程比任何框架 API 都重要。9.3 如果你在做架構(gòu)設(shè)計(jì)建議養(yǎng)成一個(gè)習(xí)慣任何架構(gòu)決策都先寫(xiě)清楚“要解決什么問(wèn)題”和“代價(jià)是什么”。引入消息隊(duì)列解決的是削峰填谷和異步解耦代價(jià)是數(shù)據(jù)的最終一致性和消息中間件的運(yùn)維成本。引入分布式事務(wù)解決的是跨服務(wù)數(shù)據(jù)一致性問(wèn)題代價(jià)是吞吐量和實(shí)現(xiàn)復(fù)雜度。引入分布式緩存解決的是熱點(diǎn)數(shù)據(jù)訪問(wèn)性能問(wèn)題代價(jià)是緩存一致性、緩存穿透、緩存雪崩等問(wèn)題。這個(gè)習(xí)慣能幫助團(tuán)隊(duì)避免盲目追逐新技術(shù)也能在技術(shù)評(píng)審中提供更清晰的決策依據(jù)。10. 總結(jié)看清維度才能看清架構(gòu)回到最初的問(wèn)題分布式和微服務(wù)有什么區(qū)別簡(jiǎn)單回答是分布式描述系統(tǒng)由多個(gè)節(jié)點(diǎn)協(xié)作運(yùn)行的形態(tài)微服務(wù)描述業(yè)務(wù)按能力拆分為獨(dú)立服務(wù)的組織方式。兩者不在同一個(gè)維度。更深入的理解是微服務(wù)架構(gòu)通常運(yùn)行在分布式環(huán)境中因此它繼承了分布式系統(tǒng)的所有復(fù)雜性——一致性、網(wǎng)絡(luò)不可靠、故障處理、分布式事務(wù)、分布式鎖。理解這一層才能真正理解為什么微服務(wù)項(xiàng)目里需要那么多中間件也才能在面試中把這個(gè)問(wèn)題回答得有條理、有深度。如果這篇文章只保留一個(gè)觀點(diǎn)那應(yīng)該是設(shè)計(jì)系統(tǒng)時(shí)先搞清楚你面臨的問(wèn)題是“物理資源不夠”還是“業(yè)務(wù)復(fù)雜度失控”前者導(dǎo)向分布式思路后者導(dǎo)向微服務(wù)思路。大多數(shù)真實(shí)項(xiàng)目?jī)蓚€(gè)問(wèn)題都存在但解決的優(yōu)先級(jí)和路徑完全不同。希望這篇文章能幫你把這兩個(gè)概念在腦海里徹底分開(kāi)。下次再有人問(wèn)“分布式和微服務(wù)有什么區(qū)別”你可以直接告訴他一個(gè)說(shuō)的是機(jī)器怎么部署一個(gè)說(shuō)的是代碼怎么組織。但真正難的不是這句話而是理解這句話背后雙方各要承受什么代價(jià)。 分布式和微服務(wù)到底有什么區(qū)別？一文講透底層邏輯與工程實(shí)踐
0. 先給結(jié)論很多人把面試掛在了這一題上先從不少開(kāi)發(fā)者都經(jīng)歷過(guò)的一個(gè)場(chǎng)景說(shuō)起。面試官問(wèn)“你做過(guò)微服務(wù)項(xiàng)目那你說(shuō)說(shuō)分布式和微服務(wù)有什么區(qū)別”很多人的第一反應(yīng)是“微服務(wù)就是分布式的一種落地方式。”然后面試官接著問(wèn)“那分布式系統(tǒng)的 CAP、事務(wù)、冪等、注冊(cè)中心這些和微服務(wù)到底是什么關(guān)系”這時(shí)候不少人就開(kāi)始含糊了。這不是個(gè)別現(xiàn)象。在實(shí)際工作中很多團(tuán)隊(duì)把“微服務(wù)”掛在嘴邊但真正遇到問(wèn)題時(shí)討論的卻是分布式系統(tǒng)的話題某個(gè)接口超時(shí)了、某個(gè)節(jié)點(diǎn)掛了、數(shù)據(jù)在兩個(gè)服務(wù)之間不一致了、某個(gè)接口被大量重復(fù)調(diào)用了。這些問(wèn)題的背后其實(shí)都是分布式系統(tǒng)的經(jīng)典問(wèn)題只是恰好發(fā)生在微服務(wù)架構(gòu)里。所以分布式和微服務(wù)到底是什么關(guān)系我的判斷是這兩個(gè)詞根本不在同一個(gè)維度上機(jī)械地比較“誰(shuí)包含誰(shuí)”意義不大。分布式描述的是“多臺(tái)機(jī)器協(xié)作”的系統(tǒng)形態(tài)微服務(wù)描述的是“如何組織業(yè)務(wù)代碼”的架構(gòu)風(fēng)格。一個(gè)系統(tǒng)可以同時(shí)是分布式的和微服務(wù)化的也可以是分布式但不是微服務(wù)甚至可以是微服務(wù)架構(gòu)但部署在一臺(tái)機(jī)器上雖然這不常見(jiàn)也有點(diǎn)奇怪。這篇文章想做的不是給兩個(gè)概念下定義就結(jié)束而是把它們的底層邏輯、適用場(chǎng)景、常見(jiàn)誤區(qū)和實(shí)際工程中的映射關(guān)系一次說(shuō)清楚。無(wú)論你是準(zhǔn)備面試還是真的要從單體架構(gòu)演進(jìn)到分布式架構(gòu)這篇文章都值得讀完。1. 一個(gè)核心判斷它們是兩個(gè)維度的東西先把最關(guān)鍵的觀點(diǎn)放在前面。1.1 分布式描述的是系統(tǒng)形態(tài)“分布式”這個(gè)詞核心意思是一個(gè)系統(tǒng)由多個(gè)節(jié)點(diǎn)組成這些節(jié)點(diǎn)通過(guò)網(wǎng)絡(luò)通信協(xié)作完成業(yè)務(wù)功能。判斷一個(gè)系統(tǒng)是不是分布式不看它的業(yè)務(wù)代碼怎么組織只看它是否滿(mǎn)足兩個(gè)條件多個(gè)獨(dú)立的計(jì)算節(jié)點(diǎn)物理機(jī)、虛擬機(jī)、容器共同參與。節(jié)點(diǎn)之間通過(guò)網(wǎng)絡(luò)進(jìn)行消息傳遞、數(shù)據(jù)同步或任務(wù)協(xié)作。節(jié)點(diǎn)之間怎么通信、數(shù)據(jù)怎么保持一致、某個(gè)節(jié)點(diǎn)掛了怎么辦這些才是分布式系統(tǒng)的核心問(wèn)題。換句話說(shuō)分布式是從“物理形態(tài)”和“系統(tǒng)拓?fù)洹苯嵌让枋鰡?wèn)題。1.2 微服務(wù)描述的是業(yè)務(wù)組織方式“微服務(wù)”這個(gè)詞核心意思是把業(yè)務(wù)系統(tǒng)拆分成一組小而自治的服務(wù)每個(gè)服務(wù)圍繞特定業(yè)務(wù)能力構(gòu)建獨(dú)立開(kāi)發(fā)、獨(dú)立部署、獨(dú)立擴(kuò)展。判斷一個(gè)系統(tǒng)是不是微服務(wù)看的是它的架構(gòu)風(fēng)格服務(wù)是否按業(yè)務(wù)邊界拆分。服務(wù)是否獨(dú)立開(kāi)發(fā)、獨(dú)立部署。服務(wù)之間是否通過(guò)輕量級(jí)通信協(xié)議通常是 HTTP/REST 或消息隊(duì)列交互。每個(gè)服務(wù)是否擁有自己獨(dú)立的數(shù)據(jù)庫(kù)或數(shù)據(jù)存儲(chǔ)。微服務(wù)是從軟件工程方法和架構(gòu)組織角度解決問(wèn)題。1.3 兩者最本質(zhì)的區(qū)別用一個(gè)類(lèi)比來(lái)幫助理解。假設(shè)你要建一棟辦公樓“分布式”描述的是這棟樓有多個(gè)樓層每層都有獨(dú)立的承重結(jié)構(gòu)、獨(dú)立的水電系統(tǒng)樓層之間通過(guò)電梯和管道連通。這是物理結(jié)構(gòu)層面的描述?！拔⒎?wù)”描述的是把這棟樓按功能分區(qū)一層做接待、二層做研發(fā)、三層做財(cái)務(wù)每個(gè)區(qū)域由不同的團(tuán)隊(duì)獨(dú)立使用和管理。這是功能組織層面的描述。這兩者當(dāng)然有關(guān)系但直接問(wèn)“分布式和微服務(wù)有什么區(qū)別”就像問(wèn)“多層建筑和功能分區(qū)有什么區(qū)別”一樣——它們說(shuō)的是兩件事。但這個(gè)類(lèi)比還有一個(gè)關(guān)鍵補(bǔ)充大多數(shù)微服務(wù)架構(gòu)在物理部署上確實(shí)是分布式的。因?yàn)槲⒎?wù)的價(jià)值之一就是獨(dú)立擴(kuò)展、獨(dú)立部署這天然要求服務(wù)運(yùn)行在不同的節(jié)點(diǎn)上。于是微服務(wù)架構(gòu)就同時(shí)具備了兩個(gè)維度的問(wèn)題既是分布式的也是微服務(wù)化的。所以實(shí)際工程中這兩件事經(jīng)常攪在一起。這也正是很多人問(wèn)不清楚、答不明白的根本原因。2. 再談分布式它要解決什么代價(jià)是什么2.1 分布式系統(tǒng)解決的根本問(wèn)題分布式系統(tǒng)的出現(xiàn)本質(zhì)上是三個(gè)字扛不住。流量大了一臺(tái)機(jī)器 CPU 飆到 99%數(shù)據(jù)庫(kù)連接池被打滿(mǎn)接口超時(shí)。這時(shí)候最直接的想法是再加一臺(tái)機(jī)器把流量分?jǐn)偟?。于是有了?fù)載均衡為了故障轉(zhuǎn)移還要做高可用兩臺(tái)機(jī)器的數(shù)據(jù)要同步于是有了主從復(fù)制、緩存、消息隊(duì)列。這些手段組合起來(lái)就是一個(gè)典型的分布式系統(tǒng)。分布式系統(tǒng)解決的核心問(wèn)題是用一堆普通機(jī)器換來(lái)單機(jī)無(wú)法提供的性能、容量和可用性。但代價(jià)是巨大的。2.2 分布式引入的三大經(jīng)典問(wèn)題把系統(tǒng)從單機(jī)改造成分布式之后會(huì)立刻面對(duì)幾個(gè)在單機(jī)時(shí)代根本不存在的問(wèn)題。第一數(shù)據(jù)一致性。單機(jī)數(shù)據(jù)庫(kù)有事務(wù)ACID 保證數(shù)據(jù)要么全部提交要么全部回滾。分布式環(huán)境下多個(gè)節(jié)點(diǎn)各自持有數(shù)據(jù)一個(gè)業(yè)務(wù)操作橫跨多個(gè)節(jié)點(diǎn)怎么保證這些數(shù)據(jù)最終一致這就是分布式事務(wù)問(wèn)題的來(lái)源?，F(xiàn)實(shí)中的解決思路包括兩階段提交、TCCTry-Confirm-Cancel、Saga 事務(wù)、最大努力通知等。Seata 這個(gè)中間件大家應(yīng)該不陌生它解決的問(wèn)題就是分布式事務(wù)。它支持 AT 模式、TCC 模式、Saga 模式和 XA 模式其中最常用的 AT 模式核心思想是通過(guò)代理數(shù)據(jù)源記錄 SQL 執(zhí)行前后的鏡像在全局事務(wù)提交時(shí)對(duì)比鏡像判斷是否沖突再?zèng)Q定回滾還是提交。這套機(jī)制本質(zhì)上就是給分布式環(huán)境下的多節(jié)點(diǎn)操作加了一個(gè)“協(xié)調(diào)層”。第二網(wǎng)絡(luò)不可靠。單機(jī)系統(tǒng)里方法調(diào)用是進(jìn)程內(nèi)的要么成功要么拋出異常。分布式環(huán)境下A 服務(wù)調(diào)用 B 服務(wù)如果超時(shí)了A 怎么知道 B 到底有沒(méi)有執(zhí)行成功重試嗎如果 B 其實(shí)已經(jīng)執(zhí)行成功了重試就可能導(dǎo)致重復(fù)操作。這時(shí)就需要冪等設(shè)計(jì)接口要支持重復(fù)調(diào)用而不產(chǎn)生副作用。Redis 分布式鎖解決的就是分布式環(huán)境下的并發(fā)控制問(wèn)題。比如一個(gè)訂單處理服務(wù)多個(gè)節(jié)點(diǎn)同時(shí)處理同一筆訂單如果不加鎖就會(huì)出現(xiàn)重復(fù)扣減庫(kù)存、重復(fù)發(fā)放優(yōu)惠券等問(wèn)題。Redisson 提供的分布式鎖就是經(jīng)典方案通過(guò) Redis 的 SETNX 或 Lua 腳本保證鎖的原子性通過(guò)看門(mén)狗機(jī)制自動(dòng)續(xù)期。第三故障處理復(fù)雜度上升。單機(jī)系統(tǒng)掛了重啟就行。分布式環(huán)境下一個(gè)節(jié)點(diǎn)掛了其他節(jié)點(diǎn)不能掛系統(tǒng)要能感知到這個(gè)故障把流量切換到健康的節(jié)點(diǎn)上。更麻煩的是“部分失敗”B 服務(wù)掛了A 服務(wù)還在運(yùn)行A 調(diào)用 B 超時(shí)A 的線程被卡住最終 A 的線程池被打滿(mǎn)A 也跟著掛。這就是分布式系統(tǒng)里常見(jiàn)的“雪崩效應(yīng)”。2.3 分布式系統(tǒng)的核心理論這部分內(nèi)容在面試中極為高頻建議至少掌握以下幾組概念。CAP 定理。一個(gè)分布式系統(tǒng)在一致性Consistency、可用性Availability、分區(qū)容錯(cuò)性Partition Tolerance三者之間最多只能同時(shí)滿(mǎn)足兩個(gè)。關(guān)鍵理解是網(wǎng)絡(luò)分區(qū)是不可避免的所以 P 必須保證。真正需要選擇的是當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)系統(tǒng)是選擇 C 還是選擇 A。選擇 CP犧牲部分可用性保證數(shù)據(jù)一致。典型如 ZooKeeper、etcd。選擇 AP保證服務(wù)可用數(shù)據(jù)可能暫時(shí)不一致。典型如 Eureka、Cassandra。BASE 理論。這是對(duì) CAP 中 AP 方案的一個(gè)補(bǔ)充核心思想是Basically Available基本可用。Soft state軟狀態(tài)。Eventually consistent最終一致性。實(shí)際工程中絕大多數(shù)微服務(wù)業(yè)務(wù)場(chǎng)景追求的都不是強(qiáng)一致而是最終一致。比如用戶(hù)下單后訂單狀態(tài)和庫(kù)存扣減通常采用異步消息 重試機(jī)制最終對(duì)齊。2.4 常見(jiàn)的分布式技術(shù)組件在實(shí)際項(xiàng)目中分布式系統(tǒng)往往會(huì)依賴(lài)以下組件解決方向代表技術(shù)說(shuō)明服務(wù)注冊(cè)與發(fā)現(xiàn)Nacos、Eureka、Consul服務(wù)實(shí)例上下線自動(dòng)感知配置管理Nacos Config、Apollo配置集中管理動(dòng)態(tài)刷新網(wǎng)關(guān)路由Spring Cloud Gateway、Nginx統(tǒng)一入口路由轉(zhuǎn)發(fā)過(guò)濾器遠(yuǎn)程調(diào)用OpenFeign、Dubbo、gRPC服務(wù)間 RPC 調(diào)用負(fù)載均衡Ribbon、LoadBalancer減少單點(diǎn)壓力分布式事務(wù)Seata跨服務(wù)事務(wù)一致性分布式鎖Redis Redisson、ZooKeeper跨節(jié)點(diǎn)互斥控制消息隊(duì)列RocketMQ、Kafka、RabbitMQ異步解耦、削峰填谷鏈路追蹤SkyWalking、Zipkin跨服務(wù)調(diào)用鏈分析分布式緩存Redis Cluster熱點(diǎn)數(shù)據(jù)加速這里需要強(qiáng)調(diào)的是出現(xiàn)這些組件是因?yàn)橄到y(tǒng)是分布式的而不是因?yàn)橄到y(tǒng)是微服務(wù)的。即使是兩個(gè)用 Go 寫(xiě)的獨(dú)立服務(wù)只要它們通過(guò)網(wǎng)絡(luò)通信、共享同一份數(shù)據(jù)它們就是一個(gè)分布式系統(tǒng)同樣需要面對(duì)上述問(wèn)題。3. 再談微服務(wù)它要解決什么代價(jià)是什么3.1 微服務(wù)出現(xiàn)的歷史背景微服務(wù)不是憑空出現(xiàn)的。它之所以成為主流是因?yàn)閱误w應(yīng)用在業(yè)務(wù)復(fù)雜度上升到一定程度后暴露出明顯的不可持續(xù)問(wèn)題。一個(gè)典型的單體應(yīng)用代碼量達(dá)到幾十萬(wàn)行甚至上百萬(wàn)行模塊邊界模糊所有人的代碼都往同一個(gè)工程里提交。每次發(fā)版哪怕只改了一行代碼整個(gè)應(yīng)用都要重新構(gòu)建、重新部署。某個(gè)模塊內(nèi)存泄漏可能導(dǎo)致整個(gè)應(yīng)用 OOM所有功能不可用。想擴(kuò)容只能整個(gè)應(yīng)用一起擴(kuò)容無(wú)法只針對(duì)熱點(diǎn)模塊擴(kuò)容。微服務(wù)的思路是按業(yè)務(wù)能力拆分把原來(lái)龐大的單體切割成一組小型服務(wù)。每個(gè)服務(wù)可以獨(dú)立演進(jìn)、獨(dú)立部署、獨(dú)立擴(kuò)容。服務(wù)之間通過(guò)接口通信彼此的實(shí)現(xiàn)細(xì)節(jié)對(duì)外部不可見(jiàn)。3.2 微服務(wù)的核心特征按照 Martin Fowler 對(duì)微服務(wù)的經(jīng)典定義加上工程實(shí)踐中的補(bǔ)充微服務(wù)架構(gòu)通常具備以下特征按業(yè)務(wù)能力拆分服務(wù)邊界由業(yè)務(wù)領(lǐng)域決定而不是由技術(shù)分層決定。比如訂單服務(wù)、用戶(hù)服務(wù)、庫(kù)存服務(wù)。獨(dú)立部署每個(gè)服務(wù)有獨(dú)立的構(gòu)建產(chǎn)物和部署流程可以單獨(dú)上線、回滾。獨(dú)立數(shù)據(jù)存儲(chǔ)每個(gè)服務(wù)擁有自己的數(shù)據(jù)庫(kù)或數(shù)據(jù)表不允許其他服務(wù)直接訪問(wèn)。輕量級(jí)通信服務(wù)間通過(guò) HTTP/REST、gRPC 或消息隊(duì)列通信不共享進(jìn)程內(nèi)存。技術(shù)異構(gòu)不同服務(wù)可以用不同的語(yǔ)言和技術(shù)棧。故障隔離一個(gè)服務(wù)掛掉不影響其他服務(wù)正常運(yùn)行。3.3 微服務(wù)拆分帶來(lái)新的復(fù)雜度微服務(wù)不是銀彈它的代價(jià)同樣巨大。從架構(gòu)層面看原本單體應(yīng)用內(nèi)部的方法調(diào)用變成了跨服務(wù)的網(wǎng)絡(luò)調(diào)用。一次業(yè)務(wù)操作可能涉及三四個(gè)服務(wù)每個(gè)服務(wù)調(diào)用都有超時(shí)和失敗的可能。原來(lái)一個(gè)事務(wù)能解決的數(shù)據(jù)一致性問(wèn)題現(xiàn)在要引入分布式事務(wù)。從運(yùn)維層面看一個(gè)單體應(yīng)用部署一套環(huán)境而一個(gè)微服務(wù)系統(tǒng)可能要同時(shí)運(yùn)維幾十個(gè)服務(wù)每個(gè)服務(wù)又有多個(gè)實(shí)例。這就催生了對(duì)容器化、服務(wù)編排、自動(dòng)化監(jiān)控、日志聚合的強(qiáng)需求。Kubernetes 之所以成為微服務(wù)部署的主流選擇正是因?yàn)樗鉀Q了大規(guī)模服務(wù)編排的問(wèn)題。從團(tuán)隊(duì)協(xié)作層面看微服務(wù)拆分后如果沒(méi)有清晰的接口契約和合理的領(lǐng)域邊界服務(wù)之間的調(diào)用關(guān)系會(huì)迅速變成一團(tuán)亂麻形成“分布式單體”的尷尬局面——名義上是微服務(wù)實(shí)際上是離不開(kāi)彼此的一組進(jìn)程。3.4 微服務(wù)和分布式的關(guān)系再進(jìn)一步現(xiàn)在可以再回答一次開(kāi)頭的那個(gè)問(wèn)題了。微服務(wù)和分布式的關(guān)系可以從兩個(gè)層面看。第一個(gè)層面微服務(wù)通常運(yùn)行在分布式環(huán)境下。微服務(wù)要獨(dú)立部署、獨(dú)立擴(kuò)展這意味著它們大概率運(yùn)行在不同的機(jī)器或容器中。所以一個(gè)微服務(wù)系統(tǒng)通常也是一個(gè)分布式系統(tǒng)需要處理網(wǎng)絡(luò)通信、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、分布式事務(wù)、分布式鎖等分布式問(wèn)題。第二個(gè)層面微服務(wù)不是分布式的必要條件。一個(gè)系統(tǒng)可以不是微服務(wù)架構(gòu)但仍然是分布式的。最典型的例子一個(gè)單體應(yīng)用 MySQL 主從復(fù)制讀寫(xiě)分離應(yīng)用部署在多臺(tái)機(jī)器上負(fù)載均衡。這個(gè)系統(tǒng)是分布式的但不是微服務(wù)。Hadoop 集群的 NameNode 和 DataNodeHDFS 的存儲(chǔ)節(jié)點(diǎn)分布在不同機(jī)器上。這是分布式存儲(chǔ)系統(tǒng)但不是微服務(wù)。所以更準(zhǔn)確的理解是微服務(wù)架構(gòu)是一種組織業(yè)務(wù)代碼的方式它通常會(huì)落在分布式環(huán)境中因此同時(shí)繼承了分布式系統(tǒng)的所有特點(diǎn)和復(fù)雜度。4. 何時(shí)需要“分布式”何時(shí)需要“微服務(wù)”很多開(kāi)發(fā)者在做架構(gòu)選型時(shí)會(huì)糾結(jié)一個(gè)問(wèn)題我到底要不要上微服務(wù)要不要搞分布式這里先把兩者的觸發(fā)條件分開(kāi)來(lái)看。4.1 觸發(fā)“分布式”需求的信號(hào)分布式系統(tǒng)的引入本質(zhì)上是被業(yè)務(wù)指標(biāo)倒逼的。出現(xiàn)以下信號(hào)時(shí)可以考慮從單機(jī)架構(gòu)走向分布式性能瓶頸單臺(tái)服務(wù)器的 CPU、內(nèi)存、磁盤(pán) IO 已經(jīng)無(wú)法支撐業(yè)務(wù)流量且優(yōu)化代碼、加緩存、加索引的手段已經(jīng)用盡?？捎眯砸髽I(yè)務(wù)要求 7x24 小時(shí)可用不允許單點(diǎn)故障。一臺(tái)機(jī)器掛掉服務(wù)中斷時(shí)間不可接受。數(shù)據(jù)容量超限單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)容量達(dá)到上限或者單庫(kù)的讀寫(xiě)壓力過(guò)高。計(jì)算量巨大一次任務(wù)需要處理海量數(shù)據(jù)單臺(tái)機(jī)器無(wú)法在規(guī)定時(shí)間內(nèi)完成計(jì)算需要多臺(tái)機(jī)器并行處理。4.2 觸發(fā)“微服務(wù)”需求的信號(hào)微服務(wù)解決的不是性能問(wèn)題而是工程復(fù)雜度和團(tuán)隊(duì)協(xié)作問(wèn)題。出現(xiàn)以下信號(hào)才值得考慮微服務(wù)架構(gòu)代碼規(guī)模失控單體應(yīng)用代碼量巨大模塊邊界模糊開(kāi)發(fā)效率明顯下降。團(tuán)隊(duì)規(guī)模變大多個(gè)團(tuán)隊(duì)同時(shí)在一個(gè)代碼庫(kù)上協(xié)作合并沖突頻繁發(fā)布互相影響。發(fā)布頻率不均不同模塊的發(fā)布節(jié)奏差異大有的模塊一周發(fā)幾十次有的模塊一個(gè)月發(fā)一次。單體應(yīng)用把所有模塊綁在一起發(fā)布導(dǎo)致低頻率模塊拖累高頻率模塊。擴(kuò)展需求不均衡系統(tǒng)的不同模塊負(fù)載差異明顯。比如用戶(hù)服務(wù)是熱點(diǎn)而日志服務(wù)很閑。單體應(yīng)用無(wú)法針對(duì)熱點(diǎn)模塊單獨(dú)擴(kuò)容。4.3 避坑建議不是越分布式越好也不是越微服務(wù)越好這是很多團(tuán)隊(duì)容易走偏的地方。先說(shuō)分布式。如果業(yè)務(wù)流量很小一個(gè)小型單體應(yīng)用加一臺(tái)數(shù)據(jù)庫(kù)機(jī)器就能穩(wěn)定運(yùn)行沒(méi)有必要引入 Redis Cluster、消息隊(duì)列、分布式事務(wù)中間件。這些組件會(huì)大幅提高運(yùn)維復(fù)雜度和故障排查成本。再說(shuō)微服務(wù)。如果團(tuán)隊(duì)人數(shù)不到十人業(yè)務(wù)正處于驗(yàn)證階段強(qiáng)行拆微服務(wù)往往得不償失。微服務(wù)的最低開(kāi)銷(xiāo)包括服務(wù)注冊(cè)發(fā)現(xiàn)、配置中心、網(wǎng)關(guān)、鏈路追蹤、日志收集、容器化部署。光把這些基礎(chǔ)設(shè)施搭建起來(lái)就需要不小的學(xué)習(xí)成本和時(shí)間投入。一個(gè)務(wù)實(shí)的路線是先用模塊化單體把代碼按業(yè)務(wù)邊界拆成清晰的 package 或 module當(dāng)團(tuán)隊(duì)規(guī)模和業(yè)務(wù)復(fù)雜度增長(zhǎng)到單體內(nèi)無(wú)法協(xié)調(diào)時(shí)再逐步把模塊抽取為獨(dú)立服務(wù)。不要為了微服務(wù)而微服務(wù)。5. 從代碼視角看一個(gè)業(yè)務(wù)在兩種架構(gòu)下的差異概念講得再多不如看代碼。下面用一個(gè)最小化的訂單創(chuàng)建場(chǎng)景來(lái)演示單體架構(gòu)和微服務(wù)架構(gòu)在代碼組織和部署上的差異。5.1 單體架構(gòu)實(shí)現(xiàn)下單操作涉及用戶(hù)校驗(yàn)、商品庫(kù)存扣減、訂單創(chuàng)建三個(gè)邏輯。在單體應(yīng)用中這些邏輯都在同一個(gè)進(jìn)程內(nèi)完成通過(guò)直接方法調(diào)用協(xié)作。// 單體應(yīng)用OrderService.java Service public class OrderService { Autowired private UserMapper userMapper; Autowired private StockMapper stockMapper; Autowired private OrderMapper orderMapper; Transactional public Order createOrder(Long userId, Long productId, Integer quantity) { // 校驗(yàn)用戶(hù) User user userMapper.selectById(userId); if (user null) { throw new BusinessException(用戶(hù)不存在); } // 扣減庫(kù)存 Stock stock stockMapper.selectById(productId); if (stock.getAvailable() quantity) { throw new BusinessException(庫(kù)存不足); } stock.setAvailable(stock.getAvailable() - quantity); stockMapper.updateById(stock); // 創(chuàng)建訂單 Order order new Order(); order.setUserId(userId); order.setProductId(productId); order.setQuantity(quantity); order.setStatus(OrderStatus.CREATED); orderMapper.insert(order); return order; } }這段代碼最顯著的特點(diǎn)是所有業(yè)務(wù)邏輯在同一個(gè)事務(wù)中執(zhí)行數(shù)據(jù)庫(kù)要么全部提交要么全部回滾。Transactional就能保證一致性不需要分布式事務(wù)。5.2 微服務(wù)架構(gòu)實(shí)現(xiàn)微服務(wù)架構(gòu)下用戶(hù)、庫(kù)存、訂單被拆分為三個(gè)獨(dú)立的服務(wù)各自擁有獨(dú)立的數(shù)據(jù)庫(kù)。此時(shí)createOrder的邏輯分布在不同服務(wù)的接口中。代碼結(jié)構(gòu)變?yōu)閛rder-service/ src/main/java/com/example/order/ OrderController.java OrderService.java OrderMapper.java user-service/ src/main/java/com/example/user/ UserController.java UserService.java UserMapper.java stock-service/ src/main/java/com/example/stock/ StockController.java StockService.java StockMapper.java訂單服務(wù)創(chuàng)建訂單時(shí)需要通過(guò)遠(yuǎn)程調(diào)用訪問(wèn)用戶(hù)服務(wù)和庫(kù)存服務(wù)// order-service 中的遠(yuǎn)程調(diào)用代碼 Service public class OrderService { Autowired private UserClient userClient; Autowired private StockClient stockClient; Autowired private OrderMapper orderMapper; public Order createOrder(Long userId, Long productId, Integer quantity) { // 遠(yuǎn)程調(diào)用 user-service 校驗(yàn)用戶(hù) UserDTO user userClient.getUserById(userId); if (user null) { throw new BusinessException(用戶(hù)不存在); } // 遠(yuǎn)程調(diào)用 stock-service 扣減庫(kù)存 boolean deducted stockClient.deductStock(productId, quantity); if (!deducted) { throw new BusinessException(庫(kù)存不足); } // 本地創(chuàng)建訂單 Order order new Order(); order.setUserId(userId); order.setProductId(productId); order.setQuantity(quantity); order.setStatus(OrderStatus.CREATED); orderMapper.insert(order); return order; } }// order-service 中定義的 Feign 客戶(hù)端接口 FeignClient(name stock-service) public interface StockClient { PostMapping(/stock/deduct) Boolean deductStock(RequestParam(productId) Long productId, RequestParam(quantity) Integer quantity); }把這段代碼和單體版本對(duì)比立刻就能看出幾個(gè)關(guān)鍵差異第一事務(wù)邊界變了。單體版本的Transactional可以包住整個(gè)下單流程。微服務(wù)版本中庫(kù)存扣減是遠(yuǎn)程調(diào)用本地事務(wù)管不到遠(yuǎn)程那邊。一旦訂單創(chuàng)建失敗庫(kù)存已經(jīng)扣了數(shù)據(jù)就不一致了。此時(shí)需要引入 Seata 這類(lèi)分布式事務(wù)中間件或者改成“先預(yù)扣庫(kù)存異步確認(rèn)訂單超時(shí)回補(bǔ)庫(kù)存”的最終一致性方案。第二調(diào)用方式變了。單體版本是進(jìn)程內(nèi)方法調(diào)用微服務(wù)版本是網(wǎng)絡(luò)調(diào)用。網(wǎng)絡(luò)調(diào)用有超時(shí)、有重試、有服務(wù)不可用。上文代碼里的deductStock如果超時(shí)了到底扣沒(méi)扣成功需要設(shè)計(jì)冪等接口客戶(hù)端也要有合理的重試策略。第三部署形態(tài)變了。單體應(yīng)用部署在一個(gè)進(jìn)程里三個(gè)服務(wù)各自部署。訂單服務(wù)擴(kuò)容只影響訂單服務(wù)庫(kù)存服務(wù)擴(kuò)展能力不足可以單獨(dú)增加庫(kù)存服務(wù)的實(shí)例。但這也意味著要引入服務(wù)注冊(cè)中心讓調(diào)用方知道庫(kù)存服務(wù)有哪些可用實(shí)例。從這兩段代碼可以直觀感受到同樣的業(yè)務(wù)從單體變成微服務(wù)后代價(jià)是分布式系統(tǒng)帶來(lái)的收益是微服務(wù)的架構(gòu)彈性帶來(lái)的。兩者在這個(gè)案例中被緊密聯(lián)系在一起但也不是同一件事。6. 微服務(wù)和分布式的高頻實(shí)踐鎖、事務(wù)、配置這部分內(nèi)容在熱搜詞里出現(xiàn)頻率很高也確實(shí)是最常出問(wèn)題的領(lǐng)域。分別展開(kāi)一下。6.1 分布式鎖從 synchronized 到 Redis 鎖單體應(yīng)用時(shí)代多個(gè)線程并發(fā)訪問(wèn)共享資源用synchronized或ReentrantLock就能解決。微服務(wù)部署多個(gè)實(shí)例后兩個(gè)實(shí)例上的線程同時(shí)操作同一份數(shù)據(jù)JVM 級(jí)別的鎖互不感知必須引入分布式鎖。Redis 分布式鎖的常見(jiàn)實(shí)現(xiàn)方式// 使用 Redisson 實(shí)現(xiàn)分布式鎖 Configuration public class RedissonConfig { Bean public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer().setAddress(redis://127.0.0.1:6379); return Redisson.create(config); } }Service public class StockService { Autowired private RedissonClient redissonClient; public boolean deductStock(Long productId, Integer quantity) { String lockKey lock:stock: productId; RLock lock redissonClient.getLock(lockKey); try { // 嘗試加鎖最多等待 5 秒鎖自動(dòng)釋放時(shí)間 30 秒 if (lock.tryLock(5, 30, TimeUnit.SECONDS)) { // 檢查庫(kù)存并扣減 Stock stock stockMapper.selectById(productId); if (stock.getAvailable() quantity) { return false; } stock.setAvailable(stock.getAvailable() - quantity); stockMapper.updateById(stock); return true; } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { // 只有持有鎖的線程才能釋放鎖 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } return false; } }分布式鎖的難點(diǎn)不在加鎖而在鎖的可靠性。常見(jiàn)的坑包括鎖自動(dòng)過(guò)期導(dǎo)致臨界區(qū)并發(fā)執(zhí)行、鎖被其他線程釋放、Redis 主從切換時(shí)鎖丟失。Redisson 的看門(mén)狗機(jī)制解決的是第一個(gè)問(wèn)題但可靠的分布式鎖設(shè)計(jì)仍然需要結(jié)合具體業(yè)務(wù)場(chǎng)景仔細(xì)評(píng)估。在生產(chǎn)環(huán)境還要注意一個(gè)問(wèn)題真正需要鎖保護(hù)的代碼執(zhí)行時(shí)間不能超過(guò)鎖的過(guò)期時(shí)間否則鎖自動(dòng)釋放后其他線程就能進(jìn)入臨界區(qū)。如果業(yè)務(wù)邏輯特別耗時(shí)應(yīng)該評(píng)估并發(fā)沖突的概率或者改造業(yè)務(wù)流程而不是一味地延長(zhǎng)鎖超時(shí)時(shí)間。6.2 分布式事務(wù)從 ACID 到最終一致事務(wù)處理是分布式系統(tǒng)里最復(fù)雜的問(wèn)題之一。單體時(shí)代一個(gè)Transactional就解決的問(wèn)題微服務(wù)架構(gòu)下需要單獨(dú)引入 Seata 或采用其他事務(wù)方案。Seata 的核心概念包括Transaction Coordinator (TC)全局事務(wù)協(xié)調(diào)者維護(hù)全局事務(wù)狀態(tài)。Transaction Manager (TM)事務(wù)管理器負(fù)責(zé)開(kāi)啟全局事務(wù)、提交或回滾。Resource Manager (RM)資源管理器管理各分支事務(wù)的資源。AT 模式下Seata 通過(guò)攔截 SQL 執(zhí)行記錄數(shù)據(jù)變更前后的鏡像。全局提交時(shí)對(duì)比前后鏡像判斷是否有并發(fā)沖突全局回滾時(shí)根據(jù)鏡像數(shù)據(jù)生成反向 SQL 恢復(fù)數(shù)據(jù)。向項(xiàng)目中引入 Seata 的基本步驟如下# application.yml 中關(guān)鍵配置 spring: cloud: alibaba: seata: tx-service-group: my_test_tx_group seata: registry: type: nacos nacos: server-addr: 127.0.0.1:8848 tx-service-group: my_test_tx_group service: vgroup-mapping: my_test_tx_group: default// 分布式事務(wù)入口方法 GlobalTransactional public void createOrderWithSeata(Long userId, Long productId, Integer quantity) { // 遠(yuǎn)程調(diào)用庫(kù)存服務(wù)扣減庫(kù)存 stockClient.deductStock(productId, quantity); // 本地創(chuàng)建訂單 orderMapper.insert(order); }GlobalTransactional注解標(biāo)記的方法就是全局事務(wù)的入口。方法內(nèi)的所有遠(yuǎn)程調(diào)用都會(huì)自動(dòng)納入 Seata 的全局事務(wù)管理。其中一個(gè)分支事務(wù)失敗整體回滾。但也有大量業(yè)務(wù)場(chǎng)景不需要強(qiáng)一致更適合采用“本地消息表 消息隊(duì)列”的最終一致性方案本地事務(wù)中寫(xiě)入業(yè)務(wù)數(shù)據(jù)和消息記錄然后異步把消息投遞到消息隊(duì)列消費(fèi)者消費(fèi)消息完成后續(xù)操作配合重試機(jī)制和冪等消費(fèi)來(lái)保證最終一致。6.3 配置中心從本地文件到動(dòng)態(tài)配置微服務(wù)實(shí)例數(shù)量多且分散如果每個(gè)實(shí)例都維護(hù)一份本地配置改一個(gè)配置就要把所有實(shí)例重新部署一遍顯然不可接受。所以需要引入配置中心。Nacos 是 Java 微服務(wù)生態(tài)中最常用的配置中心和服務(wù)注冊(cè)中心。引入后的核心變化是// 動(dòng)態(tài)刷新配置的代碼示例 RefreshScope RestController public class ConfigController { Value(${order.timeout:1000}) private Integer orderTimeout; GetMapping(/config) public String getConfig() { return 當(dāng)前訂單超時(shí)時(shí)間: orderTimeout; } }# 在 Nacos 配置中心維護(hù)的配置 order.timeout3000通過(guò)RefreshScope注解Nacos 中的配置變更后服務(wù)無(wú)需重啟即可刷新配置。這在多實(shí)例部署場(chǎng)景下價(jià)值極高——不用再為了改一個(gè)參數(shù)而滾動(dòng)重啟所有實(shí)例。7. 面試角度這道題到底想考什么既然這是高頻面試題就站在面試官視角分析一下答題時(shí)怎么組織思路。7.1 面試官提問(wèn)的真實(shí)意圖面試官問(wèn)“分布式和微服務(wù)有什么區(qū)別”通常不是想聽(tīng)一個(gè)標(biāo)準(zhǔn)定義。他真正想了解的是候選人有沒(méi)有真正做過(guò)分布式系統(tǒng)還是只是在簡(jiǎn)歷上寫(xiě)了微服務(wù)。候選人能不能區(qū)分“部署形態(tài)”和“架構(gòu)風(fēng)格”這兩個(gè)不同維度。候選人是否清楚分布式系統(tǒng)引入了哪些復(fù)雜性以及這些復(fù)雜性在微服務(wù)架構(gòu)中是如何體現(xiàn)的。如果把這道題當(dāng)成定義背誦大概率會(huì)掛在一連串追問(wèn)上。常見(jiàn)的追問(wèn)包括你們項(xiàng)目中的某個(gè)業(yè)務(wù)如何保證數(shù)據(jù)一致性服務(wù)調(diào)用超時(shí)了你會(huì)怎么處理重試要考慮什么問(wèn)題多個(gè)微服務(wù)實(shí)例同時(shí)更新同一份數(shù)據(jù)怎么控制并發(fā)你們注冊(cè)中心用的是 Nacos原理是什么為什么不用 ZooKeeper這些問(wèn)題每一個(gè)都在考察分布式系統(tǒng)的實(shí)戰(zhàn)理解。7.2 推薦回答思路可以采用“結(jié)論先行分層展開(kāi)”的答題結(jié)構(gòu)先亮出核心判斷分布式描述的是系統(tǒng)部署形態(tài)微服務(wù)描述的是業(yè)務(wù)組織架構(gòu)兩者不是同一個(gè)維度。分別解釋兩個(gè)概念分布式解決的是多節(jié)點(diǎn)協(xié)作問(wèn)題核心挑戰(zhàn)包括一致性、網(wǎng)絡(luò)不可靠、故障處理微服務(wù)解決的是單體應(yīng)用復(fù)雜度問(wèn)題核心特征是服務(wù)拆分、獨(dú)立部署、獨(dú)立擴(kuò)展。指出兩者的關(guān)系微服務(wù)通常運(yùn)行在分布式環(huán)境中因此微服務(wù)系統(tǒng)同時(shí)是分布式系統(tǒng)但分布式系統(tǒng)不一定是微服務(wù)。落到工程實(shí)踐結(jié)合自己的項(xiàng)目說(shuō)明在微服務(wù)架構(gòu)中遇到了哪些分布式問(wèn)題比如分布式事務(wù)、分布式鎖、配置管理以及自己是怎么解決的。強(qiáng)調(diào)權(quán)衡選擇微服務(wù)不是因?yàn)樗案呒?jí)”而是因?yàn)闃I(yè)務(wù)復(fù)雜度和團(tuán)隊(duì)規(guī)模已經(jīng)到了單體應(yīng)用無(wú)法協(xié)調(diào)的程度選擇分布式同樣是為了解決具體的性能和可用性問(wèn)題。按照這個(gè)思路回答既能展示概念理解也能展示工程經(jīng)驗(yàn)。8. 常見(jiàn)誤區(qū)與避坑清單圍繞分布式和微服務(wù)實(shí)踐中存在不少誤區(qū)。列幾個(gè)最典型的。8.1 誤區(qū)一把微服務(wù)和 SOA 混為一談SOA面向服務(wù)架構(gòu)是微服務(wù)的前身。兩者的區(qū)別在于SOA 偏向于企業(yè)級(jí)服務(wù)重用服務(wù)往往由 ESB企業(yè)服務(wù)總線統(tǒng)一編排微服務(wù)強(qiáng)調(diào)去中心化治理服務(wù)之間直接通信。SOA 服務(wù)粒度更大通常按系統(tǒng)模塊劃分微服務(wù)的粒度更小按業(yè)務(wù)能力劃分。SOA 的通信協(xié)議以 WebService/SOAP 為主微服務(wù)以 HTTP/REST、gRPC 和消息隊(duì)列為主。面試中能說(shuō)出這層演進(jìn)關(guān)系會(huì)展示出你理解技術(shù)演進(jìn)的動(dòng)因而不只是背名詞。8.2 誤區(qū)二以為拆成微服務(wù)就一定要用 Spring CloudSpring Cloud 是 Java 生態(tài)里最主流的微服務(wù)解決方案但不是唯一方案。技術(shù)選型要看團(tuán)隊(duì)技術(shù)棧和業(yè)務(wù)復(fù)雜度Java 技術(shù)?？梢赃x擇 Spring Cloud AlibabaNacos Sentinel Seata社區(qū)活躍中文文檔完善。Go 技術(shù)棧可以選擇 go-micro、go-zero、Kratos。如果服務(wù)數(shù)量少團(tuán)隊(duì)規(guī)模小用輕量級(jí)方案同樣可行比如 Nginx 反向代理 多個(gè)獨(dú)立服務(wù)進(jìn)程也能達(dá)到微服務(wù)的效果。關(guān)鍵詞里提到的“若依微服務(wù)plus”就是一個(gè)基于 Spring Cloud Alibaba 的開(kāi)源腳手架適合作為學(xué)習(xí)微服務(wù)架構(gòu)的入手項(xiàng)目。但要在真實(shí)項(xiàng)目中使用還需要結(jié)合業(yè)務(wù)場(chǎng)景評(píng)估它的擴(kuò)展性和維護(hù)成本。8.3 誤區(qū)三只拆服務(wù)不考慮數(shù)據(jù)最常見(jiàn)的失敗微服務(wù)改造是代碼拆了數(shù)據(jù)庫(kù)沒(méi)拆。所有微服務(wù)共用一個(gè)數(shù)據(jù)庫(kù)看起來(lái)是微服務(wù)實(shí)際只是把一個(gè)單體應(yīng)用拆成了多個(gè)部署單元數(shù)據(jù)耦合依然存在。真正的微服務(wù)要求服務(wù)之間不能直接訪問(wèn)對(duì)方的數(shù)據(jù)庫(kù)表。服務(wù)間的數(shù)據(jù)交換只能通過(guò)接口或消息。所以做微服務(wù)拆分的前提往往是對(duì)數(shù)據(jù)庫(kù)做領(lǐng)域建模和拆分規(guī)劃。這一步比拆代碼難得多也是很多團(tuán)隊(duì)改造失敗的核心原因。8.4 誤區(qū)四分布式鎖、分布式事務(wù)一上來(lái)就全上分布式鎖和分布式事務(wù)都是有代價(jià)的。分布式鎖會(huì)引入鎖等待和鎖超時(shí)問(wèn)題分布式事務(wù)會(huì)顯著降低吞吐量并增加實(shí)現(xiàn)復(fù)雜度。實(shí)際工程中的原則是能用樂(lè)觀鎖解決的不用分布式鎖能通過(guò)流程設(shè)計(jì)規(guī)避的不用分布式事務(wù)能異步最終一致的不強(qiáng)求強(qiáng)一致。比如庫(kù)存扣減如果業(yè)務(wù)可以接受超賣(mài)后在財(cái)務(wù)層面校正使用 Redis 原子減操作 異步對(duì)賬就可以如果業(yè)務(wù)要求絕對(duì)不超賣(mài)才需要引入分布式鎖或數(shù)據(jù)庫(kù)行鎖。搞清楚業(yè)務(wù)真正的要求比堆組件更重要。9. 從理論到落地給不同階段讀者的建議不同技術(shù)階段的讀者可以從這篇文章里拿走不同層次的東西。9.1 如果你是在校生或剛?cè)胄械某跫?jí)開(kāi)發(fā)建議先把單體應(yīng)用寫(xiě)熟練把 Spring Boot、MySQL、Redis 這些基礎(chǔ)技術(shù)掌握扎實(shí)。然后找個(gè)開(kāi)源項(xiàng)目實(shí)際部署一個(gè)微服務(wù)框架比如基于 Spring Cloud Alibaba 的腳手架自己跑通服務(wù)注冊(cè)發(fā)現(xiàn)、配置中心、網(wǎng)關(guān)路由、遠(yuǎn)程調(diào)用這一整條鏈路。關(guān)鍵詞里提到的“eclipse 搭建微服務(wù)架構(gòu)保姆級(jí)教程”“使用 idea、springcloud、nacos 從零搭建微服務(wù)框架”這類(lèi)資料的實(shí)操價(jià)值就在這里。不過(guò)需要提醒的是搭建微服務(wù)框架是一回事理解它為什么這樣設(shè)計(jì)是另一回事。跑通之后一定要追問(wèn)為什么需要注冊(cè)中心為什么需要配置中心如果去掉這些組件系統(tǒng)會(huì)有什么問(wèn)題9.2 如果你是有經(jīng)驗(yàn)的 Java 開(kāi)發(fā)重點(diǎn)不是學(xué)組件而是構(gòu)建問(wèn)題分析能力。微服務(wù)系統(tǒng)出問(wèn)題現(xiàn)象往往在業(yè)務(wù)層根因可能在網(wǎng)絡(luò)層、基礎(chǔ)設(shè)施層或數(shù)據(jù)一致性層。比如一個(gè)訂單服務(wù)偶發(fā)超時(shí)排查思路應(yīng)該是先看調(diào)用鏈定位超時(shí)發(fā)生在哪個(gè)環(huán)節(jié)再看目標(biāo)服務(wù)的負(fù)載、GC 情況、數(shù)據(jù)庫(kù)慢查詢(xún)?nèi)缓蠓治鍪欠袷蔷W(wǎng)絡(luò)抖動(dòng)、線程池耗盡或者依賴(lài)服務(wù)異常。這個(gè)排查流程比任何框架 API 都重要。9.3 如果你在做架構(gòu)設(shè)計(jì)建議養(yǎng)成一個(gè)習(xí)慣任何架構(gòu)決策都先寫(xiě)清楚“要解決什么問(wèn)題”和“代價(jià)是什么”。引入消息隊(duì)列解決的是削峰填谷和異步解耦代價(jià)是數(shù)據(jù)的最終一致性和消息中間件的運(yùn)維成本。引入分布式事務(wù)解決的是跨服務(wù)數(shù)據(jù)一致性問(wèn)題代價(jià)是吞吐量和實(shí)現(xiàn)復(fù)雜度。引入分布式緩存解決的是熱點(diǎn)數(shù)據(jù)訪問(wèn)性能問(wèn)題代價(jià)是緩存一致性、緩存穿透、緩存雪崩等問(wèn)題。這個(gè)習(xí)慣能幫助團(tuán)隊(duì)避免盲目追逐新技術(shù)也能在技術(shù)評(píng)審中提供更清晰的決策依據(jù)。10. 總結(jié)看清維度才能看清架構(gòu)回到最初的問(wèn)題分布式和微服務(wù)有什么區(qū)別簡(jiǎn)單回答是分布式描述系統(tǒng)由多個(gè)節(jié)點(diǎn)協(xié)作運(yùn)行的形態(tài)微服務(wù)描述業(yè)務(wù)按能力拆分為獨(dú)立服務(wù)的組織方式。兩者不在同一個(gè)維度。更深入的理解是微服務(wù)架構(gòu)通常運(yùn)行在分布式環(huán)境中因此它繼承了分布式系統(tǒng)的所有復(fù)雜性——一致性、網(wǎng)絡(luò)不可靠、故障處理、分布式事務(wù)、分布式鎖。理解這一層才能真正理解為什么微服務(wù)項(xiàng)目里需要那么多中間件也才能在面試中把這個(gè)問(wèn)題回答得有條理、有深度。如果這篇文章只保留一個(gè)觀點(diǎn)那應(yīng)該是設(shè)計(jì)系統(tǒng)時(shí)先搞清楚你面臨的問(wèn)題是“物理資源不夠”還是“業(yè)務(wù)復(fù)雜度失控”前者導(dǎo)向分布式思路后者導(dǎo)向微服務(wù)思路。大多數(shù)真實(shí)項(xiàng)目?jī)蓚€(gè)問(wèn)題都存在但解決的優(yōu)先級(jí)和路徑完全不同。希望這篇文章能幫你把這兩個(gè)概念在腦海里徹底分開(kāi)。下次再有人問(wèn)“分布式和微服務(wù)有什么區(qū)別”你可以直接告訴他一個(gè)說(shuō)的是機(jī)器怎么部署一個(gè)說(shuō)的是代碼怎么組織。但真正難的不是這句話而是理解這句話背后雙方各要承受什么代價(jià)。