WEBAPI visual output mode (RabbitMQ, message compensation related) a feature that all WEBAPI seems to be missing

Recent work I'm doing a have about message sending and receiving encapsulation work. The process is like this, the message middleware is the use of RABBITMQ, in order to ensure absolute loss of the message, we need to send and receive the message before the DB landed. Before sending, I will first do a DB insert, single table insertion, so in the performance is also acceptable, single table insert did the pressure measurement is basically one to two milliseconds, plus the message sent (with an ACK) plus the cluster is two nodes of high availability (a disk persistence node), The single TPS is basically around 2000-3000. This is enough for our business scenario. Once the message is lost or due to network problems, the cluster problem business will not be interrupted, the message will not be able to get out of the matter, we can make the message or synchronous API call compensation. This is a plan, Plan B, plan C that must be considered in architecture design, which is a sense of awe or crisis.

You may want to say two nodes or three nodes of the cluster how can be a problem, then you are wrong, wrong. It only means that you do not understand what is called distributed systems and the characteristics of distributed systems. You may not know the RABBITMQ Connection that the network jitter, the network flash causes the socket to disconnect, and how the heartbeat retry has been kept valid. When your network is extremely unstable, your Linux keepalived VIP drifts back and forth, causing your ARP to fail at all, possibly even broadcasting, while the client is always using a useless IP address. When your cluster nodes can not be connected to a whole, the problems of various wonderful things come again. These are all possible causes of problems in your cluster, so don't be careless.

(I'll make an article about the "rabbitmq high availability, failover cluster Architecture" later, so here we don't go on.)

This is a cushion, the focus of this article is to introduce the output mode I am trying to use the visual Webapi, which is much more convenient than the original JSON output mode. If your API provides two kinds of output mode, the humanization is absolutely good. Many back-end APIs now have no interface and are only providing a JSON output. However, we really need a very readable output pattern.

When I was developing the message compensation program, I drew on this idea and tried it. Let's take a look at the overall architecture blueprint:

650) this.width=650; "title=" 1 "style=" border-right-width:0px;background-image:none;border-bottom-width:0px; padding-top:0px;padding-left:0px;padding-right:0px;border-top-width:0px; "border=" 0 "alt=" 1 "src=" http:// S3.51cto.com/wyfs02/m00/8a/bd/wkiol1g6zwvyq2utaagbavca2a0793.png "width=" 1151 "height=" 566 "/>

This article describes the visual output of the API for this compensation program. There are too many things involved in the message, just to make this visual output look easy to understand. The compensation program needs to query and compare the messages sent and the received messages and then output them to determine whether the message was sent unsuccessfully or successfully. The simple logic is to compare the message send and accept tables in a certain time period, and then match the message IDs.

I'm thinking about what this data feeds back into the API, which is a regular design of two fields:

/// <summary>    ///  the accepted Message object.     /// </summary>    public class receivemessage     {        /// <summary>         ///  Send Message ID.         /// </summary>         public string SendMessageId { get; set; }         /// <summary>        ///  Accept the message ID.         /// </summary>         public string ReceiveMessageId { get; set; }     }

this represents a process from which a message is sent to an acceptance. If it fails, it may be only Sendmessageid and not receivemessageid. Then I will automatically compensate for messages that don't have receivemessageid. There are only dozens of messages at the time of development, and the output to postman looks OK, but it's not intuitive.

650) this.width=650; "title=" 2 "style=" border-right-width:0px;background-image:none;border-bottom-width:0px; padding-top:0px;padding-left:0px;padding-right:0px;border-top-width:0px; "border=" 0 "alt=" 2 "src=" http:// S3.51cto.com/wyfs02/m01/8a/c1/wkiom1g6zwzx2ahbaacmjw_txjs945.png "width=" 758 "height=" 428 "/>

Getreceivemessage is to get a list of accepted messages, that is, to see what state the current message is sent to accept.

 <summary>    ///  handles the success message object.     /// </summary>    public class successmessage     {        /// <summary>         ///  Send Message id        ///  </summary>        public string sendmessageid {  get; set; }        /// <summary>         ///  Accept Message id        ///  </summary>        public string receivemessageid  { get; set; }        /// <summary>         ///  Processing Success Message id        /// </summary>         public string successmessageid { get; set; }    }

The successmessage indicates the processing of a success message. There may be Sendmessageid,receivemessageid messages at this time, but Successmessageid may not be available. The message will be sent for processing success.

650) this.width=650; "title=" 3 "style=" border-right-width:0px;background-image:none;border-bottom-width:0px; padding-top:0px;padding-left:0px;padding-right:0px;border-top-width:0px; "border=" 0 "alt=" 3 "src=" http:// S3.51cto.com/wyfs02/m00/8a/c1/wkiom1g6zw3jxdfnaaejhcma_ro851.png "width=" 728 "height=" 537 "/>

Suddenly inspired by Elasticsearch's _cat endpoint. It seems I can try this here, WEBAPI with two output modes, one for the application of the JSON output mode, the other is for people to read the mode Text/plain mode, and the second mode can be simply understood as the row and column conversion default mode.

650) this.width=650; "title=" 4 "style=" border-right-width:0px;background-image:none;border-bottom-width:0px; padding-top:0px;padding-left:0px;padding-right:0px;border-top-width:0px; "border=" 0 "alt=" 4 "src=" http:// S3.51cto.com/wyfs02/m01/8a/c1/wkiom1g6zxhxkofdaailc2crjh0951.png "width=" 1077 "height=" 564 "/>

Does it look comfortable? This is helpful when viewing the time period of the message, and may seem laborious if you follow the original JSON output mode.

Take a look at the basic API design, in order to ensure that all of your API support? v Visualization mode requires some abstraction:

650) this.width=650; "title=" 5 "style=" border-right-width:0px;background-image:none;border-bottom-width:0px; padding-top:0px;padding-left:0px;padding-right:0px;border-top-width:0px; "border=" 0 "alt=" 5 "src=" http:// S3.51cto.com/wyfs02/m01/8a/bd/wkiol1g6zxsbkcsvaacwjwwywru822.png "width=" 683 "height=" 554 "/>

Need to define a viewmodel, all the data output this object, of course, I am simply encapsulated here. If you can, you can actually extract a library out, including the output of the text automation.

Let's see 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
The code is simple, here's an inspiration, Webapi is not really missing a visualization mode.
This article from the "humble if foolish, thirst for knowledge" blog, please be sure to keep this source http://wangqingpei557.blog.51cto.com/1009349/1877098
WEBAPI visual output mode (RabbitMQ, message compensation related) a feature that all WEBAPI seems to be missing