譯者 | 涂承燁
審校 | 重樓
Saga模式是實現持久微服務執行的好工具，但它會使維護變得困難。這里有一個讓它為你的系統工作的方法。
1.Sagas的問題
在項目中，我們都經歷過這樣的時刻：我們意識到軟件過程比我們想象的要復雜得多。處理這種過程的復雜性傳統上是痛苦的，但不必如此。
30多年來，一個被稱為Saga設計模式的具有里程碑意義的軟件開發手冊已經幫助我們處理了過程復雜性。它已經為數以千計的公司提供了服務，幫助他們構建更復雜的軟件來滿足更高要求的業務流程。
這種模式的缺點是成本和復雜性較高。
在這篇文章中，我們將首先分析Saga模式處理事務復雜性的傳統編碼方式，并看看它為什么不起作用。然后，我們將更深入地解釋那些不關注這個管道代碼問題的開發團隊會發生什么。最后，我們將展示如何避免隨之而來的項目爛攤子。
滿足持久執行的需要
Saga模式的出現是為了應對復雜軟件過程中的迫切需求：持久執行。當你正在編寫的事務進行一個簡單的數據庫調用并獲得快速響應時，你不需要在代碼中容納該事務之外的任何代碼。然而，當事務依賴于多個數據庫（或者實際上依賴于其他事務執行）來完成任務時，事情就變得更加困難了。
例如，預訂汽車的應用程序可能需要確認客戶的帳戶是否良好，其次確認他們的位置，再確認該區域內有哪些汽車。然后，它進行預訂行程，通知司機和客戶，然后在行程結束時收取客戶的付款，將所有內容寫入中央存儲，更新司機和客戶的帳戶歷史。
此類處理依賴事務的流程，需要在整個事件序列中跟蹤數據和狀態。它們必須能夠應對事務流中出現的問題。如果事務需要比預期更長的時間來返回結果（可能是網絡連接中斷了一會兒，或者數據庫達到峰值負載，需要更長的時間來響應），那么軟件必須進行調整。
它必須等待必要的事務完成，重新嘗試直到成功，并協調執行隊列中的其他事務。如果事務在完成之前崩潰，流程必須能夠回滾到執行前的一致狀態，以保持整個應用程序的完整性。
在需要在幾秒鐘內響應的用例中，這已經足夠困難了。一些應用程序可能在數小時或數天內完成執行，這取決于事務的性質及其支持的流程。開發人員面臨的挑戰是在整個執行期間維護流程的狀態。
這種可靠性（不會失敗或超時的事務）被稱為強執行保證。它與不穩定執行相反，不穩定執行可以在任何時候停止，而不完成它應該做的所有事情。不穩定執行會使系統處于不一致的狀態。
一開始看似簡單的事情變成了以我們的軟件為中心人物的傳奇故事。開發人員必須在完成過程中經歷多個步驟，確保我們在發生某些事情時能夠保留其狀態。
理解Saga模式
Saga模式為這段旅程提供了一個路線圖。該模式在1987年的一篇論文中首次討論，它通過允許復雜流程相互通信，為它們帶來持久執行。中央控制器管理該服務通信和事務狀態。
該模式為開發人員提供了持久執行所需的三樣東西。它可以將事務串在一起，以支持長時間運行的流程，并通過在發生故障時重試來保證它們的執行。它還通過確保流程完全完成或根本不完成來提供一致性。
然而，使用Saga模式需要付出沉重的代價。雖然這個概念在原則上沒有問題，但一切都取決于實現。傳統上，開發人員必須自己編寫此模式的代碼，作為應用程序的一部分。這使得它的設計、部署和維護非常困難，以至于應用程序可能成為模式的奴隸，最終占用了開發人員的大部分時間。
最終，隨著添加更多事務，開發人員將花費更多時間維護管道代碼。線性開發工作負載現在變成了指數級。隨著每一個新的變化，花在開發上的時間不成比例地增加。
手動編碼Saga模式需要將一個連貫的流程分解成塊，然后用管理其操作的代碼包裝它們，包括在它們失敗時重新嘗試它們。開發人員還必須在相互依賴的不同流程之間管理這些任務的調度和協調。它們必須使用數據庫、隊列和計時器來管理進程間的通信。
增加軟件流程和依賴關系的數量需要更多的開發人員時間來創建和維護管道基礎設施，這反過來又增加了應用程序成本。這種日益增加的復雜性也使開發人員更難證明其代碼的可靠性和安全性，這對操作和合規性都有影響。
抽象是關鍵
抽象是保留Saga模式持久執行優勢的關鍵，同時拋棄其負面包袱。我們必須通過將事務序列抽象到另一個級別來向他們隱藏事務序列，而不是讓開發人員將模式編碼到他們的應用程序中。
在計算中，抽象是一個很好理解的過程。它給每個應用程序一種錯覺，即它擁有一切，消除了開發人員適應它的需要。虛擬化系統在管理程序的幫助下做到這一點。TCP棧通過自動重試網絡連接來實現，這樣開發人員就不必編寫自己的握手代碼。關系數據庫在不可見地回滾失敗的事務以保持它們的一致性時就會這樣做。
通過創建Temporal所謂的工作流，運行一個單獨的平臺來管理持久執行，為事務排序帶來了這些好處。開發人員仍然可以控制工作流，但是他們不需要關心底層機制。
將持久執行抽象到工作流除了易于實現之外還有其他好處。經過嘗試和測試的工作流管理層使復雜的事務序列比自制的特別管道代碼更不容易失敗。為每個項目消除數千行自定義代碼還可以使代碼更容易維護，并減少技術債務。
開發人員在調試時可以很清楚地看到這些好處。當你不得不模擬和管理管道代碼時，根本原因分析和補救也會成倍地困難。工作流隱藏了整個潛在問題層。
高效的開發人員是快樂的開發人員
基于工作流的持久執行提升了開發人員的體驗。他們沒有消失在事務管理的漩渦里，而是開始做對他們來說真正重要的事情。這樣可以提高員工的士氣，很可能有助于留住他們。2021年至2031年間，美國軟件工程師的空缺職位預計將增長25%，對人才的競爭非常激烈。公司承受不起太多的人員流失。
公司在使用Saga模式來處理軟件過程中的上下文切換方面，一直在朝著正確的方向前進。但是，他們可以更進一步，將這些Saga模式從應用程序層抽象到單獨的服務中。做好這一點可以將組織中的軟件成熟度提前幾年實現。
2.避免臨界點
在這篇文章的前半部分，我們談到了在應用程序層協調事務和保存狀態是多么繁重。現在，我們將討論軟件項目是如何偏離正軌，以及你可以對此做些什么。
任何規模合理的軟件工程項目都需要持久的執行。
理想情況下，創建新軟件功能所涉及的成本和時間應該是一致的并且是可計算的。為持久性編寫代碼破壞了這種一致性。它使開發所涉及的努力看起來更像曲棍球棒曲線，而不是像線性斜率那樣。
臨界點是花在編碼新功能上的時間和精力開始激增的地方。這是管理長事務真正變得清晰起來的時候。我將描述它是什么，為什么會發生，以及為什么匆忙編寫管道代碼不是處理它的正確方法。
是什么觸發了臨界點
在臨界點之前的生活通常是好的，因為開發人員的體驗是線性的。開發人員正在使用的應用程序框架支持開發人員添加的每一個新特性，沒有令人討厭的意外。這使得開發團隊能夠通過可預測的新功能實現時間來擴展應用程序。
只要開發者做出定量的改變，添加更多相同的內容，這種線性規模就能發揮作用。當某人必須進行與其他更改不同的更改并發現應用程序框架中的缺陷時，事情往往會發生破壞。這通常是一個質變，要求改變應用程序的工作方式。
此更改可能涉及對多個數據庫的調用，或首次依賴于多個相關事務。它可能調用一個流程，該流程需要不可預知的時間來給出結果。
這種變化可能不足以在一開始就達到臨界點，但開發人員的生活將開始改變。他們可能會編寫管道代碼來管理進程間通信，以保證執行并保持事務的一致性。但這僅僅是個開始。編寫這些代碼需要時間，現在，開發人員必須對其進行擴展，以應對他們引入的每一個新的質變。
他們還會繼續這樣做一段時間，但情況會越來越糟。最終，隨著添加更多事務，開發人員將花費更多時間維護管道代碼。線性開發工作負載現在變成了指數級。隨著每一個新的變化，花在開發上的時間不成比例地增加。
“末日會議”
有些人直到它發生時才意識到臨界點。沒有經驗的初級開發人員經常不知不覺地走了進去。資深開發人員往往處于最糟糕的境地，他們知道臨界點即將到來，但日常的事務往往使他們無能為力，只能等待并收拾殘局。
最終，有人提出了一個改變，使問題浮出水面。這是壓垮駱駝的最后一根稻草。也許某個變更打破了軟件交付計劃，有影響力的人會抱怨。因此，有人稱之為“末日會議”。
在這次會議上，團隊承認他們目前的方法是不可持續的。應用程序變得如此復雜，以至于這些特別的管道更改不再支持項目進度或預算。
這一認識讓開發者經歷了悲傷的五個階段：
- 否認。這種情況會持續一段時間。人們試圖忽略這個問題，認為繼續這樣就好了。這需讓位于……
- 憤怒。有人在會議上解釋說這是不行的。他們的預算被打破了；他們的時間表被打亂了；這個問題需要解決。他們不接受否定的答復。所以人們試著…
- 討價還價。人們會想出創造性的方法，用更特別的改變來支撐事情更長時間。但最終，他們意識到這是不可擴展的，導致……
- 抑郁。最后，開發人員意識到他們將不得不進行更基本的架構更改。他們的臨時管道規范已經自生自滅了。這與……密切相關。
- 接受。每個人都帶著一種厄運的感覺離開會議，知道在這之后不會有什么好結果。是時候取消幾個周末，開始工作了。
末日的感覺是有道理的。正如我所解釋的，管道代碼很難編寫和維護。從臨界點開始，隨著開發人員發現代碼更難編寫和維護，事情變得更加困難。突然之間，他們所習慣的線性編程經驗消失了。他們花更多的時間編寫事務管理代碼，而不是在看板上使用軟件功能。這將導致開發者精疲力竭，并最終導致人員流失。
防止臨界點
我們如何避免這個臨界點，就像使曲棍球桿曲線變得平滑，并保持軟件功能和開發時間之間的線性比例？第一個建議通常是接受這次的失敗，并保證下次從頭開始編寫管道代碼，或者重用已經拼湊起來的代碼。
這行不通。這給我們留下了同樣的問題，即管道代碼最終將變得無法管理。與其說這是一個臨界點，發展會更早地失去線性。你會從項目開始就逐漸陷入開發焦慮。
相反，開發團隊需要做的是它一開始就應該做的事情：進行重大的架構變更，以支持系統地持久執行。
我們已經討論了抽象作為前進的方向。在編寫更多的項目代碼之前，首先將管道功能從應用程序層抽象到它們自己的服務層。這將通過消除非線性工作來減輕開發人員的負擔，使他們能夠擴展并保持實現新功能所需的時間不變。
這種抽象維護了程序員的線性體驗。他們總覺得自己能掌控自己的時間，而且確信自己能把事情做好。他們將不再需要考慮緩存和排隊等任務的戰略決策。他們也不必擔心將龐大的軟件工具和庫組合在一起來管理這些任務。
擁有抽象的事務工作流集的項目經理將和開發人員一樣高興。確定性和可預測性是它們的關鍵要求，這使得打破線性發展的臨界點尤其成問題。抽象事務排序的任務消除了意想不到的開發人員工作量，并保持了線性，為他們提供了滿足調度和預算承諾所需的確定性。
支持這種抽象和將管道代碼轉換為可管理工作流的工具將幫助您保持可預測的軟件開發實踐，消除可怕的臨界點，并為您節省項目補救的壓力。部署這些抽象服務的最佳時間是在項目開始之前，但是即使你的團隊現在處于危機之中，它也提供了一種擺脫困境的方法。
譯者介紹
涂承燁，51CTO社區編輯，省政府采購專家、省綜合性評標專家、公 E 采招標采購專家，獲得信息系統項目管理師、信息系統監理師、PMP，CSPM-2等認證，擁有15年以上的開發、項目管理、咨詢設計等經驗。對項目管理、前后端開發、微服務、架構設計、物聯網、大數據、咨詢設計等較為關注。
原文標題：Saga Without the Headaches，作者：Dominik Tornow
