---

背景

我們?cè)诹募軜?gòu)風(fēng)格之前先明確一個(gè)問題，什么是架構(gòu)？我們?yōu)槭裁匆x擇架構(gòu)？用來解決哪些問題？

什么是架構(gòu)

書本定義：“軟件的架構(gòu)是一種抽象的結(jié)構(gòu)，他由軟件的各個(gè)組成部分和這些部分之間的依賴關(guān)系構(gòu)成”。

我的理解是，架構(gòu)就是根據(jù)業(yè)務(wù)選擇合適的技術(shù)、中間件，并且按照合適的設(shè)計(jì)模式對(duì)這些模塊，進(jìn)行組裝來滿足業(yè)務(wù)特性的需求。

選擇架構(gòu)風(fēng)格的目的

我們選擇架構(gòu)風(fēng)格的初衷在于 “三更原則”（自己的理解） ：更好地降本提效、更快地發(fā)版上線、更好地維護(hù)系統(tǒng)穩(wěn)定性。

任何一個(gè)架構(gòu)風(fēng)格，都可以實(shí)現(xiàn)功能性需求，但是一個(gè)好的架構(gòu)風(fēng)格能在功能性需求之上，提升非功能性需求。那么你可能會(huì)問，什么是非功能性需求？舉例：擴(kuò)展性、穩(wěn)定性等等。

這里將會(huì)以我認(rèn)知結(jié)合踩過的坑，來給大家詳細(xì)講一下，我們是如何從單體架構(gòu)演進(jìn)到分布式架構(gòu)。在向分布式單體架構(gòu)的演進(jìn)的道路上，又是如何進(jìn)行的抉擇，以及為什么最后同時(shí)選擇了 微服務(wù)架構(gòu)+分布式架構(gòu) 的原因。接下來就結(jié)合一個(gè)系統(tǒng)來作為案例，貫穿主線講解。

首先來講一下，最初的單體架構(gòu)的經(jīng)歷和轉(zhuǎn)型。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

單體架構(gòu)

我們?cè)谙到y(tǒng)創(chuàng)建之初，往往都是集中業(yè)務(wù)、單點(diǎn)部署系統(tǒng)，所有業(yè)務(wù)打一個(gè)包，快速上線。滿足了業(yè)務(wù)初期的快速發(fā)版上線，而且適合中小公司沒有自己的 PaaS 平臺(tái)，應(yīng)對(duì)初期快速迭代的業(yè)務(wù)，開發(fā)、迭代、測(cè)試、發(fā)布都是非常的便捷。那么單體架構(gòu)都有什么類型呢？

單體架構(gòu)類型

單體架構(gòu)也分為大泥團(tuán)架構(gòu)、分層單體架構(gòu)、模塊化單體架構(gòu)，他們的區(qū)別是什么呢？

• 大泥團(tuán)單體架構(gòu) ：毫無分層、所有模塊聚焦在一起，相互穿插（除非是你接手需要改造，否則不要?jiǎng)?chuàng)建這樣的架構(gòu)風(fēng)格。這種大泥團(tuán)架構(gòu)很難拆分，到最后的下場(chǎng)往往都是重新搭建）；
• 分層單體架構(gòu) ：普遍的選擇。架構(gòu)進(jìn)行了簡(jiǎn)單的分層，比如傳統(tǒng)的 MVC 三層架構(gòu)；
• 模塊化單體架構(gòu) ：一般是隨著業(yè)務(wù)的發(fā)展，由分層單體架構(gòu)演變而來，特點(diǎn)就是引入了多個(gè)業(yè)務(wù)模塊并且提供相應(yīng)的服務(wù)能力。

單體架構(gòu)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

• 應(yīng)用的開發(fā)很簡(jiǎn)單
• 易于對(duì)應(yīng)用程序大規(guī)模的更改
• 測(cè)試相對(duì)簡(jiǎn)單、直觀
• 部署簡(jiǎn)單明了
• 橫向擴(kuò)展不費(fèi)吹灰之力

