最近的工作我在做一個(gè)有關(guān)于消息發(fā)送和接受封裝工作。大概流程是這樣的，消息中間件是采用rabbitmq，為了保證消息的絕對(duì)無(wú)丟失，我們需要在發(fā)送和接受前對(duì)消息進(jìn)行DB落地。在發(fā)送前我會(huì)先進(jìn)行DB的插入，單表插入，所以在性能上也是能接受的，單表插入做了壓測(cè)基本上是一到兩毫秒的時(shí)間，加上消息的發(fā)送（有ACK）再加上集群是兩個(gè)節(jié)點(diǎn)的高可用（一個(gè)磁盤持久化節(jié)點(diǎn)），單臺(tái)TPS基本上是在2000-3000左右。這對(duì)于我們的業(yè)務(wù)場(chǎng)景來(lái)說(shuō)是夠用了。一旦當(dāng)消息丟失或者由于網(wǎng)絡(luò)問(wèn)題、集群?jiǎn)栴}業(yè)務(wù)不會(huì)中斷，消息就算發(fā)不出去也沒(méi)關(guān)系，我們會(huì)進(jìn)行消息的補(bǔ)償或者同步api調(diào)用補(bǔ)償。這是架構(gòu)設(shè)計(jì)的必須要考慮的A計(jì)劃、B計(jì)劃、C計(jì)劃，這是敬畏或者危機(jī)意識(shí)。
你可能又要說(shuō)兩個(gè)節(jié)點(diǎn)或者三個(gè)節(jié)點(diǎn)的集群怎么會(huì)有問(wèn)題，那你就錯(cuò)了，大錯(cuò)特錯(cuò)。只能說(shuō)明你并不了解什么叫分布式系統(tǒng)及分布式系統(tǒng)的特性。你也許不會(huì)知道網(wǎng)絡(luò)抖動(dòng)、網(wǎng)絡(luò)閃斷導(dǎo)致socket斷開(kāi)如何進(jìn)行心跳重試已保持有效的Rabbitmq Connection。當(dāng)你的網(wǎng)絡(luò)極不穩(wěn)定，你的linux keepalived VIP 來(lái)回漂移，導(dǎo)致你的ARP根本無(wú)法成效，可能就連廣播都傳不出去，而客戶端則在一直使用一個(gè)無(wú)用的IP地址。當(dāng)你的集群節(jié)點(diǎn)之間無(wú)法連接成一個(gè)整體的時(shí)候各種奇葩的問(wèn)題又來(lái)了。這些都是可能導(dǎo)致你的集群出問(wèn)題的原因，所以不要大意。
（后面我會(huì)整理一篇專門講解“rabbitmq高可用、故障轉(zhuǎn)移集群架構(gòu)“文章，所以這里我們就不繼續(xù)介紹了）
這是一個(gè)鋪墊，本文的重點(diǎn)是介紹下我在嘗試使用可視化webapi的輸出模式，這比原本json的輸出模式看起來(lái)會(huì)方便許多。如果你的api提供兩種輸出模式，人性化絕對(duì)很好?，F(xiàn)在很多后端api都是沒(méi)有界面的都是只提供了一個(gè)json輸出。然而，我們其實(shí)很需要一個(gè)可讀性很強(qiáng)的輸出模式。
我在開(kāi)發(fā)消息補(bǔ)償程序的時(shí)候，我借鑒了這一思想進(jìn)行了嘗試。先來(lái)看下整體架構(gòu)藍(lán)圖：
本篇文章要介紹的是有關(guān)于這個(gè)補(bǔ)償程序的api的可視化輸出內(nèi)容。不涉及到消息相關(guān)太多的東西，只是為了讓這個(gè)可視化輸出看起來(lái)容易理解點(diǎn)。這個(gè)補(bǔ)償程序需要對(duì)發(fā)送的消息和接受的消息進(jìn)行查詢和比較然后輸出，用來(lái)確定消息的發(fā)送是失敗了還是成功的。簡(jiǎn)單邏輯就是比較某個(gè)時(shí)間段內(nèi)的消息發(fā)送表和接受表，然后進(jìn)行消息id的匹配。
我在想這個(gè)數(shù)據(jù)反饋到api上是個(gè)什么樣子的，按照常規(guī)設(shè)計(jì)就是兩個(gè)字段：
