譯者 | 涂承燁

審校 | 重樓

Saga模式是實(shí)現(xiàn)持久微服務(wù)執(zhí)行的好工具，但它會(huì)使維護(hù)變得困難。這里有一個(gè)讓它為你的系統(tǒng)工作的方法。

1.Sagas的問題

在項(xiàng)目中，我們都經(jīng)歷過這樣的時(shí)刻：我們意識(shí)到軟件過程比我們想象的要復(fù)雜得多。處理這種過程的復(fù)雜性傳統(tǒng)上是痛苦的，但不必如此。

30多年來，一個(gè)被稱為Saga設(shè)計(jì)模式的具有里程碑意義的軟件開發(fā)手冊(cè)已經(jīng)幫助我們處理了過程復(fù)雜性。它已經(jīng)為數(shù)以千計(jì)的公司提供了服務(wù)，幫助他們構(gòu)建更復(fù)雜的軟件來滿足更高要求的業(yè)務(wù)流程。

這種模式的缺點(diǎn)是成本和復(fù)雜性較高。

在這篇文章中，我們將首先分析Saga模式處理事務(wù)復(fù)雜性的傳統(tǒng)編碼方式，并看看它為什么不起作用。然后，我們將更深入地解釋那些不關(guān)注這個(gè)管道代碼問題的開發(fā)團(tuán)隊(duì)會(huì)發(fā)生什么。最后，我們將展示如何避免隨之而來的項(xiàng)目爛攤子。

滿足持久執(zhí)行的需要

Saga模式的出現(xiàn)是為了應(yīng)對(duì)復(fù)雜軟件過程中的迫切需求：持久執(zhí)行。當(dāng)你正在編寫的事務(wù)進(jìn)行一個(gè)簡單的數(shù)據(jù)庫調(diào)用并獲得快速響應(yīng)時(shí)，你不需要在代碼中容納該事務(wù)之外的任何代碼。然而，當(dāng)事務(wù)依賴于多個(gè)數(shù)據(jù)庫（或者實(shí)際上依賴于其他事務(wù)執(zhí)行）來完成任務(wù)時(shí)，事情就變得更加困難了。

例如，預(yù)訂汽車的應(yīng)用程序可能需要確認(rèn)客戶的帳戶是否良好，其次確認(rèn)他們的位置，再確認(rèn)該區(qū)域內(nèi)有哪些汽車。然后，它進(jìn)行預(yù)訂行程，通知司機(jī)和客戶，然后在行程結(jié)束時(shí)收取客戶的付款，將所有內(nèi)容寫入中央存儲(chǔ)，更新司機(jī)和客戶的帳戶歷史。

此類處理依賴事務(wù)的流程，需要在整個(gè)事件序列中跟蹤數(shù)據(jù)和狀態(tài)。它們必須能夠應(yīng)對(duì)事務(wù)流中出現(xiàn)的問題。如果事務(wù)需要比預(yù)期更長的時(shí)間來返回結(jié)果（可能是網(wǎng)絡(luò)連接中斷了一會(huì)兒，或者數(shù)據(jù)庫達(dá)到峰值負(fù)載，需要更長的時(shí)間來響應(yīng)），那么軟件必須進(jìn)行調(diào)整。

它必須等待必要的事務(wù)完成，重新嘗試直到成功，并協(xié)調(diào)執(zhí)行隊(duì)列中的其他事務(wù)。如果事務(wù)在完成之前崩潰，流程必須能夠回滾到執(zhí)行前的一致狀態(tài)，以保持整個(gè)應(yīng)用程序的完整性。

在需要在幾秒鐘內(nèi)響應(yīng)的用例中，這已經(jīng)足夠困難了。一些應(yīng)用程序可能在數(shù)小時(shí)或數(shù)天內(nèi)完成執(zhí)行，這取決于事務(wù)的性質(zhì)及其支持的流程。開發(fā)人員面臨的挑戰(zhàn)是在整個(gè)執(zhí)行期間維護(hù)流程的狀態(tài)。