在業(yè)務(wù)的初期，單體架構(gòu)的優(yōu)點(diǎn)，無論從哪個(gè)方面來說，都優(yōu)于其他架構(gòu)風(fēng)格，但是隨著業(yè)務(wù)的增加、耦合，單體架構(gòu)的缺點(diǎn)也逐漸暴露出來，這個(gè)也符合“康威定律”。那么單體架構(gòu)的“后期”會(huì)暴露出哪些問題呢？

缺點(diǎn)

• 代碼庫膨脹
• 過度的復(fù)雜性會(huì)嚇退開發(fā)者
• 開發(fā)速度慢
• 從代碼提交到實(shí)際部署的周期很長，而且容易出問題
• 難以擴(kuò)展
• 系統(tǒng)的穩(wěn)定性得不到保障
• 需要長期依賴某個(gè)可能過時(shí)的技術(shù)棧

單體架構(gòu)的這些缺點(diǎn)，其實(shí)影響的還是我上面提到的“三更原則”。經(jīng)過上面的鋪墊，相信大家已經(jīng)對(duì)單體架構(gòu)風(fēng)格已經(jīng)有了簡(jiǎn)單的理解。

光有方法論是不行的，我們得結(jié)合項(xiàng)目以及代碼片段來加深理解，做到真正的應(yīng)用。接下來我就用一個(gè)庫存系統(tǒng)來進(jìn)行串聯(lián)進(jìn)行講解。先通過這張圖來了解下庫存系統(tǒng)是用來做什么的？

• 創(chuàng)建之初，1 個(gè)服務(wù)提供商品庫存維護(hù)、庫存查詢、庫存扣減能力。

• 隨著業(yè)務(wù)的發(fā)展，庫存面向多個(gè)服務(wù)：B 端業(yè)務(wù)，平臺(tái)內(nèi)部業(yè)務(wù)系統(tǒng)、平臺(tái)外部中臺(tái)。C 端業(yè)務(wù)，訂單商品扣減庫存、網(wǎng)關(guān)查詢庫存數(shù)量。

單體架構(gòu)的案例——庫存系統(tǒng)

最初的庫存代碼分層如下：

• api ：對(duì)外提供的 Dubbo 服務(wù)
• common ：封裝了公共方法
• dao ：封裝了數(shù)據(jù)庫 DHCP 交互
• domain ：實(shí)體類
• inner-api ：系統(tǒng)內(nèi)部 API 交互
• router ：廢棄
• rpc ：上下游 RCP 交互
• service ：業(yè)務(wù)邏輯層
• web ：Web 服務(wù)層
• worker ：任務(wù)調(diào)度層

在最初很長的一段時(shí)間里，我們部署了兩個(gè)單體服務(wù)。一個(gè)是 API 接口來保障上游的庫存查詢以及調(diào)用，另一個(gè)是 Web 服務(wù)的后臺(tái)管理平臺(tái)。這兩個(gè)單體服務(wù)很好的貼合了最初的業(yè)務(wù)迭代和發(fā)版速度，但是后來隨著業(yè)務(wù)的增加附加調(diào)用量的增加，單體服務(wù)的無論是從性能和穩(wěn)定性都出現(xiàn)了較大的波動(dòng)。

意料之外，情理之中的事故慘案

2015 年 6 月 26 日晚，也是一個(gè)促銷活動(dòng)的前夕，庫存的 Web 管理平臺(tái)掛了，原因就是大量庫存導(dǎo)入，服務(wù)器的內(nèi)存不足導(dǎo)致機(jī)器宕機(jī)。商家、運(yùn)營無法通過導(dǎo)表的方式去維護(hù)庫存數(shù)量，在這之前已經(jīng)經(jīng)歷過了多次橫向擴(kuò)容。還是出現(xiàn)了預(yù)料之外的流量和穩(wěn)定性的問題。

而且在接下來的大促過程當(dāng)中，庫存的單體服務(wù) API 接口也承受了非常大的壓力。

