通常微服務架構中的依賴通過遠程調用實現,而遠程調用中最常見的問題就是通信消耗與連接數佔用。在高併發的情況之下,因通信次數的增加,總的通信時間消耗將會變的不那麼理想。同時,因爲對依賴服務的線程池資源有限,將出現排隊等待與響應延遲的情況。爲了優化這兩個問題,Hystrix提供了HystrixCollapser來實現請求的合併,以減少通信消耗和線程數的佔用。
HystrixCollapser實現了在HystrixCommand之前放置一個合併處理器,它將處於一個很短時間窗(默認10毫秒)內對同一依賴服務的多個請求進行整合並以批量方式發起請求的功能(服務提供方也需要提供相應的批量實現接口)。通過HystrixCollapser的封裝,開發者不需要去關注線程合併的細節過程,只需要關注批量化服務和處理。下面我們從HystrixCollapser的使用實例,對其合併請求的過程一探究竟。
Hystrix的請求合併示例
public abstract class HystrixCollapser<BatchReturnType, ResponseType, RequestArgumentType> implements
HystrixExecutable<ResponseType>, HystrixObservable<ResponseType> {
...
public abstract RequestArgumentType getRequestArgument();
protected abstract HystrixCommand<BatchReturnType> createCommand(Collection<CollapsedRequest<ResponseType, RequestArgumentType>> requests);
protected abstract void mapResponseToRequests(BatchReturnType batchResponse, Collection<CollapsedRequest<ResponseType, RequestArgumentType>> requests);
...
}
從HystrixCollapser
抽象類的定義中可以看到,它指定了三個不同的類型:
BatchReturnType
:合併後批量請求的返回類型ResponseType
:單個請求返回的類型RequestArgumentType
:請求參數類型
而對於這三個類型的使用可以在它的三個抽象方法中看到:
RequestArgumentType getRequestArgument()
:該函數用來定義獲取請求參數的方法。HystrixCommand<BatchReturnType> createCommand(Collection<CollapsedRequest<ResponseType, RequestArgumentType>> requests)
:合併請求產生批量命令的具體實現方法。mapResponseToRequests(BatchReturnType batchResponse, Collection<CollapsedRequest<ResponseType, RequestArgumentType>> requests)
:批量命令結果返回後的處理,這裏需要實現將批量結果拆分並傳遞給合併前的各個原子請求命令的邏輯。
接下來,我們通過一個簡單的示例來直觀的理解實現請求合併的過程。
假設,當前微服務USER-SERVICE
提供了兩個獲取User
的接口:
/users/{id}
:根據id返回User對象的GET請求接口。/users?ids={ids}
:根據ids參數返回User對象列表的GET請求接口,其中ids爲以逗號分割的id集合。
而在服務消費端,爲這兩個遠程接口已經通過RestTemplate
實現了簡單的調用,具體如下:
@Service
public class UserServiceImpl implements UserService {
@Autowired
private RestTemplate restTemplate;
@Override
public User find(Long id) {
return restTemplate.getForObject("http://USER-SERVICE/users/{1}", User.class, id);
}
@Override
public List<User> findAll(List<Long> ids) {
return restTemplate.getForObject("http://USER-SERVICE/users?ids={1}", List.class, StringUtils.join(ids, ","));
}
}
接着,我們來實現將短時間內多個獲取單一User對象的請求命令進行合併的實現:
- 第一步:爲請求合併的實現準備一個批量請求命令的實現,具體如下:
public class UserBatchCommand extends HystrixCommand<List<User>> {
UserService userService;
List<Long> userIds;
public UserBatchCommand(UserService userService, List<Long> userIds) {
super(Setter.withGroupKey(asKey("userServiceCommand")));
this.userIds = userIds;
this.userService = userService;
}
@Override
protected List<User> run() throws Exception {
return userService.findAll(userIds);
}
}
批量請求命令實際上就是一個簡單的HystrixCommand實現,從上面的實現中可以看到它通過調用userService.findAll
方法來訪問/users?ids={ids}
接口以返回User的列表結果。
- 第二步,通過繼承
HystrixCollapser
實現請求合併器:
public class UserCollapseCommand extends HystrixCollapser<List<User>, User, Long> {
private UserService userService;
private Long userId;
public UserCollapseCommand(UserService userService, Long userId) {
super(Setter.withCollapserKey(HystrixCollapserKey.Factory.asKey("userCollapseCommand")).andCollapserPropertiesDefaults(
HystrixCollapserProperties.Setter().withTimerDelayInMilliseconds(100)));
this.userService = userService;
this.userId = userId;
}
@Override
public Long getRequestArgument() {
return userId;
}
@Override
protected HystrixCommand<List<User>> createCommand(Collection<CollapsedRequest<User, Long>> collapsedRequests) {
List<Long> userIds = new ArrayList<>(collapsedRequests.size());
userIds.addAll(collapsedRequests.stream().map(CollapsedRequest::getArgument).collect(Collectors.toList()));
return new UserBatchCommand(userService, userIds);
}
@Override
protected void mapResponseToRequests(List<User> batchResponse, Collection<CollapsedRequest<User, Long>> collapsedRequests) {
int count = 0;
for (CollapsedRequest<User, Long> collapsedRequest : collapsedRequests) {
User user = batchResponse.get(count++);
collapsedRequest.setResponse(user);
}
}
}
在上面的構造函數中,我們爲請求合併器設置了時間延遲屬性,合併器會在該時間窗內收集獲取單個User的請求並在時間窗結束時進行合併組裝成單個批量請求。下面getRequestArgument
方法返回給定的單個請求參數userId,而createCommand
和mapResponseToRequests
是請求合併器的兩個核心:
createCommand
:該方法的collapsedRequests
參數中保存了延遲時間窗中收集到的所有獲取單個User的請求。通過獲取這些請求的參數來組織上面我們準備的批量請求命令
UserBatchCommand
實例。mapResponseToRequests
:在批量命令UserBatchCommand
實例被觸發執行完成之後,該方法開始執行,其中batchResponse
參數保存了createCommand
中組織的批量請求命令的返回結果,而collapsedRequests
參數則代表了每個被合併的請求。在這裏我們通過遍歷批量結果batchResponse
對象,爲collapsedRequests
中每個合併前的單個請求設置返回結果,以此完成批量結果到單個請求結果的轉換。
請求合併的原理分析
下圖展示了在未使用HystrixCollapser
請求合併器之前的線程使用情況。可以看到當服務消費者同時對USER-SERVICE
的/users/{id}
接口發起了五個請求時,會向該依賴服務的獨立線程池中申請五個線程來完成各自的請求操作。
而在使用了HystrixCollapser
請求合併器之後,相同情況下的線程佔用如下圖所示。由於同一時間發生的五個請求處於請求合併器的一個時間窗內,這些發向/users/{id}
接口的請求被請求合併器攔截下來,並在合併器中進行組合,然後將這些請求合併成一個請求發向USER-SERVICE
的批量接口/users?ids={ids}
,在獲取到批量請求結果之後,通過請求合併器再將批量結果拆分並分配給每個被合併的請求。從圖中我們可以看到以來,通過使用請求合併器有效地減少了對線程池中資源的佔用。所以在資源有效並且在短時間內會產生高併發請求的時候,爲避免連接不夠用而引起的延遲可以考慮使用請求合併器的方式來處理和優化。
使用註解實現請求合併器
在快速入門的例子中,我們使用@HystrixCommand
註解優雅地實現了HystrixCommand
的定義,那麼對於請求合併器是否也可以通過註解來定義呢?答案是肯定!
以上面實現的請求合併器爲例,也可以通過如下方式實現:
@Service
public class UserService {
@Autowired
private RestTemplate restTemplate;
@HystrixCollapser(batchMethod = "findAll", collapserProperties = {
@HystrixProperty(name="timerDelayInMilliseconds", value = "100")
})
public User find(Long id) {
return null;
}
@HystrixCommand
public List<User> findAll(List<Long> ids) {
return restTemplate.getForObject("http://USER-SERVICE/users?ids={1}", List.class, StringUtils.join(ids, ","));
}
}
@HystrixCommand
我們之前已經介紹過了,可以看到這裏通過它定義了兩個Hystrix命令,一個用於請求/users/{id}
接口,一個用於請求/users?ids={ids}
接口。而在請求/users/{id}
接口的方法上通過@HystrixCollapser
註解爲其創建了合併請求器,通過batchMethod
屬性指定了批量請求的實現方法爲findAll
方法(即:請求/users?ids={ids}
接口的命令),同時通過collapserProperties
屬性爲合併請求器設置相關屬性,這裏使用@HystrixProperty(name="timerDelayInMilliseconds", value = "100")
將合併時間窗設置爲100毫秒。這樣通過@HystrixCollapser
註解簡單而又優雅地實現了在/users/{id}
依賴服務之前設置了一個批量請求合併器。
請求合併的額外開銷
雖然通過請求合並可以減少請求的數量以緩解依賴服務線程池的資源,但是在使用的時候也需要注意它所帶來的額外開銷:用於請求合併的延遲時間窗會使得依賴服務的請求延遲增高。比如:某個請求在不通過請求合併器訪問的平均耗時爲5ms,請求合併的延遲時間窗爲10ms(默認值),那麼當該請求的設置了請求合併器之後,最壞情況下(在延遲時間窗結束時才發起請求)該請求需要15ms才能完成。
由於請求合併器的延遲時間窗會帶來額外開銷,所以我們是否使用請求合併器需要根據依賴服務調用的實際情況來選擇,主要考慮下面兩個方面:
- 請求命令本身的延遲。如果依賴服務的請求命令本身是一個高延遲的命令,那麼可以使用請求合併器,因爲延遲時間窗的時間消耗就顯得莫不足道了。
- 延遲時間窗內的併發量。如果一個時間窗內只有1-2個請求,那麼這樣的依賴服務不適合使用請求合併器,這種情況下不但不能提升系統性能,反而會成爲系統瓶頸,因爲每個請求都需要多消耗一個時間窗才響應。相反,如果一個時間窗內具有很高的併發量,並且服務提供方也實現了批量處理接口,那麼使用請求合併器可以有效的減少網絡連接數量並極大地提升系統吞吐量,此時延遲時間窗所增加的消耗就可以忽略不計了。
原文:http://blog.didispace.com/spring-cloud-hystrix-request-collapse/
本文節選自我的《Spring Cloud微服務實戰》,更多內容可購買我的書或加入我的知識星球參與討論