(1) Service Management
1) generated automatically link calls
A large-scale distributed systems, or that is now popular micro-service architecture for instance, a distributed system is composed of a large number of service components. So between these services is how call each other? Call link is valid? To be honest, almost no one to back out of the clear, because the service is too many, probably hundreds or even thousands of service.
Based dubbo would need to do a distributed system, calls between the various services automatically recorded and automatically dependencies and call the link between the various services generated out, made a map, show up, everyone it can be seen on the right.
Service A -> Service B -> C Services
-> Services E
-> D Services
-> Services F
-> Services W
2) access service pressure and time statistics
Automatic statistics the number of calls and access latency between the various interfaces and services, but also divided into two levels. A level of granularity is the interface, that is, each interface of each service is called how many times a day, TP50, TP90, TP99, three grades of delay is the number of requests respectively; the second level from the beginning of the source of the entrance, a complete after dozens of link requests service, complete a request, a day full link to go many times, the whole link request delay TP50, TP90, TP99, namely how much.
After these things get, we can look back pressure of the main current system where, how to expand and optimize ah
3) Other
Service stratification (avoid circular dependencies), call monitoring and alarm link failure, the authentication service, to monitor the availability of each service (interface call success rate? Several 9?) Of 99.99%, 99.9%, 99%
(2) Service downgraded
A service instance invokes the service B, service B hang result, few retries call service A service B, or not directly degraded, take a spare logic returns a response to the user
public interface HelloService {
void sayHello();
}
public class HelloServiceImpl implements HelloService {
public void sayHello() {
System.out.println("hello world......");
}
}
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<dubbo:application name="dubbo-provider" />
<dubbo:registry address="zookeeper://127.0.0.1:2181" />
<dubbo:protocol name="dubbo" port="20880" />
<dubbo:service interface="com.zhss.service.HelloService" ref="helloServiceImpl" timeout="10000" />
<bean id="helloServiceImpl" class="com.zhss.service.HelloServiceImpl" />
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<dubbo:application name="dubbo-consumer" />
<dubbo:registry address="zookeeper://127.0.0.1:2181" />
<dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="return null">
</dubbo:reference>
</beans>
Now that mock, or null if the call fails unity
But can be modified to mock true, then implement a Mock class with a path under the same interface naming is the interface name plus a suffix Mock. Then implement your own logic in the relegation Mock class.
public class HelloServiceMock implements HelloService {
public void sayHello() {
// downgrade logic
}
}
(3) failure retry timeout and retry
The so-called failure retry, that is if the consumer fails to call provider, such as throwing an exception, and this time should be able to retry, or call a time-out can be retried.
<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>
After the interface for a service, to spend 5s, you can not do here waiting for you here to configure the timeout, I wait for 2s, did not return, I directly on the withdrawal, so you can not do
If a timeout, timeout will set the timeout; if a call fails the specified number will automatically retry
You with specific scenes in your company who said you how to set these parameters, timeout, usually set to 200ms, we believe that no more than 200ms not return
retries, 3 times, set retries, also typically when a read request, for example, you want to query data, you can set up a retries, if the first one did not read, error, retry the specified number of times, try to read again 2 secondary