這種可靠性（不會(huì)失敗或超時(shí)的事務(wù)）被稱為強(qiáng)執(zhí)行保證。它與不穩(wěn)定執(zhí)行相反，不穩(wěn)定執(zhí)行可以在任何時(shí)候停止，而不完成它應(yīng)該做的所有事情。不穩(wěn)定執(zhí)行會(huì)使系統(tǒng)處于不一致的狀態(tài)。

一開始看似簡單的事情變成了以我們的軟件為中心人物的傳奇故事。開發(fā)人員必須在完成過程中經(jīng)歷多個(gè)步驟，確保我們?cè)诎l(fā)生某些事情時(shí)能夠保留其狀態(tài)。

理解Saga模式

Saga模式為這段旅程提供了一個(gè)路線圖。該模式在1987年的一篇論文中首次討論，它通過允許復(fù)雜流程相互通信，為它們帶來持久執(zhí)行。中央控制器管理該服務(wù)通信和事務(wù)狀態(tài)。

該模式為開發(fā)人員提供了持久執(zhí)行所需的三樣?xùn)|西。它可以將事務(wù)串在一起，以支持長時(shí)間運(yùn)行的流程，并通過在發(fā)生故障時(shí)重試來保證它們的執(zhí)行。它還通過確保流程完全完成或根本不完成來提供一致性。

然而，使用Saga模式需要付出沉重的代價(jià)。雖然這個(gè)概念在原則上沒有問題，但一切都取決于實(shí)現(xiàn)。傳統(tǒng)上，開發(fā)人員必須自己編寫此模式的代碼，作為應(yīng)用程序的一部分。這使得它的設(shè)計(jì)、部署和維護(hù)非常困難，以至于應(yīng)用程序可能成為模式的奴隸，最終占用了開發(fā)人員的大部分時(shí)間。

最終，隨著添加更多事務(wù)，開發(fā)人員將花費(fèi)更多時(shí)間維護(hù)管道代碼。線性開發(fā)工作負(fù)載現(xiàn)在變成了指數(shù)級(jí)。隨著每一個(gè)新的變化，花在開發(fā)上的時(shí)間不成比例地增加。

手動(dòng)編碼Saga模式需要將一個(gè)連貫的流程分解成塊，然后用管理其操作的代碼包裝它們，包括在它們失敗時(shí)重新嘗試它們。開發(fā)人員還必須在相互依賴的不同流程之間管理這些任務(wù)的調(diào)度和協(xié)調(diào)。它們必須使用數(shù)據(jù)庫、隊(duì)列和計(jì)時(shí)器來管理進(jìn)程間的通信。

增加軟件流程和依賴關(guān)系的數(shù)量需要更多的開發(fā)人員時(shí)間來創(chuàng)建和維護(hù)管道基礎(chǔ)設(shè)施，這反過來又增加了應(yīng)用程序成本。這種日益增加的復(fù)雜性也使開發(fā)人員更難證明其代碼的可靠性和安全性，這對(duì)操作和合規(guī)性都有影響。

抽象是關(guān)鍵

抽象是保留Saga模式持久執(zhí)行優(yōu)勢的關(guān)鍵，同時(shí)拋棄其負(fù)面包袱。我們必須通過將事務(wù)序列抽象到另一個(gè)級(jí)別來向他們隱藏事務(wù)序列，而不是讓開發(fā)人員將模式編碼到他們的應(yīng)用程序中。

在計(jì)算中，抽象是一個(gè)很好理解的過程。它給每個(gè)應(yīng)用程序一種錯(cuò)覺，即它擁有一切，消除了開發(fā)人員適應(yīng)它的需要。虛擬化系統(tǒng)在管理程序的幫助下做到這一點(diǎn)。TCP棧通過自動(dòng)重試網(wǎng)絡(luò)連接來實(shí)現(xiàn)，這樣開發(fā)人員就不必編寫自己的握手代碼。關(guān)系數(shù)據(jù)庫在不可見地回滾失敗的事務(wù)以保持它們的一致性時(shí)就會(huì)這樣做。

