從舊系統(tǒng)遷移到新系統(tǒng)總是一個(gè)痛苦的過(guò)程，這篇文章介紹了Pinterest怎樣定義自動(dòng)化的遷移層幫助用戶(hù)從舊系統(tǒng)遷移到新的工作流系統(tǒng)。原文：Spinner: The Mass Migration to Pinterest’s New Workflow Platform^[1]

我們?cè)?a href="http://www.reibang.com/p/ebcfca7013b8" target="_blank">上一篇文章中討論了如何做出決定并采取行動(dòng)虱疏，將舊系統(tǒng)Pinball^[2]遷移到j(luò)基于Apache Airflow的新系統(tǒng)Spinner上暮刃。提醒一下，我們從Airflow 1.10-stable版本創(chuàng)建了自定義分支宦棺，并且從主干上cherry-pick了部分功能舌缤。

本文將介紹我們?nèi)绾卧O(shè)計(jì)和完成遷移箕戳，明確需求，并與工程師團(tuán)隊(duì)協(xié)調(diào)国撵，無(wú)縫的將3000多個(gè)工作流遷移到Airflow陵吸。我們將深入探討所做的權(quán)衡，但在此之前介牙，我們先介紹一下學(xué)到的經(jīng)驗(yàn)教訓(xùn)壮虫。

按照我們的標(biāo)準(zhǔn)，一個(gè)成功的遷移過(guò)程的關(guān)鍵是：

• 理解并填補(bǔ)之前的內(nèi)部工作流系統(tǒng)與Airflow之間的差距环础，確定特性差異囚似、安全差異和用戶(hù)習(xí)慣使用的術(shù)語(yǔ)。
• 提供以低成本方式同時(shí)大規(guī)模遷移工作流的工具线得，并提供驗(yàn)證方法饶唤。
• 與用戶(hù)進(jìn)行清晰持續(xù)的溝通，并提供相關(guān)材料贯钩，如wiki募狂、培訓(xùn)課程、積極的用戶(hù)支持和公告角雷。
• 啟用無(wú)狀態(tài)UI分區(qū)調(diào)度器祸穷，支持kubernetes集成，以提供定制化勺三、可伸縮的解決方案雷滚。
• 提供清晰的CI/CD流水線，幫助系統(tǒng)一致吗坚、可靠揭措、高效的維護(hù)多個(gè)基礎(chǔ)架構(gòu)分支胯舷。
• 嚴(yán)格測(cè)試刻蚯，在預(yù)發(fā)環(huán)境里進(jìn)行單元測(cè)試和集成測(cè)試绊含，以阻止破壞性變更，并在部署時(shí)采取謹(jǐn)慎的方法炊汹。
• 維護(hù)運(yùn)行狀況檢查和綜合指標(biāo)躬充，并在負(fù)載增加時(shí)對(duì)告警進(jìn)行微調(diào)。

最需要避免的問(wèn)題包括：

• 確保遷移之前和之后的調(diào)度一致讨便。由于定義調(diào)度器的方式不同(舊系統(tǒng)并非完全基于cron)充甚，因此舊系統(tǒng)和Spinner系統(tǒng)的調(diào)度間隔并不總是一致的。因此霸褒，要防止操作被忽略或者被過(guò)度操作伴找。
• 為每個(gè)任務(wù)分配內(nèi)存等資源，以防止任務(wù)啟動(dòng)失敗废菱。
• Kubernetes pod的初始化成本是非預(yù)期的技矮，pod啟動(dòng)延時(shí)確實(shí)有不小的成本，必須被團(tuán)隊(duì)內(nèi)所有用例所接受殊轴。
• Kubernetes pod內(nèi)冗余的sidecar會(huì)增加延時(shí)與網(wǎng)絡(luò)問(wèn)題衰倦，并會(huì)增加工作流的調(diào)度延時(shí)。
• 在用戶(hù)教育和支持方面的投資可能會(huì)很高旁理。
• 為維護(hù)舊的DSL和新的Airflow DSL而增加的混合解決方案的成本開(kāi)銷(xiāo)并不低樊零。

