色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

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

jf_ro2CN3Fa ? 來源:芋道源碼 ? 作者:芋道源碼 ? 2022-10-20 10:28 ? 次閱讀


背景

我們在聊架構風格之前先明確一個問題,什么是架構?我們為什么要選擇架構?用來解決哪些問題?

什么是架構

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

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

選擇架構風格的目的

我們選擇架構風格的初衷在于 “三更原則”(自己的理解) :更好地降本提效、更快地發版上線、更好地維護系統穩定性。

任何一個架構風格,都可以實現功能性需求,但是一個好的架構風格能在功能性需求之上,提升非功能性需求。那么你可能會問,什么是非功能性需求?舉例:擴展性、穩定性等等。

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

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

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序,支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

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

單體架構

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

單體架構類型

單體架構也分為大泥團架構、分層單體架構、模塊化單體架構,他們的區別是什么呢?

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

單體架構的優缺點

優點

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

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

缺點

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

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

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

  • 創建之初,1 個服務提供商品庫存維護、庫存查詢、庫存扣減能力。

  • 隨著業務的發展,庫存面向多個服務:B 端業務,平臺內部業務系統、平臺外部中臺。C 端業務,訂單商品扣減庫存、網關查詢庫存數量。

06df0526-501e-11ed-a3b6-dac502259ad0.png

單體架構的案例——庫存系統

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

  • api :對外提供的 Dubbo 服務
  • common :封裝了公共方法
  • dao :封裝了數據庫 DHCP 交互
  • domain :實體類
  • inner-api :系統內部 API 交互
  • router :廢棄
  • rpc :上下游 RCP 交互
  • service :業務邏輯層
  • web :Web 服務層
  • worker :任務調度層
07015446-501e-11ed-a3b6-dac502259ad0.png

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

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

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

0711fe90-501e-11ed-a3b6-dac502259ad0.png

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

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

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

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

  • 項目地址:https://gitee.com/zhijiantianya/yudao-cloud
  • 視頻教程:https://doc.iocoder.cn/video/

分布式架構

分布式架構的優缺點

優點

  • 可用性高
  • 可擴展性高
  • 系統容錯性高
  • 業務代碼可讀性高
  • 維護簡單

這些優點正是我們當時庫存系統欠缺的,尤其是其中的可用性、系統容錯性,是我們系統演進迭代的首要目標。

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

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

2)分布式架構的缺點

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

庫存系統的特點,高可用、高并發、強數據一致性。接下來我們就來講一下,庫存是如何從單體架構向分布式架構進行的轉型。

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

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

1)功能拆分

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

074d9108-501e-11ed-a3b6-dac502259ad0.png

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

2)業務拆分

業務拆分的思路是什么呢?

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

基于上述拆分的思路,庫存系統又是如何劃分的業務模塊呢?動了哪些代碼?

3)如何劃分業務模塊

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

075a0a1e-501e-11ed-a3b6-dac502259ad0.png078961ba-501e-11ed-a3b6-dac502259ad0.png07a6ad1a-501e-11ed-a3b6-dac502259ad0.png

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

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

  • 同層級間相互引用
  • Service 層包含了太多業務邏輯,無法保障原子性
07eff7ae-501e-11ed-a3b6-dac502259ad0.png

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

  • 對 Service 層進行 CQS 的拆分
  • 把業務邏輯從原有的 Service 層抽離,保障 Service 方法遵循 SRP 原則
  • 新增業務聚合層(或者向六邊形架構里提到的 adapter 轉接口)來聚合 Service 層的方法
081d378c-501e-11ed-a3b6-dac502259ad0.png

原始代碼

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

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

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

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

SkuMainBeanskuMainUpdate=updateIsWeightMark(skuMainBean);
SkuMainBeanskuMainPre=this.get(skuMainUpdate.getId());
//系統下架的商品強制下架
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);
}
//發送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 服務

082efc4c-501e-11ed-a3b6-dac502259ad0.png

