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