#5 可移植性與遷移

時(shí)間：2022-03-04 18:40:01 | 來(lái)源：行業(yè)動(dòng)態(tài)

時(shí)間：2022-03-04 18:40:01 來(lái)源：行業(yè)動(dòng)態(tài)

無(wú)服務(wù)器：假定大家已經(jīng)在使用AWS的多種不同服務(wù)，這時(shí)候選擇Lambda函數(shù)肯定是明智之舉，因?yàn)槠淠軌蚺c其他服務(wù)順暢集成且可支持快速訪問(wèn)。

即使您并沒(méi)有使用AWS服務(wù)、而且擔(dān)心供應(yīng)商鎖定問(wèn)題，也可以通過(guò)域映射/DNS變更等方式保證代碼中使用的所有API端點(diǎn)和URL始終處于您的控制之下。

這樣我們就可以隨時(shí)切斷特定服務(wù)，并將其重新定向至您所選定的其他端點(diǎn)（例如其他FaaS服務(wù)商）。這種方式顯然比在不受控制或者您無(wú)法調(diào)整的端點(diǎn)中部署硬編碼代碼要安全得多。

但考慮到市面上FaaS服務(wù)商眾多，大家對(duì)供應(yīng)商鎖定問(wèn)題的擔(dān)憂也自有道理。以Lambda為例，如果它無(wú)法滿足您所在地區(qū)的特定要求，大家可以執(zhí)行以下操作。一切Lambda處理程序的代碼都應(yīng)處于隔離狀態(tài)，僅僅以墊片的形式在其他模塊/類中充當(dāng)邏輯。

這種方式不僅提高了可重用性，而且能夠大大降低重構(gòu)時(shí)Lambda遷移的便捷度與直接性。另外，這種方式還有利于支持單元測(cè)試。下面來(lái)看瘦Lambda處理程序?qū)嵗?br />
說(shuō)起遷移，目前人們對(duì)于如何將FaaS融入現(xiàn)有DevOps框架仍充當(dāng)爭(zhēng)議。組織可能一口氣編寫了幾百個(gè)函數(shù)，但在一段時(shí)間之后再也沒(méi)人清楚哪些函數(shù)中包含著哪些其他函數(shù)、又有多少函數(shù)仍在正常使用。

容器：如果大家選擇了基于容器的微服務(wù)架構(gòu)，就能享受到由此帶來(lái)的良好可移植性。我們可以輕松將程序代碼從開發(fā)者的筆記本電腦處轉(zhuǎn)移到本地?cái)?shù)據(jù)中心或者不同云服務(wù)商的云計(jì)算平臺(tái)，整個(gè)過(guò)程既不費(fèi)力也不費(fèi)神。

隨著企業(yè)承擔(dān)的創(chuàng)新壓力越來(lái)越大、產(chǎn)品上市時(shí)間越來(lái)越短，微服務(wù)架構(gòu)的加持能幫助大家快速為應(yīng)用程序建立起全新版本。因此，如果大家是出于降低遷移難度、使用豐富的容器技術(shù)堆棧等目的而決定從單體式應(yīng)用程序轉(zhuǎn)向容器，那么微服務(wù)架構(gòu)應(yīng)該是個(gè)理想的探索起點(diǎn)。

然而，在云平臺(tái)上運(yùn)行容器時(shí)仍然涉及眾多依賴項(xiàng)。例如代碼升級(jí)需要協(xié)同規(guī)劃，具體涵蓋容器主機(jī)、容器鏡像、容器引擎以及容器編排等。

對(duì)于某些需要遷移至微服務(wù)形式的遺留應(yīng)用程序，直接容器化所帶來(lái)的操作難度和成本往往要低于對(duì)整體應(yīng)用程序進(jìn)行重構(gòu)。