一、前言

本文討論的自動(dòng)化，是指通過代碼的方式，將原本人工完成的相關(guān)操作由機(jī)器代為處理，如此達(dá)到釋放人力和提升效率等目標(biāo)。

然而實(shí)現(xiàn)自動(dòng)化的過程不總是那么順利，自動(dòng)化后的效果未必那么理想。可能有的團(tuán)隊(duì)會(huì)發(fā)現(xiàn)自動(dòng)化腳本盡管釋放了業(yè)務(wù)人員，但成本卻轉(zhuǎn)移到開發(fā)人員身上。他們需要投入大量時(shí)間去更新失效的自動(dòng)化邏輯，出現(xiàn)問題后的排障時(shí)間和難度也隨之增加。如果自動(dòng)化任務(wù)的成功率低、問題修復(fù)速度慢，那么大量的工作將不得不降級為人工處理，自動(dòng)化的業(yè)務(wù)價(jià)值無從體現(xiàn)。

我們發(fā)現(xiàn)，通過完善自動(dòng)化任務(wù)的相關(guān)基建（包括任務(wù)調(diào)度引擎和任務(wù)管理平臺等），上述問題可以得到顯著的控制和緩解。本文將分享攜程旅游研發(fā)在這方面的嘗試和經(jīng)驗(yàn)，希望能為其他開發(fā)者和團(tuán)隊(duì)提供參考。

二、平臺背景

旅游內(nèi)部不少業(yè)務(wù)都有自動(dòng)化需求，部分團(tuán)隊(duì)已經(jīng)上線了自己的自動(dòng)化項(xiàng)目，這些項(xiàng)目由不同的團(tuán)隊(duì)維護(hù)，但均有相似的痛點(diǎn)：

• 無法及時(shí)關(guān)閉自動(dòng)化任務(wù)：由于缺乏有效的控制手段，自動(dòng)化任務(wù)一旦重啟就難以中斷。
• 排障效率低下：目前大部分自動(dòng)化任務(wù)是前端自動(dòng)化任務(wù)，前端由于站點(diǎn)更新、網(wǎng)絡(luò)波動(dòng)、代理異常等常見原因?qū)е氯蝿?wù)無法完成，出錯(cuò)的原因很雜，不能復(fù)現(xiàn)場景，難以查找根因。
• 日志查找困難：現(xiàn)有的日志系統(tǒng)以時(shí)間為錨點(diǎn)記錄日志，沒有劃分任務(wù)的邊界。一次自動(dòng)化任務(wù)產(chǎn)生的日志通常是一個(gè)普通請求的2到5倍，需要從大量連續(xù)的任務(wù)執(zhí)行日志中找到需要的信息，并且隨著任務(wù)增加，存儲(chǔ)的日志的文件數(shù)量也隨之增長，查找變得更加困難。
• 復(fù)現(xiàn)困難：任務(wù)的入?yún)⑼ǔ：腿罩救岷驮谝黄?，?dǎo)致復(fù)現(xiàn)問題時(shí)難以分析。
• 日志沒有權(quán)限限制：任何人都可以查看日志，可能導(dǎo)致敏感信息泄露。

三、平臺目標(biāo)

為了解決自動(dòng)化的共性問題，減少重復(fù)開發(fā)，我們希望通過創(chuàng)建一個(gè)統(tǒng)一的平臺來提升自動(dòng)化效率和可靠性，具體目標(biāo)如下：

• 提高排錯(cuò)效率：通過詳細(xì)的日志記錄和輔助工具，低成本快速還原任務(wù)場景，便于快速定位和復(fù)現(xiàn)。
• 被動(dòng)感知任務(wù)異常：建立實(shí)時(shí)監(jiān)控和通知機(jī)制，實(shí)時(shí)檢測并推送任務(wù)異常信息，減少人為監(jiān)控負(fù)擔(dān)，完全釋放人力。
• 聚焦業(yè)務(wù)本身：讓開發(fā)者專注于核心業(yè)務(wù)邏輯，不必?fù)?dān)心自動(dòng)化過程中可能出現(xiàn)的性能問題，通過平臺提供的工具確保自動(dòng)化任務(wù)高效、穩(wěn)定地運(yùn)行。

