Article Directory
In daily learning, we only learned how to use Apache Dubbo as an RPC communication framework, as well as the application and principles of the service registry. This is just the tip of the iceberg. In fact, Apache Dubbo is more like an ecosystem. It provides integration of many mainstream frameworks, such as:
1. Supports service publishing of multiple protocols. The default is dubbo:/, and it can also support rest://, webservice://, thrift://, etc. · Support a variety of different registration centers, such as Nacos, ZooKeeper, Redis, and in the future will also support Consul, Eureka, Etcd, etc.
2. Support multiple serialization technologies, such as avro, fst, fastjson, hessian2, kryo, etc.
In addition, Apache Dubbo has very complete functions in service governance, such as cluster fault tolerance, service routing, load balancing, service degradation, service current limiting, service monitoring, and security verification.
(1) Cluster fault tolerance
In distributed network communication, fault tolerance is a must. What is fault tolerance? Literally, it is the ability of the service to tolerate errors. We all know that there will be many uncertain factors in network communication that cause the request to fail, such as network delays, network interruptions, and service exceptions. When the service caller (consumer) calls the service provider's interface, if the request fails due to the above-mentioned reasons, a mechanism is needed for the service caller to deal with it. Dubbo provides a cluster fault-tolerant mechanism to handle such errors gracefully.
(1) Fault-tolerant mode
Dubbo provides 6 fault-tolerant modes by default, and the default is Failover Cluster. If these 6 fault-tolerant modes cannot meet your actual needs, you can also expand by yourself. This is also the power of Dubbo. Almost all functions provide plug-in extensions.
[Failover Cluster]: Automatically switch after failure. When the service call fails, it will switch to other machines in the cluster to retry. The default number of retries is 2, and the number of times can be modified through the attribute retries=2, but an increase in the number of retries will cause a longer response delay. This fault-tolerant mode is usually used for read operations, because transactional operations will cause data duplication problems.
[Failfast Cluster]: Fast failure. When the service call fails, an error is reported immediately, that is, only one call is initiated. Usually used for some idempotent write operations, such as adding new data, because when the service call fails, it is likely that the request has been successfully processed on the server side, but the response failed due to network delays, in order to avoid the situation where the result is uncertain This fault-tolerant mechanism can be used to cause the problem of repeated data insertion.
[Failsafe Cluster]: Fail safe. That is, when an exception occurs, the exception is directly ignored.
[Failback Cluster]: Automatically reply after failure. When an exception occurs in the service call, the failed request is recorded in the background and retransmitted regularly. This mode is suitable for message notification operations to ensure that the request must be sent successfully.
[Forking Cluster]: Call multiple services in the cluster in parallel, and return as long as one of them succeeds. The maximum number of parallels can be set by forks=2.
[Broadcast Cluster]: Broadcast calls to all service providers, and any service error indicates that the service call failed. This mechanism is usually used to notify all service providers to update cache or local resource information.
Configuration method The
configuration method is very simple, just add a parameter to the @Service annotation of the specified service. Note that unless otherwise specified, the subsequent code is based on the previous Dubbo Spring Cloud code. Adding the cluster=
"failfast" parameter to the @Service annotation indicates that the current service's fault tolerance mode is fast failure.
In practical applications, the query statement fault tolerance strategy recommends using the default Failover Cluster, and adding, deleting and modifying operations is recommended to use Failfast Cluster or use the Failover Cluster (retries="O") strategy to prevent duplicate data addition and other problems! It is recommended to design the interface When the query interface method is made into a separate interface to provide query.
(2) Load balancing
Load balancing should not be an unfamiliar concept. In the case of a large number of visits, we will increase the number of nodes through horizontal expansion to balance the flow of requests, thereby improving the overall performance of the service. Simply put, if the TPS of a service node is 100, then if it is increased to a cluster of 5 nodes, it means that the TPS of the entire cluster can reach 500.
When a service caller faces a service provider cluster composed of 5 nodes, the request should be distributed to which node in the cluster depends on the load balancing algorithm, through which each server node can obtain a load suitable for its processing capacity. Load balancing can be divided into hardware load balancing and software load balancing. The most common hardware load balancing is F5, and the current mainstream software load balancing is Nginx.
There are 4 load balancing strategies provided in Dubbo, and the default load balancing strategy is random. Similarly, if these four strategies cannot meet actual needs, we can extend them based on the SPI mechanism in Dubbo.
[Random LoadBalance]: Random algorithm. You can set a larger weight value for servers with better performance. The larger the weight value, the greater the probability of randomness.
[RoundRobin LoadBalance]: Polling. Set the polling ratio according to the weight after the convention.
[LeastActive LoadBalance]: The least active load balance. Nodes that process slower will receive fewer requests.
[ConsistentHash LoadBalance]: Consistent Hash. Requests with the same parameters are always sent to the same service provider.
Configuration method
Add loadbalance parameter to @Service annotation:
@Service(cluster = "failfast", loadbalance = "roundrobin")
(3) Service degradation
Service degradation is a system protection strategy. When server access pressure is high, unimportant services can be downgraded according to the current business conditions to ensure the normal operation of core services. The so-called downgrade is to temporarily shut down some non-essential functions during periods of high traffic. For example, during the Double 11 promotion, Taobao will shut down functions such as viewing historical orders and product reviews, thereby freeing up more resources for protection. Most users can complete transactions normally.
[There are multiple levels of downgrade classification]:
1. According to whether it is automated or not, it can be divided into automatic downgrade and manual downgrade.
2. According to the function, it can be divided into read service downgrade and write service downgrade.
Manual downgrading generally has certain predecessors, such as temporarily shutting down certain non-core services, such as evaluation and recommendation, before the big e-commerce promotion. And the automatic downgrade comes more from the automatic triggering of "smoothness in the bottom" when certain abnormalities occur in the system, such as:
[Failure degradation]: The called remote service "hangs up", the network fails or the RPC service returns abnormally. In this case, if the business permits, you can respond to the client by setting the bottom data.
[Current limit downgrade]: No matter what type of system, the traffic it supports is limited. In order to protect the system from being overwhelmed, the system will limit the current for the core business. When the request traffic reaches the threshold, subsequent requests will be intercepted, and such requests can enter the queuing system, such as 12306. You can also return directly to the downgrade page, such as returning to the "Activity too hot, please come back later" page.
Dubbo provides a Mock configuration to achieve service degradation, which means that when the service provider fails to access the network abnormally, the client does not throw an exception, but returns the bottom data through the degraded configuration. The operation steps are as follows:
Create the MockHelloService class in the spring-cloud-dubbo-consumer project. This class only needs to implement the automatically degraded interface, and then rewrite the abstract method in the interface to return local data.
(4) Host binding rules
Host binding means the IP address published by the Dubbo service. By default, Dubbo will find and bind the host IP address in the following order:
1. Find the IP address configured by the DUBBO_IP_TO_BIND attribute in the environment variable.
2. Find the IP address configured in the dubbo.protocol.host property. The default is empty. If there is no configuration or the IP address is illegal, continue to search.
3. Obtain the local IP address through LocalHost.getHostAddress. If the acquisition fails, continue to search down.
4. If the address of the registry is configured, use Socket communication to connect to the address of the registry, and use a for loop to pass socket.getLocalAddress () .getHostAddress () Scan each network card to obtain the network card IP address.
In the above process, if a legal IP address is detected in any step, it will be returned as the exposed service IP address. It should be noted that the obtained IP address is not the address written to the registry. By default, the IP address written to the registry is preferred to the IP address configured in the environment variable DUBBO_IP_TO_REGISTRY. When this attribute is not configured, the previously obtained IP address will be selected and written into the registry.
Using the default host binding rules, there may be cases where the obtained IP address is incorrect, causing service consumers to communicate with the URL address obtained on the registry. Because Dubbo's strategy to detect the local IP address is to call LocalHost.getHostAddress first, the principle of this method is to map the IP address by obtaining the hostname of the machine. If it points to a wrong IP address, then the wrong address will serve as a service The published address is registered on the ZooKeeper node. Although the Dubbo service can be started normally, the service consumer cannot call it normally. According to the IP address search rules in Dubbo, if you encounter this situation, you can use many ways to solve it:
1. Configure the machine name corresponding to the correct IP address mapping in /etc/hosts.
2. Add the DUBBO_IP_TO_BIND or DUBBO_IP_TO_REGISTRY attribute to the environment variable, and the Value value is the bound host address.
3. Set the host address through dubbo.protocol.host.
In addition to obtaining the IP address of the binding host, the public port also needs attention. The Dubbo framework provides default port numbers for different protocols:
4. The default port number of the Dubbo protocol is 20880. The default port number of the Webservice protocol is 80.
In actual use, it is recommended to specify a port number to avoid conflicts with other Dubbo service ports.