《服務通過緩存傳遞資料， 是否可行》一文引發一個服務之間“通過緩存傳遞資料”設計合理性的討論。
如上圖：
service-A將資料放入cache
service-B從cache裡讀取資料
這種架構設計好還是不好， 網友進行了激烈的討論， 感興趣的同學可以看下《服務通過緩存傳遞資料， 是否可行》的評論， 看到這麼多互聯網技術人對一個技術方案問題進行思考與探討， 很是開心。 這裡， 分享下個人的觀點。
先說結論
樓主旗幟鮮明的反對“服務之間通過緩存傳遞資料”。
核心理由
一、資料管道場景， MQ比cache更加適合
如果只是單純的將cache作為兩個服務資料通訊的管道，
MQ是互聯網常見的邏輯解耦， 物理解耦元件， 支援1對1， 1對多各種模式， 非常成熟的資料通道
畫外音：詳見《MQ， 互聯網架構解耦神器》
而cache反而會將service-A/B/C/D耦合在一起， 大家要彼此協同約定key的格式， ip位址等
MQ能夠支持push， 而cache只能拉取， 不即時， 有時延
MQ天然支援集群， 支援高可用， 而cache未必
MQ能支援資料落地， cache具備將資料存在記憶體裡， 具有“易失”性， 當然， 有些cache支援落地， 但互聯網技術選型的原則是， 讓專業的軟體幹專業的事情：nginx做反向代理， db做固化， cache做緩存， mq做通道
綜上， 資料管道場景， MQ比cache更加適合。
二、資料共管場景， 兩個(多個)service同時讀寫一個cache實例會導致耦合
如果不是資料管道， 是兩個(多個)service對一個cache進行資料共管，
大家要彼此協同約定key的格式， ip位址等， 耦合
約定好同一個key， 可能會產生資料覆蓋， 導致資料不一致
不同服務業務模式， 資料量， 併發量不一樣， 會因為一個cache相互影響， 例如service-A資料量大， 佔用了cache的絕大部分記憶體， 會導致service-B的熱資料全部被擠出cache， 導致cache失效；又例如service-A併發量高， 佔用了cache的絕大部分連接， 會導致service-B拿不到cache的連接， 從而服務異常
綜上， 資料共管場景， 多個service耦合在一個cache實例裡， 也是不推薦的， 需要垂直拆分， 實例解耦。
三、資料訪問場景， 兩個(多個)service有讀寫一份資料的需求
根據服務化的原則， 資料是私有的（本質也是解耦）：
service層會向資料的需求方遮罩下層存儲引擎， 分庫，
任何需求方不能繞過service讀寫其後端的資料
假設有其他service要有資料獲取的需求， 應該通過service提供的RPC介面來訪問， 而不是直接讀寫後端的資料， 無論是cache還是db。
綜上
資料管道， MQ比cache更合適
多個服務不應該公用一個cache實例， 應該垂直拆分解耦
服務化架構， 不應該繞過service讀取其後端的cache/db， 而應該通過RPC介面訪問
希望邏輯是清晰的， 供大夥參考， 歡迎不同的聲音共同探討。
免責聲明：轉載自網路 不用於商業宣傳 版權歸原作者所有 侵權刪