Visualized WebAPi output mode (related to RabbitMQ and message compensation) -- a function that seems to be missing in all webapis, webapirabbitmq

Visualized WebAPi output mode (related to RabbitMQ and message compensation) -- a function that seems to be missing in all webapis, webapirabbitmq

Recently I am working on sending and receiving message encapsulation. The general process is like this. The message middleware uses rabbitmq. To ensure that the message is never lost, we need to implement the DB before sending and receiving the message. Before sending the message, I will insert DB and single table first, so the performance is acceptable. The pressure test for single table insertion is usually one to two milliseconds, in addition, the message sending (with ACK) and the cluster are highly available on two nodes (one persistent disk node), a single TPS is basically around. This is enough for our business scenarios. Once a message is lost or the service is not interrupted due to network problems or cluster problems, it does not matter if the message cannot be sent. We will compensate the message or call the synchronous api. This is a plan A, plan B, and plan C that must be considered in architecture design. This is a sense of reverence or crisis.

You may want to talk about how the cluster with two or three nodes has problems, so you are wrong. It is a big mistake. It only means that you do not know the characteristics of distributed systems. You may not know how to retry the effective Rabbitmq Connection when the socket is disconnected due to network jitter or transient network disconnection. When your network is extremely unstable and your linux keepalived VIP drifting back and forth, your ARP won't be effective at all, and even the broadcast won't be passed out, the client is always using a useless IP address. When your cluster nodes cannot be connected to one whole, all sorts of strange issues arise. These are the reasons that may cause problems in your cluster.
(I will sort out an article dedicated to"Rabbitmq high-availability and Failover cluster architectureThe article, so we will not continue to introduce it here)

This is a foreshadowing. The focus of this article is to introduce the output mode of visual webapi, which is much more convenient than the original json output mode. If your api provides two output modes, it is absolutely user-friendly. Currently, many backend APIs do not have interfaces and only provide one json output. However, we actually need a readable output mode.

I tried this idea when developing the message compensation program. Let's take a look at the overall architecture blueprint:

This article will introduce the visual output of the api for this compensation program. It does not involve too many messages, just to make the visual output seem easy to understand. This compensation program needs to query and compare the sent and received messages and then output them to determine whether the message is successfully sent or failed. The simple logic is to compare the message sending and receiving tables in a certain period of time, and then match the Message id.

I am wondering what the data is like when it is fed back to the api. According to the general design, there are two fields:

/// <Summary> /// message recipient. /// </Summary> public class ReceiveMessage {/// <summary> /// send the message ID. /// </Summary> public string SendMessageId {get; set ;}/// <summary> // receives the message ID. /// </Summary> public string ReceiveMessageId {get; set ;}}

This indicates a process in which a message is sent to and accepted. If it fails, it may be that only SendMessageId does not have ReceiveMessageId. Then I will automatically compensate for messages without ReceiveMessageId. There were only a few dozen messages during development, and the output to postman seemed okay, but not intuitive.

GetReceiveMessage is used to obtain the list of accepted messages, that is, to view the status of the current message sent to the accepted message.

/// <Summary> /// the message object that is successfully processed. /// </Summary> public class SuccessMessage {// <summary> /// send message ID /// </summary> public string SendMessageId {get; set ;} /// <summary> /// accept the Message ID /// </summary> public string ReceiveMessageId {get; set ;} /// <summary >/// ID of the message that is successfully processed /// </summary> public string SuccessMessageId {get; set ;}}

SuccessMessage indicates successful message processing. In this case, there may be SendMessageId and ReceiveMessageId messages, but SuccessMessageId may not. The message is sent successfully.

It was suddenly inspired by the _ cat endpoint of ElasticSearch. It seems that here I can try that webapi has two output modes: one is the json output mode used by the program, and the other is the text/plain mode that can be read by people, the second mode can be simply understood as the default mode for row-column conversion.

Does it look quite comfortable. This is very helpful for viewing messages during the time period. It may seem difficult to view messages according to the original json output mode.

Let's take a look at the basic api design. To ensure that all your APIs are supported? V visualization mode requires certain abstraction:

You need to define a ViewModel. All the data outputs this object. Of course, I am simply encapsulating it here. If you can, you can extract a library specifically, including automation of text output.

Let's take a look at BaseApiController:

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) {// verify 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 ("illegal access, lack of token", Encoding. UTF8, "text/plain")}, cancellationToken); checkResult. start (); return checkResult;} if (controllerContext. request. requestUri. query. equals (ViewQuerystring) this. isView = true; base. executeAsync (controllerContext, cancellationToken); // 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 mode 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 ;}}

　　

The code is very simple. Here is an inspiration. Does webapi really lack a visual mode.

Author: Wang qingpei

Source: http://www.cnblogs.com/wangiqngpei557/

The copyright of this article is shared by the author and the blog Park. You are welcome to reprint this article. However, you must keep this statement without the author's consent and go to the Article Page.