一、背景
在電商平臺上，二八定律尤為明顯，20%的高價值商家往往創造了80%以上的銷售額。而這些商家通常擁有大量的訂單、商品、出價等管理需求，推動了他們對批次操作功能的迫切需求。批次操作能夠幫助這些商家高效地處理商品資訊、庫存和訂單管理，顯著提升運營效率。
透過批次操作，商戶可以在短時間內對多個產品進行修改，如統一調價、調整促銷策略等，從而快速響應市場變化，最佳化使用者體驗。此外，批次操作還降低了人工出錯的風險，確保了資料的一致性，讓商家能夠更加專注於戰略規劃和客戶關係管理。總之，對於這些商戶而言，批次操作不僅是提升管理效率的關鍵工具，也是實現業務增長的重要保障。
在得物的商家後臺中，商家的所有批次操作都承載在批處理系統（批處理中心），商家可以透過在功能頁面操作批次匯入或是批次匯出來完成批次操作。操作後的檔案將展示在下載中心。
此外，批處理中心還維護了交易後臺、客服、匯金、門店等多個域的批次操作任務。截止目前，批處理中心維護了十個域的上千種批次任務，日均處理數萬個相關任務，數億條相關資料。
隨著得物體量的不斷上升，批處理系統也在不斷演進。簡單來說，批處理系統經歷了從分散到耦合、再到集中與隔離的多個發展階段。接下來，我們以批處理的開發者小王的視角，介紹批處理系統的這三種設計，並探討它們各自的特點與適用場景。
二、集中式：流程擴充套件
假設小王接到了一個批次操作的需求，要求在商家後臺能進行批次出價。需求很簡單，小王僅用時兩天半就完成了基本流程的搭建。
業務上線後，商家反饋非常好，產品要求立刻上線一個批次修改出價的需求。於是小王照葫蘆畫瓢寫又寫了一條流程。
兩條几乎一樣的流程，有程式碼潔癖的小王表示無法接受。經過分析後，小王發現，不管是什麼匯入流程，有些步驟總是固定的，因此決定程式碼複用。
程式碼複用後，出價和修改之間只有格式校驗和業務邏輯不同。其餘的檔案下載、內容解析、結果儲存和上傳均使用相同的節點。既然各個業務之間的差異主要集中在資料處理，小王決定直接將其開成擴充套件點。不同的業務場景只需要實現各自的資料處理擴充套件，就能無縫接入批處理流程。業務擴充套件的示意圖如下：
在具體實現的時候，小王在程式碼裡面透過業務身份來進行擴充套件點的選擇，可以建立一個相關的工廠類進行。
@Component
public class BpcProcessHandlerFactory {
@Autowired
private ApplicationContext applicationContext;
private static ConcurrentHashMap<String, BpcProcessDefine> templateMap = new ConcurrentHashMap<>();
@PostConstruct
private void init() {
Map<String, ImportService> importServiceMap = applicationContext.getBeansOfType(ImportService.class);
for (ImportService importService : importServiceMap.values()) {
initImportService(importService);
}
}
private void initImportService(ImportService importService) {
// ...
}
public BpcProcessHandler getBpcProcessHandler(String templateCode) {
if (StringUtils.isBlank(templateCode)) {
return null;
}
if(!templateMap.containsKey(templateCode)) {
return null;
}
return templateMap.get(templateCode).newProcessHandler();
}
}對於匯入的任務處理，簡化的程式碼流程如下：
@Service
public class BpcProcessService {
@Autowired
private BpcProcessHandlerFactory bpcProcessHandlerFactory;
public String doBpcProcess(BpcProcessReq req) throws BpcProcessException {
// 獲取擴充套件點
BpcProcessHandler bpcProcessHandler = bpcProcessHandlerFactory.getBpcProcessHandler(req.getTaskTemplateCode());
if (bpcProcessHandler == null) {
throw new BpcProcessException("找不到模版定義");
}
// 1. 建立任務
createTask();
// 2. 檔案下載 && 檔案儲存
downloadFromOss();
// 3. 資料解析
int loopCnt = 0;
int maxLoopCnt = bpcProcessHandler.getMaxLoopCnt();
while(loopCnt++ < maxLoopCnt) {
// 呼叫擴充套件點處理
bpcProcessHandler.process();
// 更新任務
updateTaskProcess();
}
// 更新任務
updateTaskStatus();
return taskId;
}
}在完成了流程擴充套件點後，小王心想，這下可算是高枕無憂了。後續有新的匯入場景，只需要實現自己的校驗邏輯和處理邏輯即可。
但是好景不長，隨著商家體量的增長，小王發現對接的業務越來越多了；先是出價、再是商品然後是其他逆向、服務費的批次服務，小王一個人實在是寫不過來了，只能讓各個業務的開發到批處理系統開發自己的業務。各個人的編碼習慣不一樣，批處理系統對接的Jar也越來越多，系統已經變成了一個大雜燴。
怎麼才能改變這個現狀呢？
三、平臺化：配置註冊
在集中式架構中：所有的業務處理流程是共用的，不同的業務透過實現各自的擴充套件點來完成各個業務的邏輯。這帶來了一個最明顯的問題，即系統的邊界模糊，業務耦合重。
這個擴充套件點能不能寫在外部呢？
小王靈光一現：SPI不就可以嗎。Java的SPI機制能幫助我們獲取各個業務的實現，因此批處理系統只需要基於SPI抽象出一套核心的匯入/匯出流程即可。由於各個業務要能準確找到SPI，還需要加入一定業務配置能力。
和集中式架構對比，配置化方案的可擴充套件性更強，但是也不可避免的帶來了一個缺點：開發人員需要去建立配置。
而批處理配置至少需要包含以下內容：
- Excel格式。
- 流程呼叫的SPI資訊。
- 資料物件和Excel欄位之間的對映關係。
其中欄位的對映關係和SPI等資訊的維護成本較高，為了減輕開發人員的工作量，小王還維護了一個IDEA外掛。用於一鍵上傳配置。
後端開發人員可以僅透過註解的方法一鍵上報自身的配置，大大減輕了業務的配置上傳的工作量。
同步執行-通用配置處理
在建立完配置後，可以利用dubbo的泛化呼叫來執行各個SPI的實現：
@Override
public String invoke(ServiceDefinition serviceDefinition, Object inputParam) {
GenericService genericService = DubboConfig.buildService(serviceDefinition.getInterfaceName(), serviceDefinition.getTimeout());
//引數list轉換處理，由請求引數key轉換成內部引數
String[] parameterTypes = new String[] {serviceDefinition.getRequestType().getClassName()};
Object[] args = new Object[] {inputParam};
long startTime = System.currentTimeMillis();
Object result;
try {
log.info("invoke service={}#{} with request={}", serviceDefinition.getInterfaceName(), serviceDefinition.getMethod(), JSON.toJSONString(args));
result = genericService.$invoke(serviceDefinition.getMethod(), parameterTypes, args);
long endTime = System.currentTimeMillis();
digestLog(serviceDefinition, true, endTime - startTime);
log.info("invoke service={}#{} with result={}", serviceDefinition.getInterfaceName(), serviceDefinition.getMethod(), JSON.toJSONString(result));
} catch (Exception ex) {
long endTime = System.currentTimeMillis();
digestLog(serviceDefinition, false, endTime - startTime);
log.info("failed to dubbo invoke：" + serviceDefinition.getInterfaceName() + "#" +serviceDefinition.getMethod() + " with error " + ex.getMessage());
throw new DependencyException(ErrorCodeEnum.DEFAULT_DEPENDENCY_ERROR.getCode(), ex.getMessage(), ex);
}
if (result == null) {
throw new DependencyException(ErrorCodeEnum.DEFAULT_BIZ_ERROR.getCode(), "the result is null");
}
Map resultMap = JSON.parseObject(JSON.toJSONString(result), Map.class);
processError(resultMap);
Object data = resultMap.get("data");
return JSON.toJSONString(data);
}簡化版的執行流程如下所示：
@Service
public class BpcProcessService {
@Autowired
private BpcProcessHandlerFactory bpcProcessHandlerFactory;
public String doBpcProcess(BpcProcessReq req) throws BpcProcessException {
// 1. 獲取配置
TaskTemplate template = getTemplate();
// 2. 建立任務
Task task = createTask();
// 3. 檔案下載 && 檔案儲存
downloadFromOss();
// 4. 資料解析
int loopCnt = 0;
int maxLoopCnt = template.getMaxLoopCnt();
while(loopCnt++ < maxLoopCnt) {
// 呼叫SPI處理
invoke(template, task)
// 更新任務
updateTaskProcess();
}
// 更新任務
updateTaskStatus();
return taskId;
}
}可以看到配置化後的執行策略和之前流程擴充套件的執行策略是類似的，主要的變化就是從呼叫本地擴充套件點，切換成了呼叫配置後的SPI。
排程執行-業務針對調整
配置化完成之後，小王鬆了一口氣，這下系統總算是乾淨了。業務的歸業務，流程的歸流程，兩者互不打擾。然而凡事總不順利、沒過多久批處理系統就出了一次冒煙。簡單來說，這次冒煙是由於批處理系統同時處理了大量任務導致的記憶體溢位。
針對這次冒煙，小王仔細分析系統資料後發現，商家下載中心的業務有著自己的業務特點：
- 不同任務之間的數量差異巨大（如，運營任務和商家任務的差距）；
- 商家操作的流量時間上分佈不均，大部分商家操作集中在剛上班(10點左右)和快下班(17點左右)；
- 任務流量在商家上分佈不均，重點商家會建立大量任務。
以下是小王分析的部分資料來源圖：
- 任務流量分佈不均，下面是各個任務型別的執行統計，其中不同顏色代表不同型別的任務。
- 時間流量分佈不均，下面是匯入匯出任務流量的時間分佈
- 商家流量分佈不均
這些特點在批處理系統中表現為：
- 系統穩定性風險高，出現過一次線上冒煙。因為系統資源是有限的，高峰期的大流量任務可能會佔用過多系統記憶體，導致OOM。
- 商家體驗得不到保證，運營操作可能會導致商家長時間等待。
不就是資源導致的風險嗎，小王覺得這是小case 了，加個限流就搞定了，然後就對建立任務加上了限流。結果上線後情況不僅沒有好轉，還因為限流“誤殺”了好多比較重要的匯入任務，經過分析後小王終於找到了原因。在商家下載中心的業務中，限流並不能滿足資源保護訴求。這實際上是由系統本身的內部架構決定的、因為批處理在大部分情況下是一個低CPU高記憶體佔用的系統。如果對任務的提交進行限流，一方面容易誤傷核心的訂單/出價任務，另一個方面忽略了高耗時任務的影響。如下圖所示：
- 運營任務"恰好"佔用了流控的視窗，導致後續提交的商家任務都被限流。
- 長耗時任務會跨越多個時間視窗，導致限流不生效。
不能限流，那隻能自己來了。只要把一切都拿到手裡，任務啥時候執行不就是自己說了算了嘛。於是小王打算轉變身份，從被動式執行到主動式排程。換言之，就是從同步流程切換成非同步排程流程，由系統自己來解決資源的分配，並對業務進行隔離。小王很快畫好了自己的核心流程。
流程很簡單，建立任務的時候不再直接執行，而是等待系統排程後執行。然而小王在排程和隔離這裡又犯了難，這倆該怎麼做呢？
業務隔離
隔離主要分為兩大類，物理隔離和邏輯隔離。
物理隔離：不同的機器執行不同業務的排程。
- 叢集隔離：類似於應用釋出時的藍綠叢集，我們可以把叢集分為核心叢集+非核心叢集，用核心叢集來保障商家訂單，出價等相關動作的穩定性，用非核心叢集來保障其他鏈路；
- 機器隔離：機器隔離相較於叢集隔離，其粒度更小。透過指定IP來控制不同業務之間的排程；
邏輯隔離：透過使用不同執行緒池的方式來完成業務的隔離。
凡事先易後難，小王決定先採用簡單的方式來對業務進行隔離，執行緒池的方式已經能分離開可能造成資損的任務和不會造成資損的任務了。在排程方面，小王列舉了業內常見的帶優先順序的排程方法
任務排程
1.優先佇列：利用執行緒池的等待佇列來完成優先順序的排程。
優點：程式碼簡單，易維護，只需要維護一個優先順序佇列即可。
缺點：需要額外增加一個狀態來代表等待排程，有飢餓問題，存在一定穩定性風險，因為對執行緒池的等待佇列缺少管控手段。
2.老化策略：利用老化策略，動態提升任務優先順序。
優點：較大程度上避免飢餓問題，優先順序的可擴充套件性高，對任務的管控能力強，狀態機侵入少。
缺點：需要考慮併發問題，程式碼較複雜。
3.多級佇列：利用多級佇列來完成任務優先順序。
優點：較大程度上避免飢餓問題，程式碼較為簡潔，任務管控能力強，狀態機改動少。
缺點：任務優先順序可擴充套件性較差，如果新增一個優先順序需要改動排程程式碼，沒有高優任務時，系統吞吐性較差。
綜合以上各種方案後，小王最終採用了多級佇列 + 執行緒隔離的方式來進行任務的排程。在排程的具體實現上，採用定時任務來進行流程的觸發。
此外，為了支援大任務量場景臨時增加系統吞吐，小王還增加了分片的能力，透過接受分片引數，每臺機器只取自己的分片。簡化版本的程式碼如下：
@Service
@Slf4j
public class TaskScheduleServiceImpl implements TaskScheduleService {
@Override
@LogAnnotation
public void schedule(int shared, int all) {
StopWatch stopWatch = new StopWatch();
stopWatch.start();
// 丟執行緒池執行
List<Long> highTaskIds = taskInstanceRepository.queryUnstartedTaskIdByPriority(TaskPriorityEnum.HIGH, all * arkConfig.highSize);
highTaskIds = highTaskIds.stream().filter((id) -> id % all == shared).collect(Collectors.toList());
log.info("優先順序排程任務，待執行高優任務 Ids = {}", highTaskIds);
process(highTaskIds, (id) -> taskThreadPool.executeHigh(() -> process(id)));
// 丟執行緒池執行
List<Long> mediumTaskIds = taskInstanceRepository.queryUnstartedTaskIdByPriority(TaskPriorityEnum.MEDIUM, all * arkConfig.mediumSize);
mediumTaskIds = mediumTaskIds.stream().filter((id) -> id % all == shared).collect(Collectors.toList());
log.info("優先順序排程任務，待執行中優任務 Ids = {}", mediumTaskIds);
process(mediumTaskIds, (id) -> taskThreadPool.executeMedium(() -> process(id)));
// 丟執行緒池執行
List<Long> lowTaskIds = taskInstanceRepository.queryUnstartedTaskIdByPriority(TaskPriorityEnum.LOW, all * arkConfig.lowSize);
lowTaskIds = lowTaskIds.stream().filter((id) -> id % all == shared).collect(Collectors.toList());
log.info("優先順序排程任務，待執行低優任務 Ids = {}", lowTaskIds);
process(lowTaskIds, (id) -> taskThreadPool.executeLow(() -> process(id)));
log.info("優先順序排程任務，執行完畢, cost = {}", stopWatch.getTime());
}
private void process(List<Long> idList, Consumer<Long> consumer) {
if (CollectionUtils.isEmpty(idList)) {
return;
}
for (Long id : idList) {
consumer.accept(id);
}
}
private void process(Long id) {
// 任務處理邏輯。。。
}
}幹完了這些事後，小王突然想起來，測試環境還需要走染色呢。
於是又在排程上增加了染色環境的路由。
這回總算是徹底解決了系統的穩定性問題了，以後系統存在吞吐風險時，只需要動態調整召回數量就好了。
四、本地化：任務上報
作為上面的一切後，小王開啟了APM的監控，發現系統的記憶體佔用還是很高。明明覆雜的業務流程都放到外面了，為啥效能還是一般呢？
小王思考了現在批處理存在的缺點：
- 配置維護成本高、業務需要上報SPI資訊和對映關係，且配置完成後更改風險高。
- 全域性資源利用率低，一份業務資料在多個系統都需要佔用記憶體。
- 排程的隔離是基於執行緒池or物理機器，粒度較粗，無法完全避免業務之間的互相干擾。
此外，還有一個令他最難受的問題，就是業務諮詢很多。很多業務雖然對接了他的系統，但是在執行失敗時他們經常找不到錯誤原因，需要小王配合排查。如何解決這幾個問題呢？
小王決定返璞歸真，迴歸本源。批處理中心是為了解決商家批次匯入匯出的問題而生的，其產生的主要目的在於幫助業務平臺減少檔案解析、檔案生成、檔案上傳、頁面展示的成本。
這些問題一定需要一個系統來支援嗎？檔案解析和生成實際上是用EasyExcel的SDK完成的，檔案上傳是用Oss的SDK完成的，還有一個頁面展示的功能是一個非常輕量的邏輯。換言之，完全可以在業務系統把前幾件事都做了。構建一個批處理外掛來完成批處理中心的大部分能力，批處理系統僅作為展示使用。小王產生了一個新的想法：把邏輯放到批處理SDK中去，批處理僅維護一兩臺機器用於承載展示邏輯即可。
整體的架構設計如下圖所示：
在本地化的思路下：批處理中心類似於一箇中心節點，各個業務系統作為其的葉子節點，只需要定時上報任務相關情況即可。批處理系統只負責頁面的展示，和業務完全解耦。
本地化帶來了以下幾個明顯的好處：
- 效率高，不再需要跨系統之間的邏輯呼叫，既能節約系統資源，又能減少網路傳輸時間。
- 維護成本低，業務方可隨時調整業務對映，批處理只需要維護極小的配置(模版和對應的展示名稱、展示地方)。
- 迭代升級容易，平臺化的改造由於影響面比較大，風險高。而SDK的升級是單應用升級的，因此影響小，風險可控。
- 流程擴充套件相對簡單，SDK可以提供相對較多的鉤子函式。
當然，凡事沒有銀彈。本地化也不可避免帶來了一些缺點：
- 業務需要維護部分配置，這其中主要是一些oss相關的配置。
本地化後，批處理中心不需要維護業務邏輯、也不需要任務排程、任務的隔離粒度最細。小王總算是能安心睡個好覺了。
五、總結
上面我們以一個批處理系統普通開發者的視角，迴歸了商家批處理系統發展的三個階段(本地化正在進行中)。這三個階段，體現了從厚到薄、從業務耦合到業務隔離的演進過程。從本地到平臺再到本地，頗有種天下大勢，分久必合合久必分的感覺。這三種方式並沒有絕對的優劣之分，而是隨著業務需求的變化而逐步演化的。
在初始階段，系統功能較少，通常只有一兩個簡單的匯入匯出功能，此時使用流程擴充套件是最輕量、最靈活的選擇，能夠快速滿足商家的基本需求。隨著業務量的增長，系統之間的隔離性變得越來越重要，這時引入配置註冊成為必要措施，以確保不同模組之間的自主性和穩定性。
進一步發展後，平臺化改造的初步實現通常採用同步呼叫方式，但隨之而來的穩定性要求推動了非同步排程的引入。然而，到了後期，即使是非同步排程也可能面臨系統吞吐量不足的問題。因此，業務系統本地執行狀態上報的模式逐漸成為更優的選擇，能夠有效提升系統的響應速度和處理能力。
隨著業務的不斷髮展，商家的批處理系統必然會進行更新與迭代，以適應新的需求和挑戰。系統設計沒有銀彈，所有設計的迭代實際上就是開發人員遇見問題、解決問題的能力體現。
*文/稚歸
本文屬得物技術原創，更多精彩文章請看：得物技術
未經得物技術許可嚴禁轉載，否則依法追究法律責任！