接下來(lái)看看我們是怎么解決這些挑戰(zhàn)的。

方法與需求

我們將平臺(tái)的遷移需求定義為：

1. 用戶(hù)只需做出最少的代碼更改
2. 遷移時(shí)不需要中斷生產(chǎn)工作流的執(zhí)行
3. 設(shè)置遺留系統(tǒng)的下線日期并完成系統(tǒng)下線

考慮到這些需求孽文，我們可以有兩種方式進(jìn)行遷移：

1. 請(qǐng)求工作流的所有者在Arflow DSL中重寫(xiě)舊工作流驻襟，并在這個(gè)轉(zhuǎn)換過(guò)程中提供支持
2. 平臺(tái)提供直接進(jìn)行DSL轉(zhuǎn)換的工具

使用方法1，可以減少我們和用戶(hù)的技術(shù)債務(wù)芋哭，平臺(tái)不必維護(hù)額外的基礎(chǔ)設(shè)施沉衣，但由于所有定制的用戶(hù)邏輯和依賴(lài)關(guān)系已經(jīng)被添加到遺留的Pinball任務(wù)中，因此存在一些挑戰(zhàn)楷掉。不過(guò)即使沒(méi)有這些挑戰(zhàn)厢蒜，我們也沒(méi)有讓用戶(hù)接受這個(gè)提議，因?yàn)槊總€(gè)團(tuán)隊(duì)都得花費(fèi)大量工程時(shí)間來(lái)做遷移烹植，而這些都是成本斑鸦。最后，由于需要依賴(lài)用戶(hù)來(lái)完成工作草雕，可能會(huì)推遲遺留系統(tǒng)的下線時(shí)間巷屿，因此這種方式并不可行。

因此墩虹，我們采用的方法更接近方法2：我們?cè)贏irflow調(diào)度器中構(gòu)建了一個(gè)遷移層嘱巾，動(dòng)態(tài)解析DAG文件憨琳，將遺留工作流系統(tǒng)中的工作流定義轉(zhuǎn)換為Airflow的DAG。這意味著不需要用戶(hù)修改代碼旬昭，為用戶(hù)提供了透明的遷移體驗(yàn)篙螟。遺留工作流中的每個(gè)作業(yè)都被轉(zhuǎn)換為包裝操作器類(lèi)型，該類(lèi)型是專(zhuān)門(mén)為支持工作流遷移用例而實(shí)現(xiàn)的问拘。在執(zhí)行期間遍略，操作器啟動(dòng)新的k8s pod，使用遺留系統(tǒng)的鏡像啟動(dòng)遺留作業(yè)的實(shí)際邏輯骤坐。通過(guò)這種方式绪杏，我們可以為遷移后的任務(wù)模擬遺留系統(tǒng)的執(zhí)行環(huán)境。

遷移層

重申一下纽绍，這個(gè)項(xiàng)目的目標(biāo)是用最少的用戶(hù)工作量盡量透明的推動(dòng)工作流遷移蕾久。下圖展示了這一過(guò)程的端到端體驗(yàn)，后續(xù)我們將更深入研究各個(gè)組件拌夏。

Pinterest遷移調(diào)度器/組件以及原生調(diào)度器/組件僧著。

左側(cè)的組件是Pinterest遷移調(diào)度程序，這是基于原生Airflow調(diào)度器構(gòu)建的，并利用了之前編寫(xiě)的多分區(qū)調(diào)度器。

PinterestDagBag

當(dāng)調(diào)度器在遷移模式下啟動(dòng)時(shí)瘫絮，使用定制的DagBag類(lèi)跃洛，命名為PinterestDagBag，其負(fù)責(zé)從遷移元數(shù)據(jù)文件（而不是python的DAG文件）解析DAG。為了更好理解，我們需要介紹之前的Pinball^[2]系統(tǒng)是如何工作的。

