單體架構(gòu)與微服務(wù)架構(gòu)對比Spring Cloud 微服務(wù)入門指南—1.1 什么是單體架構(gòu)單體架構(gòu)Monolithic Architecture是指把應(yīng)用的所有功能模塊全部打進(jìn)同一個程序里部署后跑在同一個進(jìn)程中的架構(gòu)模式。它是傳統(tǒng)軟件開發(fā)中最常見、最基礎(chǔ)的架構(gòu)形態(tài)。## 1.2 單體架構(gòu)優(yōu)缺點單體架構(gòu)的優(yōu)點優(yōu)點說明開發(fā)簡單直觀代碼都在一個工程里不用處理分布式問題IDE 友好、調(diào)試方便小團(tuán)隊能快速啟動部署方便快捷打一個 WAR/JAR 包即可發(fā)布不需要容器編排和服務(wù)編排測試容易集成端到端測試起一個應(yīng)用就行不用為服務(wù)間依賴做一堆 mock集成測試覆蓋率高性能開銷小模塊間是進(jìn)程內(nèi)調(diào)用沒有網(wǎng)絡(luò)和序列化開銷響應(yīng)延遲低技術(shù)棧統(tǒng)一團(tuán)隊只學(xué)一套技術(shù)體系培訓(xùn)和招人成本低事務(wù)一致性簡單本地事務(wù)就能保證數(shù)據(jù)一致不用碰分布式事務(wù)單體架構(gòu)的缺點缺點說明代碼高度耦合功能一多模塊邊界就模糊改一處牽全身維護(hù)成本漲得很快擴(kuò)展困難只能整個應(yīng)用一起擴(kuò)容沒法單獨給某個高負(fù)載模塊擴(kuò)容資源利用率低技術(shù)棧受限全局一套選型想給某個模塊換技術(shù)很難新技術(shù)的采用受制于歷史包袱部署影響面大改一處就要全量發(fā)布風(fēng)險高一次發(fā)布可能讓整個系統(tǒng)不可用啟動越來越慢代碼膨脹后啟動時間從幾秒漲到幾分鐘開發(fā)體驗和彈性伸縮都受影響團(tuán)隊協(xié)作困難多團(tuán)隊改同一個代碼庫沖突頻繁合并和發(fā)布的協(xié)調(diào)成本很高單點故障風(fēng)險任何一個模塊的內(nèi)存泄漏或異常都可能拖垮整個進(jìn)程故障隔離能力弱技術(shù)債務(wù)累積改不動、不敢改的模塊越來越多架構(gòu)腐化加劇新人上手門檻持續(xù)升高二、微服務(wù)架構(gòu)上面介紹了單體架構(gòu)這時候就要引入微服務(wù)架構(gòu)了。2.1 什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)Microservices Architecture是把單一應(yīng)用拆成一組小型、獨立部署的服務(wù)的架構(gòu)風(fēng)格。每個服務(wù)圍繞一個明確的業(yè)務(wù)能力構(gòu)建跑在自己的進(jìn)程里服務(wù)間通過輕量級通信機(jī)制如 HTTP/REST、消息隊列協(xié)作。簡單來說單體架構(gòu)就像是把一堆藥材堆在一起而微服務(wù)架構(gòu)則是把這堆藥材按功效做了分類。2.2 單體架構(gòu) 與 微服務(wù)架構(gòu)對比對比維度單體架構(gòu)微服務(wù)架構(gòu)架構(gòu)理念一個應(yīng)用包含一切每個服務(wù)做好一件事通信機(jī)制進(jìn)程內(nèi)方法調(diào)用零網(wǎng)絡(luò)開銷網(wǎng)絡(luò)遠(yuǎn)程調(diào)用存在序列化與網(wǎng)絡(luò)開銷數(shù)據(jù)管理共享單一數(shù)據(jù)庫每服務(wù)獨享數(shù)據(jù)庫數(shù)據(jù)邊界清晰部署粒度全量構(gòu)建全量部署單服務(wù)獨立構(gòu)建獨立部署擴(kuò)展能力整體復(fù)制無法精準(zhǔn)擴(kuò)容按服務(wù)負(fù)載獨立擴(kuò)縮容故障隔離弱一處異常全盤崩潰強(qiáng)故障可隔離在單個服務(wù)運維復(fù)雜度低一套部署一套監(jiān)控高需服務(wù)治理、分布式監(jiān)控、容器編排適用階段項目初期、小型應(yīng)用、團(tuán)隊≤10人業(yè)務(wù)復(fù)雜、團(tuán)隊規(guī)?；⑿杩焖俚x型建議架構(gòu)選型沒有絕對優(yōu)劣關(guān)鍵是匹配業(yè)務(wù)階段。項目初期優(yōu)先用單體架構(gòu)快速驗證業(yè)務(wù)模式當(dāng)業(yè)務(wù)復(fù)雜度上升再逐步向微服務(wù)演進(jìn)。盲目提前微服務(wù)化只會帶來不必要的復(fù)雜度。2.3 微服務(wù)架構(gòu)優(yōu)缺點微服務(wù)解決了單體的擴(kuò)展瓶頸但也引入了分布式系統(tǒng)固有的復(fù)雜度。要不要上微服務(wù)需要把好處和代價都看明白。微服務(wù)架構(gòu)的優(yōu)點優(yōu)點說明獨立部署與交付每個服務(wù)能獨立構(gòu)建、測試、部署發(fā)布周期從周級縮短到天級甚至小時級CI/CD 友好彈性擴(kuò)展可以只給某個高負(fù)載服務(wù)單獨擴(kuò)容資源利用率高成本可控故障隔離單個服務(wù)故障不會拖垮全局配合熔斷降級能做到優(yōu)雅降級而不是雪崩技術(shù)演進(jìn)靈活單個服務(wù)能獨立重構(gòu)、升級甚至重寫技術(shù)債務(wù)可控、迭代靈活可復(fù)用與可組合服務(wù)以 API 暴露能力可被多個前端或第三方復(fù)用沉淀企業(yè)能力中心微服務(wù)架構(gòu)的缺點缺點說明分布式復(fù)雜性網(wǎng)絡(luò)不可靠、調(diào)用可能超時、服務(wù)可能宕機(jī)要處理重試、冪等、超時、降級等難題運維成本高服務(wù)從 1 個變成 N 個需要容器編排K8s、配置中心、服務(wù)網(wǎng)格、全鏈路監(jiān)控等基礎(chǔ)設(shè)施支撐數(shù)據(jù)一致性難跨服務(wù)事務(wù)無法用本地 ACID 保證要引入 Saga、TCC、消息最終一致性等分布式事務(wù)方案服務(wù)通信開銷網(wǎng)絡(luò)調(diào)用帶來序列化/反序列化和網(wǎng)絡(luò)延遲開銷對時延敏感場景要專門優(yōu)化調(diào)試與排障困難一個請求跨多個服務(wù)傳統(tǒng)單機(jī)調(diào)試失靈要依賴分布式鏈路追蹤如 Sleuth/Zipkin定位問題接口契約管理服務(wù)間 API 變更需版本管理和兼容性控制否則容易引發(fā)調(diào)用方故障測試復(fù)雜度高端到端測試要編排多服務(wù)依賴環(huán)境搭建和 mock 成本明顯上升安全邊界擴(kuò)大服務(wù)間網(wǎng)絡(luò)通信帶來新的攻擊面需要服務(wù)間鑒權(quán)與 mTLS 等機(jī)制2.4 微服務(wù)拆分拆分是微服務(wù)落地最核心也最難的環(huán)節(jié)。拆得好系統(tǒng)清晰好維護(hù)拆得不好服務(wù)是拆了但耦合還在。拆分原則拆分的第一原則是圍繞業(yè)務(wù)能力拆而不是按技術(shù)分層拆。按技術(shù)分層拆的意思是把用戶接口數(shù)據(jù)訪問這些技術(shù)層單獨拆成服務(wù)這樣做每個業(yè)務(wù)變更都要橫跨多個服務(wù)協(xié)作服務(wù)自治就名存實亡了。而拆分方式也主要分為按模塊縱向拆分和抽取公共模塊橫向拆分。拆分時還要注意以下原則高內(nèi)聚低耦合經(jīng)常一起變更的功能放進(jìn)同一個服務(wù)跨服務(wù)調(diào)用越少越好。單一職責(zé)一個服務(wù)對應(yīng)一個明確的業(yè)務(wù)能力避免大而全。獨立數(shù)據(jù)所有權(quán)拆服務(wù)的同時把數(shù)據(jù)邊界劃好每個服務(wù)獨占自己的數(shù)據(jù)存儲禁止別的服務(wù)直接連它的數(shù)據(jù)庫表。三、Spring Cloud前面主要介紹微服務(wù)相關(guān)的概念接下來將簡單介紹微服務(wù)項目中常見的一個微服務(wù)架構(gòu)——Spring CloudSpring Cloud 是什么Spring Cloud是基于 Spring Boot 構(gòu)建的、面向微服務(wù)架構(gòu)的一站式治理框架可以理解成微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施全家桶服務(wù)注冊發(fā)現(xiàn)、配置管理、API 網(wǎng)關(guān)、負(fù)載均衡、熔斷降級、分布式鏈路追蹤都有對應(yīng)的組件。有個很形象的區(qū)分Spring Boot 解決單個微服務(wù)怎么快速構(gòu)建Spring Cloud 解決多個微服務(wù)怎么協(xié)作治理。而且 Spring Cloud 本身是一套規(guī)范和抽象底層實現(xiàn)可以替換——比如服務(wù)注冊發(fā)現(xiàn)既可以用 Netflix 的 Eureka也可以用阿里的 NacosSpring Cloud 定義統(tǒng)一接口具體實現(xiàn)由各家提供。它的核心價值是你不用從零搭建分布式基礎(chǔ)設(shè)施靠注解和自動配置就能快速接入服務(wù)治理能力把精力放在業(yè)務(wù)邏輯本身。