基于以上目標(biāo)，我們設(shè)計(jì)開發(fā)出前端自動(dòng)化任務(wù)平臺TaskHub，一個(gè)能夠幫助自動(dòng)化提效的解決方案。

四、TaskHub介紹

在TaskHub中，我們把自動(dòng)化腳本的執(zhí)行，稱為任務(wù)。

任務(wù)是無狀態(tài)的，任務(wù)與任務(wù)之間沒有直接關(guān)系。任務(wù)的設(shè)計(jì)目標(biāo)是實(shí)現(xiàn)某一特定的自動(dòng)化功能。

在自動(dòng)化過程中，核心是確保任務(wù)的正確執(zhí)行。任務(wù)執(zhí)行過程中產(chǎn)生的副作用不應(yīng)阻礙任務(wù)的執(zhí)行。因此，我們將TaskHub主要分為兩個(gè)部分：平臺和引擎。平臺用于記錄和管理任務(wù)執(zhí)行過程中的產(chǎn)物，而引擎專門負(fù)責(zé)任務(wù)的執(zhí)行。

平臺：可以方便查看、配置、中斷任務(wù)。

引擎：負(fù)責(zé)調(diào)度任務(wù)執(zhí)行，是任務(wù)執(zhí)行的核心。

整體設(shè)計(jì)：

引擎通過NPM的方式安裝，以 SDK 的方式運(yùn)行在項(xiàng)目中。這樣做有以下幾個(gè)好處：

1）引擎和平臺完全解耦。即使平臺不可用也不影響任務(wù)運(yùn)行，確保任務(wù)高可用。

2）靈活部署?，F(xiàn)有自動(dòng)化業(yè)務(wù)不會(huì)因?yàn)榻尤?TaskHub 改變原來的部署方式，業(yè)務(wù)可根據(jù)自身需求按需部署。

接下來分別介紹下平臺和引擎。

4.1 TaskHub平臺

平臺包含三個(gè)主要模塊：項(xiàng)目、任務(wù)和日志。它們之間是一對多的關(guān)系：一個(gè)項(xiàng)目包含多個(gè)任務(wù)，一個(gè)任務(wù)包含多條日志。每個(gè)模塊都有嚴(yán)格的權(quán)限校驗(yàn)，確保數(shù)據(jù)安全和訪問控制。

• 項(xiàng)目模塊：項(xiàng)目是任務(wù)的集合。它包含項(xiàng)目的基本信息，并負(fù)責(zé)管理項(xiàng)目成員和權(quán)限，為同一類任務(wù)做統(tǒng)一配置。
• 任務(wù)模塊：包含任務(wù)的輸入、輸出、運(yùn)行時(shí)間等信息。任務(wù)流程被結(jié)構(gòu)化展示，使任務(wù)的輸入和輸出更加清晰，降低復(fù)現(xiàn)難度，提高排錯(cuò)效率。
• 日志模塊：記錄任務(wù)運(yùn)行的所有日志，分為業(yè)務(wù)日志和系統(tǒng)日志兩個(gè)子模塊，方便快速切換和篩查。除了傳統(tǒng)的文字日志，TaskHub還支持圖片日志。如果在自動(dòng)化過程中遇到意外錯(cuò)誤，可以截圖記錄錯(cuò)誤頁面，留下錯(cuò)誤快照，方便后期排查時(shí)快速了解錯(cuò)誤發(fā)生的場景。

4.2 TaskHub引擎

TaskHub 引擎的核心是調(diào)度執(zhí)行用戶的腳本。用戶只需編寫任務(wù)的 .ts 文件，引擎會(huì)為每個(gè)任務(wù)分配一個(gè)獨(dú)立的 Node 子進(jìn)程，每個(gè)任務(wù)都在自己的子進(jìn)程中運(yùn)行。

這樣設(shè)計(jì)有以下幾個(gè)好處：

