1.1.簡介
Hystix,即熔斷器。
主頁:https://github.com/Netflix/Hystrix/
Hystix是Netflix開源的一個延遲和容錯庫,用於隔離訪問遠程服務、第三方庫,防止出現級聯失敗。
1.2.熔斷器的工作機制:
正常工作的情況下,客戶端請求調用服務API接口:
當有服務出現異常時,直接進行失敗回滾,服務降級處理:
當服務繁忙時,如果服務出現異常,不是粗暴的直接報錯,而是返回一個友好的提示,雖然拒絕了用戶的訪問,但是會返回一個結果。
這就好比去買魚,平常超市買魚會額外贈送殺魚的服務。等到逢年過節,超時繁忙時,可能就不提供殺魚服務了,這就是服務的降級。
系統特別繁忙時,一些次要服務暫時中斷,優先保證主要服務的暢通,一切資源優先讓給主要服務來使用,在雙十一、618時,京東天貓都會採用這樣的策略。
1.3.動手實踐
1.3.1.引入依賴
首先在user-consumer中引入Hystix依賴:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
1.3.2.開啓熔斷
@SpringBootApplication
@EnableEurekaClient
@EnableHystrix //2.使用@EnableHystrix開啓斷路機制
public class ServiceRibbonApplication {
public static void main(String[] args) {
SpringApplication.run(ServiceRibbonApplication.class, args);
}
}
1.3.2.改造消費者
我們改造user-consumer,添加一個用來訪問的user服務的DAO,並且聲明一個失敗時的回滾處理函數:
@Component
public class UserDao {
@Autowired
private RestTemplate restTemplate;
private static final Logger logger = LoggerFactory.getLogger(UserDao.class);
@HystrixCommand(fallbackMethod = "queryUserByIdFallback")
public User queryUserById(Long id){
long begin = System.currentTimeMillis();
String url = "http://user-service/user/" + id;
User user = this.restTemplate.getForObject(url, User.class);
long end = System.currentTimeMillis();
// 記錄訪問用時:
logger.info("訪問用時:{}", end - begin);
return user;
}
public User queryUserByIdFallback(Long id){
User user = new User();
user.setId(id);
user.setName("用戶信息查詢出現異常!");
return user;
}
}
@HystrixCommand(fallbackMethod="queryUserByIdFallback")
:聲明一個失敗回滾處理函數queryUserByIdFallback,當queryUserById執行超時(默認是1000毫秒),就會執行fallback函數,返回錯誤提示。- 爲了方便查看熔斷的觸發時機,我們記錄請求訪問時間。
在原來的業務邏輯中調用這個DAO:
@Service
public class UserService {
@Autowired
private UserDao userDao;
public List<User> queryUserByIds(List<Long> ids) {
List<User> users = new ArrayList<>();
ids.forEach(id -> {
// 我們測試多次查詢,
users.add(this.userDao.queryUserById(id));
});
return users;
}
}
1.3.3.改造服務提供者
改造服務提供者,隨機休眠一段時間,以觸發熔斷:
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
public User queryById(Long id) throws InterruptedException {
// 爲了演示超時現象,我們在這裏然線程休眠,時間隨機 0~2000毫秒
Thread.sleep(new Random().nextInt(2000));
return this.userMapper.selectByPrimaryKey(id);
}
}
1.3.4.啓動測試
然後運行並查看日誌:
id爲9、10、11的訪問時間分別是:
id爲12的訪問時間:
因此,只有12是正常訪問,其它都會觸發熔斷,我們來查看結果:
1.3.5.優化
雖然熔斷實現了,但是我們的重試機制似乎沒有生效,是這樣嗎?
其實這裏是因爲我們的Ribbon超時時間設置的是1000ms:
而Hystix的超時時間默認也是1000ms,因此重試機制沒有被觸發,而是先觸發了熔斷。
所以,Ribbon的超時時間一定要小於Hystix的超時時間。
我們可以通過hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds
來設置Hystrix超時時間。
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMillisecond: 6000 # 設置hystrix的超時時間爲6000ms