一方面是上游調(diào)用方有很多，比如 App 端首頁中的門店網(wǎng)關(guān)，查詢商品是否有庫存，是否展示。購物車加車，也會(huì)查詢商品庫存的數(shù)量，提單則會(huì)對(duì)庫存數(shù)量進(jìn)行扣減，乃至后續(xù)的訂單取消同樣也會(huì)調(diào)用庫存接口。

另一方面大的 KA 商家通過中臺(tái)對(duì)接對(duì)庫存進(jìn)行操作，為了盡可能的讓商家門店的庫存和線上平臺(tái)的庫存保持一致，減少線上線下庫存不一致導(dǎo)致的超賣、少賣。中臺(tái)同步間隔時(shí)間都非常短，5 分鐘~10 分鐘就要全量同步一次。后續(xù)隨著入駐的商家增多，這個(gè)量級(jí)增長得也非常的迅速。于是我們開啟了單體服務(wù)向分布式服務(wù)演進(jìn)的大門。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://gitee.com/zhijiantianya/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

分布式架構(gòu)

分布式架構(gòu)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

• 可用性高
• 可擴(kuò)展性高
• 系統(tǒng)容錯(cuò)性高
• 業(yè)務(wù)代碼可讀性高
• 維護(hù)簡(jiǎn)單

這些優(yōu)點(diǎn)正是我們當(dāng)時(shí)庫存系統(tǒng)欠缺的，尤其是其中的可用性、系統(tǒng)容錯(cuò)性，是我們系統(tǒng)演進(jìn)迭代的首要目標(biāo)。

《分布式架構(gòu)體系》中描述到，分布式架構(gòu)的核心理念也是按照（功能、業(yè)務(wù)、領(lǐng)域等）對(duì)系統(tǒng)進(jìn)行拆分，通過合理的拆分結(jié)構(gòu)，實(shí)現(xiàn)各業(yè)務(wù)模塊的解耦，同時(shí)通過系統(tǒng)級(jí)容錯(cuò)設(shè)計(jì)，在廉價(jià)硬件基礎(chǔ)設(shè)施上構(gòu)建起高可用、可擴(kuò)展的開放技術(shù)體系。

所以我們庫存系統(tǒng)到底要按照什么進(jìn)行拆分，功能？業(yè)務(wù)？領(lǐng)域？在拆分之前我們一定要明確設(shè)計(jì)的目標(biāo)，避免目標(biāo)方向錯(cuò)誤帶來的人力、成本資源的浪費(fèi)。在弄清楚目標(biāo)之前，我們先了解下分布式架構(gòu)的缺點(diǎn)，通過了解這些缺點(diǎn)來衡量滿足我們目標(biāo)的前提下，需要進(jìn)行哪些方面的取舍，就如 CAP 原則一樣，只能滿足其中的兩個(gè)，AP 或者 CP。

2）分布式架構(gòu)的缺點(diǎn)

• 服務(wù)多，人員對(duì)拆分后的業(yè)務(wù)模塊理解要花費(fèi)一些成本
• 技術(shù)棧升級(jí)耗費(fèi)人力
• 分布式事務(wù)的保持
• 業(yè)務(wù)模塊之間的 RPC 交互損耗

庫存系統(tǒng)的特點(diǎn)，高可用、高并發(fā)、強(qiáng)數(shù)據(jù)一致性。接下來我們就來講一下，庫存是如何從單體架構(gòu)向分布式架構(gòu)進(jìn)行的轉(zhuǎn)型。

單體架構(gòu)如何向分布式架構(gòu)轉(zhuǎn)型

因?yàn)閹齑婷媾R的最大的問題是穩(wěn)定性，所以我們首先針對(duì)功能進(jìn)行了拆分。

1）功能拆分

這一步是相對(duì)簡(jiǎn)單的，我們梳理出庫存面向服務(wù)的業(yè)務(wù)方進(jìn)行服務(wù)劃分。這部分無需進(jìn)行太多代碼的改造，一套接口通過變更不同的 group 別名，部署到不同的集群即可。