1）數(shù)據(jù)隔離。借助進(jìn)程數(shù)據(jù)隔離的特性，無成本實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)的隔離，帶來了數(shù)據(jù)的安全性。

2）任務(wù)易清理。任務(wù)執(zhí)行完成時(shí)，使用 process.exit()退出子進(jìn)程即可釋放資源和依賴。此前度假部分自動(dòng)化任務(wù)的方案在釋放資源時(shí)有較重的心智負(fù)擔(dān)，需仔細(xì)編排以避免影響其他任務(wù)。

3）任務(wù)可遠(yuǎn)程關(guān)閉。度假部分自動(dòng)化場景有中斷執(zhí)行的需求，獨(dú)立的子進(jìn)程使得中斷更簡單，直接對子進(jìn)程進(jìn)行操作即可。

4.2.1 如何初始化項(xiàng)目

在 TaskHub平臺 注冊一個(gè)新項(xiàng)目后，使用 TaskHub SDK 提供的 engine 對象來初始化 TaskHub引擎。只需將項(xiàng)目ID傳入 engine.initProject 方法，引擎就會(huì)與 TaskHub平臺 上的項(xiàng)目進(jìn)行綁定。這樣，后續(xù)的任務(wù)日志、狀態(tài)等信息就會(huì)與相應(yīng)的項(xiàng)目關(guān)聯(lián)起來。

初始化引擎代碼示意如下：

接下來，通過調(diào)用 project 的 addTask 方法，即可啟動(dòng)任務(wù)，引擎內(nèi)部會(huì)使用子進(jìn)程運(yùn)行用戶的腳本。

以上就是運(yùn)行TaskHub自動(dòng)化任務(wù)的核心代碼。

4.2.2 引擎內(nèi)部設(shè)計(jì)

在 TaskHub 引擎中，每當(dāng)一個(gè)新任務(wù)啟動(dòng)時(shí)，引擎會(huì)創(chuàng)建一個(gè)新的子進(jìn)程，并在子進(jìn)程中運(yùn)行任務(wù)，如下圖所示：

在簡單的自動(dòng)化場景中，通過主進(jìn)程啟動(dòng)任務(wù)可以滿足大多數(shù)需求。然而，在復(fù)雜的業(yè)務(wù)場景中，僅僅依靠主進(jìn)程啟動(dòng)一個(gè)子進(jìn)程來運(yùn)行任務(wù)是不夠的。

在任務(wù)執(zhí)行過程中，子進(jìn)程對于主進(jìn)程來說是一個(gè)黑盒。主進(jìn)程無法直接了解任務(wù)當(dāng)前運(yùn)行到哪一步，以及任務(wù)的當(dāng)前狀態(tài)。為了便于主進(jìn)程和子進(jìn)程之間的數(shù)據(jù)流轉(zhuǎn)，TaskHub 引擎建立了主進(jìn)程和子進(jìn)程之間的雙向通信機(jī)制。

以獲取任務(wù)運(yùn)行結(jié)果為例，當(dāng)子進(jìn)程運(yùn)行任務(wù)后，我們希望在主進(jìn)程中獲取任務(wù)的返回結(jié)果。

我們可以在主進(jìn)程中使用之前創(chuàng)建的 task 實(shí)例來注冊監(jiān)聽事件，等待子進(jìn)程發(fā)送消息。具體代碼如下所示：

在任務(wù)腳本中，根據(jù)需要發(fā)送任務(wù)狀態(tài)的更新，如下所示：

需要注意的是，子進(jìn)程可以向主進(jìn)程發(fā)送消息，而主進(jìn)程也可以收發(fā)子進(jìn)程的消息。這種雙向通信機(jī)制在以下場景中非常有用：

1）狀態(tài)監(jiān)控：主進(jìn)程可以實(shí)時(shí)接收子進(jìn)程的狀態(tài)更新，了解任務(wù)執(zhí)行的每一步驟。

2）任務(wù)控制：主進(jìn)程可以向子進(jìn)程發(fā)送指令，例如暫停、繼續(xù)或終止任務(wù)。

