Cloudflare：為什么要使用無服務器計算？

為什么要使用無服務器計算？

與傳統(tǒng)的基于云或以服務器為中心的基礎設施相比，無服務器計算具有諸多優(yōu)勢。對于許多開發(fā)人員而言，無服務器架構以更低的成本提供了更大的可擴展性、更大的靈活性以及更快的發(fā)布時間。借助無服務器體系結構，開發(fā)人員無需擔心購買、供應和管理后端服務器的事宜。但是，無服務器計算并不是所有Web應用程序開發(fā)人員的靈丹妙藥。

無服務器計算的工作原理

無服務器計算是一種體系結構，供應商可在其中提供客戶所需的后端服務。要了解有關無服務器計算的更多信息，請參閱什么是無服務器計算？

無服務器計算的優(yōu)勢是什么？

無需服務器管理

盡管“無服務器”計算實際上是在服務器上進行的，但開發(fā)人員無需管理服務器-它們由供應商管理。這可以減少DevOps中的必要投資，從而降低支出，還可以使開發(fā)人員專注于創(chuàng)建和擴展應用程序，而不受服務器容量的限制。

開發(fā)人員僅對其使用的服務器空間付費，因此降低了成本

與“按需付費”電話計劃一樣，開發(fā)人員僅需為使用量付費。僅當無服務器應用程序需要后端函數時，代碼才會運行，并且代碼會根據需要自動擴展。調配是動態(tài)、精確、實時的。一些服務的精確度極高，以至于費用細分到100毫秒的增量。相比之下，在傳統(tǒng)的“全套服務器”架構中，開發(fā)人員必須預先計劃所需的服務器容量，然后購買容量，而不管最終是否會用上。

無服務器架構本身具有可擴展性

想象一下，如果郵局可以以某種方式神奇地隨意增減郵遞卡車，隨著郵件數量的增加（例如，在母親節(jié)之前）擴大車隊的規(guī)模，并在需要減少送貨次數的時候縮小車隊，會多么成本高效。從本質上講，無服務器應用程序就起到這樣的作用。

使用無服務器基礎設施構建的應用程序將隨著用戶群的增加或使用量的增加而自動擴展。如果一個函數需要在多個實例中運行，則供應商的服務器將根據需要啟動、運行并結束，并且通常使用容器（如果這些函數最近運行過，它們的啟動速度會更快-請參閱下文“性能可能受到影響”）。因此，無服務器應用程序能夠處理異常大量的請求，也能夠處理來自單個用戶的單個請求。具有固定服務器空間量的傳統(tǒng)結構化應用程序可能會因使用量的突然增加而不堪重負。

快速部署和更新

使用無服務器基礎設施，無需將代碼發(fā)布到服務器或進行任何后端配置即可發(fā)布應用程序的有效版本。開發(fā)人員可以非?？焖俚厣蟼魃倭看a并發(fā)布新產品。他們可以一次上傳全部代碼，也可以一次上傳一個函數，因為應用程序不是單個的單體堆棧，而是供應商提供的函數的集合。

這也使得開發(fā)人員可以快速更新、修補、修復或向應用程序添加新功能。不必對整個應用程序進行更改；開發(fā)人員可以一次更新一個函數。

代碼可以在更接近最終用戶的位置運行，從而減少延遲

因為應用程序未托管在源站，所以它的代碼可以在任何地方運行。因此，根據所使用的供應商，應用程序函數可能在接近最終用戶的服務器上運行。這減少了等待時間，因為來自用戶的請求不再必須一直傳遞到源站。Cloudflare Workers支持這種無服務器延遲縮減。

無服務器計算有什么缺點？

測試和調試變得更具挑戰(zhàn)性

復制無服務器環(huán)境以查看代碼在部署后將如何實際執(zhí)行是非常困難的。調試更加復雜，因為開發(fā)人員無法查看后端流程，并且因為應用程序被分解為較小的獨立函數。Cloudflare Workers Playground是一個沙箱，可幫助減少測試和調試中的摩擦。

無服務器計算會引入新的安全問題

當供應商運行整個后端時，可能無法完全審查其安全性，這對于處理個人或敏感數據的應用程序尤其成問題。

因為公司沒有分配到自己的離散物理服務器，所以無服務器提供商在任何給定時間通常是在單個服務器上運行來自多個客戶的代碼。與其他方共享機械的問題稱為“多租戶”問題-想想幾家公司試圖同時租賃一個辦公室工作并在其中工作會是什么情況。多租戶可能會影響應用程序性能，如果多租戶服務器配置不正確，可能會導致數據泄露。對于沙盒能夠正常運行并且具有足夠強大的基礎設施的網絡，多租戶幾乎沒有影響。例如，Cloudflare運行的15 Tbps網絡具有足夠的額外容量來緩解服務降級，并且Cloudflare托管的所有無服務器功能都在自己的沙箱中運行（通過Chrome V8引擎）。

無服務器架構不用于長時間運行的進程

這限制了可以在無服務器架構中經濟高效地運行的應用程序的種類。由于無服務器提供商針對為代碼的運行時間收費，因此與傳統(tǒng)應用程序相比，在無服務器基礎設施中運行具有長時間運行進程的應用程序可能會產生更高費用。

性能可能會受到影響

因為無服務器代碼不是一直在運行，所以在使用時可能需要“啟動”。此啟動時間可能會降低性能。但是，如果經常使用一段代碼，則無服務器提供商將使其保持激活狀態(tài)-對此現成代碼的請求稱為“熱啟動”。對一段時間未使用的代碼的請求稱為“冷啟動”。

Cloudflare Workers通過使用Chrome V8引擎，在很大程度上避免了冷啟動問題，該引擎在大多數情況下能夠在5毫秒內啟動并運行JavaScript代碼。如果代碼已經在運行，則響應時間不到一毫秒。

存在供應商鎖定風險

允許一個供應商為應用程序提供所有后端服務將不可避免地增加對該供應商的依賴。在一家供應商處建立無服務器體系結構可能會導致在必要時難以切換供應商，尤其是每個供應商提供的功能和工作流程都略有不同。（Cloudflare Workers易于遷移，因為它們是用JavaScript編寫的，并且是根據廣泛使用的Service Worker API編寫的。）

誰應該使用無服務器架構？

希望縮短上市時間并構建可快速擴展或更新的輕便、靈活應用程序的開發(fā)人員可能會從無服務器計算中受益匪淺。

如果應用程序使用量不一致，高峰時段與很少甚至沒有流量的時間交替出現，則無服務器體系結構將減少應用程序的成本。對于此類應用程序，購買一臺或多臺連續(xù)運行且始終可用（即使未使用時）的服務器或服務器塊可能浪費資源。無服務器設置將在需要時立即響應，并且在不用時不會產生成本。

此外，想要將某些或全部應用程序函數放到最終用戶附近以縮短延遲的開發(fā)人員，將至少需要部分無服務器的體系結構，因為這樣做需要將某些進程移出源站。

開發(fā)人員應在何時避免使用無服務器架構？

從成本角度和系統(tǒng)體系結構角度來看，在某些情況下，使用自行管理或作為服務提供的專用服務器更為有意義。例如，具有相當恒定、可預測的工作負載的大型應用程序可能需要傳統(tǒng)設置，在這種情況下，傳統(tǒng)設置產生的成本可能會更低廉。

另外，將遺留應用程序遷移到具有完全不同的體系結構的新基礎設施可能會非常困難。