Distributed application problems:
- Complex distributed application architecture dozens of dependencies Each dependency inevitably fail at some point. When the plurality of micro-service calls, if a micro-services appears response time is too long or is not available, top quality service will take up more and more resources, thereby causing "avalanche effect."
- At higher flow rates, may instantly or a few seconds so that the server resource saturation, leading to increased delay between services, threads, and other resource constraints, the entire service is unavailable.
These need to isolate and manage failures and delays, failure to reach a single service does not crash the whole system.
Breaker: Hystrix client
Service failures in the lower level of service could cause a user cascading failures. When a call to a particular service reaches a predetermined threshold value (the default value of 20 Hystrix faults within 5 seconds), the circuit is opened, without speaking. In the case of error and open, developers can provide backup.
Open circuit stops cascading failure, and allows unnecessary failures or service time to heal. Fallback can call another Hystrix protection, static data or a normal null value. Rollback may be linked, so the first Fallback make some other business to call back to the static data.
Service fuse
Cited package:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
@EnableCircuitBreaker // open support for hystrixR fuse mechanism
A service abnormal returns to the calling method in line with expectations, alternative responses (Fallback) can handle, and not a long wait or throw an exception can not be handled.
Hystrix service will be downgraded, then blown micro-service calls that node, the quick return "wrong" response information.
@Component
public class StoreIntegration {
@HystrixCommand(fallbackMethod = "defaultStores")
public Object getStores(Map<String, Object> parameters) {
//do stuff that might fail，throw exception
}
public Object defaultStores(Map<String, Object> parameters) {
return /* something useful */;
}
}
Service downgraded
The first turn off some services, and other resources to spare, and then start the corresponding service.
Why downgrade?
Examples of the above, there are disadvantages: processing logic in the provider, hard-coded, high coupling, and is prone to expansion process.
In addition, we will be the main logic of extra logic into the main logic, inappropriate, you should use aspect-oriented programming ideas, it will be blown out of logic.
Implement a FallbackFactory <Interface> class interface, remember plus @Component, downgrade processing logic rewriting of the corresponding interface. Client Settings feign.hystrix.enabled = true.
@Component // 不要忘记添加，不要忘记添加
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
@Override
public DeptClientService create(Throwable throwable) {
return new DeptClientService() {
@Override
public Dept get(long id) {
return new Dept().setDeptNo(id)
.setDeptName("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
.setDbSource("no this database in MySQL");
}
@Override
public List<Dept> list() {
return null;
}
@Override
public boolean add(Dept dept) {
return false;
}
};
}
}
After this, service degradation logic integrated into the consumers, the service provider to suspend or fuse, can immediately return Fallback, without fail, resource-intensive avalanche.
Breaker: Hystrix Dashboard
One of the main advantages is that it Hystrix collect a set of indicators for each of HystrixCommand. Hystrix dashboard displays operating conditions of each circuit breaker in an efficient manner.
/hystrix.stream single instance endpoint monitor, / turbine stream endpoints to monitor the relevant examples. For example, a call to b, b calls c, etc., monitoring a / turbine stream, will be a, b, c associated with the operation of the endpoints are displayed.
Reproduced in: https: //www.jianshu.com/p/ce39f620425c