3）異常處理：子進(jìn)程在遇到問題時(shí)，可以立即通知主進(jìn)程，使得異常情況能夠迅速得到響應(yīng)和處理。

4）數(shù)據(jù)傳輸：主進(jìn)程和子進(jìn)程之間可以交換數(shù)據(jù)，確保任務(wù)執(zhí)行所需的信息流暢傳遞。

以上是引擎內(nèi)部任務(wù)調(diào)度的實(shí)現(xiàn)，接下來介紹引擎如何與TaskHub平臺進(jìn)行通信。

4.2.3 引擎外部通信

如上面所說，TaskHub 平臺的主要用途是記錄自動(dòng)化腳本執(zhí)行過程中產(chǎn)生的日志、任務(wù)狀態(tài)，以及其他需要被持久化的狀態(tài)。所以主要通信的內(nèi)容包括：任務(wù)狀態(tài)的變更、日志推送、引擎輪詢獲取需要主動(dòng)終止的任務(wù)。

引擎通信接口 IMessageSender

整體設(shè)計(jì)中提到 TaskHub 引擎與 TaskHub 平臺是解耦的。引擎內(nèi)部定義了一份接口 IMessageSender，只要實(shí)現(xiàn)了接口就能與引擎共同運(yùn)行，TaskHub 平臺只是引擎接口的一份實(shí)現(xiàn)。

接口定義如下：

我們期望 TaskHub 平臺的可用性等級是穩(wěn)定的，不期望在更高可用性等級要求的應(yīng)用接入時(shí)被迫提升自己的可用性等級。所以，通信接口中關(guān)于日志的部分， 引擎對 原有的日志平臺 也做了一份實(shí)現(xiàn)，作為TaskHub日志系統(tǒng)的兜底方案。

當(dāng) TaskHub 平臺不可用時(shí)，引擎與平臺的通信會(huì)降級到兜底方案，此時(shí)部分能力是受限的，例如終止任務(wù)的能力。但是這并不會(huì)影響自動(dòng)化任務(wù)的執(zhí)行，引擎的調(diào)度能力、腳本的日志留痕等能力仍然可用，并且，所有運(yùn)行日志可以在原有的日志平臺獲取。

以上是引擎設(shè)計(jì)相關(guān)的內(nèi)容，除此之外，TaskHub還提供了兩個(gè)輔助 SDK 以補(bǔ)充 TaskHub 平臺的使用：

• logger：幫助用戶記錄日志到TaskHub平臺，支持文字和圖片日志。
• media：集成了OSS平臺，提供簡單易用的API將本地圖片或base64格式的圖片上傳至服務(wù)器，方便任務(wù)運(yùn)行過程中對圖像數(shù)據(jù)的管理。

五、使用案例

5.1 度假業(yè)務(wù)自動(dòng)化數(shù)據(jù)錄入

度假業(yè)務(wù)內(nèi)部有一個(gè)需求，業(yè)務(wù)人員需要定期在某個(gè)站點(diǎn)錄入數(shù)據(jù)。后來，將數(shù)據(jù)結(jié)構(gòu)化處理后，通過自動(dòng)化程序定時(shí)進(jìn)行數(shù)據(jù)錄入，代替之前的人工操作。

雖然這種自動(dòng)化模式解決了一部分問題，但在實(shí)踐中也發(fā)現(xiàn)了一些新的問題：

1）排障效率低。在自動(dòng)化的過程中，由于站點(diǎn)加載的資源很多，涉及出錯(cuò)的原因很雜，通過現(xiàn)有日志系統(tǒng)排障需要投入大量時(shí)間，效率低下，占用了寶貴的開發(fā)時(shí)間。

2）無法及時(shí)關(guān)閉單個(gè)任務(wù)。目前只能通過關(guān)閉整個(gè)自動(dòng)化應(yīng)用來關(guān)閉某個(gè)正在運(yùn)行的任務(wù)，這個(gè)過程不僅會(huì)關(guān)閉其他正在運(yùn)行的任務(wù)，而且整個(gè)關(guān)閉的流程很長，無法及時(shí)關(guān)閉。

