最近的工作我在做一個有關于消息發送和接受封裝工作。大概流程是這樣的，消息中間件是采用rabbitmq，為了保證消息的絕對無丟失，我們需要在發送和接受前對消息進行DB落地。在發送前我會先進行DB的插入，單表插入，所以在性能上也是能接受的，單表插入做了壓測基本上是一到兩毫秒的時間，加上消息的發送(有ACK)再加上集群是兩個節點的高可用(一個磁盤持久化節點)，單臺TPS基本上是在2000-3000左右。這對于我們的業務場景來說是夠用了。一旦當消息丟失或者由于網絡問題、集群問題業務不會中斷，消息就算發不出去也沒關系，我們會進行消息的補償或者同步api調用補償。這是架構設計的必須要考慮的A計劃、B計劃、C計劃，這是敬畏或者危機意識。

你可能又要說兩個節點或者三個節點的集群怎么會有問題，那你就錯了，大錯特錯。只能說明你并不了解什么叫分布式系統及分布式系統的特性。你也許不會知道網絡抖動、網絡閃斷導致socket斷開如何進行心跳重試已保持有效的Rabbitmq Connection。當你的網絡極不穩定，你的linux keepalived VIP 來回漂移，導致你的ARP根本無法成效，可能就連廣播都傳不出去，而客戶端則在一直使用一個無用的IP地址。當你的集群節點之間無法連接成一個整體的時候各種奇葩的問題又來了。這些都是可能導致你的集群出問題的原因，所以不要大意。

(后面我會整理一篇專門講解“rabbitmq高可用、故障轉移集群架構“文章，所以這里我們就不繼續介紹了)

這是一個鋪墊，本文的重點是介紹下我在嘗試使用可視化webapi的輸出模式，這比原本json的輸出模式看起來會方便許多。如果你的api提供兩種輸出模式，人性化絕對很好?，F在很多后端api都是沒有界面的都是只提供了一個json輸出。然而，我們其實很需要一個可讀性很強的輸出模式。

我在開發消息補償程序的時候，我借鑒了這一思想進行了嘗試。先來看下整體架構藍圖：

本篇文章要介紹的是有關于這個補償程序的api的可視化輸出內容。不涉及到消息相關太多的東西，只是為了讓這個可視化輸出看起來容易理解點。這個補償程序需要對發送的消息和接受的消息進行查詢和比較然后輸出，用來確定消息的發送是失敗了還是成功的。簡單邏輯就是比較某個時間段內的消息發送表和接受表，然后進行消息id的匹配。

我在想這個數據反饋到api上是個什么樣子的，按照常規設計就是兩個字段：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/// <summary> /// 接受的消息對象。 /// </summary> public?class?ReceiveMessage { ????/// <summary> ????/// 發送消息ID。 ????/// </summary> ????public?string?SendMessageId {?get;?set; } ????/// <summary> ????/// 接受消息ID。 ????/// </summary> ????public?string?ReceiveMessageId {?get;?set; } }

這表示一個消息從發送到接受的一個過程。如果失敗了，可能是只有SendMessageId而沒有ReceiveMessageId。然后我才會針對沒有ReceiveMessageId的消息進行自動補償。在開發的時候只有幾十條消息，輸出到postman中的看起來也還行，但是不直觀。

GetReceiveMessage是獲取接受消息列表，就是查看當前消息發送到接受是個什么狀態。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

/// <summary> /// 處理成功消息對象。 /// </summary> public?class?SuccessMessage { ????/// <summary> ????/// 發送消息ID ????/// </summary> ????public?string?SendMessageId {?get;?set; } ????/// <summary> ????/// 接受消息ID ????/// </summary> ????public?string?ReceiveMessageId {?get;?set; } ????/// <summary> ????/// 處理成功消息ID ????/// </summary> ????public?string?SuccessMessageId {?get;?set; } }

SuccessMessage表示處理成功消息情況。此時有可能是有SendMessageId，ReceiveMessageId消息，但是SuccessMessageId可能是沒有的。就會針對處理成功的消息進行發送。

