[[317866]]

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

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

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

1. 應(yīng)該何時進行變更？

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

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

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

2. 應(yīng)該如何進行變更

一旦確定你正在開發(fā)的產(chǎn)品需要升級，那么就是時候?qū)ψ兏较蜃龀雒髦堑臎Q定了。代碼一旦編寫就會成為遺留代碼， 沒有人能保證你當(dāng)時編寫所用的技術(shù)在未來不會失去支持或變得過時。（安息吧，AngularJS。）因此，變更應(yīng)該支持未來的靈活性。以下是一些選項：

選項一：大爆炸式的重寫

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

選項二：鳳凰涅槃

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

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

選項三：混合方法

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

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

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

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

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

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

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

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

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

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

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

作者介紹

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