Pinball有令牌（Token）的概念：當(dāng)Pinball工作流做好運(yùn)行準(zhǔn)備端逼，工作流解析器將把工作流定義轉(zhuǎn)換成令牌，存儲(chǔ)所有必需的運(yùn)行時(shí)信息污淋。PinterestDagBag從遺留系統(tǒng)的工作流解析器中檢索工作流定義(也就是令牌)顶滩，遺留系統(tǒng)托管在名為令牌獲取器（Token Fetcher）的容器中。然后將傳統(tǒng)的工作流定義轉(zhuǎn)換為原生Airflow DAG和運(yùn)行中的任務(wù)(例如操作器或感應(yīng)器)寸爆。

完成這種抽象和轉(zhuǎn)換(不需要DAG文件)的方法實(shí)際上非常簡(jiǎn)單礁鲁，一個(gè)DAG文件本質(zhì)上只是一個(gè)或多個(gè)DAG的標(biāo)識(shí)符。對(duì)于原生Airflow來(lái)說(shuō)赁豆，DAG文件恰好攜帶了工作流定義仅醇，但完全有可能以一種不直接包含工作流定義，而是指向定義所在源代碼的方式來(lái)組成DAG文件魔种。我們編寫(xiě)了一個(gè)“dag文件”析二，表示遺留工作流定義的托管位置，并確保定制的PinterestDagBag模塊能夠從中解析出DAG對(duì)象。遷移元數(shù)據(jù)文件的示例如下：

{
    “cluster_name”: “core001”,
    “workflow_name”: “test_workflow”,
    “migration_date”: “2020–01–01 00:00:00”
}

調(diào)度器能夠發(fā)現(xiàn)和處理的元數(shù)據(jù)是在工作流遷移啟動(dòng)時(shí)生成的(我們將在后面詳細(xì)描述)叶摄，每個(gè)遷移元數(shù)據(jù)文件都表示如何在Token Fetcher容器的幫助下獲取遺留工作流的定義属韧，下一節(jié)將討論這部分內(nèi)容。

Token Fetcher

一旦遷移調(diào)度器發(fā)現(xiàn)元數(shù)據(jù)蛤吓，Token Fetcher容器就開(kāi)始發(fā)揮作用宵喂，運(yùn)行遺留系統(tǒng)的解析器，并與遷移調(diào)度器一起工作柱衔，其開(kāi)放API可以用來(lái)檢索遺留工作流規(guī)范以及解析作業(yè)樊破。遺留工作流中的每個(gè)作業(yè)都被解析成一個(gè)作業(yè)令牌數(shù)據(jù)結(jié)構(gòu)，其中包含規(guī)范唆铐，以及最重要的作業(yè)執(zhí)行命令，如下所示：

python data_job_runner.py — job_full_class=reporter.examples.ExampleSparkJob — executor=prod_011 — job_args=”end_date=2021–12–30"

通過(guò)Toke Fetcher容器奔滑，PinterestDagBag模塊可以調(diào)用相應(yīng)的API艾岂，根據(jù)遷移元數(shù)據(jù)文件檢索工作流規(guī)范和作業(yè)令牌。

解析遷移文件的組件之間的交互朋其。

PinboardOnK8sOperator

在深入研究這個(gè)特殊的操作器之前王浴，我們回顧一下Pinboard是什么。在上一篇文章里梅猿，我們介紹過(guò)Pinboard是Pinterest的python代碼單一存儲(chǔ)庫(kù)氓辣，在之前的系統(tǒng)中，所有工作流和作業(yè)都定義在這個(gè)存儲(chǔ)庫(kù)里袱蚓。