在接入TaskHub后，自動(dòng)化系統(tǒng)的容錯(cuò)率和排障效率得到了顯著提升。

收益：

及時(shí)關(guān)閉任務(wù)：每個(gè)任務(wù)運(yùn)行在不同的子進(jìn)程上，可以殺掉子進(jìn)程立即關(guān)閉單個(gè)任務(wù)。

提升日志排障效率：除了可以及時(shí)關(guān)閉外，TaskHub 顯著提升了查找日志排障的效率，節(jié)省了大量時(shí)間。

以下圖表對比了傳統(tǒng)日志查找與TaskHub任務(wù)日志的差異：

傳統(tǒng)日志查找：開發(fā)人員需要從大量日志文件中找到錯(cuò)誤發(fā)生時(shí)的日志文件，然后再從文件中定位到異常任務(wù)的錯(cuò)誤日志，費(fèi)時(shí)費(fèi)力，容易遺漏關(guān)鍵細(xì)節(jié)。

TaskHub任務(wù)日志：TaskHub為不同任務(wù)劃分邊界，不再需要從大量雜亂的日志中尋找關(guān)鍵信息。每個(gè)任務(wù)的日志被結(jié)構(gòu)化記錄，便于快速查找和定位問題。此外，任務(wù)的輸入輸出也清晰可見，可以快速復(fù)現(xiàn)場景。

任務(wù)詳情

 任務(wù)日志

5.2 復(fù)雜業(yè)務(wù)場景的自動(dòng)化改造

在更為復(fù)雜的業(yè)務(wù)場景中，自動(dòng)化需求往往更加多樣化。例如，當(dāng)前有一個(gè)需求：人工需要定期在某個(gè)站點(diǎn)上查看頁面特定元素的狀態(tài)，如果滿足某些條件，則去另一個(gè)站點(diǎn)錄入數(shù)據(jù)。

為了將該項(xiàng)目進(jìn)行自動(dòng)化改造，可以將場景拆分為以下兩個(gè)需求：

需求1：在某個(gè)站點(diǎn)上通過查找頁面來獲得業(yè)務(wù)數(shù)據(jù)。

需求2：定期在某個(gè)站點(diǎn)上錄入數(shù)據(jù)，錄入數(shù)據(jù)之前需要判斷【需求1】中的業(yè)務(wù)結(jié)果。

具體實(shí)現(xiàn)方案：

需求1：設(shè)計(jì)成一個(gè)接口，通過調(diào)用接口返回的結(jié)果來獲得業(yè)務(wù)數(shù)據(jù)。

需求2：設(shè)計(jì)成定時(shí)任務(wù)，定期執(zhí)行。每次執(zhí)行之前先請求【需求1】的接口，判斷條件是否滿足。

這是很自然的自動(dòng)化改造，能夠釋放人力資源，并且任務(wù)也被合理地拆分。然而，在實(shí)際運(yùn)行中，可能無法完全達(dá)到預(yù)期效果：

1）人工并未完全釋放：加入自動(dòng)化后，人工仍需定時(shí)關(guān)注自動(dòng)化任務(wù)是否正常運(yùn)行，無法徹底擺脫手動(dòng)監(jiān)控。

2）排障復(fù)雜度增加：隨著前置任務(wù)的增加，自動(dòng)化排障的復(fù)雜度直線上升。當(dāng)【需求2】的任務(wù)運(yùn)行出現(xiàn)異常時(shí)，如果發(fā)現(xiàn)是由于前置的【需求1】出現(xiàn)問題，就需要根據(jù)錯(cuò)誤的發(fā)生時(shí)間去【需求1】的機(jī)器上查找日志。若有多個(gè)前置任務(wù)，排查成本將大幅增加。

我們來看下加入TaskHub之后，會(huì)有哪些改變。

1）任務(wù)異常主動(dòng)通知：從原來的主動(dòng)查看任務(wù)狀態(tài)，轉(zhuǎn)變?yōu)楸粍?dòng)接收任務(wù)異常通知。任務(wù)出現(xiàn)異常時(shí)，系統(tǒng)會(huì)主動(dòng)提醒，減少了人工監(jiān)控的負(fù)擔(dān)。

