台湾 Gay 无套,亚洲中文无码av无字幕

背景

我們在聊架構風格之前先明確一個問題，什么是架構？我們?yōu)槭裁匆x擇架構？用來解決哪些問題？

什么是架構

書本定義：“軟件的架構是一種抽象的結構，他由軟件的各個組成部分和這些部分之間的依賴關系構成”。

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

選擇架構風格的目的

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

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

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

首先來講一下，最初的單體架構的經歷和轉型。

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

項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

單體架構

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

單體架構類型

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

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

單體架構的優(yōu)缺點

優(yōu)點

應用的開發(fā)很簡單
易于對應用程序大規(guī)模的更改
測試相對簡單、直觀
部署簡單明了
橫向擴展不費吹灰之力

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

缺點

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

單體架構的這些缺點，其實影響的還是我上面提到的“三更原則”。經過上面的鋪墊，相信大家已經對單體架構風格已經有了簡單的理解。

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

創(chuàng)建之初，1 個服務提供商品庫存維護、庫存查詢、庫存扣減能力。
隨著業(yè)務的發(fā)展，庫存面向多個服務：B 端業(yè)務，平臺內部業(yè)務系統(tǒng)、平臺外部中臺。C 端業(yè)務，訂單商品扣減庫存、網關查詢庫存數(shù)量。

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

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

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

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

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

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

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

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

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

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

項目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

分布式架構

分布式架構的優(yōu)缺點

優(yōu)點

可用性高
可擴展性高
系統(tǒng)容錯性高
業(yè)務代碼可讀性高
維護簡單

這些優(yōu)點正是我們當時庫存系統(tǒng)欠缺的，尤其是其中的可用性、系統(tǒng)容錯性，是我們系統(tǒng)演進迭代的首要目標。

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

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

2）分布式架構的缺點

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

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

單體架構如何向分布式架構轉型

因為庫存面臨的最大的問題是穩(wěn)定性，所以我們首先針對功能進行了拆分。

1）功能拆分

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

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

2）業(yè)務拆分

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

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

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

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

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

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

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

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

這里截取部分代碼片段作為案例，來講述下我們在拆分業(yè)務的過程中，需要做一些什么操作。

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

原始代碼

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

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

@Value("${system.group.environment}")
privateStringsystemGroupEnvironment;
/**
*問題：service層聚合了太多業(yè)務邏輯倒置上層方法沒辦法統(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)下架的商品強制下架
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 服務

Write 服務

抽離到業(yè)務層 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è)務邏輯倒置上層方法沒辦法統(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)下架的商品強制下架
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);
}
}

構建好的業(yè)務層

拆分小結

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

基于 CQRS 打造分布式服務

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

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

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

CQRS 的思想適合所有業(yè)務場景嗎？

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

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

在這個過程中，存在兩個問題：

大數(shù)據量任務同步的問題：也就是 Event Bus 同步 Redis 的數(shù)據同步速度問題。
延遲問題：庫存要求實時性非常高，如果因為任務積壓導致的延遲，會讓庫存陷入困境之中。大量的庫存數(shù)量不對導致的超賣、超賣會瞬間擊潰業(yè)務。

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