[[317866]]

在傳統(tǒng)企業(yè)甚至互聯(lián)網企業(yè)中往往存在大量的遺留代碼，這些遺留代碼大多都能夠正常工作，有的可能還運行著關鍵業(yè)務或者持有核心數(shù)據(jù)。但是，大部分遺留代碼通常經常存在技術陳舊、代碼復雜、難以修改等特點。隨著時間的推移，遺留代碼的維護和管理的成本越來越大。在全面轉型微服務的今天，這些遺留代碼該如何處理呢？Tomasz Kania-Orzeł 為我們闡述了升級遺留代碼的最佳實踐，我相信，這篇文章對于擁有大量遺留代碼的企業(yè) / 組織很有借鑒意義。

“我在 Ruby on Rails 上有一款可以追溯到 2011 年的應用，在過去五年來沒有添加任何新功能。而且它現(xiàn)在運行死慢死慢的，隨著我們用戶群不斷地增長，它已經幾乎不能提供服務了。您能幫我們解決這個問題嗎？”

這是我在 Monterail 的客戶那兒遇到的最常見的情景之一。這種難以維護且存在安全漏洞的遺留代碼，對于必須使用它的企業(yè)，以及必須處理它的開發(fā)人員（比如我們）來說，真不啻噩夢一場。在我擔任軟件工程師十年左右的時間里，有過很多機會讓我得以觀察一些開發(fā)人員為了更新 Web 應用程序中的遺留代碼而進行的技術轉變，這些技術轉變有成功，也有失敗。例如，這可能意味著，從某個框架的版本 2 升級為版本 6，或者從 Ruby 變更為 Python，或者從單體應用轉變?yōu)槲⒎占軜嫞蛘邚氖止嫿ǜ臑槌掷m(xù)交付。為了完成一次無痛（或至少不那么痛苦）更新，你必須確定進行更改是否有必要，確定最合適自己的方法并承諾長期踐行。

1. 應該何時進行變更？

糟糕的性能是做出技術變更的原因。另一個原因就是你所使用的技術的普及程度逐漸或突然下降了。畢竟，如果市場上能夠支持你工作的開發(fā)人員越來越少，那么你的技術存在被封閉的風險就越來越大。有些人早在 2010 年就用 Backbone 構建了他們的應用程序，如今卻在努力解決“模型 - 視圖 - 控制器”的問題，而其他人都在使用基于組件的框架，如 React 或 Vue 等。如果你選擇的框架正在失去積極的支持，那么風險就會更大。還記得 AngularJS 嗎？2018 年 7 月，它就進入了長期支持階段，這意味著 Google 不會再合并新的功能或修補程序，哪怕是一個微小的突破性改動。

譯注：“模型 - 視圖 - 控制器”（Model–view–controller，MVC），是是軟件工程中的一種軟件架構模式，把軟件系統(tǒng)分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。MVC 最早由 Trygve Reenskaug 在 1978 年提出，是 Xerox PARC 在 20 世紀 80 年代為程序語言 Smalltalk 發(fā)明的一種軟件架構。MVC 的目的是實現(xiàn)一種動態(tài)的程式設計，使后續(xù)對程序的修改和擴展簡化，并且使程序某一部分的重復利用成為可能。除此之外，MVC 通過對復雜度的簡化，使程序結構更加直觀。

當你的技術在人力或機器成本方面過于低效、過于昂貴，這不僅是發(fā)起技術變更的一個好機會，而且也可能是你在技術變得不可挽回之前修復它的最后機會。你永遠不會想達到這樣的地步：創(chuàng)建一個新功能是完全不可行的。歐洲電子商務公司 Zalando 正努力快速擴展其單體 PHP 應用程序，卻 無法以快速或高效的方式提供新功能。這促使他們在 2016 年從單體架構應用轉向微服務，使不同的團隊能夠以更快的速度交付功能。

2. 應該如何進行變更

一旦確定你正在開發(fā)的產品需要升級，那么就是時候對變更方向做出明智的決定了。代碼一旦編寫就會成為遺留代碼， 沒有人能保證你當時編寫所用的技術在未來不會失去支持或變得過時。（安息吧，AngularJS。）因此，變更應該支持未來的靈活性。以下是一些選項：

選項一：大爆炸式的重寫

第一個也是最明顯的選項，就是大爆炸式的重寫：從頭開始更改代碼庫，并在一次轉換中切換所有用戶。但是，完全重寫是非常耗時的，而且必然也會產生相當巨大的成本。你也有可能最終得到的是一款在幾個月甚至幾年內都不適合發(fā)布的應用程序，并且在這個過程結束之前，你都無法看到最終結果。另外，應用程序越大，開發(fā)者在重寫過程中提供維護和添加新功能的難度就越大。如果有文檔和技術知識的話，向大型代碼庫添加新功能就像在公園里散步一樣簡單。若沒有這些的話，要做到這些，真的很難。

選項二：鳳凰涅槃

第二個選項是在現(xiàn)有代碼庫中添加使用新技術構建的新功能。理想情況下，你不應該觸及舊技術，而應該將所有新功能分離開來。但不幸的是，這樣的原始結果相當罕見：新功能幾乎總是需要與舊功能集成。這也需要一個詳細的計劃，因為事情很復雜，沒有周密計劃的話很難做好。在復雜的架構中創(chuàng)建新的組件，需要大量關于遺留應用程序中組件運行情況的信息。你需要一個廣闊的視角，從新舊兩個角度看待這項技術。