2）快速排障：通過捕捉錯(cuò)誤快照，將其記錄到 TaskHub 的圖片日志中，開發(fā)人員能夠快速定位并解決問題。

3）清晰的排障鏈路：TaskHub 不僅提升了單一任務(wù)日志的查找效率，對于多個(gè)串聯(lián)任務(wù)也同樣適用。通過在下游日志中打印上游任務(wù)ID，可以快速查找上游日志，無需在多個(gè)機(jī)器日志中來回跳轉(zhuǎn)。

下圖展示了一個(gè)三個(gè)串聯(lián)任務(wù)的排障例子。

值得注意的是，TaskHub 并沒有改變原有項(xiàng)目的設(shè)計(jì)，只是將任務(wù)的運(yùn)行方式從 Node 轉(zhuǎn)變?yōu)?TaskHub 引擎。

TaskHub 將自動(dòng)化中的任務(wù)概念獨(dú)立出來，本質(zhì)上，任務(wù)就是腳本的執(zhí)行。無論任務(wù)是通過接口調(diào)用、定時(shí)函數(shù)還是定時(shí)器喚起，任務(wù)的喚起方式雖然不同，但任務(wù)執(zhí)行的邏輯保持一致。這樣一來，開發(fā)者可以更專注于任務(wù)的邏輯實(shí)現(xiàn)，再根據(jù)需求喚起任務(wù)即可。

到目前為止，已有 12 個(gè)自動(dòng)化項(xiàng)目使用 TaskHub 運(yùn)行，累計(jì)完成了 48w 次自動(dòng)化任務(wù)，記錄了 1300w 條日志。

六、RPC BFF最佳實(shí)踐

在進(jìn)行 TaskHub BFF 的技術(shù)選型時(shí)，我們對比了當(dāng)前多種主流的技術(shù)棧。由于 TaskHub BFF 有多個(gè)調(diào)用方，并且在客戶端和服務(wù)端都有消費(fèi)場景，綜合考慮上手成本和多個(gè)消費(fèi)者之間的同步成本等因素，最終選擇了 RPC BFF。

關(guān)于RPC BFF 更多介紹可以查看文章《攜程度假基于 RPC 和 TypeScript 的 BFF 設(shè)計(jì)與實(shí)踐》。

傳統(tǒng)服務(wù)開發(fā)中，服務(wù)提供方需要撰寫服務(wù)代碼，然后在第三方平臺同步接口文檔，消費(fèi)者再根據(jù)文檔約定在不同調(diào)用環(huán)境中使用這些接口。

而在 RPC BFF 模式的開發(fā)中，服務(wù)提供方撰寫服務(wù)代碼之后，消費(fèi)者只需通過一個(gè)命令就可以獲得接口的調(diào)用文檔和調(diào)用函數(shù)。這種方式不僅簡化了開發(fā)流程，還提高了接口調(diào)用的一致性和可靠性。

在使用RPC BFF的過程中，我們也總結(jié)了一些最佳實(shí)踐，希望能夠給大家?guī)硪恍﹩l(fā)。

6.1 收斂類型

在設(shè)計(jì) RPC 接口的返回值時(shí)，有些開發(fā)者可能會(huì)沿用樸素函數(shù)的設(shè)計(jì)思路，即當(dāng)接口返回成功時(shí)，返回一個(gè)成功標(biāo)識和數(shù)據(jù)；當(dāng)失敗時(shí)，則返回一個(gè)失敗狀態(tài)和錯(cuò)誤碼，讓消費(fèi)端根據(jù)不同的錯(cuò)誤碼進(jìn)行相應(yīng)操作，如下所示：

這種設(shè)計(jì)存在以下幾個(gè)問題：

1）邏輯不夠清晰：簡單地將返回結(jié)果分為成功和失敗，實(shí)際開發(fā)中可能還有“可接受的錯(cuò)誤”或其他復(fù)雜的狀態(tài)，擴(kuò)展性不佳。