拆分后，不同的服務(wù)應(yīng)對(duì)不同的業(yè)務(wù)方，系統(tǒng)錯(cuò)誤的隔離性好，不會(huì)說出現(xiàn)一損俱損的局面，穩(wěn)定性上也有了保障。在解決了穩(wěn)定性的問題后，留給我們了一些喘氣的間隔，可以有時(shí)間去進(jìn)行代碼的優(yōu)化。因?yàn)閯偛乓蔡岬搅?，我們只是通過分布式的集群部署來解決容錯(cuò)性的問題，但是代碼還是一套，臃腫的代碼也會(huì)拖慢我們的開發(fā)上線速度。那么接下來要進(jìn)行的就是，對(duì)業(yè)務(wù)代碼的解耦，這塊也是難度最高的。我們是如何做的呢？

2）業(yè)務(wù)拆分

業(yè)務(wù)拆分的思路是什么呢？

• 以業(yè)務(wù)本身為導(dǎo)向，充分了解系統(tǒng)業(yè)務(wù)模型，劃分業(yè)務(wù)邊界；
• 業(yè)務(wù)依賴的范圍，細(xì)分功能，盡量減少功能之間的重復(fù)依賴；
• 根據(jù)拆分功能的影響大小進(jìn)行評(píng)估，拆小保大；
• 拆分的過程中不要修改業(yè)務(wù)邏輯，不要進(jìn)行拆分之外的任何優(yōu)化動(dòng)作（除非是bug）。

基于上述拆分的思路，庫存系統(tǒng)又是如何劃分的業(yè)務(wù)模塊呢？動(dòng)了哪些代碼？

3）如何劃分業(yè)務(wù)模塊

關(guān)于業(yè)務(wù)劃分，網(wǎng)上有很多方法論，事件風(fēng)暴法、四色建模法等等，但是萬法不離其宗，那就是圍繞事件。以庫存系統(tǒng)舉例：庫存初始化（門店 + sku 庫存創(chuàng)建）、庫存數(shù)量維護(hù)（修改現(xiàn)貨數(shù)量、修改可售狀態(tài)）、扣減業(yè)務(wù)（購物車扣減、提單扣減、訂單取消扣減）、提醒業(yè)務(wù)（缺貨提醒）等。每一個(gè)事件都有獨(dú)立的鏈路軸，以及時(shí)間線可以形成閉環(huán)。

4）如何在原有模塊上拆分

大多數(shù)單體架構(gòu)都是面向過程的設(shè)計(jì)，domain 層充斥這個(gè)各種 DTO、VO、BO，所以在層與層的數(shù)據(jù)交互過程中，大都是經(jīng)歷了多次的 POJO。另外就是 Service 層充斥著和 DAO 層數(shù)據(jù)交互以及參雜了業(yè)務(wù)，而且嚴(yán)重違反了依賴倒置原則，整個(gè)層變得非常的沉重。這里舉個(gè)例子：

• 同層級(jí)間相互引用
• Service 層包含了太多業(yè)務(wù)邏輯，無法保障原子性

這里截取部分代碼片段作為案例，來講述下我們?cè)诓鸱謽I(yè)務(wù)的過程中，需要做一些什么操作。

• 對(duì) Service 層進(jìn)行 CQS 的拆分
• 把業(yè)務(wù)邏輯從原有的 Service 層抽離，保障 Service 方法遵循 SRP 原則
• 新增業(yè)務(wù)聚合層（或者向六邊形架構(gòu)里提到的 adapter 轉(zhuǎn)接口）來聚合 Service 層的方法

原始代碼

