table of Contents
Foreword
For API Gateway, the industry seems to be divided under it, are the following classification / scene.
- Oriented Web App
- For Mobile App
- Oriented Partner OpenAPI
- Oriented Partner ExternalAPI
- other. . .
In 18 years in August, when the honor with .NET Core 2.1 reconstruct an external service gateway project, the role of the data capacity of this project is actually within the company can provide the public out, allowing needy companies.
According to the classification of this project, should be classified to face OpenAPI Partner .
The project started with Nancy wrote at that time to provide a new capability out of time, it is to increase the ability of the code, after the release in order to truly provide external, but something was to provide both relatively small, responsible colleagues have to flash people, so it is still acceptable.
In 18 years in July, when more and more capability to provide external, and change the code every time, I can not stand on the proposed reconstruction.
This project is about a call a day effective amount of about 15 million, on top of a virtual machine deployed on CentOS six 4c4g of (in fact, use that many machines, each machine is basically about 20% and 10% of cpu memory ), with Jexus to hosting. Grand entrance is Nginx, so in the end flows are:
Request -> Nginx -> Jexus -> dotnet
Here are a few things to say for this gateway involved.
Unified Authentication
Authentication with this one is still very ancient practice, with the user name and password is the way to deal with, this can be understood as a sign of the inspection process.
Here supports two forms, one parameter is transmitted in the clear, there is a parameter encrypted transmission.
In fact, some companies feel that I can not pass directly to you in plain text of 123 to 123 after a pass encryption, decryption and then let you go deal.
Limiting service
Limiting function is to restrict the caller to call too often, this limit is divided into seconds, days, months three levels based on business scenarios.
Different callers, different data services have different restrictions, this is done based on Redis.
Route Forwarding
Routing forwarding using a HttpClientFactory.
At the beginning or use steeltoe to handle service registration and discovery, but the findings were not easy to use, and then there are also many services do not access Eureka, so in the end there is no processing service registration and discovery, but the direct use of a domain name is requested.
Parameters restructuring
A user request parameters will basically be passed through the downstream service, of course, we can not rule out some special needs.
Here is a simple example to explain, like the caller just want to check the weather in Guangzhou, Shenzhen did not want him to check the weather, and the service is downstream of these two cities can check in, so there must be some special parameters to tell downstream service.
This time, we need the user to the Senate to conduct a reorganization, re-construct a JSON parameter threw downstream services, will be equivalent to the special circumstances of fixed parameter format for downstream services, using JObject to deal with.
Linktrace
Because sometimes call chain is very complex, in order to record a caller's request to complete the call chain, the gateway here will generate a traceId in the request header, routing and forwarding of time together will be issued in the past.
Different service when logging will record this traceId also unified together, so that all the logs from the log can be found through this system traceId.
Fuse downgrade
Downstream service does not necessarily guarantee 7 * 24 hours of normal service, sometimes because the database processing timeout, the network request times out, resulting in a period of time, does not respond to normal.
This time the gateway should not have to go to every real service request, and to disconnect for some time, failure to return directly to the caller.
This one is a combination of HttpClientFactory and Polly to achieve, save a lot of trouble.
Total time service
Total time can be said to be a large core of this gateway, because you want to make money, need to pay money to the caller. Money is the basic per-counted out.
Wrote a blog before, implementation is similar.
Pay-per-interface simple realization of ideas .
Monitoring business indicators
Need to know the last time a certain range, calling the situation a different caller, different data services (success, failure, effectively, the total number, etc.)
Here is the Prometheus , is responsible for writing index data, prometheus going to pull this data, then combine Grafana to make different billboards to show.
Logging
Logging is divided into two categories, one is the log, one is to call log.
Log is currently expanding NLog , the data thrown Kafka, then there will be pumping operation and maintenance data to Elasticsearch.
To avoid Kafka ventilation, so the data is lost if it fails to Kafka, will place orders to the log file, and then collected by Filebeat, then threw Elasticsearch.
The last show in the form of graylog, something like
Call log is one of the bases and the caller settlement, so this importance can still be pricey.
Currently using asynchronous write add fault tolerance. Call log database archiving ultimately fall.
Iterative update
Update a program is inevitable, so there is a good release process can reduce some of the difficulties. Although after reconstruction, the project also updated three times.
Here is the Go CD to publish, and send then to operate the plant, the pipeline from pre-test to.
to sum up
Although this project quite small, but can also be described as "small but perfectly formed."
Finally ask, who recently Gangster recruit younger brother do? Any, you can contact me ha.