一旦我們獲得了來(lái)自Token的數(shù)據(jù)钞啸，就使用定制的PinboardOnK8sOperator操作器來(lái)包裝遺留作業(yè)的Token抽象。每個(gè)作業(yè)令牌被轉(zhuǎn)換為該操作器的一個(gè)實(shí)例喇潘，存儲(chǔ)從檢索到的令牌中獲取的執(zhí)行命令体斩。在執(zhí)行期間，啟動(dòng)一個(gè)k8s pod颖低，加載pinboard來(lái)執(zhí)行命令絮吵，以模擬遺留系統(tǒng)的作業(yè)執(zhí)行環(huán)境。這也可以防止對(duì)Airflow執(zhí)行環(huán)境造成任何干擾忱屑。

Airflow的序列化DAG特性被用來(lái)序列化遷移后的DAG和任務(wù)蹬敲，有助于減少DAG的解析開(kāi)銷(xiāo)。PinterestDagBag只在工作流的序列化DAG不存在時(shí)才調(diào)用Token Fetcher來(lái)檢索作業(yè)Token并進(jìn)行轉(zhuǎn)換莺戒。同樣伴嗡，當(dāng)遷移的DAG的要被調(diào)度執(zhí)行時(shí)，DagFileProcessor再次調(diào)用Token Fetcher來(lái)檢索最新的作業(yè)Token并刷新序列化的DAG脏毯。這個(gè)序列化DAG也用在UI渲染中闹究，所以不需要在Web服務(wù)器上啟動(dòng)Token Fetcher容器。此外食店，由于執(zhí)行PinboardOnK8sOperator所需的屬性都是可序列化的渣淤，所以在執(zhí)行遷移任務(wù)時(shí)也使用了序列化DAG特性赏寇。

遷移工具

為了簡(jiǎn)化工作流遷移的過(guò)程，我們構(gòu)建了一個(gè)UI工具价认，讓用戶(hù)可以將現(xiàn)有的工作流遷移到Airflow嗅定。只需幾次單擊，就可以在舊系統(tǒng)上停止調(diào)度工作流用踩，并將其調(diào)度到新的Spinner集群上渠退。一旦工作流被遷移，遷移元數(shù)據(jù)文件將被上傳到s3脐彩，并且可以被遷移調(diào)度器發(fā)現(xiàn)碎乃。該工具還支持遷移回遺留系統(tǒng)、發(fā)布高級(jí)遷移報(bào)告并提供管理員角色惠奸，以幫助用戶(hù)管理遷移記錄梅誓。

我們還將遷移API公開(kāi)給其他系統(tǒng)的下游服務(wù)，幫助這些系統(tǒng)用可編程的方式構(gòu)建工作流佛南。

準(zhǔn)備將工作流遷移至Spinner集群的UI梗掰。

顯示不同的遷移階段的UI。

通過(guò)這個(gè)工具嗅回，遷移工作流只需要幾分鐘時(shí)間及穗，而不需要用戶(hù)花上幾個(gè)小時(shí)重寫(xiě)代碼，減輕了用戶(hù)負(fù)擔(dān)绵载。用戶(hù)只需要登錄UI埂陆，選擇工作流，將其調(diào)度到Spinner中運(yùn)行尘分，驗(yàn)證輸出是否有效(這需要手動(dòng)操作)猜惋，最后通過(guò)關(guān)閉遷移記錄來(lái)結(jié)束遷移工作。這個(gè)工具對(duì)于平臺(tái)和用戶(hù)來(lái)說(shuō)是非常重要培愁，如果沒(méi)有它著摔，我們就不可能在一年內(nèi)完成遷移的目標(biāo)。

動(dòng)態(tài)DAG

我們的遷移工作需要但是Airflow不支持的一個(gè)主要功能是動(dòng)態(tài)DAG定续。動(dòng)態(tài)DAG可以根據(jù)調(diào)度器處理的不同動(dòng)態(tài)生成不同的DAG布局谍咆。例如，如果DAG布局是基于某些外部服務(wù)或數(shù)據(jù)的狀態(tài)生成的私股，那么就會(huì)和從DAG文件加載的布局有所不同摹察，并且和解析DAG文件的時(shí)間相關(guān)。我們期望當(dāng)新的DAG被調(diào)度執(zhí)行時(shí)倡鲸，就能夠確定DAG布局供嚎。計(jì)算出來(lái)的布局將會(huì)被保存下來(lái)，并且DAG的執(zhí)行將會(huì)與保存的布局保持一致。worker可以基于保存的布局加載任務(wù)克滴，而不需要再次進(jìn)行DAG解析逼争，而再次解析可能會(huì)生成一個(gè)不同的DAG布局。