@Service
publicclassSkuMainServiceImplimplementsSkuMainService{
privatestaticfinalorg.slf4j.LoggerLOGGER=LoggerFactory.getLogger(SkuMainServiceImpl.class);

@Resource
privateSkuMainDaoskuMainDao;
@Resource
privateZkConfManagerCenterServicezkConfManagerCenterService;
@Resource
privateProductImagesServiceproductImagesService;//同級(jí)互相引用，未遵循依賴倒置
@Resource
privateMqServicemqServiceImpl;

@Value("${system.group.environment}")
privateStringsystemGroupEnvironment;
/**
*問題：service層聚合了太多業(yè)務(wù)邏輯倒置上層方法沒辦法統(tǒng)一
*@paramskuMainInfoMQEntity
*@throwsException
*/
publicvoideditorSaveProuct(SkuMainInfoMQEntityskuMainInfoMQEntity)throwsException{
try{
SkuMainBeanskuMainBean=skuMainInfoMQEntity.getSkuMainBean();
if(skuMainBean==null){
thrownewException("修改參數(shù)為空！");
}

SkuMainBeanoriginalSku=this.getSkuMainBeanBySkuId(skuMainBean.getId());
if(originalSku==null){
thrownewException("無效SkuId！");
}

SkuMainBeanskuMainUpdate=updateIsWeightMark(skuMainBean);
SkuMainBeanskuMainPre=this.get(skuMainUpdate.getId());
//系統(tǒng)下架的商品強(qiáng)制下架
if(skuMainPre!=null&&skuMainPre.getSystemFixedStatus()!=null&&skuMainPre.getSystemFixedStatus().equals(SystemFixedStatusEnum.SYSTEM_FIXED_STATUS_DOWN.getCode())){
skuMainUpdate.setFixedStatus(FixedStatusEnum.PRODUCT_DOWN.getCode());
}

booleanflag=skuMainDao.editorProduct(skuMainUpdate);
if(flag){
if(!zkConfManagerCenterService.isDefaultStoreStatisticsScore(skuMainBean.getOrgCode())){
SkuMainBeansaveSkumainBean=this.get(skuMainUpdate.getId());
//防止未查到,把緩存覆蓋
if(saveSkumainBean!=null){
cacheSkuMainBean(saveSkumainBean);
}
//發(fā)送Sku修改MQ
sendSkuModifyMq(SkuModifyOpSourceEnum.MIX_UPDATE_SKU,originalSku,newSkuMainInfoMQEntity(skuMainUpdate));
ProductImagesBeanproductImagesBean=productImagesService.queryImagesBySkuId(skuMainUpdate.getId());
SkuMainInfoCheckMQEntityskuMainInfoCheckMQEntity=newSkuMainInfoCheckMQEntity();
skuMainInfoCheckMQEntity.setSkuMainBean(skuMainUpdate);
skuMainInfoCheckMQEntity.setProductImagesBean(productImagesBean);
mqServiceImpl.sendJosMQ(skuMainInfoCheckMQEntity,MqTypeEnum.RcsKeyWordsCheck);
mqServiceImpl.sendJosMQ(skuMainInfoCheckMQEntity,MqTypeEnum.SenseKeyWordsCheck);
}else{
LOGGER.info("addopenplatformsku,notnotnotsendmq!skuId={}",skuMainBean.getId());
}
}
}catch(Exceptione){
LOGGER.error("修改商品信息失敗.e:",e);
thrownewException(e);
}
}

CQS 和 SRP 的改造，拆解 GOD Classes

Read 服務(wù)

Write 服務(wù)

抽離到業(yè)務(wù)層 Business 層后

@Service
publicclassSkuMainBusinessServiceImplimplementsSkuMainBusinessService{
privatestaticfinalorg.slf4j.LoggerLOGGER=LoggerFactory.getLogger(SkuMainBusinessServiceImpl.class);

@Resource
privateZkConfManagerCenterServicezkConfManagerCenterService;
@Resource
privateMqServicemqService;
@Resource
privateSkuMainReadserviceskuMainReadservice;
@Resource
privateSkuMainWriteserviceskuMainWriteservice;

@Value("${system.group.environment}")
privateStringsystemGroupEnvironment;
/**
*問題：service層聚合了太多業(yè)務(wù)邏輯倒置上層方法沒辦法統(tǒng)一
*@paramskuMainInfoMQEntity
*@throwsException
*/
publicvoideditorSaveProuct(SkuMainInfoMQEntityskuMainInfoMQEntity)throwsException{
try{
SkuMainBeanskuMainBean=skuMainInfoMQEntity.getSkuMainBean();
if(skuMainBean==null){
thrownewException("修改參數(shù)為空！");
}
SkuMainBeanoriginalSku=skuMainReadservice.getSkuMainBeanBySkuId(skuMainBean.getId());
if(originalSku==null){
thrownewException("無效SkuId！");
}
SkuMainBeanskuMainUpdate=skuMainWriteservice.updateIsWeightMark(skuMainBean);
SkuMainBeanskuMainPre=skuMainReadservice.queryDbById(skuMainUpdate.getId());
//系統(tǒng)下架的商品強(qiáng)制下架
if(skuMainPre!=null&&skuMainPre.getSystemFixedStatus()!=null&&skuMainPre.getSystemFixedStatus().equals(SystemFixedStatusEnum.SYSTEM_FIXED_STATUS_DOWN.getCode())){
skuMainUpdate.setFixedStatus(FixedStatusEnum.PRODUCT_DOWN.getCode());
}
booleanflag=skuMainWriteservice.editorProduct(skuMainUpdate);
if(flag){
if(!zkConfManagerCenterService.isDefaultStoreStatisticsScore(skuMainBean.getOrgCode())){
SkuMainBeansaveSkumainBean=skuMainservice.queryDbById(skuMainUpdate.getId());
//防止未查到,把緩存覆蓋
if(saveSkumainBean!=null){
skuMainWriteservice.cacheSkuMainBean(saveSkumainBean);
}
//發(fā)送Sku修改MQ
skuMainWriteservice.sendSkuModifyMq(SkuModifyOpSourceEnum.MIX_UPDATE_SKU,originalSku,newSkuMainInfoMQEntity(skuMainUpdate));
}else{
LOGGER.info("addopenplatformsku,notnotnotsendmq!skuId={}",skuMainBean.getId());
}
}
}catch(Exceptione){
LOGGER.error("修改商品信息失敗.e:",e);
thrownewException(e);
}
}

構(gòu)建好的業(yè)務(wù)層

拆分小結(jié)

拆分到這里，業(yè)務(wù)層的劃分基本就比較清晰了。而且在這個(gè)增量整合底層代碼的過程中，面向過程的業(yè)務(wù)線也都梳理的比較清晰了，底層方法也都提取到了業(yè)務(wù)層收口，通過接口對(duì)外提供服務(wù)。那么接下來我們要面臨的問題就是，如何對(duì)具體的讀寫進(jìn)行拆分。

基于 CQRS 打造分布式服務(wù)

上面我們也提到了，進(jìn)行了整體功能的拆分，并沒有對(duì)具體的讀寫服務(wù)的拆分。在面向服務(wù)的場(chǎng)景下，功能里也是分讀服務(wù)、寫服務(wù)。那么我們有什么原則來指導(dǎo)讀寫服務(wù)的分離么？那就是 CQRS 的思想：命令職責(zé)查詢分離，不單單指代碼，同樣也是適用于服務(wù)。

優(yōu)先拆分讀還是優(yōu)先拆分寫

建議從拆分讀開始，因?yàn)樽x服務(wù)相對(duì)于寫服務(wù)簡(jiǎn)單一些，而且更容易提高系統(tǒng)對(duì)外服務(wù)的穩(wěn)定性，寫服務(wù)的流程相對(duì)底層改動(dòng)比較大，測(cè)試的周期也會(huì)比較長。在前期，動(dòng)寫服務(wù)系統(tǒng)出問題的概率會(huì)比較大，所以綜合穩(wěn)定性、擴(kuò)展性來說，優(yōu)先拆分讀服務(wù)是一個(gè)比較好的選擇。

CQRS 的思想適合所有業(yè)務(wù)場(chǎng)景嗎？

以庫存系統(tǒng)舉例，我們就按照 CQRS 的思想復(fù)刻一版，看看會(huì)出現(xiàn)什么問題。

• 每一次修改同步庫存寫入任務(wù)表
• schedule 任務(wù)讀取任務(wù)表
• 把任務(wù)表的修改數(shù)據(jù)同步到 Read 服務(wù)中的 Redis 中

在這個(gè)過程中，存在兩個(gè)問題：

• 大數(shù)據(jù)量任務(wù)同步的問題：也就是 Event Bus 同步 Redis 的數(shù)據(jù)同步速度問題。

• 延遲問題：庫存要求實(shí)時(shí)性非常高，如果因?yàn)槿蝿?wù)積壓導(dǎo)致的延遲，會(huì)讓庫存陷入困境之中。大量的庫存數(shù)量不對(duì)導(dǎo)致的超賣、超賣會(huì)瞬間擊潰業(yè)務(wù)。

