Deployment and User Guide for Micro Services Gateway SIA-GATEWAY

1. DeskTop

DeskTop displays the currently registered gateway groups. Clicking a gateway group will select the gateway group and jump to the homepage.

< p>Each gateway group includes the following four items:

• Role value: gateway application name prefix, used to distinguish gateway groups
• Owned instances: number of gateway group instances< /li>
• Gateway status: the current status of the gateway group
• Gateway description: the description of the gateway group, which can be modified

Second, home page

The homepage shows the current running status of the gateway.

< p>Mainly includes the following parts:

• Gateway call trend: call volume of each node per hour, 30 hours in total
• Gateway health status: health status of each node per hour, total 30 hours
• Monitoring alarms: warnings sent during operation
• Gateway cluster status: monitoring of the CPU, JVM and connection number of each node, of which CPU and JVM data are taken from Actuator

3. Route management

Route management is divided into the following four parts:

3.1 New Route

New Route Fill in the following options:

• Route ID: the unique identification of the route, which is also the primary key of the database table
• Gateway cluster group name: fill in the current gateway group name, visible in the upper right corner
• application name: optional , Generally fill in the application name
• Matching path: the path of the back-end service
• Back-end service strategy: There are three options as follows:

< thead>

< td>Fill in the name of the application registered to the registry. When routing matches, the corresponding instance will be matched according to the service list of the registry

< /tbody>

Backend Service Policy	Description
Backend Service ID
backend service URL	route After matching, it is directly forwarded to the filled URL
ListofServer	After the route is matched, use the polling strategy to select an instance to forward

• Back-end service URL: Back-end service strategy selects back-end service URL and ListofServ Fill in the backend ip:port for er
• Whether the prefix is ​​effective: If yes, the real matching path=matching path+public prefix

3.2 Route import and export< /h3>

Route import and export can be used to synchronize the routing data of the test environment and the production environment

• Route export: Export all routes of the current gateway group by default, and select some routes to export, click Route export will download routerList.json file
• Route import: Click route import to select the imported route file, after importing, it will prompt the route ID of successful and failed import, The imported route is in edit state

3.3 Routing operation

Routing operation is divided into the following two parts:

• Modify routing status: routing The status is divided into three states: edit, release, and offline, corresponding to release, offline, modify, delete, and view operations
• Routing component management: API Gateway provides a rich set of components, in the component management After binding the route, you can view or configure the components under the route. For the function and usage of each component, please refer to Component Management

3.4 Routing Topology

Click on Routing Topology map displays the real-time topology map of the route. The topology map is divided into three sections: Application -> Gateway -> Backend Service. If there is no request for the route, the route topology map is empty.

< h2>Four. Component Management

The gateway provides feature-rich public components and supports users to upload third-party components. When using components, you first need to bind routing in Component Management, and then view or configure components in Route Management.

< h3>4.1 Common Components

The description of common components describes the functions and usage of the components, which are divided into the following categories:

• Logs: divided into request log components and impact log components
• Grayscale: divided into blue-green deployment components and canary components
• Monitoring: statistical components, statistical routing access status
• Current limiting: current limiting components , Limit the number of requests per unit time of routing
• Security: security authentication components and black and white list components

4.2 third-party components

The third-party components are determined by the user Custom implementation, ready to use after uploading. Click Third Party Components to view the third-party components that have been uploaded, and click Component Upload to upload custom third-party components.

V. Gateway monitoring

The gateway monitoring is divided into two parts: operation status monitoring and topology map

5.1 Running status monitoring

The running status monitoring includes the following monitoring Item:

• Monitoring: Integrated Hystrix dashboard
• Log: Display the current log file content, data comes from Actuator
• JVM: Monitoring load, class loading, Threads, etc., data comes from Actuator
• Memory: monitors JVM memory, data comes from Actuator
• Garbage collection: monitors parnew and CMS collectors, data comes from Actuator
• Configuration : Including internal and external configuration files, the data comes from Actuator

5.2 Topology diagram

The topology diagram shows the service flow diagram of the gateway, which is the whole routing topology diagram gather.

Six. Log Management

Log management is integrated with Kibana. When users click Log Management, they will jump to Kibana to display the log data of the gateway group ES index. If the route is bound to a log request component or a log response component,
can be route management–operation->request log component or < code>Response log component Jump.

< h2>Seven. Fuse Management

The fuse management shows the request information that is blown by Hystrix during the operation of the gateway, including fuse type, error information and stack information.

< h2>8. Registration Center Management

Registration center management mainly includes two parts: registration information query and dynamic modification of registry address

8.1 Registration Information Query

The registration information comes from the current gateway For Eureka where the group is located, click Query for eligible applications.

8.2 Dynamically modify the address of the registry

The Eureka server address uses the local configuration by default, and the user can modify the Eureka address through Set Eureka, and set it after successful setting The Eureka address will be saved in the database.
At the same time, the gateway group node will be notified to modify the registry address in the memory and register again. Clicking Reset Eureka will clear the Eureka address in the database and notify the gateway group node to use the local configuration.
After setting/resetting, a pop-up window will prompt the result.

Registration center address setting/reset success conditions:

• There is no route with the state of published under this gateway group
• The management terminal can request the new registration center address

9. Routing connectivity test

Support GET and POST two methods to test whether the routing is connected.

10. Gateway Swagger

The gateway Swagger integrates all the gateway interface documents of the services registered in the registry. You can view the interface documents by selecting different services in the upper right corner.

< h2>11. System blacklist

The system blacklist can be set to a global blacklist. Currently, the IP interception strategy is supported. After setting, all requests from this IP will be intercepted.

< h2>12. Gateway Audit

The gateway audit displays all users, behaviors and performances operating on the gateway management side, which facilitates monitoring and analysis of user behaviors.

< h2>Thirteen. Gateway settings

The gateway settings are divided into three parts: alert mailbox, log level operation, view version number

13.1 Early Warning Mailbox

An early warning email will be sent when an early warning occurs To the set mailbox

13.2 Log level operation

The gateway log level defaults to INFO, and the user can view or dynamically adjust the log level during debugging. The log name can be com.creditease and root, and the log level can be INFO and DEBUG.

In Logback and other log frameworks, the logger hierarchy is similar to java inheritance, organized by name, and the logger name is used to separate the parent logger and the child logger. When the child logger does not set the log level,
Use the parent log level until ROOT, which is equivalent to Object in Java. After the child log level is set, the parent (including ROOT) log level will no longer be valid for the child log,
similar to the java child class overriding the parent class method.

13.3 View the version number

The gateway version number is used to distinguish the version of each instance of the gateway. The version number in the default configuration is in the form of sag_x.y_timestamp, where timestamp is the packaging timestamp,
Can be modified by zuul.version in the configuration file.

Links to SIA related open source products

• Microservice task scheduling framework: https://github.com/siaorg/sia-task
• Microservice routing gateway: https://github.com/siaorg/sia-gateway
• Rabbitmq queue service PLUS: https://github.com/siaorg/sia-rabbitmq-plus

Source: CreditEase Institute of Technology