通過創(chuàng)建Temporal所謂的工作流，運(yùn)行一個(gè)單獨(dú)的平臺(tái)來管理持久執(zhí)行，為事務(wù)排序帶來了這些好處。開發(fā)人員仍然可以控制工作流，但是他們不需要關(guān)心底層機(jī)制。

將持久執(zhí)行抽象到工作流除了易于實(shí)現(xiàn)之外還有其他好處。經(jīng)過嘗試和測試的工作流管理層使復(fù)雜的事務(wù)序列比自制的特別管道代碼更不容易失敗。為每個(gè)項(xiàng)目消除數(shù)千行自定義代碼還可以使代碼更容易維護(hù)，并減少技術(shù)債務(wù)。

開發(fā)人員在調(diào)試時(shí)可以很清楚地看到這些好處。當(dāng)你不得不模擬和管理管道代碼時(shí)，根本原因分析和補(bǔ)救也會(huì)成倍地困難。工作流隱藏了整個(gè)潛在問題層。

高效的開發(fā)人員是快樂的開發(fā)人員

基于工作流的持久執(zhí)行提升了開發(fā)人員的體驗(yàn)。他們沒有消失在事務(wù)管理的漩渦里，而是開始做對(duì)他們來說真正重要的事情。這樣可以提高員工的士氣，很可能有助于留住他們。2021年至2031年間，美國軟件工程師的空缺職位預(yù)計(jì)將增長25%，對(duì)人才的競爭非常激烈。公司承受不起太多的人員流失。

公司在使用Saga模式來處理軟件過程中的上下文切換方面，一直在朝著正確的方向前進(jìn)。但是，他們可以更進(jìn)一步，將這些Saga模式從應(yīng)用程序?qū)映橄蟮絾为?dú)的服務(wù)中。做好這一點(diǎn)可以將組織中的軟件成熟度提前幾年實(shí)現(xiàn)。

2.避免臨界點(diǎn)

在這篇文章的前半部分，我們談到了在應(yīng)用程序?qū)訁f(xié)調(diào)事務(wù)和保存狀態(tài)是多么繁重。現(xiàn)在，我們將討論軟件項(xiàng)目是如何偏離正軌，以及你可以對(duì)此做些什么。

任何規(guī)模合理的軟件工程項(xiàng)目都需要持久的執(zhí)行。

理想情況下，創(chuàng)建新軟件功能所涉及的成本和時(shí)間應(yīng)該是一致的并且是可計(jì)算的。為持久性編寫代碼破壞了這種一致性。它使開發(fā)所涉及的努力看起來更像曲棍球棒曲線，而不是像線性斜率那樣。

臨界點(diǎn)是花在編碼新功能上的時(shí)間和精力開始激增的地方。這是管理長事務(wù)真正變得清晰起來的時(shí)候。我將描述它是什么，為什么會(huì)發(fā)生，以及為什么匆忙編寫管道代碼不是處理它的正確方法。

是什么觸發(fā)了臨界點(diǎn)

在臨界點(diǎn)之前的生活通常是好的，因?yàn)殚_發(fā)人員的體驗(yàn)是線性的。開發(fā)人員正在使用的應(yīng)用程序框架支持開發(fā)人員添加的每一個(gè)新特性，沒有令人討厭的意外。這使得開發(fā)團(tuán)隊(duì)能夠通過可預(yù)測的新功能實(shí)現(xiàn)時(shí)間來擴(kuò)展應(yīng)用程序。

只要開發(fā)者做出定量的改變，添加更多相同的內(nèi)容，這種線性規(guī)模就能發(fā)揮作用。當(dāng)某人必須進(jìn)行與其他更改不同的更改并發(fā)現(xiàn)應(yīng)用程序框架中的缺陷時(shí)，事情往往會(huì)發(fā)生破壞。這通常是一個(gè)質(zhì)變，要求改變應(yīng)用程序的工作方式。

