服務之間通過緩存傳遞數據，我堅決反對！
數據的移動，需要載體，DB和cache是常見的數據存儲載體。
如上圖：
- service-A將數據放入cache;
- service-B從cache里讀取數據;
cache作為數據存儲載體的好處是：
- cache的讀取和寫入都非常快;
- service-A和service-B物理上解耦;
那么問題來了：
- 你遇到過這種“服務之間通過緩存傳遞數據”的架構設計么?
- 這種架構設計好還是不好，為什么?
關于這種架構設計方案，分享下個人的觀點。
樓主支持這種架構設計么?
先說結論，樓主旗幟鮮明的反對“服務之間通過緩存傳遞數據”。
為什么反對呢?
核心理由有3點。
第一點：數據管道場景，MQ比cache更加適合。
如果只是單純的將cache作為兩個服務數據通訊的管道，service-A生產數據，service-B(當然，可能有service-C/service-D等)訂閱數據，MQ比cache更加合適：
(1)MQ是互聯網常見的邏輯解耦，物理解耦組件，支持1對1，1對多各種模式，非常成熟的數據通道;
(2)而cache反而會將service-A/B/C/D耦合在一起，大家要彼此協同約定key的格式，ip地址等;
(3)MQ能夠支持push，而cache只能拉取，不實時，有時延;
(4)MQ天然支持集群，支持高可用，而cache未必;
(5)MQ能支持數據落地，cache具備將數據存在內存里，具有“易失”性，當然，有些cache支持落地，但互聯網技術選型的原則是，讓專業的軟件干專業的事情：nginx做反向代理，db做固化，cache做緩存，mq做通道;
綜上，數據管道場景，MQ比cache更加適合。
第二點：數據共管場景，兩個(多個)service同時讀寫一個cache實例會導致耦合。
如果不是數據管道，是兩個(多個)service對一個cache進行數據共管，同時讀寫，也是不推薦的，這些service會因為這個cache耦合在一起：
(1)大家要彼此協同約定key的格式，ip地址等，耦合;
(2)約定好同一個key，可能會產生數據覆蓋，導致數據不一致;
(3)不同服務業務模式，數據量，并發量不一樣，會因為一個cache相互影響，例如service-A數據量大，占用了cache的絕大部分內存，會導致service-B的熱數據全部被擠出cache，導致cache失效;又例如service-A并發量高，占用了cache的絕大部分連接，會導致service-B拿不到cache的連接，從而服務異常;
綜上，數據共管場景，多個service耦合在一個cache實例里，也是不推薦的，需要垂直拆分，實例解耦。
第三點：數據訪問場景，兩個(多個)service有讀寫一份數據的需求。
根據服務化的原則，數據是私有的(本質也是解耦)：
(1)service層會向數據的需求方屏蔽下層存儲引擎，分庫，chace的復雜性;
(2)任何需求方不能繞過service讀寫其后端的數據;
假設有其他service要有數據獲取的需求，應該通過service提供的RPC接口來訪問，而不是直接讀寫后端的數據，無論是cache還是db。
綜上所述
- 數據管道場景，MQ比cache更合適;
- 多個服務不應該公用一個cache實例，應該垂直拆分解耦;
- 服務化架構，不應該繞過service讀取其后端的cache/db，而應該通過RPC接口訪問;
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
