日常工作中, 后端常用的中間件有這么幾種: 數(shù)據(jù)庫/緩存/消息隊列/搜索引擎, 這幾種中間件在典型架構(gòu)中的組合使用方式如下:
Arch
這幾種中間件的常用實現(xiàn)有: MySQL/Redis/RocketMQ or Kafka/ElasticSearch, 那么通過每一種中間件的學(xué)習(xí),我們經(jīng)常有這種感覺: 這些東西有很多相似的地方,原理很相似,通過抽象總結(jié), 我梳理了以下的通用中間件模型:
跳出來,在極大的尺度上考慮,中間件層可以抽象為一個全局的分布式存儲系統(tǒng), 在理想的系統(tǒng)里,
大量用戶帶來的流量帶來數(shù)據(jù),通過全局的存儲系統(tǒng)增刪查改; 然而現(xiàn)實是----不存在這種系統(tǒng),因為不同的場景對數(shù)據(jù)的要求不一樣: 有的讀頻繁,有的是寫頻繁等等等等, 不同的場景誕生出不同的中間件,但從全局的抽象層面,他們的共性如圖所示:
- 客戶端連接 ;
- 流量的讀寫場景,讀寫比例是怎樣的? 是否需要事務(wù)支持? 對性能吞吐要求如何?
- 客戶端連接服務(wù)端需要網(wǎng)絡(luò)模型支持,如RPC框架, 以及序列化/反序列化;-->一般是IO多路復(fù)用;
- 網(wǎng)絡(luò)模型建立連接后,任務(wù)如何分發(fā),如何分發(fā)到不同的worker或數(shù)據(jù)node?
- 數(shù)據(jù)的分片? 副本? 如何擴展,擴展后如何重新分配數(shù)據(jù)?
- 技術(shù)的數(shù)據(jù)模型? 數(shù)據(jù)結(jié)構(gòu)是B+樹還是LSM樹? 是否用到了緩存/索引? 是否持久化, --> 底層本質(zhì): 復(fù)制狀態(tài)機,WAL;
- 如果模型是主從模型的話,節(jié)點如何選舉出master? 寫數(shù)據(jù)時如何同步到所有節(jié)點(數(shù)據(jù)廣播)?master節(jié)點,普通節(jié)點掛了如何恢復(fù)? --> 這塊一般涉及到分布式共識算法,如Paxos,Raft,Zab等;
- cluster集群架構(gòu)是Master-Slav模式還是Peer 2Peer 模式? 是否有NamingServer協(xié)調(diào)? -->一般自己實現(xiàn)NamingServer或者使用分布式協(xié)調(diào)基礎(chǔ)中間件Zookeeper;
縱向: 中間件是否有管理端?如何監(jiān)控和運維?安全和權(quán)限管理?
在這之上, 考慮在高性能/高可用/高擴展不同維度的要求下,模型如何應(yīng)對.
以上是中間件模型的通用抽象,可以從全局指導(dǎo)學(xué)習(xí)和實踐.