2）錯(cuò)誤碼維護(hù)復(fù)雜：前后端都需要維護(hù)同一套錯(cuò)誤碼，增加了開發(fā)和維護(hù)成本。

3）錯(cuò)誤處理遺漏：編碼時(shí)容易遺漏未處理的錯(cuò)誤狀態(tài)，增加了系統(tǒng)不穩(wěn)定性。

其實(shí)，可以使用 RPC BFF 的 Union 類型，將所有可能返回的狀態(tài)聯(lián)合起來，合并為最終返回的類型。

通過聚合所有返回結(jié)果，不再需要維護(hù)同一套錯(cuò)誤碼，并且通過類型系統(tǒng)就能確保所有可能的狀態(tài)都被處理。如下圖所示，在消費(fèi)返回結(jié)果時(shí)，代碼編輯器中有代碼提示，不會(huì)遺漏任何狀態(tài)。

如果接口或類型有更新，只需要一個(gè)命令就可以同步更新接口和接口類型。

6.2 原子化過程

RPC BFF 的核心理念是面向函數(shù)的接口編程，得益于它對底層通信細(xì)節(jié)的封裝，開發(fā)者只需考慮函數(shù)的功能即可。

與 RESTful 優(yōu)先資源的理念不同，RPC BFF 的原子是一個(gè)過程。REST 將資源暴露出來，而 RPC 是將過程暴露出來。

所以，可以通過分析服務(wù)流程（過程），將其拆解為最小不可分割的流程，再將這些流程通過函數(shù)實(shí)現(xiàn)。

只需保證所有原子化的過程都被很好地處理。在原子過程之上的過程調(diào)用，只需按需組合這些原子過程，從而形成一個(gè)過程流，最終形成一個(gè)有向無環(huán)圖（Directed Acyclic Graph）。

例如，有一個(gè)接口接收一個(gè) ProjectId ，并返回該 ID 對應(yīng)的項(xiàng)目信息。如果未獲取到項(xiàng)目，則返回未找到。

getProjectById既可以對外暴露，也可以在其他函數(shù)中調(diào)用。

假設(shè)有一個(gè)業(yè)務(wù)流程，需要首先檢查項(xiàng)目是否存在，然后根據(jù)項(xiàng)目狀態(tài)執(zhí)行不同的操作。如下圖所示，在 getProjectSetting 中，我們調(diào)用接口的方式就像調(diào)用本地函數(shù)一樣，并且利用前面說的返回值類型組合，清晰地完成代碼邏輯。

通過這種方式，有以下幾個(gè)收益：

1）高復(fù)用性：原子化的函數(shù)可以在不同的業(yè)務(wù)場景中復(fù)用，減少代碼重復(fù)。

2）清晰明確：每個(gè)函數(shù)只負(fù)責(zé)一個(gè)具體的操作，邏輯清晰，易于維護(hù)和測試。

3）組合靈活：可以根據(jù)業(yè)務(wù)需求，靈活組合原子化過程，構(gòu)建復(fù)雜的業(yè)務(wù)邏輯。

七、結(jié)語

通過重新梳理整個(gè)自動(dòng)化流程，我們拆分出了運(yùn)行自動(dòng)化任務(wù)的核心部分和輔助模塊。在保證自動(dòng)化任務(wù)高可用的基礎(chǔ)上，提高了自動(dòng)化的整體效率和容錯(cuò)率?？紤]到自動(dòng)化場景的復(fù)雜性，我們特別設(shè)計(jì)了主進(jìn)程與子進(jìn)程的雙向通信機(jī)制，以應(yīng)對各種自動(dòng)化場景的挑戰(zhàn)。

此外，我們還提供了兩個(gè)自動(dòng)化場景案例，詳細(xì)分析TaskHub如何幫助提升自動(dòng)化效率。

最后，我們結(jié)合團(tuán)隊(duì)在RPC BFF的實(shí)踐，分享了一些使用經(jīng)驗(yàn)。

未來，我們將繼續(xù)探索更多的自動(dòng)化場景，并不斷完善TaskHub。