Write 服務

085fe26c-501e-11ed-a3b6-dac502259ad0.png

抽離到業務層 Business 層后

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

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

@Value("${system.group.environment}")
privateStringsystemGroupEnvironment;
/**
*問題:service層聚合了太多業務邏輯倒置上層方法沒辦法統一
*@paramskuMainInfoMQEntity
*@throwsException
*/
publicvoideditorSaveProuct(SkuMainInfoMQEntityskuMainInfoMQEntity)throwsException{
try{
SkuMainBeanskuMainBean=skuMainInfoMQEntity.getSkuMainBean();
if(skuMainBean==null){
thrownewException("修改參數為空!");
}
SkuMainBeanoriginalSku=skuMainReadservice.getSkuMainBeanBySkuId(skuMainBean.getId());
if(originalSku==null){
thrownewException("無效SkuId!");
}
SkuMainBeanskuMainUpdate=skuMainWriteservice.updateIsWeightMark(skuMainBean);
SkuMainBeanskuMainPre=skuMainReadservice.queryDbById(skuMainUpdate.getId());
//系統下架的商品強制下架
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);
}
//發送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);
}
}

構建好的業務層

087b2a36-501e-11ed-a3b6-dac502259ad0.png

拆分小結

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

基于 CQRS 打造分布式服務

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

092340fe-501e-11ed-a3b6-dac502259ad0.png

優先拆分讀還是優先拆分寫

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

CQRS 的思想適合所有業務場景嗎?

以庫存系統舉例,我們就按照 CQRS 的思想復刻一版,看看會出現什么問題。

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

在這個過程中,存在兩個問題:

  • 大數據量任務同步的問題:也就是 Event Bus 同步 Redis 的數據同步速度問題。

  • 延遲問題:庫存要求實時性非常高,如果因為任務積壓導致的延遲,會讓庫存陷入困境之中。大量的庫存數量不對導致的超賣、超賣會瞬間擊潰業務。

094d025e-501e-11ed-a3b6-dac502259ad0.png

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

CQRS 的活學活用:CQRS-StockCenter

  • business 業務層寫入命令
  • writeService 服務寫入讀服務 Redis
  • MQ 消息作為異步數據補全寫入 MySQL 備份、寫入流水
09921a60-501e-11ed-a3b6-dac502259ad0.png

庫存通過這套設計強依賴了 Redis 來作為庫存查詢、修改的中間件。保障了數據的強一致性。庫存在原有的服務上,分離了讀寫,保障了系統的 CQRS 命令職責查詢分離。

0a01606e-501e-11ed-a3b6-dac502259ad0.png

分布式事務

大家都知道事務。簡單來說,事務由一組關聯操作構成,A->B->C ,如果執行到C報錯了,那么要回滾 B->A。

對于本地事務來說,這個相對很簡單,如果你用了事務型數據庫比如 MySQL,并且不涉及多個數據源的情況下,保障事務的 ACID 非常的容易。但是我們這里要提到的就是分布式事務。

系統拆分后,由于每個服務是一個獨立的模塊,負責一塊業務,那么在整個業務軸的流程下,各個服務節點的跨系統事務回滾成為了一個難題。

業界也有一些方案,比如 JTA(Java Transaction API 即 Java 事務 API)和 JTS(Java Transaction Service 即 Java 事務服務),為 J2EE 平臺提供了分布式事務服務。

但是,這種需要滿足 XA(兩階段提交)的標準非常的重。而且現在的業務多樣性,很多數據庫比如 MongoDB,并不支持 XA 的標準分布式事務,一些流行的中間件,比如 RabbitMQ 和 Kafka 也不支持分布式事務。

審核編輯 :李倩


聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 模塊
    +關注

    關注

    7

    文章

    2695

    瀏覽量

    47433
  • 代碼
    +關注

    關注

    30

    文章

    4779

    瀏覽量

    68525
  • 架構
    +關注

    關注

    1

    文章

    513

    瀏覽量

    25468