此更改可能涉及對(duì)多個(gè)數(shù)據(jù)庫的調(diào)用，或首次依賴于多個(gè)相關(guān)事務(wù)。它可能調(diào)用一個(gè)流程，該流程需要不可預(yù)知的時(shí)間來給出結(jié)果。

這種變化可能不足以在一開始就達(dá)到臨界點(diǎn)，但開發(fā)人員的生活將開始改變。他們可能會(huì)編寫管道代碼來管理進(jìn)程間通信，以保證執(zhí)行并保持事務(wù)的一致性。但這僅僅是個(gè)開始。編寫這些代碼需要時(shí)間，現(xiàn)在，開發(fā)人員必須對(duì)其進(jìn)行擴(kuò)展，以應(yīng)對(duì)他們引入的每一個(gè)新的質(zhì)變。

他們還會(huì)繼續(xù)這樣做一段時(shí)間，但情況會(huì)越來越糟。最終，隨著添加更多事務(wù)，開發(fā)人員將花費(fèi)更多時(shí)間維護(hù)管道代碼。線性開發(fā)工作負(fù)載現(xiàn)在變成了指數(shù)級(jí)。隨著每一個(gè)新的變化，花在開發(fā)上的時(shí)間不成比例地增加。

“末日會(huì)議”

有些人直到它發(fā)生時(shí)才意識(shí)到臨界點(diǎn)。沒有經(jīng)驗(yàn)的初級(jí)開發(fā)人員經(jīng)常不知不覺地走了進(jìn)去。資深開發(fā)人員往往處于最糟糕的境地，他們知道臨界點(diǎn)即將到來，但日常的事務(wù)往往使他們無能為力，只能等待并收拾殘局。

最終，有人提出了一個(gè)改變，使問題浮出水面。這是壓垮駱駝的最后一根稻草。也許某個(gè)變更打破了軟件交付計(jì)劃，有影響力的人會(huì)抱怨。因此，有人稱之為“末日會(huì)議”。

在這次會(huì)議上，團(tuán)隊(duì)承認(rèn)他們目前的方法是不可持續(xù)的。應(yīng)用程序變得如此復(fù)雜，以至于這些特別的管道更改不再支持項(xiàng)目進(jìn)度或預(yù)算。

這一認(rèn)識(shí)讓開發(fā)者經(jīng)歷了悲傷的五個(gè)階段：

• 否認(rèn)。這種情況會(huì)持續(xù)一段時(shí)間。人們?cè)噲D忽略這個(gè)問題，認(rèn)為繼續(xù)這樣就好了。這需讓位于……
• 憤怒。有人在會(huì)議上解釋說這是不行的。他們的預(yù)算被打破了；他們的時(shí)間表被打亂了；這個(gè)問題需要解決。他們不接受否定的答復(fù)。所以人們?cè)囍?/span>
• 討價(jià)還價(jià)。人們會(huì)想出創(chuàng)造性的方法，用更特別的改變來支撐事情更長時(shí)間。但最終，他們意識(shí)到這是不可擴(kuò)展的，導(dǎo)致……
• 抑郁。最后，開發(fā)人員意識(shí)到他們將不得不進(jìn)行更基本的架構(gòu)更改。他們的臨時(shí)管道規(guī)范已經(jīng)自生自滅了。這與……密切相關(guān)。
• 接受。每個(gè)人都帶著一種厄運(yùn)的感覺離開會(huì)議，知道在這之后不會(huì)有什么好結(jié)果。是時(shí)候取消幾個(gè)周末，開始工作了。

