A, zuul Profile
1, the role of
zuul using a series of filter following functions
- Authentication and security - to authenticate for each resource
- Tracking and monitoring - Real-time observation of the back-end micro services TPS, response time, number of failed accurate information
- Log - access log records all the requested data, can provide unified support for log analysis and inquiry
- Dynamic routing - Dynamic routing will request up-to-back service
- Stress test - a gradual increase in pressure to access the cluster, to test the performance of the cluster
- 限流 - allocating capacity for each type of request and dropping requests that go over the limit
- Static response - gateway to return some response directly, rather than through internal service returns a response
2, components:
- zuul-core：library which contains the core functionality of compiling and executing Filters
- zuul-netflix：library which adds other NetflixOSS components to Zuul - using Ribbon for routing requests, for example.
3, example:
- zuul-simple-webapp：webapp which shows a simple example of how to build an application with zuul-core
- zuul-netflix-webapp：webapp which packages zuul-core and zuul-netflix together into an easy to use package
github Address: https://github.com/Netflix/zuul/
Two, zuul filter
1, key elements
- Type：most often defines the stage during the routing flow when the Filter will be applied (although it can be any custom string)
- Value can be: pre, route, post, error, custom
- Execution Order: filter执行的顺序（applied within the Type, defines the order of execution across multiple Filters）
- Criteria：filter执行的条件（the conditions required in order for the Filter to be executed）
- Action: Action filter executed (the action to be executed if the Criteria is met)
important point:
- Does not directly communicate communication between the filters, they share a state by a RequestContext
- The RequestContext a request for each is unique
- filter currently in use groovy to write, you can also use java
- The source code for each Filter is written to a specified set of directories on the Zuul server that are periodically polled for changes
- zuul can dynamically read, compile, and run these Filters
- filter will be updated is read from the disk into memory, and dynamically compiled into the server is running, can be used after each subsequent request (Updated filters are read from disk, dynamically compiled into the running server, and are invoked by Zuul for each subsequent request)
2, filter of the type (associated with a typical request lifecycle filter type)
- PRE Filters
- Execution timing: before routing to the origin.
- This type of filter might do
- request authentication
- choosing origin servers (-sorting machine)
- logging debug info.
- Limiting
- ROUTING Filters
- This type of filter might do: true to the service of a server (this server is pre filter elected) made the request, handle routing the request to an origin, This is where the origin HTTP request is built and sent using Apache HttpClient or Netflix Ribbon.
- POST Filters
- 执行时机：after the request has been routed to the origin
- This type of filter might do
- adding standard HTTP headers to the response
- gathering statistics and metrics
- streaming the response from the origin to the client
- ERROR Filters
- Execution timing: the other three stages executive (when an error occurs during one of the other phases) a stage when an error occurs
- CUSTOM Filters
- The default filter along the stream, zuul allow us to create some custom Filter type, and accurate implementation of them.
- For example: We customize a STATIC type of filter, for generating a response from zuul, rather than from behind services (we have a custom STATIC type that generates a response within Zuul instead of forwarding the request to an origin)
Three, zuul request lifecycle (filter flow)
Description: corresponding to (b) the filter type view
Four, zuul core architecture
The core zuul is: filter, filter flow and core architecture. These shows will do in the next chapter in the form of code.