突然受到ElasticSearch的_cat endpoint 啟發。似乎這里我可以嘗試下，webapi帶有兩種輸出模式，一種是針對程序使用的json輸出模式，另外一種是針對人可以閱讀的模式text/plain模式，而第二種模式可以簡單的理解為是行列轉換缺省模式。

是不是看起來會很舒服。這在進行消息的時間段查看非常有幫助，如果還按照原本的json輸出模式可能看起來會比較吃力。

來看下基本的api的設計，為了保證你的所有api支持?v可視化模式，需要一定的抽象：

需要定義一種ViewModel，所有的數據都輸出這種對象，當然我這里也只是簡單地封裝。如果可以，其實可以專門提取出一個庫出來，包括對文本的輸出自動化。

我們看下BaseApiController:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

public?class?BaseApiController : ApiController ???{ ???????public?class?ViewModel ???????{ ???????????public?string?Content {?get;?set; } ???????????public?object?JsonObject {?get;?set; } ???????????public?bool?Success =?true; ???????} ???????protected?bool?IsView; ???????private?const?string?ViewQuerystring =?"?v"; ???????public?ViewModel ResultModel; ???????private?const?string?CheckToken =?"CheckToken"; ???????private?const?string?Token =?"49BBD022-CDBF-4F94-80E4-5BCACB1192EC"; ???????private?bool?_checkStatus; ???????public?override?Task<HttpResponseMessage> ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken) ???????{ ???????????//驗證token ???????????if?(controllerContext.Request.Headers !=?null?&& controllerContext.Request.Headers.Contains(CheckToken)) ???????????{ ???????????????var?requestToken = controllerContext.Request.Headers.GetValues(CheckToken).FirstOrDefault(); ???????????????if?(requestToken !=?null?&& requestToken.Equals(Token)) ???????????????{ ???????????????????this._checkStatus =?true; ???????????????} ???????????} ???????????if?(!_checkStatus) ???????????{ ???????????????var?checkResult =?new?Task<HttpResponseMessage>(() =>?new?HttpResponseMessage ???????????????{ ???????????????????Content =?new?StringContent("非法訪問，缺少token", Encoding.UTF8,?"text/plain") ???????????????}, cancellationToken); ???????????????checkResult.Start(); ???????????????return?checkResult; ???????????} ???????????if?(controllerContext.Request.RequestUri.Query.Equals(ViewQuerystring)) ???????????????this.IsView =?true; ???????????base.ExecuteAsync(controllerContext, cancellationToken); ???????????//text模式 ???????????if?(this.IsView) ???????????{ ???????????????var?textResult =?new?Task<HttpResponseMessage>(() =>?new?HttpResponseMessage ???????????????{ ???????????????????Content =?new?StringContent(this.ResultModel.Content, Encoding.UTF8,?"text/plain") ???????????????}, cancellationToken); ???????????????textResult.Start(); ???????????????return?textResult; ???????????} ???????????//json模式 ???????????var?resultData =?new?Result<object> ???????????{ ???????????????Data =?this.ResultModel.JsonObject, ???????????????Type =?this.ResultModel.Success ? ResultType.Successfully : ResultType.Failure ???????????}; ???????????var?jsonResult =?new?Task<HttpResponseMessage>(() =>?new?HttpResponseMessage ???????????{ ???????????????Content =?new?ObjectContent(typeof(Result), resultData,?new?JsonMediaTypeFormatter(),?"application/json") ???????????}, cancellationToken); ???????????jsonResult.Start(); ???????????return?jsonResult; ???????} ???}

代碼很簡單，這里給我們一個啟發，webapi是不是真的缺少了一個可視化模式。

出處：http://www.cnblogs.com/wangiqngpei557/

總結

以上是生活随笔為你收集整理的WebAPi的可视化输出模式(RabbitMQ、消息补偿相关）——所有webapi似乎都缺失的一个功能...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。