所以每一個(gè)架構(gòu)、每一種思想都是要結(jié)合業(yè)務(wù)去分析。我們可以借鑒 CQRS 的命令查詢職責(zé)分離，在面對(duì)業(yè)務(wù)系統(tǒng)部署的時(shí)候，不要死板的遵循固有的模式，要對(duì)現(xiàn)有的風(fēng)格做出一定的取舍。所以，我們?cè)趹?yīng)對(duì)庫存業(yè)務(wù)的時(shí)候，基于 CQRS 的風(fēng)格創(chuàng)建出了庫存獨(dú)有的 CQRS-StockCenter。

CQRS 的活學(xué)活用：CQRS-StockCenter

• business 業(yè)務(wù)層寫入命令
• writeService 服務(wù)寫入讀服務(wù) Redis
• MQ 消息作為異步數(shù)據(jù)補(bǔ)全寫入 MySQL 備份、寫入流水

庫存通過這套設(shè)計(jì)強(qiáng)依賴了 Redis 來作為庫存查詢、修改的中間件。保障了數(shù)據(jù)的強(qiáng)一致性。庫存在原有的服務(wù)上，分離了讀寫，保障了系統(tǒng)的 CQRS 命令職責(zé)查詢分離。

分布式事務(wù)

大家都知道事務(wù)。簡(jiǎn)單來說，事務(wù)由一組關(guān)聯(lián)操作構(gòu)成，A->B->C ，如果執(zhí)行到C報(bào)錯(cuò)了，那么要回滾 B->A。