使用單體應用程序，你可以在單獨部署的新代碼庫中創(chuàng)建新功能，同時使用與新代碼和遺留代碼交互的單個數(shù)據(jù)庫來存儲數(shù)據(jù)。這個解決方案看起來很簡單，但它能否取得長期成功，要取決于你的承諾是否堅如磐石。（特別是當你的整體系統(tǒng)受到機器性能或并發(fā)性問題的影響時，就需要考慮這些問題。）例如，如果你的單體應用程序開始獲得更多的用戶，那么，單個數(shù)據(jù)庫可能會成為瓶頸。（另一方面，云端中的數(shù)據(jù)庫可以擴展。）由于原始代碼庫的長期脆弱性，特別是考慮到潛在的安全漏洞或 bug，這種架構并不能持久。實際上，讓過時的代碼保持原樣就意味著你在等待它最終永遠失敗。

選項三：混合方法

重寫整個代碼庫是一個極端的想法，而且往往考慮不周。在舊代碼庫上添加新功能更可行，但會帶來嚴重的副作用，例如，如果你的遺留代碼是基于較舊的框架版本，那么就會出現(xiàn)安全問題。那么，還有什么事情是你可以做的，而且不那么昂貴，或者不那么危險的？ 你還有其他選擇嗎？

我推薦一種混合方法。這一選項，就像大爆炸式重寫一樣，也需要對整個舊代碼進行變更。但與第一種選項不同的是，重寫應該是在一段時間內展開（比如說幾年），以最大限度地減少技術債務和財務成本。這種漸進式方法將基于你的愿景，這一點至關重要。你需要知道首先要改變什么：有些功能是核心的，對業(yè)務至關重要，而其他功能則更多的是扮演輔助角色。有了明確的目標，在多個層面上工作就會變得更容易。例如，你是否仍然計劃在這個轉換過程中發(fā)布一項新功能？如果是這樣的話，你就需要在計劃中考慮到這一點。如果沒有清晰的路線圖，你的代碼最終將會變得一團糟，這將會使開發(fā)者更難理解。

對我來說，這種方法關乎未來和可擴展性：而且它最容易使用微服務來實現(xiàn)。假設你的遺留代碼庫是新的微服務生態(tài)系統(tǒng)中的一個元素。當然，它太過于龐大，過于復雜，不可能是真正的微服務，但它可以像微服務一樣與新功能進行通信。為了處理這種安排，你需要創(chuàng)建 API 或“橋”這樣的接口，以允許遺留代碼與新技術進行通訊。當你以單獨的微服務形式添加新功能時，它們將會一點一點地吞噬遺留代碼的業(yè)務邏輯。雖然你可以通過向遺留的單體應用程序添加新功能來實現(xiàn)類似的功能，但此舉可能會造成技術債務，并失去靈活性。

幾乎所有的解決方案都有副作用，包括這種方法。但是我們需要知道如何將副作用最小化。對于 Web 應用的前端，反向代理可以緩和這一變更帶來的副作用。使用這種方法，你甚至可以在不觸及遺留軟件的情況下，替換 Web 應用中為單個 URL 提供服務的邏輯。但這種技術有其自身的要求，例如，如果你有用戶登錄的話，就應該維護頁面之間的狀態(tài)。我們始終需要存儲狀態(tài)，但在這個解決方案中，我們需要在兩個應用之間移動或共享狀態(tài)。這很難維護，但你還是可以得到更具彈性的基礎設施。

更復雜的更改需要對基礎設施進行改進，比如，創(chuàng)建一個前端服務器層，你可以從其中呈現(xiàn)來自不同源的應用程序片段，如上面的微服務示例。基于 XML 的標記語言 ESI（Edge Sides Includes）可能適合這項任務，而 Varish 或 Nginx 然后，為了確保你的應用在用戶群增長時能夠保持性能，請創(chuàng)建負載均衡器和基于上下文的獨立數(shù)據(jù)庫，這些數(shù)據(jù)庫在微服務或宏服務中單獨使用。

創(chuàng)造一個能夠支持這種安排的靈活環(huán)境也是一個挑戰(zhàn)。轉移到微服務時，你只需在基礎設施上投資一次，但你將需要進一步支持這種架構的維護。盡管如此，它可能仍然比重寫所有代碼要便宜得多。

如果你的主要目標是創(chuàng)建一個易于維護的生態(tài)系統(tǒng)（而不是關注性能第一，維護第二），你還需要在開發(fā)過程中確定系統(tǒng)的關鍵元素，并創(chuàng)建路線圖來對它們進行更改。在這個過程中引入一些持續(xù)集成和部署的魔法，其中，CI 和 CD 流程可以在沒有 QA 或開發(fā)人員的幫助就能自動進行，然后你最終將得到一個結構清晰、易于修改和調整的成熟軟件。

當然，這種混合方法并不是世界上唯一可行或正在使用的選項。但是，代碼庫的增量更改最終導致了完全重寫，你得以能夠使用工作代碼，從而使業(yè)務保持安全，同時，微服務使不同團隊能夠獨立地交付新的和不同的功能，提供了一個為長期使用而設計的過程和架構。

3. 要做持久的更改需要什么？

你可能會看著我的首選解決方案，然后心想，“嗯，這有點過于工程化了”，或者“我沒有一個團隊能勝任這種工作”，或者“這對我的平臺來說太過于復雜”，或者甚至“這不是純粹的微服務架構！”我并不反對你這些想法，但我確實認為，升級你的技術將會迫使你作長遠考慮。

我提供的并不是快速解決方案。相反，混合方法為你提供了基于工作基礎之上的新技術。通過逐步轉向微服務，增量更改允許你輕松地更新應用程序，并利用最新的框架，所有這些都不會迫使你在可靠性上作出妥協(xié)。那么，你準備好重新構建你的軟件了嗎？

作者介紹

Tomasz Kania-Orzel，是一名經驗豐富的軟件和 DevOps 工程師，最喜歡研究前端技術。目前在 Monterail 擔任技術主管，領導一支由 75 名開發(fā)人員組成的團隊。