Gateway Scheme Summary __api

After this period of thinking, practice, frustration, rethinking, and then practice, the API Gateway scheme is summed up. Overall goal

Mainly in order to solve the SOA service framework to provide external API related issues, mainly related to the following aspects: Unified authentication of the flow of anti-attack system split API horizontal expansion, high availability, load all horizontal service automatic scaling ...

To solve a series of problems above, a gateway system is needed to serve as a unified portal for external service invocation. The programme is divided into two parts: part I.

For specific code, see
Https://github.com/zhuzhong/gateway-dubbox.git

The back-end service uses the Dubbox SOA service Framework, the internal call protocol between services is the Dubbo protocol, while for the front-end H5 provides the interface with the rest protocol, the data transmission format is JSON, that is, Http+json technology. The first part of the main solution is the rest protocol to provide services to the external gateway problem. Purpose

Our service framework uses the Dubbox (this is not more descriptive), the internal system calls are using the Dubbo protocol, and the rest protocol is used for front-end service delivery. Front-end applications face many rest services and require a gateway system in order to solve the unified invocation. Why do I write to the API gateway, there is now a framework to solve this type of problem, but based on the Java language Open source is not (in addition to Zuul, it is possible I did not find). No C + +, unable to scale nginx cannot be extended nginx not LUA, unable to expand Nginx feature design

Originally builds a version https://github.com/zhuzhong/gateway.git according to the personal understanding, but the version design is too complex, especially the front-end parameter passes, and the gateway and the back-end service heartbeat detection function does not have, the service registration and the discovery all is completes manually, is not automatic. This design plan refer to Spring-cloud's Zuul design idea. Although most of the code is in the previous version, the overall design mentality has changed, and it can be considered to be two different versions, because they are completely dissimilar in how they are used. You can also refer to this version only, without needing to care about the previous version of the content. Main function

The front-end request unified interception;

Load balance;

Heartbeat detection authentication parameter verification Routing routing rule

Very simple: The URL of the front-end request, remove the gateway contextpath the corresponding URL address is the corresponding back-end service URL;
For the URL of the backend service, it is divided into two parts: the part is the context ContextPath, and the other is the request path;
By listening to the registry ZK, you can get a list of all the servers that provide rest services, group according to the contextpath of the service, and then route requests. Back-end Services list Fetch

The back-end services list, by listening to the registry ZK, and then parsing out the corresponding list of services. When the service address injected in the registry changes, it is again resolved;
ZK helps us complete the back-end Services list movement state change and Heartbeat detection;

Front-End Request Url:http://localhost:8080/gateway/restapi/test

The Contextpath=gateway of the gateway

Contextpath=restapi of back-end services

To get a list of servers based on the contextpath=restapi of backend services, choose one, such as Http://localhost:10000/,

The full API service address for the back-end service is:
Http://localhost:10000/restapi/test

The interface is then invoked to obtain the corresponding response, and the front-end can be returned to the technology stack SPRINGMVC Spring servlet3 asynchronous HttpClient 4.5.3

Zookeeper

Apache-chain Part II

Code See HTTPS://GITHUB.COM/ZHUZHONG/GATEWAY-NGXCFG.GIT, this part mainly solves the problem of automatic scaling and load balancing of gateways. Purpose

Using Nginx as the reverse proxy server for the first part of the gateway, the gateway system can only be expanded manually and cannot be automatically shrunk. To solve this problem, you can use the Lua script to use Nginx Plus

But these two requirements for me, are not feasible, so can only build their own wheels. The wheel is mainly to solve the project Https://github.com/zhuzhong/gateway-dubbox.git load balance and dynamic scaling problem. Design Ideas

Design Idea Main reference http://blog.csdn.net/akin_zhou/article/details/50373414

Draw the corresponding service list from the registry zookeeper;
Pull the corresponding list of services from the registry, mainly to obtain the Nginx configuration information requires the service address and the appropriate port information.

Generate the Nginx configuration file;
Generate Nginx configuration information, mainly divided into two parts

Upstream part

The location part of these two parts introduces the nginx main configuration file in the form of include

Let Nginx reload the new profile using the example

Enable this bean in Gateway-dubbox, and start the Gateway-dubbox service to inject it into the registry

<!--virtual Service injection Registry-->
<bean class= "Com.aldb.gateway.service.support.DefaultVirtualServiceImpl" init-method= "Init" >
<property name= "RootPath" value= "${virtual.zk.rootpath}" ></property>
<property name= "Zkservers" value= "${virtual.zk.zkservers}" ></property>
<property name= "context "Value=" ${proj.contextpath} "></property>
<property name=" IP "value=" ${virtual.ip} "></ property>
<property name= "Port" value= "${virtual.port}" ></property>

Configure nginx.conf

Increase the include/opt/test/up.conf in the HTTP section;
Increase include/opt/test/lo.conf in the server section;

Configure Gateway-ngxcfg

Use the same registration center as the Gateway-dubbox virtual service

Start Gateway-ngxcfg, which deploys the same machine as Nginx

See if the appropriate configuration file has been generated in the appropriate directory, and notice whether the master process ID for Nginx has changed. Nginx Reload configuration file is done through Java calling Shell, and the corresponding shell file needs to be placed on the server (see shell-demo.sh in Source code) and configure the corresponding Shellfile parameters