Distributed Service Framework Learning Notes 4 Service Routing __ Architecture

Transparent Routing

Many open source RPC framework callers need to configure the address information of the service provider, although it is possible to avoid hard-coded address information by reading the list of service addresses of the database, but consumers still perceive the address information of the service provider, which violates the transparent routing principle. subscription Publishing based on the Service registration center

In the Distributed Service Framework, the service registry is used to store the service provider address information, the service publication related attribute information, the consumer obtains the service provider's address information through the active inquiry and the passive notification, without needing to hard-code the service provider address information in the code as before. Spending only needs to know what services the current system publishes, without needing to know where the service is located, which is transparent routing. It works based on the subscription publishing mechanism of the service registry (for example, zookeeper).

Consumers need to cache the service provider address. Load Balancing

Load Balancing Policy:
1. Random
2. Round-robin
3. Service Call delay
4. Consistent hash
Requests for the same parameters are always sent to the same service provider, and when a provider is down, the original request to the provider, based on the virtual node, is spread to the other provider without causing drastic changes. The platform provides the default number of virtual nodes that can be modified by configuration parameters.
5. Viscous connection
Used for connections to stateful services, where possible, the client always initiates a service call to the same provider, unless the provider is down and the other is connected. Because services are often strongly recommended as stateless, sticky connections are rarely used in actual projects. Local routing priority Policy INJVM Mode

In some business scenarios, services that need to be consumed are also published within the local JVM. This scenario, in terms of performance, reliability, and so on, requires a priority call to the service provider within the JVM, a local-priority routing pattern called INJVM mode.
The INJVM protocol is a pseudo protocol that does not open a port and does not initiate a remote service invocation, giving priority to a service provider within the JVM, which executes the same process compared to other routing strategies, except that it replaces the remote service invocation with an internal call. innative Mode

If the physical machine or VM configuration is better, multiple application processes tend to choose to be combined. Service consumers and service providers may be deployed on the same machine (VM). Service routing takes precedence over the service provider of the machine, and if the remote service call is not found again, the pattern is called the innative mode. Routing Rules

Load balancing, local routing priority, and so on, are usually used to meet the online requirements of most businesses, but in some scenarios the routing policy needs to be set up with some filtering conditions, and the more common is conditional Routing and script routing based on an expression. Conditional routing rule through the IP conditional expression for black and white list access control, traffic guidance, only exposed some service providers, to prevent the entire cluster services are washed away, resulting in other services can not be separated from read and write: method=find*,list*,get*,query*= >providerip=192.168.1.* before and after table separation: app=web*=>providerip=192.168.1.,app=java=>provierip=192.168.2.* grayscale upgrade, To route a Web foreground application to a new service version: app=web*=>providerip=192.168.1.* script Routing rules

Script routing rules, especially usually support dynamic compilation, can be modified in real time, do not need to restart the system, which dynamically adjusts the routing rules online is very effective. Routing Policy Customization

The main application scenario is as follows:
-Grayscale Upgrade
-Service failure, peak business diversion
-Non-common routing customization requirements related to the business domain
The routing extension strategy is as follows: The platform provides the routing interface for the user to implement the platform to provide the routing configuration XML Schema definition, supports the user to extend the routing Rule service to publish the custom routing policy, for the service publication through the Spring Bean way, the user defines the extension route bean, Then, when the service provider configures the routing rules, reference the associated extended bean, and if it is extended through the JDK's SPI, you need to add the extended routing implementation class and policy name to the routing policy file in the Meta-inf/services directory of the jar package. Configuring Routing

The routing configuration policy is designed as follows:
1. Local Configuration
2. Unified Registration Management
3. Dynamic release Best Practice--multi-machine room routing

Multi-machine room routing, different computer room will share a service registration center cluster (except for disaster-tolerant room).
Only by random, polling and other load balancing strategy, the message will be routed to two rooms, not to the target of the engine room calls. Conditional routing rules make it easy to solve problems.

Based on the original load balancing strategy, the conditional routing strategy is configured, because the network segments in different computer rooms are usually different, and the address filtering can be realized according to the matching of network segment conditions. The specific configuration strategy is as follows:
app=web*,consumerip=192.168.1.=>providerip=192.168.1.. For the computer room A in all the web foreground applications, only access to the internal service providers, not across the room call.
Another strategy is the virtual grouping, which divides the service provider (across the engine room) logic of the entire cluster system into groups, and a consumer accesses only a single virtual grouping of service providers to prevent Cross Group service calls. If it is a multiple room deployment, virtual grouping can correspond to 1 rooms, if it is a single room, the virtual group can correspond to 1 rooms. By splitting and grouping, you can prevent a consumer from seeing all the service providers in the cluster, either reducing competitive performance or enhancing fault isolation.
It should be pointed out that when a large area of downtime in a room or the service provider does not work, the need to access other health service providers across the room, to prevent a computer room failure caused business interruption.