對(duì)于本地事務(wù)來說，這個(gè)相對(duì)很簡(jiǎn)單，如果你用了事務(wù)型數(shù)據(jù)庫比如 MySQL，并且不涉及多個(gè)數(shù)據(jù)源的情況下，保障事務(wù)的 ACID 非常的容易。但是我們這里要提到的就是分布式事務(wù)。

系統(tǒng)拆分后，由于每個(gè)服務(wù)是一個(gè)獨(dú)立的模塊，負(fù)責(zé)一塊業(yè)務(wù)，那么在整個(gè)業(yè)務(wù)軸的流程下，各個(gè)服務(wù)節(jié)點(diǎn)的跨系統(tǒng)事務(wù)回滾成為了一個(gè)難題。

業(yè)界也有一些方案，比如 JTA（Java Transaction API 即 Java 事務(wù) API）和 JTS（Java Transaction Service 即 Java 事務(wù)服務(wù)），為 J2EE 平臺(tái)提供了分布式事務(wù)服務(wù)。

但是，這種需要滿足 XA（兩階段提交）的標(biāo)準(zhǔn)非常的重。而且現(xiàn)在的業(yè)務(wù)多樣性，很多數(shù)據(jù)庫比如 MongoDB，并不支持 XA 的標(biāo)準(zhǔn)分布式事務(wù)，一些流行的中間件，比如 RabbitMQ 和 Kafka 也不支持分布式事務(wù)。

審核編輯 ：李倩