LindDotNetCore ~ Ocelot implements the microservice gateway,

LindDotNetCore ~ Ocelot implements the microservice gateway,

Back to directory

The Gateway has its own definition in the hardware, and the software architecture also has its own explanation. It is the entrance to all requests, and requests are routed to the gateway for processing and processing, return to the client. In this process, the core of the gateway is the core of Ocelot. We can implement user authorization, verification, caching, authentication, and many other considerations in the gateway!

Good friends included in the eldest brother: http://www.csharpkit.com/2018-01-06_69695.html

Address: http://www.cnblogs.com/axzxs2001/p/8005041.html

Github address: https://github.com/TomPallister/Ocelot

Definition

API gateway is a server and the only entry point of the system. From the perspective of object-oriented design, it is similar to the appearance mode. API gateway encapsulates the internal system architecture and provides a custom API for each client. It may also have other responsibilities, such as identity authentication, monitoring, Server Load balancer, caching, request fragmentation and management, and static Response Processing.

For example, mobile phones and WEB websites both need to call API interfaces. They communicate directly with the gateway without worrying about whether the specific service is A or B.

 

Project Demo

Install the Ocelot Package: Install-Package Ocelot

Create two projects, the gateway main project, DemoA and DemoB. In this way, both project A and Project B will specify the Gateway project and access the two projects through the gateway.

Gateway project, port 5000

DemoA project, port 5001

DemoB project, port 5002

Add the configuration file configuration. json In the Gateway project and copy it to the output directory. Right-click Properties and choose always copy.

{  "ReRoutes": [    {      "DownstreamPathTemplate": "/api/polly",      "DownstreamScheme": "http",      "DownstreamPort": 5001,      "DownstreamHost": "localhost",      "UpstreamPathTemplate": "/api/polly",      "UpstreamHttpMethod": [ "Get" ],      "QoSOptions": {        "ExceptionsAllowedBeforeBreaking": 3,        "DurationOfBreak": 10,        "TimeoutValue": 5000      },      "HttpHandlerOptions": {        "AllowAutoRedirect": false,        "UseCookieContainer": false      },      "AuthenticationOptions": {        "AuthenticationProviderKey": "",        "AllowedScopes": []      }    }  ]}

When the gateway is started, inject the configuration file

Public static IWebHost BuildWebHost (string [] args) {IWebHostBuilder builder = new WebHostBuilder (); // inject WebHostBuilder return builder. configureServices (service => {service. addSingleton (builder );}). configureAppConfiguration (conbuilder => {conbuilder. addJsonFile ("configuration. json ");}). useKestrel (). useUrls ("http: // *: 5000 "). useStartup <Startup> (). build ();}

Add ocelot middleware and services

services.AddOcelot(Configuration as ConfigurationRoot);app.UseOcelot().Wait();

When debugging multiple projects, our ports 5000 and 5001 will be monitored. We enter the api/polly path configured between them, and then we can see that it will be bound to the 5001 sub-station!

 

In this way, even if our gateway is running, all projects have their own routing templates and find services based on the routes! All services look like a website outside!

Back to directory