日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
服務(wù)讀寫分離架構(gòu),絕不推薦

緣起

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),文安企業(yè)網(wǎng)站建設(shè),文安品牌網(wǎng)站建設(shè),網(wǎng)站定制,文安網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,文安網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿,時刻以成就客戶成長自我,堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

在《服務(wù)讀寫分離(讀服務(wù),寫服務(wù)),是否可行?》中,對背景做了交代,互聯(lián)網(wǎng)架構(gòu)設(shè)計上,數(shù)據(jù)庫可以讀寫分離,服務(wù)能否讀寫分離呢?

下面是兩種常見的“服務(wù)讀寫分離”架構(gòu):

一、單純服務(wù)讀寫分離

如上圖,服務(wù)化之后:

  • 業(yè)務(wù)方通過RPC分別調(diào)用讀服務(wù)和寫服務(wù)
  • 服務(wù)層分為讀服務(wù)與寫服務(wù)
  • 底層是高可用的數(shù)據(jù)庫集群

二、服務(wù)和數(shù)據(jù)庫同時讀寫分離

讀服務(wù)與寫服務(wù)讀寫的是不同的數(shù)據(jù)庫,如上圖:

  • 寫服務(wù)訪問寫庫
  • 讀服務(wù)訪問讀庫

寫庫與讀庫是一個組從同步的集群。

這種架構(gòu)設(shè)計好還是不好,網(wǎng)友進行了激烈的討論,感興趣的同學(xué)可以看下《服務(wù)讀寫分離(讀服務(wù),寫服務(wù)),是否可行?》的評論,這里,分享下個人的觀點。

三、先說結(jié)論

樓主旗幟鮮明的反對服務(wù)區(qū)分讀寫分離。

四、小理由

調(diào)用方對同一個基礎(chǔ)服務(wù),某一個RPC接口,在讀服務(wù),還是寫服務(wù),容易困惑

對于同一個基礎(chǔ)服務(wù),服務(wù)數(shù)量翻倍了,運維更加復(fù)雜

五、強理由

一般來說,垂直拆分,是按照“子業(yè)務(wù)”維度進行拆分,而不是按照“讀寫”維度進行拆分,這是模塊化設(shè)計的基本準(zhǔn)則。

1. 完全打破了“服務(wù)化數(shù)據(jù)庫私有”的微服務(wù)初衷

兩個服務(wù)因為同一份數(shù)據(jù)庫資源訪問而耦合在一起,當(dāng)數(shù)據(jù)庫資源發(fā)生變化的時候(例如:ip變化,域名變化,表結(jié)構(gòu)變化,水平切分變化等),有兩個依賴點需要修改。

而好的設(shè)計,有變化產(chǎn)生時,只有一個需要修改(低耦合,高內(nèi)聚),前段時間的“耦合”系列文章,已經(jīng)多次提到了這一點:

《小小的IP,大大的耦合》

《小小的公共庫,大大的耦合》

《服務(wù)化了,耦合卻更加嚴(yán)重了》

2. 沒法很好的添加緩存

大部分互聯(lián)網(wǎng)業(yè)務(wù)是讀多寫少的業(yè)務(wù),數(shù)據(jù)庫讀取最容易成為瓶頸,常見提升讀性能的方式是,增加緩存。

如上圖,讀服務(wù)的下游增加一個緩存,當(dāng)有讀請求訪問時:

  • 先訪問緩存,如果***,直接返回
  • 如果緩存不***,訪問數(shù)據(jù)庫,然后將數(shù)據(jù)放入緩存中,以便下一次能夠***

額,然后,這個架構(gòu)中,這個方案是不可行的。

因為,寫服務(wù)修改數(shù)據(jù)庫時,緩存中的數(shù)據(jù)沒有辦法得到淘汰!!!

OK,有朋友說,寫數(shù)據(jù)庫之前,可以由寫服務(wù)來淘汰緩存:

即,讀服務(wù)與寫服務(wù)都可以操作緩存。額,這個設(shè)計,又違背了“服務(wù)化緩存私有”的微服務(wù)初衷,兩個服務(wù)因為同一份緩存資源訪問而耦合在一起,當(dāng)緩存資源發(fā)生變化的時候,有兩個依賴點需要修改。

況且,如果真的兩個服務(wù)訪問相同的數(shù)據(jù)庫和緩存,為什么不合成一個服務(wù)呢?

硬要拆成兩個服務(wù),不是自己玩自己么?

OK,有另外的朋友說,可以由寫服務(wù)發(fā)消息來淘汰緩存:

如上圖:

  • 緩存私有,只有讀服務(wù)操縱緩存
  • 數(shù)據(jù)庫發(fā)生寫請求時,寫服務(wù)給MQ發(fā)消息,由讀服務(wù)來淘汰緩存

這種設(shè)計:

  • 讀服務(wù)來淘汰緩存,本質(zhì)是一個寫請求,不是很奇怪么?
  • 引入了一個MQ組件,引入更大的一致性風(fēng)險
  • 讀服務(wù)和寫服務(wù)如果是一個進程,豈不是更好么,干嘛硬要跨進程通信呢?

所以,還是一個服務(wù)更好:

  • 調(diào)用方無二義性,不糾結(jié)
  • 好維護
  • 數(shù)據(jù)庫,緩存私有,無耦合

六、結(jié)論

互聯(lián)網(wǎng)微服務(wù)架構(gòu),應(yīng)該按照“子業(yè)務(wù)”進行微服務(wù)拆分,而不應(yīng)該按照“讀寫”來進行微服務(wù)拆分,避免過度設(shè)計。

【本文為專欄作者“58沈劍”原創(chuàng)稿件,轉(zhuǎn)載請聯(lián)系原作者】


本文標(biāo)題:服務(wù)讀寫分離架構(gòu),絕不推薦
分享路徑:http://www.dlmjj.cn/article/dpgcdij.html