原文標題:單體架構服務轉型至分布式的踩坑經歷

文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    【書籍評測活動NO.53】鴻蒙操作系統設計原理與架構

    子系統, 分門別類地闡述鴻蒙操作系統關鍵子系統的技術架構和主要設計思路,包括內核、方舟運行時、圖形、媒體、驅動框架、各種分布式技術,以及安全、DFX 等方面的相關架構設計思路 。 圍繞HarmonyOS
    發表于 12-16 15:10

    一文講清什么是分布式云化數據庫!

    分布式云化數據庫是一種先進的數據管理系統,它將傳統的數據庫技術與分布式計算、云計算和大數據處理技術相融合。這種數據庫架構旨在提供高可用性、高擴展性和高性能的數據存儲解決方案。
    的頭像 發表于 10-14 10:06 ?218次閱讀

    解析一體式IO與分布式IO:從架構到應用

    在工業自動化領域,IO(輸入/輸出)系統扮演著舉足輕重的角色。它們不僅負責數據的采集和控制指令的發送,還直接影響到系統的靈活性、可靠性和成本效益。明達技術將為您介紹一體式IO和分布式IO在架構及應用層的主要區別,幫助您更好地理解這兩種技術。
    的頭像 發表于 10-08 10:02 ?242次閱讀
    解析一體式IO與<b class='flag-5'>分布式</b>IO:從<b class='flag-5'>架構</b>到應用

    分布式工業物聯網平臺:引領智能制造的新篇章

    產品銷往世界各地,以最小的成本創造最大的利潤。 分布式工業物聯網平臺的定義與特點 分布式工業物聯網平臺是一種基于云計算架構,通過分布式網絡實現設備連接、數據收集、處理和分析的系統。它集
    的頭像 發表于 09-27 17:09 ?219次閱讀

    一體式IO與分布式IO:工業控制系統的兩種架構

    一體式IO與分布式IO架構各有優勢和局限性。選擇合適的IO架構需要根據實際的生產需求、系統規模、成本預算和維護能力綜合考慮。隨著工業自動化技術的發展,分布式IO
    的頭像 發表于 07-17 16:12 ?1020次閱讀
    一體式IO與<b class='flag-5'>分布式</b>IO:工業控制系統的兩種<b class='flag-5'>架構</b>

    Redis是怎么從單體架構發展到分布式緩存的?

    Redis 架構是如何一步一步發展到今天的樣子的?
    的頭像 發表于 04-20 15:37 ?799次閱讀
    Redis是怎么從<b class='flag-5'>單體</b><b class='flag-5'>架構</b>發展到<b class='flag-5'>分布式</b>緩存的?

    分布式運維管理平臺助力醫療行業數字化轉型案例分享

    決定引入分布式運維管理平臺,以推動數字化轉型進程。 二、平臺應用與優勢 數據整合與共享 分布式運維管理平臺通過整合醫院內部的各類信息系統和醫療設備數據,實現了數據的全面共享和互通。醫生可以實時查看患者的病歷信息、
    的頭像 發表于 03-26 16:16 ?369次閱讀

    分布式KVM坐席管理系統:打造智慧化城市運營新引擎

    訊維分布式KVM坐席管理系統,以其獨特的分布式架構和智能化管理特性,正在成為智慧化城市運營的新引擎。該系統通過高效的信息共享和處理,不僅提升了城市管理的工作效率,更為城市的智能化、精細化運營提供了
    的頭像 發表于 03-18 16:15 ?585次閱讀

    鴻蒙OS 分布式任務調度

    形式、數據結構、服務描述語言,屏蔽硬件差異;支持遠程啟動、遠程調用、業務無縫遷移等分布式任務。 分布式任務調度平臺在底層實現 Ability(分布式任務調度的基本組件)跨設備的啟動/關閉、連接及斷開連接以及遷移等能力,實現跨設備
    的頭像 發表于 01-29 16:50 ?489次閱讀

    分布式大屏控制系統的可擴展性設計

    系統易于擴展,可以根據需求增加或減少模塊,實現系統的靈活配置。模塊化設計還便于系統的維護和升級,提高了系統的可維護性。 分布式架構:采用分布式架構,將系統節點分散在各個地理位置或網絡中
    的頭像 發表于 01-29 14:46 ?576次閱讀

    如何提高分布式大屏控制系統的穩定性和可靠性

    提高分布式大屏控制系統的穩定性和可靠性可以從以下幾個方面入手: 架構設計:在系統架構設計階段,應采用高可用性、高可擴展性的設計原則,確保系統具備容錯和負載均衡的能力。采用分布式
    的頭像 發表于 01-29 14:39 ?403次閱讀

    智能網聯汽車電子電氣架構詳解

    汽車電子電氣架構正在由傳統的分布式架構域集中式和中央集中式演進, 并繼續演進至車路云一體化協同。智能網聯汽車整體軟件架構需要采用 SOA
    的頭像 發表于 01-17 09:24 ?2258次閱讀
    智能網聯汽車電子電氣<b class='flag-5'>架構</b>詳解

    什么是分布式架構?

    分布式架構是指將一個系統或應用拆分成多個獨立的節點,這些節點通過網絡連接進行通信和協作,以實現共同完成任務的一種架構模式。這種架構模式旨在提高系統的可擴展性、可靠性和性能表現。 一、
    的頭像 發表于 01-12 15:04 ?1229次閱讀
    什么是<b class='flag-5'>分布式</b><b class='flag-5'>架構</b>?

    分布式節點服務器是什么?

    分布式節點服務器是一種將多個服務器分布式連接、協同工作,以實現負載均衡、提高系統性能和可靠性、提供高可用性的服務器架構。 具體來說,分布式節點服務器是通過將一個大型系統分成多個子系統,
    的頭像 發表于 01-12 15:04 ?737次閱讀
    <b class='flag-5'>分布式</b>節點服務器是什么?

    【Vsan數據恢復】Vsan分布式存儲虛擬磁盤文件丟失的數據恢復案例

    一套vsan分布式存儲架構有數臺服務器節點,該vsan分布式存儲架構配置了固態硬盤和機械硬盤,固態硬盤作為緩存盤使用,機械硬盤作為容量盤使用。 機房供電異常導致服務器異常關機,工作人
    的頭像 發表于 01-03 16:39 ?617次閱讀
    主站蜘蛛池模板: 使劲别停好大好深好爽动态图| 国产精品高清免费网站| 87影院午夜福利| avove主播| 国产美女影院| 美妇教师双飞后菊| 神马伦理不卡午夜电影| 伊人久久大香线蕉观看| 曰曰夜夜在线影院视| 最近中文字幕mv手机免费高清| 啊…嗯啊好深男男小黄文| 国内精品九九视频| 欧美xxxxb| 亚洲成人免费观看| 99视频精品全部免费 在线| 国产麻豆精品久久一二三| 蜜柚视频在线观看全集免费观看| 婷婷综合久久狠狠色| 亚洲 无码 制服 日韩| 99国产在线精品观看二区| 成人免费视频网站www| 精品无人区麻豆乱码1区2| 伦理片92伦理午夜| 午夜天堂一区人妻| 亚洲精品久久久久AV无码| 一个人在线观看免费高清视频在线观看| a级精品九九九大片免费看| 狠狠婷婷综合久久久久久| 日本高清加勒比| 无套暴躁白丝秘书| 999久久久无码国产精蜜柚| 国模丽丽啪啪一区二区| 日本色高清| 91亚洲精品| 精品无码国产污污污免费网站2| 三级叫床震大尺度视频| 999在线观看精品免费| 精品亚洲永久免费精品| 香蕉久久一区二区三区啪啪| 成人精品视频网站| 免费国产网站|