末日的感覺是有道理的。正如我所解釋的，管道代碼很難編寫和維護(hù)。從臨界點(diǎn)開始，隨著開發(fā)人員發(fā)現(xiàn)代碼更難編寫和維護(hù)，事情變得更加困難。突然之間，他們所習(xí)慣的線性編程經(jīng)驗(yàn)消失了。他們花更多的時(shí)間編寫事務(wù)管理代碼，而不是在看板上使用軟件功能。這將導(dǎo)致開發(fā)者精疲力竭，并最終導(dǎo)致人員流失。

防止臨界點(diǎn)

我們?nèi)绾伪苊膺@個(gè)臨界點(diǎn)，就像使曲棍球桿曲線變得平滑，并保持軟件功能和開發(fā)時(shí)間之間的線性比例？第一個(gè)建議通常是接受這次的失敗，并保證下次從頭開始編寫管道代碼，或者重用已經(jīng)拼湊起來的代碼。

這行不通。這給我們留下了同樣的問題，即管道代碼最終將變得無法管理。與其說這是一個(gè)臨界點(diǎn)，發(fā)展會(huì)更早地失去線性。你會(huì)從項(xiàng)目開始就逐漸陷入開發(fā)焦慮。

相反，開發(fā)團(tuán)隊(duì)需要做的是它一開始就應(yīng)該做的事情：進(jìn)行重大的架構(gòu)變更，以支持系統(tǒng)地持久執(zhí)行。

我們已經(jīng)討論了抽象作為前進(jìn)的方向。在編寫更多的項(xiàng)目代碼之前，首先將管道功能從應(yīng)用程序?qū)映橄蟮剿鼈冏约旱姆?wù)層。這將通過消除非線性工作來減輕開發(fā)人員的負(fù)擔(dān)，使他們能夠擴(kuò)展并保持實(shí)現(xiàn)新功能所需的時(shí)間不變。

這種抽象維護(hù)了程序員的線性體驗(yàn)。他們總覺得自己能掌控自己的時(shí)間，而且確信自己能把事情做好。他們將不再需要考慮緩存和排隊(duì)等任務(wù)的戰(zhàn)略決策。他們也不必?fù)?dān)心將龐大的軟件工具和庫組合在一起來管理這些任務(wù)。

擁有抽象的事務(wù)工作流集的項(xiàng)目經(jīng)理將和開發(fā)人員一樣高興。確定性和可預(yù)測性是它們的關(guān)鍵要求，這使得打破線性發(fā)展的臨界點(diǎn)尤其成問題。抽象事務(wù)排序的任務(wù)消除了意想不到的開發(fā)人員工作量，并保持了線性，為他們提供了滿足調(diào)度和預(yù)算承諾所需的確定性。

支持這種抽象和將管道代碼轉(zhuǎn)換為可管理工作流的工具將幫助您保持可預(yù)測的軟件開發(fā)實(shí)踐，消除可怕的臨界點(diǎn)，并為您節(jié)省項(xiàng)目補(bǔ)救的壓力。部署這些抽象服務(wù)的最佳時(shí)間是在項(xiàng)目開始之前，但是即使你的團(tuán)隊(duì)現(xiàn)在處于危機(jī)之中，它也提供了一種擺脫困境的方法。

譯者介紹

涂承燁，51CTO社區(qū)編輯，省政府采購專家、省綜合性評(píng)標(biāo)專家、公 E 采招標(biāo)采購專家，獲得信息系統(tǒng)項(xiàng)目管理師、信息系統(tǒng)監(jiān)理師、PMP，CSPM-2等認(rèn)證，擁有15年以上的開發(fā)、項(xiàng)目管理、咨詢?cè)O(shè)計(jì)等經(jīng)驗(yàn)。對(duì)項(xiàng)目管理、前后端開發(fā)、微服務(wù)、架構(gòu)設(shè)計(jì)、物聯(lián)網(wǎng)、大數(shù)據(jù)、咨詢?cè)O(shè)計(jì)等較為關(guān)注。

原文標(biāo)題：Saga Without the Headaches，作者：Dominik Tornow