Airflow原生并不支持這個(gè)功能劝赔，其潛在問(wèn)題就在于當(dāng)worker試圖執(zhí)行DAG任務(wù)時(shí)誓焦，從DAG文件檢索到的布局和DAG執(zhí)行是創(chuàng)建的布局是不一致的。在這種情況下着帽，worker無(wú)法從DAG獲得特定的任務(wù)杂伟。

我們基于Airflow構(gòu)建了這一功能，設(shè)計(jì)了一種名為DynamicDAG的新型DAG仍翰，并公開(kāi)了compute_layout方法赫粥。任務(wù)實(shí)例化邏輯封裝在compute_layout方法中，而不是在DAG文件的最外層定義任務(wù)歉备。這個(gè)方法只在創(chuàng)建新的DAG運(yùn)行時(shí)被調(diào)用生成DAG布局傅是，布局快照將被保存并綁定到這個(gè)DAG運(yùn)行中，所以當(dāng)需要獲得某個(gè)特定DAG運(yùn)行時(shí)的任務(wù)時(shí)蕾羊，系統(tǒng)能夠從保存的DAG布局中檢索，而不是從DAG文件中加載帽驯。下面的代碼片段展示了如何使用DynamicDAG接口構(gòu)建動(dòng)態(tài)DAG龟再。

dag = DynamicDAG(
dag_id=”dynamic_test”,
compute_layout=compute_layout,
skip_early_layout_compute=True,….
)
def compute_layout(dynamic_dag: DynamicDAG, execution_date: datetime = None, dagrun_conf: dict = None) -> None:
“””
Compute layout for dynamic DAG
“””
# Use random int
rand_int = random.randint(1, 3)
for i in range(rand_int):
python_task_1 = dynamic_dag.add_task_into_dynamic_dag(operator_class=PythonOperator,
task_id=f’python_task_{i}’,
python_callable=python_callable,
op_kwargs={‘task_id’: f’python_task_{i}’,
‘execution_date’: execution_date})
python_task_2 = dynamic_dag.add_task_into_dynamic_dag(operator_class=PythonOperator,
task_id=f’python_task_{i}_v2',
python_callable=python_callable,
op_kwargs={‘task_id’: f’python_task_{i}’,
‘execution_date’: execution_date})
python_task_1 >> python_task_2

請(qǐng)注意，雖然我們是為了幫助遷移而創(chuàng)建了這個(gè)類(lèi)尼变，但它也適用于本地工作流利凑，我們可以將這個(gè)類(lèi)用于業(yè)務(wù)邏輯。

我們修改了Airflow中的主要組件嫌术，如調(diào)度器哀澈、Web服務(wù)器和執(zhí)行器，以支持我們的版本特性度气，下面的流程圖顯示了有/沒(méi)有DAG版本特性的調(diào)度器處理邏輯的差異割按。在新的設(shè)計(jì)中，調(diào)度器模塊有兩個(gè)主要的變化：

1. DAG布局將在DAG運(yùn)行時(shí)創(chuàng)建期間被重新生成并被序列化磷籍，所以一個(gè)新創(chuàng)建的DAG運(yùn)行時(shí)將總是被綁定到一個(gè)特定的DAG布局适荣。
2. 當(dāng)調(diào)度器處理特定版本的DAG布局時(shí)（例如驗(yàn)證DAG完整性或調(diào)度任務(wù)實(shí)例），系統(tǒng)將加載并反序列化DAG布局院领。通過(guò)這種方式弛矛，確保總是能夠調(diào)度和執(zhí)行正確版本的DAG比然。

