DDD死黨：內存Join--將復用和擴展用到極致
作者：geekhalo
使用 @JoinInMemory 注解完成繁瑣的配置工作，將通用配置保留在自定義注解進行統一管理，基于 @AliasFor 完成入參的配置，還可以使用 @JoinInMemoryConfig 開啟并發處理。
1. 為什么"內存Join"是個無法繞過的話題
首先，我們先簡單解釋下，什么是“內存Join”。
相信大家對關系數據庫的 join 語句肯定不陌生，其作用就是通過關聯關系從多個表中查詢數據，關聯條件和數據聚合全部由 數據庫服務完成。
圖片
而 內存 Join，簡單來說就是把原本數據庫幫我們完成的數據聚合操作遷移到應用服務，在應用服務的內存中完成。
圖片
數據庫join非常簡單，但隨著系統的發展，內存join變得越來越重要，其核心驅動力有：
- 微服務。微服務要求“數據資產私有化”，也就是說每個服務的數據庫是私有資產，不允許其他服務的直接訪問。如果需要訪問，只能通過服務所提供的接口完成
- 分庫分表的限制。當數據量超過 MySQL 單實例承載能力時，通常會通過“分庫分表”這一技術手段來解決，分庫分表后，數據被分散到多個分區中，導致 join 語句失效
- 性能瓶頸。在高并發情況下，join 存在一定的性能問題，高并發、高性能端場景不適合使用。很多公司規范中對 join 的使用做出了明確的限制
2. 課程先導
發現變化，封裝變化，管理變化，是開發人員的必備技能。
本篇文章從查詢訂單這個業務場景為入口，針對數據的內存join進行多次抽象和封裝，最終實現“內存Join聲明化”。
首先，先看下最終的效果，從直觀上感受下“抽象”帶來的效率提升。
圖片
通過抽象，可以達到如下效果：
- 左邊一坨“模板代碼” 等價于右邊一個注解
- 模型需要綁定 UserVO 數據，只需使用 @JoinUserVOOnId 注解進行聲明配置即可
- @JoinInMemoryConfig 注解的 PARALLEL 配置將開啟多線程并行處理，以提供性能
神秘背后的本質便是“抽象”。讓我們以訂單查詢為線索，層層遞進，最終實現“能力聲明化”。
能力聲明化，是抽象的一種高級表現，無需編寫代碼，通過配置的方式為特定組件進行能力加強。
在正式開始之前，可以先了解下整體的推演流程：
圖片
3.【案例分析】訂單查詢
假設，我們是訂單中心的一位研發伙伴，需要開發 “我的訂單” 模塊，其核心接口包括：
- 我的訂單，查詢用戶的全部訂單，包括 訂單信息、用戶信息、郵寄地址信息、商品信息等；
- 訂單詳情，查詢某個訂單的詳細信息，包括 訂單信息、用戶信息、郵寄地址信息、商品信息、支付信息等；
根據需求定義 OrderService 接口如下：
public interface OrderService {
// 我的訂單
List<OrderListVO> getByUserId(Long userId);
// 訂單詳情
OrderDetailVO getDetailByOrderId(Long orderId);
}
// 為配合多種實現策略，使用抽象類進行統一
public abstract class OrderListVO {
public abstract OrderVO getOrder();
public abstract UserVO getUser();
public abstract AddressVO getAddress();
public abstract ProductVO getProduct();
}
// 為配合多種實現策略，使用抽象類進行統一
public abstract class OrderDetailVO {
public abstract OrderVO getOrder();
public abstract UserVO getUser();
public abstract AddressVO getAddress();
public abstract ProductVO getProduct();
public abstract List<PayInfoVO> getPayInfo();
}3.1. Foreach + 單條抓取方案
這么簡單的需求，那不是信手拈來，很快就提供了一版
圖片
代碼具體如下：
@Service
public class OrderServiceCodingV1 implements OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private AddressRepository addressRepository;
@Autowired
private ProductRepository productRepository;
@Autowired
private UserRepository userRepository;
@Autowired
private PayInfoRepository payInfoRepository;
@Override
public List<OrderListVO> getByUserId(Long userId) {
// 獲取用戶訂單
List<Order> orders = this.orderRepository.getByUserId(userId);
// 依次進行數據綁定
return orders.stream()
.map(order -> convertToOrderListVO(order))
.collect(toList());
}
private OrderListVOCodingV1 convertToOrderListVO(Order order) {
OrderVO orderVO = OrderVO.apply(order);
OrderListVOCodingV1 orderDetailVO = new OrderListVOCodingV1(orderVO);
// 綁定地址信息
Address address = this.addressRepository.getById(order.getAddressId());
AddressVO addressVO = AddressVO.apply(address);
orderDetailVO.setAddress(addressVO);
// 綁定用戶信息
User user = this.userRepository.getById(order.getUserId());
UserVO userVO = UserVO.apply(user);
orderDetailVO.setUser(userVO);
// 綁定商品信息
Product product = this.productRepository.getById(order.getProductId());
ProductVO productVO = ProductVO.apply(product);
orderDetailVO.setProduct(productVO);
return orderDetailVO;
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
// 暫時忽略
Order order = this.orderRepository.getById(orderId);
return convertToOrderDetailVO(order);
}
private OrderDetailVO convertToOrderDetailVO(Order order) {
OrderDetailVOCodingV1 orderDetail = new OrderDetailVOCodingV1(OrderVO.apply(order));
// 獲取地址并進行綁定
Address address = this.addressRepository.getById(order.getAddressId());
AddressVO addressVO = AddressVO.apply(address);
orderDetail.setAddress(addressVO);
// 獲取用戶并進行綁定
User user = this.userRepository.getById(order.getUserId());
UserVO userVO = UserVO.apply(user);
orderDetail.setUser(userVO);
// 獲取商品并進行綁定
Product product = this.productRepository.getById(order.getProductId());
ProductVO productVO = ProductVO.apply(product);
orderDetail.setProduct(productVO);
// 獲取支付信息并進行綁定
List<PayInfo> payInfos = this.payInfoRepository.getByOrderId(order.getId());
List<PayInfoVO> payInfoVOList = payInfos.stream()
.map(PayInfoVO::apply)
.collect(toList());
orderDetail.setPayInfo(payInfoVOList);
return orderDetail;
}
}如果真的這樣實現，那你離“被跑路”不遠了。
為什么會這么說呢？因為 ==“我的訂單”這個接口存在嚴重的性能問題!==
“我的訂單”接口具體實現如下：
- 查詢 order 信息
- 依次對其進行數據抓取
- 完成數據綁定并返回結果
單個用戶請求，數據庫訪問總次數 = 1（獲取用戶訂單）+ N（訂單數量） * 3（需要抓取的關聯數據）
其中，N（訂單數量） * 3（關聯數據數量） 存在性能隱患，存在嚴重的==讀放大效應==。一旦遇到忠實用戶，存在成百上千訂單，除了超時別無辦法。
“訂單詳情”接口實現，目前問題不大，最大的問題為：==“訂單詳情”與“我的訂單”兩個接口存在大量的重復邏輯！==
3.2. 批量查詢 + 內存Join
首先，我們先來解決 “我的訂單”接口的性能問題。從之前的分析可知，性能低下的根本原因在于==“讀放大效應”==，數據庫請求次數與用戶訂單數成正比，為了更好的保障性能，最好將數據庫操作控制在一個常量。
整體思路為：先批量獲取要綁定的數據，然后遍歷每一個訂單，在內存中完成數據綁定。
圖片
實現代碼如下：
@Service
public class OrderServiceCodingV2 implements OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private AddressRepository addressRepository;
@Autowired
private ProductRepository productRepository;
@Autowired
private UserRepository userRepository;
@Autowired
private PayInfoRepository payInfoRepository;
@Override
public List<OrderListVO> getByUserId(Long userId) {
List<Order> orders = this.orderRepository.getByUserId(userId);
List<OrderListVOCodingV2> orderDetailVOS = orders.stream()
.map(order -> new OrderListVOCodingV2(OrderVO.apply(order)))
.collect(toList());
// 批量獲取用戶，并依次進行綁定
List<Long> userIds = orders.stream()
.map(Order::getUserId)
.collect(toList());
List<User> users = this.userRepository.getByIds(userIds);
Map<Long, User> userMap = users.stream()
.collect(toMap(User::getId, Function.identity(), (a, b) -> a));
for (OrderListVOCodingV2 orderDetailVO : orderDetailVOS){
User user = userMap.get(orderDetailVO.getOrder().getUserId());
UserVO userVO = UserVO.apply(user);
orderDetailVO.setUser(userVO);
}
// 批量獲取地址，并依次進行綁定
List<Long> addressIds = orders.stream()
.map(Order::getAddressId)
.collect(toList());
List<Address> addresses = this.addressRepository.getByIds(addressIds);
Map<Long, Address> addressMap = addresses.stream()
.collect(toMap(Address::getId, Function.identity(), (a, b) -> a));
for (OrderListVOCodingV2 orderDetailVO : orderDetailVOS){
Address address = addressMap.get(orderDetailVO.getOrder().getAddressId());
AddressVO addressVO = AddressVO.apply(address);
orderDetailVO.setAddress(addressVO);
}
// 批量獲取商品，并依次進行綁定
List<Long> productIds = orders.stream()
.map(Order::getProductId)
.collect(toList());
List<Product> products = this.productRepository.getByIds(productIds);
Map<Long, Product> productMap = products.stream()
.collect(toMap(Product::getId, Function.identity(), (a, b) -> a));
for (OrderListVOCodingV2 orderDetailVO : orderDetailVOS){
Product product = productMap.get(orderDetailVO.getOrder().getProductId());
ProductVO productVO = ProductVO.apply(product);
orderDetailVO.setProduct(productVO);
}
return orderDetailVOS.stream()
.collect(toList());
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
// 暫時忽略
Order order = this.orderRepository.getById(orderId);
return convertToOrderDetailVO(order);
}
private OrderDetailVO convertToOrderDetailVO(Order order) {
// 暫時忽略
return orderDetail;
}
}調整之后，對于“我的訂單”接口，單個用戶請求==數據庫的訪問次數變成了常量(4)==。
如果你是這么實現的，那恭喜你，你已步入==合格程序員行列==。
3.3. 并行批量查詢 + 內存Join
批量查詢+內存Join 方案能滿足大部分場景，如果要抓取的數據太多，也就是數據庫訪問這個==常量變大==時，性能也會越來越差。
原因很簡單，由于串行執行，==整體耗時 = 獲取訂單耗時 + sum(抓取數據耗時)==
聰明的同學早就躍躍欲試，這個我會：==多線程并行執行唄。==
是的，基于 Future 的實現如下（還有很多版本，比如 CountDownLatch）
整體設計如下：
圖片
示例代碼如下：
@Service
public class OrderServiceCodingV3 implements OrderService {
private ExecutorService executorService;
@Autowired
private OrderRepository orderRepository;
@Autowired
private AddressRepository addressRepository;
@Autowired
private ProductRepository productRepository;
@Autowired
private UserRepository userRepository;
@Autowired
private PayInfoRepository payInfoRepository;
@PostConstruct
public void init(){
// 初始化線程池（不要使用Executors，這里只是演示，需要對資源進行評估）
this.executorService = Executors.newFixedThreadPool(20);
}
@SneakyThrows
@Override
public List<OrderListVO> getByUserId(Long userId) {
List<Order> orders = this.orderRepository.getByUserId(userId);
List<OrderListVOCodingV2> orderDetailVOS = orders.stream()
.map(order -> new OrderListVOCodingV2(OrderVO.apply(order)))
.collect(toList());
List<Callable<Void>> callables = Lists.newArrayListWithCapacity(3);
// 創建異步任務
callables.add(() -> {
// 批量獲取用戶，并依次進行綁定
List<Long> userIds = orders.stream()
.map(Order::getUserId)
.collect(toList());
List<User> users = this.userRepository.getByIds(userIds);
Map<Long, User> userMap = users.stream()
.collect(toMap(User::getId, Function.identity(), (a, b) -> a));
for (OrderListVOCodingV2 orderDetailVO : orderDetailVOS){
User user = userMap.get(orderDetailVO.getOrder().getUserId());
UserVO userVO = UserVO.apply(user);
orderDetailVO.setUser(userVO);
}
return null;
});
// 創建異步任務
callables.add(() ->{
// 批量獲取地址，并依次進行綁定
List<Long> addressIds = orders.stream()
.map(Order::getAddressId)
.collect(toList());
List<Address> addresses = this.addressRepository.getByIds(addressIds);
Map<Long, Address> addressMap = addresses.stream()
.collect(toMap(Address::getId, Function.identity(), (a, b) -> a));
for (OrderListVOCodingV2 orderDetailVO : orderDetailVOS){
Address address = addressMap.get(orderDetailVO.getOrder().getAddressId());
AddressVO addressVO = AddressVO.apply(address);
orderDetailVO.setAddress(addressVO);
}
return null;
});
// 創建異步任務
callables.add(() -> {
// 批量獲取商品，并依次進行綁定
List<Long> productIds = orders.stream()
.map(Order::getProductId)
.collect(toList());
List<Product> products = this.productRepository.getByIds(productIds);
Map<Long, Product> productMap = products.stream()
.collect(toMap(Product::getId, Function.identity(), (a, b) -> a));
for (OrderListVOCodingV2 orderDetailVO : orderDetailVOS){
Product product = productMap.get(orderDetailVO.getOrder().getProductId());
ProductVO productVO = ProductVO.apply(product);
orderDetailVO.setProduct(productVO);
}
return null;
});
// 執行異步任務
this.executorService.invokeAll(callables);
return orderDetailVOS.stream()
.collect(toList());
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
// 暫時忽略
Order order = this.orderRepository.getById(orderId);
return convertToOrderDetailVO(order);
}
private OrderDetailVO convertToOrderDetailVO(Order order) {
// 暫時忽略
}
}多線程并發執行，==整體耗時 = 獲取訂單耗時 + max(抓取數據耗時)==
如果你能夠這樣實現的，那恭喜你，你已步入==高級程序員行列==。
然后呢，到此為止了？NO，接下來才是高潮?。?！
讓我們==打開認知==，開啟==“抽象+封裝”==之旅。
4. Fetcher封裝
仔細研究上述代碼，尋找里面的==“變與不變”==，你會發現：
- 由于“我的訂單” 和 “訂單詳情” 返回的是==不同的 VO==，導致在實現綁定操作時寫了兩套基本一樣的邏輯；
- Address、User、Product 的綁定==邏輯骨架是一樣的==，一些==細節操作存在差異==；
找到邏輯中的變化點，接下來便是有針對性的進行封裝。
4.1. 消除方法中的重復代碼
對于 “我的訂單” 和 “訂單詳情” 返回==不同的 VO==，該怎么處理呢？
非常簡單，思路如下：
- 【不變】抽象出“行為接口” Fetcher，統一操作行為
- 【變化】基于多態，不同的 VO 派生自相同的接口，但可以自己定義實現，從而實現個性化變化
整體設計如下：
圖片
簡單示例如下：
// 以 UserVO 為例，ProductVO、AddressVO，PayInfoVO 基本一致，不在贅述
public interface UserVOFetcherV1 {
Long getUserId();
void setUser(UserVO user);
}
// OrderDetailVO 實現對應的接口，為了突出重點暫時忽略具體實現
public class OrderDetailVOFetcherV1 extends OrderDetailVO
implements AddressVOFetcherV1,
ProductVOFetcherV1,
UserVOFetcherV1,
PayInfoVOFetcherV1{
}
// OrderListVO 實現對應接口，為了突出重點暫時忽略具體實現
public class OrderListVOFetcherV1 extends OrderListVO
implements AddressVOFetcherV1,
ProductVOFetcherV1,
UserVOFetcherV1 {
}有了統一的操作接口，接下來便是抽取具體的綁定邏輯，以 UserVOFetcherExecutor 為例：
@Component
public class UserVOFetcherExecutorV1 {
@Autowired
private UserRepository userRepository;
public void fetch(List<? extends UserVOFetcherV1> fetchers){
List<Long> ids = fetchers.stream()
.map(UserVOFetcherV1::getUserId)
.distinct()
.collect(Collectors.toList());
List<User> users = userRepository.getByIds(ids);
Map<Long, User> userMap = users.stream()
.collect(toMap(user -> user.getId(), Function.identity()));
fetchers.forEach(fetcher -> {
Long userId = fetcher.getUserId();
User user = userMap.get(userId);
if (user != null){
UserVO userVO = UserVO.apply(user);
fetcher.setUser(userVO);
}
});
}
}實現邏輯沒有變化，最重要的變化在于“入參類型”，不在是具體的 VO，而是抽象的 UserVOFetcher 接口。
AddressVOFetcherExecutor、ProductVOFetcherExecutor、PayInfoVOFetcherExecutor 與 UserVOFetcherExecutorV1 邏輯基本一致，篇幅問題不在贅述。
這樣一個小小的調整，會給使用方帶來什么便利？一起看下使用方的變化：
@Service
public class OrderServiceFetcherV1 implements OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private AddressVOFetcherExecutorV1 addressVOFetcherExecutorV1;
@Autowired
private ProductVOFetcherExecutorV1 productVOFetcherExecutorV1;
@Autowired
private UserVOFetcherExecutorV1 userVOFetcherExecutorV1;
@Autowired
private PayInfoVOFetcherExecutorV1 payInfoVOFetcherExecutorV1;
@Override
public List<OrderListVO> getByUserId(Long userId) {
List<Order> orders = this.orderRepository.getByUserId(userId);
List<OrderListVOFetcherV1> orderDetailVOS = orders.stream()
.map(order -> new OrderListVOFetcherV1(OrderVO.apply(order)))
.collect(toList());
// 直接使用 FetcherExecutor 完成數據綁定
this.addressVOFetcherExecutorV1.fetch(orderDetailVOS);
this.productVOFetcherExecutorV1.fetch(orderDetailVOS);
this.userVOFetcherExecutorV1.fetch(orderDetailVOS);
return orderDetailVOS.stream()
.collect(toList());
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
Order order = this.orderRepository.getById(orderId);
OrderDetailVOFetcherV1 orderDetail = new OrderDetailVOFetcherV1(OrderVO.apply(order));
List<OrderDetailVOFetcherV1> orderDetailVOS = Arrays.asList(orderDetail);
// 直接使用 FetcherExecutor 完成數據綁定
this.addressVOFetcherExecutorV1.fetch(orderDetailVOS);
this.productVOFetcherExecutorV1.fetch(orderDetailVOS);
this.userVOFetcherExecutorV1.fetch(orderDetailVOS);
this.payInfoVOFetcherExecutorV1.fetch(orderDetailVOS);
return orderDetail;
}
}兩個方法直接使用 FetcherExecutor 完成數據抓取和綁定，實現了==綁定邏輯的復用==。
如果再有 VO 需要進行數據綁定，只需：
- VO 實現 XXXFetcher 接口，實現對應方法，提供關聯數據并完成數據綁定
- 使用 XXXFetcherExecutor 完成數據綁定
至此，面對新業務基本上與“綁定邏輯”說再見了。
4.2. 重構綁定邏輯
接下來讓我們一起聚焦于綁定邏輯，先對比下上述的UserVOFetcherExecutor 與下面的 AddressVOFetcherExecutor， 找到里面的變化與不變：
@Component
public class AddressVOFetcherExecutorV1 {
@Autowired
private AddressRepository addressRepository;
public void fetch(List<? extends AddressVOFetcherV1> fetchers){
// 獲取關聯信息
List<Long> ids = fetchers.stream()
.map(AddressVOFetcherV1::getAddressId)
.distinct()
.collect(Collectors.toList());
// 查詢關聯數據
List<Address> addresses = addressRepository.getByIds(ids);
// 轉為為 Map
Map<Long, Address> addressMap = addresses.stream()
.collect(toMap(address -> address.getId(), Function.identity()));
// 依次進行數據綁定
fetchers.forEach(fetcher -> {
Long addressId = fetcher.getAddressId();
Address address = addressMap.get(addressId);
if (address != null){
// 轉換為 VO
AddressVO addressVO = AddressVO.apply(address);
// 將數據寫回到結果
fetcher.setAddress(addressVO);
}
});
}
}仔細觀察，會發現：
- ==【不變】邏輯骨架基本一致==，基本是由：
獲取關聯信息
查詢關聯數據
將其轉換為 Map
講數據轉化為 VO
將 VO 綁定到結果對象
- ==【變化】實現細節存在差異==；
- 從什么接口中獲取關聯信息
- 如何查詢關聯數據
- 轉換為 Map 的鍵是什么
- 如何將數據轉換為 VO
- 如何完成數據的綁定
熟悉設計模式的伙伴是否眼前一亮？停頓一下好好回想一下，哪種模式就是用來處理這種問題的？
答案便是：模板方法模式
整體思想為：
- 將不變的邏輯骨架封裝在父類方法
- 將變化的實現細節放在子類中進行擴展
整體設計如下：
圖片
抽取公共父類如下：
abstract class BaseItemFetcherExecutor<FETCHER extends ItemFetcher, DATA, RESULT>
implements ItemFetcherExecutor<FETCHER>{
@Override
public void fetch(List<FETCHER> fetchers) {
// 獲取關聯信息
List<Long> ids = fetchers.stream()
.map(this::getFetchId)
.distinct()
.collect(Collectors.toList());
// 查詢關聯數據
List<DATA> datas = loadData(ids);
// 轉為為 Map
Map<Long, List<DATA>> dataMap = datas.stream()
.collect(groupingBy(this::getDataId));
// 依次進行數據綁定
fetchers.forEach(fetcher -> {
Long id = getFetchId(fetcher);
List<DATA> ds = dataMap.get(id);
if (ds != null){
// 轉換為 VO
List<RESULT> result = ds.stream()
.map( data -> convertToVo(data))
.collect(Collectors.toList());
// 將數據寫回到結果
setResult(fetcher, result);
}
});
}
protected abstract Long getFetchId(FETCHER fetcher);
protected abstract List<DATA> loadData(List<Long> ids);
protected abstract Long getDataId(DATA data);
protected abstract RESULT convertToVo(DATA data);
protected abstract void setResult(FETCHER fetcher, List<RESULT> result);
}基于 BaseItemFetcherExecutor 的 UserFetcherExecutor 如下：
@Component
public class UserVOFetcherExecutorV2
extends BaseItemFetcherExecutor<UserVOFetcherV2, User, UserVO>{
@Autowired
private UserRepository userRepository;
@Override
protected Long getFetchId(UserVOFetcherV2 fetcher) {
return fetcher.getUserId();
}
@Override
protected List<User> loadData(List<Long> ids) {
return this.userRepository.getByIds(ids);
}
@Override
protected Long getDataId(User user) {
return user.getId();
}
@Override
protected UserVO convertToVo(User user) {
return UserVO.apply(user);
}
@Override
protected void setResult(UserVOFetcherV2 fetcher, List<UserVO> userVO) {
if (CollectionUtils.isNotEmpty(userVO)) {
fetcher.setUser(userVO.get(0));
}
}
@Override
public boolean support(Class<UserVOFetcherV2> cls) {
// 暫時忽略，稍后會細講
return UserVOFetcherV2.class.isAssignableFrom(cls);
}
}UserVOFetcherExecutor究竟發生什么變化呢？好像變得更復雜了：
- 從代碼量角度（行數）變得更多了，因為類函數明顯變大
- 從復雜度角度（邏輯）變得更加簡單，每個方法基本都是一兩句語句
那我們究竟得到了什么好處？可以花幾分鐘好好思考一下?。?！
在說結果之前，讓我們看下另一個變化點。回想下 FetcherExecutor 的執行點，如下：
@Override
public List<OrderListVO> getByUserId(Long userId) {
List<Order> orders = this.orderRepository.getByUserId(userId);
List<OrderListVOFetcherV1> orderDetailVOS = orders.stream()
.map(order -> new OrderListVOFetcherV1(OrderVO.apply(order)))
.collect(toList());
// 手工調用，OrderListVO 實現新接口，需要增加新的依賴和調用
this.addressVOFetcherExecutorV1.fetch(orderDetailVOS);
this.productVOFetcherExecutorV1.fetch(orderDetailVOS);
this.userVOFetcherExecutorV1.fetch(orderDetailVOS);
return orderDetailVOS.stream()
.collect(toList());
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
Order order = this.orderRepository.getById(orderId);
OrderDetailVOFetcherV1 orderDetail = new OrderDetailVOFetcherV1(OrderVO.apply(order));
List<OrderDetailVOFetcherV1> orderDetailVOS = Arrays.asList(orderDetail);
// 手工調用，OrderDetailVO 實現新接口，需要增加新的依賴和調用
this.addressVOFetcherExecutorV1.fetch(orderDetailVOS);
this.productVOFetcherExecutorV1.fetch(orderDetailVOS);
this.userVOFetcherExecutorV1.fetch(orderDetailVOS);
this.payInfoVOFetcherExecutorV1.fetch(orderDetailVOS);
return orderDetail;
}其實，需要調用哪些 FetcherExecutor 完全可以由 VO 實現的接口來確定。也就是說，==需要綁定新數據，只需 VO 繼承并實現新的 Fetcher 接口即可。==
對此，我們需要：
- 一個統一的訪問入口，對外提供訪問
- 每個 FetcherExecutor 能夠識別 VO 并執行綁定邏輯
哪個設計模式是用來解決這個問題？花幾分鐘好好思考一下！
答案是：==責任鏈模型==
標準的責任鏈模式用起來比較繁瑣，在 Spring 實現中大量使用他的一種變現，及提供一個驗證接口，由組件自身完成判斷，用于決定是否執行自身邏輯。
整體設計如下：
圖片
首先，為了統一 FetcherExecutor 的行為，抽取通用接口：
public interface ItemFetcherExecutor<F extends ItemFetcher> {
/**
* 該組件是否能處理 cls 類型
* @param cls
* @return
*/
boolean support(Class<F> cls);
/**
* 執行真正的數據綁定
* @param fetchers
*/
void fetch(List<F> fetchers);
}具體的實現，可以見 UserVOFetcherExecutorV2 的 support 方法：
@Override
public boolean support(Class<UserVOFetcherV2> cls) {
return UserVOFetcherV2.class.isAssignableFrom(cls);
}實現邏輯非常簡單，只是判斷 cls 是否實現了 UserVOFetcherV2 接口。
有了 FetcherExecutor 組件后，接下來就是為其提供統一的訪問入口：
@Service
public class FetcherService {
@Autowired
private List<ItemFetcherExecutor> itemFetcherExecutors;
public <F extends ItemFetcher> void fetch(Class<F> cls, List<F> fetchers){
if (CollectionUtils.isNotEmpty(fetchers)){
this.itemFetcherExecutors.stream()
// 是否能處理該類型
.filter(itemFetcherExecutor -> itemFetcherExecutor.support(cls))
// 執行真正的綁定
.forEach(itemFetcherExecutor -> itemFetcherExecutor.fetch(fetchers));
}
}
}邏輯即為簡單，依次遍歷 FetcherExecutor，根據 support 執行結果，執行 fetch 邏輯。
【小常識】Spring 可以將容器中的全部實現直接注入到 List<Bean>。在上述代碼中，將會把所有的 ItemFetcherExecutor 實現注入到 itemFetcherExecutors 屬性。因此，在新增 FetcherExecutor 時，只需將其聲明為 Spring Bean，無需調整代碼邏輯。
OK，我們有了 FetcherService 提供統一的數據綁定能力，原來 OrderServiceFetcher 中 fetch 操作的變化點轉移到 FetcherService，自身變得非常穩定。具體如下：
@Service
public class OrderServiceFetcherV2 implements OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private FetcherService fetcherService;
@Override
public List<OrderListVO> getByUserId(Long userId) {
List<Order> orders = this.orderRepository.getByUserId(userId);
List<OrderListVOFetcherV2> orderDetailVOS = orders.stream()
.map(order -> new OrderListVOFetcherV2(OrderVO.apply(order)))
.collect(toList());
// VO 數據綁定發生變化，只需調整 VO 實現接口，此處無需變化
fetcherService.fetch(OrderListVOFetcherV2.class, orderDetailVOS);
return orderDetailVOS.stream()
.collect(toList());
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
Order order = this.orderRepository.getById(orderId);
OrderDetailVOFetcherV2 orderDetail = new OrderDetailVOFetcherV2(OrderVO.apply(order));
// VO 數據綁定發生變化，只需調整 VO 實現接口，此處無需變化
fetcherService.fetch(OrderDetailVOFetcherV2.class, Arrays.asList(orderDetail));
return orderDetail;
}
}終于，我們將變化收斂到 VO 內，VO 需要綁定新的數據，只需實現對應接口即可。
4.3. 并發綁定
經過重構，代碼結構變得非常清晰，如果想通過多線程并發方式提供性能，需要調整哪些組件呢？好好想想?。?！
只需對FetcherService進行調整，讓我們來一個并發版本，具體如下：
@Service
public class ConcurrentFetcherService {
private ExecutorService executorService;
@Autowired
private List<ItemFetcherExecutor> itemFetcherExecutors;
@PostConstruct
public void init(){
this.executorService = Executors.newFixedThreadPool(20);
}
@SneakyThrows
public <F extends ItemFetcher> void fetch(Class<F> cls, List<F> fetchers){
if (CollectionUtils.isNotEmpty(fetchers)){
// 創建異步執行任務
List<Callable<Void>> callables = this.itemFetcherExecutors.stream()
.filter(itemFetcherExecutor -> itemFetcherExecutor.support(cls))
.map(itemFetcherExecutor -> (Callable<Void>) () -> {
itemFetcherExecutor.fetch(fetchers);
return null;
}).collect(Collectors.toList());
// 線程池中并行執行
this.executorService.invokeAll(callables);
}
}
}OrderServiceFetcherV3 只需使用 ConcurrentFetcherService 替代 原來的 FetcherService 并擁有了并發能力。
5. 注解方案
5.1. 復雜配置 @JoinInMemory 來幫忙
縱觀整個 Fetcher 封裝，雖然結構清晰，但細節過于繁瑣，特別是：
- 待抓取數據需要抽取 Fetcher 接口
- 需要提供自己的 FetcherExecutor 實現
- VO 需要實現多個 Fetcher 接口
這些不便將成為落地最大的阻礙，那有沒有辦法進行進一步簡化？
這需要思考下這些設計背后的深層需求：
- Fetcher接口目的包括
提供綁定信息
設置綁定結果
被 FetcherExecutor 識別并進行處理
- FetcherExecutor設計的目標包括：
- 識別待處理的 Fetcher
- 定制個性化流程
所有這些需求是否可用 ==注解== 的方式實現？
- 在 VO 屬性上增加注解，說明綁定結果寫回到該屬性上
- 注解配置來源屬性，提供綁定信息
- 注解配置流程屬性，完成 FetcherExecutor 的個性化定制
- 每個注解背后是一個 FetcherExecutor 實現，完成 FetcherExecutor 與 “Fetcher” 綁定
根據上述分析，注解可完成全部任務，新建注解如下：
@Target({ElementType.FIELD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface JoinInMemory {
/**
* 從 sourceData 中提取 key
* @return
*/
String keyFromSourceData();
/**
* 從 joinData 中提取 key
* @return
*/
String keyFromJoinData();
/**
* 批量數據抓取
* @return
*/
String loader();
/**
* 結果轉換器
* @return
*/
String joinDataConverter() default "";
/**
* 運行級別，同一級別的 join 可 并行執行
* @return
*/
int runLevel() default 10;
}乍一看，需要配置的信息真多，其實大多數配置全部與 FetcherExecutor 實現相關。
abstract class AbstractJoinItemExecutor<SOURCE_DATA, JOIN_KEY, JOIN_DATA, JOIN_RESULT> implements JoinItemExecutor<SOURCE_DATA> {
/**
* 從原始數據中生成 JoinKey
* @param data
* @return
*/
protected abstract JOIN_KEY createJoinKeyFromSourceData(SOURCE_DATA data);
/**
* 根據 JoinKey 批量獲取 JoinData
* @param joinKeys
* @return
*/
protected abstract List<JOIN_DATA> getJoinDataByJoinKeys(List<JOIN_KEY> joinKeys);
/**
* 從 JoinData 中獲取 JoinKey
* @param joinData
* @return
*/
protected abstract JOIN_KEY createJoinKeyFromJoinData(JOIN_DATA joinData);
/**
* 將 JoinData 轉換為 JoinResult
* @param joinData
* @return
*/
protected abstract JOIN_RESULT convertToResult(JOIN_DATA joinData);
/**
* 將 JoinResult 寫回至 SourceData
* @param data
* @param JoinResults
*/
protected abstract void onFound(SOURCE_DATA data, List<JOIN_RESULT> JoinResults);
/**
* 未找到對應的 JoinData
* @param data
* @param joinKey
*/
protected abstract void onNotFound(SOURCE_DATA data, JOIN_KEY joinKey);
@Override
public void execute(List<SOURCE_DATA> sourceDatas) {
// 從源數據中提取 JoinKey
List<JOIN_KEY> joinKeys = sourceDatas.stream()
.filter(Objects::nonNull)
.map(this::createJoinKeyFromSourceData)
.filter(Objects::nonNull)
.distinct()
.collect(toList());
log.debug("get join key {} from source data {}", joinKeys, sourceDatas);
// 根據 JoinKey 獲取 JoinData
List<JOIN_DATA> allJoinDatas = getJoinDataByJoinKeys(joinKeys);
log.debug("get join data {} by join key {}", allJoinDatas, joinKeys);
// 將 JoinData 以 Map 形式進行組織
Map<JOIN_KEY, List<JOIN_DATA>> joinDataMap = allJoinDatas.stream()
.filter(Objects::nonNull)
.collect(groupingBy(this::createJoinKeyFromJoinData));
log.debug("group by join key, result is {}", joinDataMap);
// 處理每一條 SourceData
for (SOURCE_DATA data : sourceDatas){
// 從 SourceData 中 獲取 JoinKey
JOIN_KEY joinKey = createJoinKeyFromSourceData(data);
if (joinKey == null){
log.warn("join key from join data {} is null", data);
continue;
}
// 根據 JoinKey 獲取 JoinData
List<JOIN_DATA> joinDatasByKey = joinDataMap.get(joinKey);
if (CollectionUtils.isNotEmpty(joinDatasByKey)){
// 獲取到 JoinData， 轉換為 JoinResult，進行數據寫回
List<JOIN_RESULT> joinResults = joinDatasByKey.stream()
.filter(Objects::nonNull)
.map(joinData -> convertToResult(joinData))
.collect(toList());
log.debug("success to convert join data {} to join result {}", joinDatasByKey, joinResults);
onFound(data, joinResults);
log.debug("success to write join result {} to source data {}", joinResults, data);
}else {
log.warn("join data lost by join key {} for source data {}", joinKey, data);
// 為獲取到 JoinData，進行 notFound 回調
onNotFound(data, joinKey);
}
}
}
}JoinInMemory 注解屬性和AbstractJoinItemExecutor基本一致，在此就不做贅述，我們先看下具體的使用方式：
@Data
public class OrderDetailVOAnnV1 extends OrderDetailVO {
private final OrderVO order;
@JoinInMemory(keyFromSourceData = "#{order.userId}",
keyFromJoinData = "#{id}",
loader = "#{@userRepository.getByIds(#root)}",
joinDataConverter = "#{T(com.geekhalo.lego.joininmemory.order.UserVO).apply(#root)}"
)
private UserVO user;
// 其他暫時忽略
}
@Data
public class OrderListVOAnnV1 extends OrderListVO {
private final OrderVO order;
@JoinInMemory(keyFromSourceData = "#{order.userId}",
keyFromJoinData = "#{id}",
loader = "#{@userRepository.getByIds(#root)}",
joinDataConverter = "#{T(com.geekhalo.lego.joininmemory.order.UserVO).apply(#root)}"
)
private UserVO user;
// 其他暫時忽略
}我們以 UserVO user 屬性為例
屬性 | 含義 |
keyFromSourceData = "#{order.userId}" | 以屬性 order 中的 userId 作為 JoinKey |
keyFromJoinData = "#{id}" | 以 user 的 id 作為 JoinKey |
loader = "#{@userRepository.getByIds(#root)}" | 將 userRepository bean 的 getByIds 方法作為加載器，其中 #root 為 joinKey 集合（user id 集合） |
joinDataConverter = "#{T(com.geekhalo.lego.joininmemory.order.UserVO).apply(#root)}" | 將 com.geekhalo.lego.joininmemory.order.UserVO 靜態方法 apply 作為轉換器，#root 指的是 User 對象 |
@JoinInMemory 注解中大量使用 SpEL，不熟悉的伙伴可以自行網上進行檢索。
其他部分不變，定義 OrderService 如下：
@Service
public class OrderServiceAnnV1 implements OrderService {
@Autowired
private OrderRepository orderRepository;
@Autowired
private JoinService joinService;
@Override
public List<OrderListVO> getByUserId(Long userId) {
List<Order> orders = this.orderRepository.getByUserId(userId);
List<OrderListVOAnnV1> orderDetailVOS = orders.stream()
.map(order -> new OrderListVOAnnV1(OrderVO.apply(order)))
.collect(toList());
this.joinService.joinInMemory(OrderListVOAnnV1.class, orderDetailVOS);
return orderDetailVOS.stream()
.collect(toList());
}
@Override
public OrderDetailVO getDetailByOrderId(Long orderId) {
Order order = this.orderRepository.getById(orderId);
OrderDetailVOAnnV1 orderDetail = new OrderDetailVOAnnV1(OrderVO.apply(order));
this.joinService.joinInMemory(OrderDetailVOAnnV1.class, Arrays.asList(orderDetail));
return orderDetail;
}
}相對于 Fetcher 抽象，我們將 Fetcher、FetcherExecutor 全部配置化，并通過 注解的方式進行呈現，相對于 Coding 方案，注解方案更加靈活，工作量也更小。
5.2. 復雜配置 @Alias 來幫忙
相對于 Fetcher 封裝，一個 @JoinInMemory 成功干掉了兩個組件，但觀其自身配置起來還是非常繁瑣。比如，在訂單查詢這個場景，在 OrderListVO 和 OrderDetailVO 中都需要對 UserVO 進行數據綁定，觀察兩個注解，我們會發現很多重復配置：
//OrderListVO
@JoinInMemory(keyFromSourceData = "#{order.userId}",
keyFromJoinData = "#{id}",
loader = "#{@userRepository.getByIds(#root)}",
joinDataConverter = "#{T(com.geekhalo.lego.joininmemory.order.UserVO).apply(#root)}"
)
private UserVO user;
// OrderDetailVO
@JoinInMemory(keyFromSourceData = "#{order.userId}",
keyFromJoinData = "#{id}",
loader = "#{@userRepository.getByIds(#root)}",
joinDataConverter = "#{T(com.geekhalo.lego.joininmemory.order.UserVO).apply(#root)}"
)
private UserVO user;兩個配置完全一樣，細品之后會發現：
- 【變化】入參變化，讀取的屬性不同，只是本次恰巧相同而已
OrderListVO 指的是 OrderListVO 屬性 order 的id值
OrderDetailVO 指的是 OrderDetailVO 屬性 order 的值
- 【不變】處理邏輯不變
- keyFromJoinData 指的是 user對象的 id
- loader 指的是通過 userRepository 的 getByIds 加載數據
- joinDataConverter 指的是將 user 轉換為 UserVO
- 【不變】
- 將綁定結果 UserVO 綁定到屬性上（屬性名不同沒有影響）
對于不變部分如何進行統一管理？
自定義注解 結合 Spring @AliasFor 便可以解決這個問題，以 UserVO 為例：
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
// 管理通用屬性
@JoinInMemory(keyFromSourceData = "",
keyFromJoinData = "#{id}",
loader = "#{@userRepository.getByIds(#root)}",
joinDataConverter = "#{T(com.geekhalo.lego.joininmemory.order.UserVO).apply(#root)}"
)
public @interface JoinUserVOOnId {
// 使用別名將 keyFromSourceData 的配置暴露出來
@AliasFor(
annotation = JoinInMemory.class
)
String keyFromSourceData();
}新注解有如下幾個特點：
- 在注解上使用 @JoinInMemory 注解完成對通用屬性的配置
- 在自定義注解 JoinUserVOOnId 的 keyFromSourceData 屬性上，添加 @AliasFor 注解，將配置暴露給使用方
有了自定義注解，使用變的非常方便：
@Data
public class OrderListVOAnnV2 extends OrderListVO {
private final OrderVO order;
// 只需配置參數即可，其他配置由 JoinUserVOOnId 進行管理
@JoinUserVOOnId(keyFromSourceData = "#{order.userId}")
private UserVO user;
}
@Data
public class OrderDetailVOAnnV2 extends OrderDetailVO {
private final OrderVO order;
// 只需配置參數即可，其他配置由 JoinUserVOOnId 進行管理
@JoinUserVOOnId(keyFromSourceData = "#{order.userId}")
private UserVO user;
}其他使用方式不變，但實現了邏輯簡化：
- 新增綁定數據，只需自定義綁定注解
- VO 需新的綁定數據，只需在屬性上添加綁定注解
5.3. 開啟并發 @JoinInMemoryConfig 來幫忙
如果擔心性能，可以一鍵開啟并發綁定，示例如下：
@Data
@JoinInMemoryConfig(executorType = JoinInMemeoryExecutorType.PARALLEL)
public class OrderListVOAnnV3 extends OrderListVO {
private final OrderVO order;
@JoinUserVOOnId(keyFromSourceData = "#{order.userId}")
private UserVO user;
@JoinAddressVOOnId(keyFromSourceData = "#{order.addressId}")
private AddressVO address;
@JoinProductVOOnId(keyFromSourceData = "#{order.productId}")
private ProductVO product;
}JoinInMemoryConfig 配置如下：
屬性 | 含義 |
executorType | PARALLEL 并行執行；SERIAL 串行執行 |
executorName | 執行器名稱，并行執行所使用的線程池名稱，默認為 defaultExecutor |
6. 最佳實踐
6.1.將定義注解視為最佳實踐
@JoinInMemory 注解上配置的信息太多，如果直接在業務代碼中使用，非常難以維護，當每個配置發生變化后，很難一次性修改到位。所以，建議只將他作為“原注解”使用。
整體思路詳見：
圖片
6.2. 注意線程池隔離
對于不同的數據綁定需求，建議使用不同的線程池，從資源層面對不同功能進行隔離，從而將由于依賴接口發生阻塞導致線程耗盡所造成的影響控制在最小范圍。
@JoinInMemoryConfig 的 executorName 屬性配置的便是執行器名稱，不配置直接使用 “defaultExecutor”，具體代碼如下：
@Bean
public ExecutorService defaultExecutor(){
BasicThreadFactory basicThreadFactory = new BasicThreadFactory.Builder()
.namingPattern("JoinInMemory-Thread-%d")
.daemon(true)
.build();
int maxSize = Runtime.getRuntime().availableProcessors() * 3;
return new ThreadPoolExecutor(0, maxSize,
60L, TimeUnit.SECONDS,
new SynchronousQueue<>(),
basicThreadFactory,
new ThreadPoolExecutor.CallerRunsPolicy());
}如需使用自定義線程池需：
- 自定義線程池，并將其注冊到Spring 容器
- @JoinInMemoryConfig executorName 設置為線程池的 bean name
7. 小結
推導邏輯有點長不知道你get到多少，先簡單回顧一下：
- 今天面對的問題是：如何在應用成進行數據 Join 操作；
- 我們以我的訂單和訂單詳情兩個接口為業務切入點，層層進行抽象，發現變化、封裝變化、管理變化
- 首先是手寫代碼，包括 foreach+單條抓取，批量查詢+內存Join，并行查詢 + 內存Join。在這個層次基本沒有抽象可言，存在大量重復代碼，系統擴展性低
- 其次是 Fetcher方案，為了分離“變化”與“不變”抽取出 Fetcher 和 FetcherExecutor 兩個接口，并使用模板方法和責任鏈模式對其進行抽象，提升系統的擴展性，但實現過于繁瑣不便于推廣
- 最后是注解方案，使用 @JoinInMemory 注解完成繁瑣的配置工作，將通用配置保留在自定義注解進行統一管理，基于 @AliasFor 完成入參的配置，還可以使用 @JoinInMemoryConfig 開啟并發處理
不知道你有什么感觸，接下來，有什么計劃？
- 沒有改變，習慣怎么做就怎么做？
- 將 JoinInMemory 引入到自己的工程？
- 嘗試發現項目中的“變化”和“不變”，嘗試自己封裝，增加抽象能力？
責任編輯：武曉燕
來源：
geekhalo
