Shulou(Shulou.com)06/01 Report--

This article shows you how to implement RPC based on Ocelot's API gateway Relay. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Preface

As we all know, the API gateway works in the application layer, so why should it be designed in this way instead of working directly in the transport layer or the network layer and other lower-level environments? Let's first take a brief look at TCP/IP 's five-tier model.

The specific working principle of each layer must be familiar to everyone, and the author is not repeating this content. Going back to the above question, why the API gateway needs to work on the application layer becomes clear at a glance. The gateway at the physical level is handed over to physical devices, such as physical firewalls, while HTTP is an application layer protocol that has been completely standardized and standardized in network communication, and communication protocols can be seen everywhere. Of course, you can integrate the gateway into FTP and add corresponding protocol conversion processing.

In retrospect, what is RPC? is it a protocol? No. To be exact, it is just an abbreviation of the name of "remote call". It is not any standardized protocol, nor is it a protocol standard recognized by the public. we are more often used to create custom (such as Socket,Netty) message methods to call, compared to the http protocol, we save a lot of useless message content in http, such as headers message headers. This simple GET request returns a hello world request and response, and the metadata is about 10 bytes, but with the standard content of http, such as headers headers, it is estimated that it will swell to 25030 bytes. Here is a common http headers header.

Therefore, many system internal calls still use self-defined RPC call mode to communicate. After all, speed and performance is one of the key indicators of the intranet, while standardization and semantic independence play an important role in the extranet. So, why the API gateway does not work on RPC, because it does not have a general standard like HTTP/HTTPS, requires us to convert standardized protocols into custom protocols, often referred to as Relay, as shown in the figure.

We have briefly introduced the gateway implementation of Ocelot in Http, which can be done in the configuration file without any modification, which is quite convenient. But what should we do when we need to implement a custom RPC protocol?

Here you can handle the conversion of downstream protocols by adding (or extending) OcelotMiddleware.

Ocelot downstream Middleware extension

We know that in the Ocelot gateway, all operations are filtered and processed through middleware, and the iterative communication between multiple middleware forms the communication pipeline of Ocelot. OcelotPipelineConfiguration is used in the source code to extend and configure more Ocelot middleware, as shown in the source code:

In the source code, we can see that all the middleware corresponding to the operands are DownstreamContext downstream context objects. MapWhenOcelotPipeline can just meet the needs of our extended middleware, which provides List delegation for us to configure multiple downstream processing middleware and map it to the Ocelot pipeline builder. When we look at the source code of DownstreamContext, we can see that when building the downstream context, the HttpContext object is passed by default, and the downstream request and response is received through DownstreamRequest and DownstreamResponse.

In this way, we can add custom middleware by extending OcelotPipelineConfiguration, and let's define its extension name as OcelotPipelineConfigurationExtensions.

When we have the extension definition of DownstreamContext, and in the downstream configuration, we need to specify that the configuration protocol is tcp, then we can start to implement the extended middleware, which we define as RelayRequesterMiddleware.

The bold code above is the main place to handle the downstream interception, where we can use the protocol conversion from http to rpc. Of course, in the usage configuration of Ocelot, we need to add the Middleware middleware.

App.UseOcelot (pipelineConfiguration = > pipelineConfiguration.AddRpcMiddleware ()). Wait ()

The above completes the extension of DownstreamContext in Ocelot

To sum up, when we need to extend downstream protocols, we need to manually configure OcelotPipelineConfiguration and add it to IOcelotPipelineBuilder, and then implement custom processing of downstream middleware by extending IOcelotPipelineBuilder.

Manual protocol conversion

In fact, to the above section, I believe that many friends can achieve custom downstream interception and processing, and the introduction of this section is only a reference for how to convert protocols in Doteasy.RPC.

Let's first look at the URL: http://127.0.0.1:8080/api/values in a set of http, and then look at the URL:tcp://127.0.0.1:8080/api/values in tcp. Is there any difference? There is no difference, the only difference is that scheme changes from http to tcp. In rpc procedure call, we generally do not have the way of "absolute path + predicate" to identify the service node, which is usually tcp://127.0.0.1:8080, and the specified service node is handed over to the registry to complete, that is, the so-called service discovery.

Because there is no internal implementation of Doteasy.RPC, such as ": /: @: /." This standardized and unified positioning, so the author's approach is to integrate the client of RPC into the Ocelot host, let it replace the requests and responses downstream of DownstreamConext, achieve the generation of all proxies through extended reflection, and call methods according to predicates and parameters, so that the code does not need to make too many changes.

First of all, you need to understand one purpose of doing this.

In a single call to Doteasy.RPC, in order to reduce the time of generating proxies for many interfaces, we will check whether the dynamic proxies of the relevant interfaces have been generated before each call to ensure that only one fragment of proxies are generated at a time. However, as a repeater in a gateway, it is very powerless to generate a code snippet at a time, and all the interfaces need to be generated as proxies to make it easy to find and invoke in Relay.

If we look at a URL: http://127.0.0.1:8080/api/1/Sync in RESTful style, we usually put the predicate at the end and the parameters before the predicate. During the manual conversion of RPC, we can use the predicate to assume the name of the RPC service we need to invoke (but it is not necessarily Sync).

Based on the service container in Doteasy.RPC, it is very convenient to realize parameter type conversion and later Headers processing.

The author's transformation method is to invoke predicates as service names and parameter values. Although this method is very poor at present, it provides a set of ideas for custom transformation and can be constantly optimized and adjusted. The current disadvantages are as follows:

When there are multiple parameters in http, protocol conversion cannot be performed because you do not know what the parameter set of the agent target method is, and only globally assume one-to-one parameter targets.

RPC client integrates a large number of proxy generation in the gateway, so it is unable to achieve dynamic update, such as manual replacement of DLL and automatic update of dynamic proxy by interface.

Each call needs to find the specified (or fuzzy matching) method name from a large number of agents, and this lookup can be a very serious bottleneck if there is a 1KW + interface name.

The above content is how to implement RPC based on Ocelot's API gateway Relay. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.