普通DAG和動(dòng)態(tài)DAG的比較丈氓。

Kubernetes對(duì)遷移的支持

概述

基礎(chǔ)設(shè)施層利用內(nèi)部Kubernetes集群，從而提供“無(wú)限”的可伸縮性、與其他任務(wù)的隔離万俗、易于維護(hù)和升級(jí)湾笛，以及改進(jìn)的安全性。

Spinner和Pinterest Kubernetes集群如何通過(guò)DB交互该编。

在上圖中迄本，可以看到遷移的任務(wù)用例經(jīng)歷了兩個(gè)迭代。遷移的任務(wù)用例有一個(gè)Airflow的工作pod课竣，然后啟動(dòng)一個(gè)遷移的任務(wù)pod來(lái)加載調(diào)用和運(yùn)行命令所需的環(huán)境嘉赎。這種pod over pod場(chǎng)景增加了額外的2-4分鐘的啟動(dòng)時(shí)間，可能會(huì)給用戶(hù)作業(yè)帶來(lái)沉重的成本于樟。稍后公条，我們將介紹增強(qiáng)的遷移任務(wù)用例，可以在原來(lái)的工作pod中運(yùn)行遷移后的pod邏輯迂曲，從而節(jié)省了啟動(dòng)第二個(gè)pod的成本靶橱。執(zhí)行增強(qiáng)的遷移任務(wù)工作pod時(shí)，生命周期如下所示路捧。

遷移任務(wù)工作Pod

遷移任務(wù)工作pod運(yùn)行邏輯和完成執(zhí)行

Airflow工作容器啟動(dòng)Airflow任務(wù)命令关霸，生成遷移后的任務(wù)命令，該命令將被發(fā)送到pinboard容器杰扫，而pinboard容器只是一個(gè)可以調(diào)用舊DSL邏輯并返回輸出狀態(tài)的容器队寇。Airflow工作容器只是監(jiān)視pinboard容器的活躍度，等待其退出并返回狀態(tài)章姓。從用戶(hù)的角度來(lái)看佳遣，當(dāng)UI試圖獲取活動(dòng)任務(wù)日志時(shí)，它是一個(gè)獨(dú)立進(jìn)程凡伊，使用kubernetes API從主機(jī)提取日志零渐。Airflow工作容器輪詢(xún)查詢(xún)狀態(tài)，直到任務(wù)完成系忙。

Pod構(gòu)建

最后我們介紹一下工作Pod的生成方式诵盼。

構(gòu)建Pod執(zhí)行K8S操作的端到端流程。

下面會(huì)更詳細(xì)的解釋幫助容器生成規(guī)范yaml的不同組件及其各自的任務(wù)操作笨觅。在Kubernetes執(zhí)行器中拦耐，當(dāng)一個(gè)任務(wù)計(jì)劃運(yùn)行時(shí)，會(huì)生成Airflow工作Pod規(guī)范见剩。因?yàn)槭沁w移任務(wù)杀糯，也會(huì)生成pinboard容器規(guī)范，并將其合并到遷移的Airflow工作Pod規(guī)范中苍苞。最終固翰，該規(guī)范將提交給kubernetes集群州疾，以啟動(dòng)一個(gè)帶有工作容器和pinboard容器的Airflow工作Pod惠昔。

從序列圖中琢融，你可能還會(huì)注意到一些資源分配步驟业栅。在kubernetes環(huán)境中，我們需要預(yù)定義Pod的資源歉铝。因此盈简，我們還利用一些歷史數(shù)據(jù)以及可以直接從UI更新為配置的托管數(shù)據(jù)來(lái)幫助我們?yōu)槊總€(gè)遷移的任務(wù)進(jìn)行智能資源分配。我們?cè)趦?nèi)部創(chuàng)建了一個(gè)流程來(lái)跟蹤任務(wù)Pod的資源使用情況太示，以便更好理解他們的行為柠贤，并最大限度的節(jié)約資源。

部署

關(guān)于系統(tǒng)如何啟動(dòng)新構(gòu)建的決策樹(shù)

如前一節(jié)所述类缤，在執(zhí)行遷移期間臼勉，將啟動(dòng)單獨(dú)的k8s pod/容器，使用遺留系統(tǒng)的鏡像(即pinboard鏡像)運(yùn)行實(shí)際業(yè)務(wù)邏輯餐弱，從而確保任務(wù)的行為在遷移后保持不變宴霸。因此，我們構(gòu)建了專(zhuān)用的CI/CD流水線來(lái)生成膏蚓、驗(yàn)證和發(fā)布鏡像瓢谢。

遷移后的pinboard鏡像的部署生命周期遵循以下步驟：

1. 觸發(fā)Jenkins作業(yè)，基于最新的提交構(gòu)建pinboard鏡像驮瞧。我們的Teletraan^[3]管理工具會(huì)按預(yù)定節(jié)奏觸發(fā)恩闻，或者手動(dòng)觸發(fā)。
2. 發(fā)布工件剧董，另一個(gè)Jenkins作業(yè)會(huì)查看是否發(fā)布了任何變更，如果有變更破停，就運(yùn)行DAG單元測(cè)試并發(fā)布預(yù)發(fā)鏡像翅楼。
3. 然后，定期執(zhí)行的驗(yàn)證工作流將預(yù)發(fā)鏡像發(fā)布到金絲雀環(huán)境中真慢，并執(zhí)行一組觸發(fā)作業(yè)毅臊，這些作業(yè)觸發(fā)其他監(jiān)測(cè)工作流來(lái)驗(yàn)證預(yù)發(fā)鏡像，并查詢(xún)使用ExternalTaskSensors的預(yù)發(fā)鏡像的狀態(tài)黑界。這些金絲雀工作流是為了測(cè)試舊系統(tǒng)中常見(jiàn)的作業(yè)類(lèi)型管嬉，以覆蓋最常用的操作器。金絲雀工作流套件還包括用戶(hù)貢獻(xiàn)的工作流朗鸠，以保護(hù)他們的關(guān)鍵工作流不受可能破壞其流水線的問(wèn)題鏡像的影響蚯撩。一旦所有的感應(yīng)器任務(wù)接收到成功狀態(tài)，就發(fā)布生產(chǎn)鏡像烛占，供Web服務(wù)器胎挎、調(diào)度器和worker在生產(chǎn)中使用沟启。如果在金絲雀驗(yàn)證測(cè)試期間出現(xiàn)故障，工作流團(tuán)隊(duì)將得到自動(dòng)通知犹菇，并需要手動(dòng)檢查問(wèn)題以糾正并重新部署德迹。

金絲雀工作流啟動(dòng)許多工作流，進(jìn)行檢查揭芍，然后啟動(dòng)新的構(gòu)建

這個(gè)部署流水線還允許發(fā)布熱修復(fù)版本胳搞，以保護(hù)所有用戶(hù)在幾個(gè)小時(shí)后不受完整部署的影響，而只是發(fā)布一個(gè)特定的提交称杨。單一存儲(chǔ)庫(kù)有時(shí)具有復(fù)雜的依賴(lài)肌毅，可能導(dǎo)致許多意想不到的任務(wù)失敗。金絲雀驗(yàn)證流水線允許我們?cè)谌魏巫兏绊懙缴a(chǎn)環(huán)境之前捕獲潛在的問(wèn)題列另。

DAG文件同步

正如遷移工具一節(jié)中提到的芽腾，Spinner自動(dòng)遷移工具生成一個(gè)將發(fā)布到s3的遷移元數(shù)據(jù)文件，該文件是調(diào)度器的標(biāo)識(shí)符页衙，用于查找遷移后的工作流和作業(yè)令牌摊滔。同步服務(wù)在Airflow Web服務(wù)器和調(diào)度器上運(yùn)行，同步主機(jī)上的遷移元數(shù)據(jù)文件與來(lái)自s3的DAG文件店乐，并且也基于調(diào)度器層和分區(qū)號(hào)艰躺。正如在上一篇文章中提到的，有多個(gè)調(diào)度器同時(shí)服務(wù)于遷移工作流和原生工作流眨八，但是一個(gè)調(diào)度器只能其中一種DAG腺兴，不能同時(shí)處理兩者。任何新的遷移元數(shù)據(jù)文件都會(huì)在8秒內(nèi)同步到調(diào)度器廉侧，然后由PinterestDagBag模塊處理页响。下面是我們現(xiàn)有的遷移調(diào)度程序分區(qū)。

可用的不同遷移集群

指標(biāo)

在工作流遷移項(xiàng)目開(kāi)始時(shí)段誊，系統(tǒng)上運(yùn)行的大多數(shù)工作流都是從遺留系統(tǒng)遷移過(guò)來(lái)的闰蚕。為了度量系統(tǒng)的健康程度，需要更重視這些工作流连舍。正如在上一篇文章中提到的没陡，我們的系統(tǒng)級(jí)SLO是跨多個(gè)集群承載的所有調(diào)度器的聚合加權(quán)平均值。因此索赏，遷移后的調(diào)度器具有更高的權(quán)重盼玄，因?yàn)榘嗪透邔哟蔚墓ぷ髁鳌LO是通過(guò)每15分鐘為每個(gè)調(diào)度程序運(yùn)行一個(gè)預(yù)定的DAG來(lái)測(cè)量的潜腻，這個(gè)DAG會(huì)發(fā)出統(tǒng)計(jì)信息埃儿。如果任何指標(biāo)丟失了一個(gè)點(diǎn)，加權(quán)平均值將下降砾赔，我們測(cè)量該指標(biāo)的總體正常運(yùn)行時(shí)間不會(huì)低于98%蝌箍。任何指標(biāo)丟失一個(gè)數(shù)據(jù)點(diǎn)青灼，都會(huì)通知工作流團(tuán)隊(duì)，除非速率低于閾值（通常意味著更大的問(wèn)題）妓盲，并不會(huì)通知所有用戶(hù)杂拨。

跟蹤系統(tǒng)運(yùn)行狀況SLO的度量圖

結(jié)束語(yǔ)

我們與其他想要探索如何增強(qiáng)主要組件來(lái)定制業(yè)務(wù)需求的Airflow愛(ài)好者分享我們的發(fā)現(xiàn)，我們采用基本的Airflow系統(tǒng)悯衬，加入自定義修改弹沽，支持其與我們的遷移層協(xié)同工作，協(xié)調(diào)客戶(hù)工作流筋粗。

希望這篇關(guān)于如何從舊系統(tǒng)遷移到Pinterest Airflow系統(tǒng)的文章對(duì)你有所幫助策橘。

References:
[1] Spinner: The Mass Migration to Pinterest’s New Workflow Platform: https://medium.com/pinterest-engineering/spinner-the-mass-migration-to-pinterests-new-workflow-platform-997d9243f56a
[2] Pinball: Building workflow management: https://medium.com/@Pinterest_Engineering/pinball-building-workflow-management-88a044c9b9e3
[3] Teletraan: https://github.com/pinterest/teletraan

你好，我是俞凡娜亿，在Motorola做過(guò)研發(fā)丽已，現(xiàn)在在Mavenir做技術(shù)工作，對(duì)通信买决、網(wǎng)絡(luò)沛婴、后端架構(gòu)、云原生督赤、DevOps嘁灯、CICD、區(qū)塊鏈躲舌、AI等技術(shù)始終保持著濃厚的興趣丑婿，平時(shí)喜歡閱讀、思考没卸，相信持續(xù)學(xué)習(xí)羹奉、終身成長(zhǎng)，歡迎一起交流學(xué)習(xí)约计。
微信公眾號(hào)：DeepNoMind