一些歷史

不久之前，開發(fā)，部署和運(yùn)維還相當(dāng)復(fù)雜。在一開始，運(yùn)維不僅需要修補(bǔ)程序代碼，還要支持物理機(jī)器。保持服務(wù)器，硬件與軟件處于最新狀態(tài)也是一項(xiàng)艱巨的任務(wù)。

在2000年代，一個(gè)新的模型——架構(gòu)即服務(wù)(IaaS)很快流行起來。IaaS提供了從第三方租用遠(yuǎn)程服務(wù)器與虛擬機(jī)的可能性。這些提供商負(fù)責(zé)管理硬件，網(wǎng)絡(luò)以及預(yù)留空間。

在IaaS出現(xiàn)之后，為開發(fā)者減負(fù)，讓他們卸下所有非開發(fā)任務(wù)的想法推動(dòng)了新方法，模型和服務(wù)的創(chuàng)新。

什么是容器?

Docker官方給出了如下簡(jiǎn)短而優(yōu)雅的定義：“容器是一個(gè)標(biāo)準(zhǔn)軟件單元，它將代碼及其依賴打包到一起，因而應(yīng)用可以快速穩(wěn)定地運(yùn)行在不同的計(jì)算環(huán)境中。”換句話來說，使用容器，開發(fā)者能確保應(yīng)用能運(yùn)行在任何云平臺(tái)上或本地服務(wù)器上。在某些方面，容器與虛擬機(jī)相類似，都是獨(dú)立的資源。然而，虛擬機(jī)模仿物理機(jī)，而容器創(chuàng)建了軟件層的抽象。

什么是無服務(wù)器計(jì)算？

在無服務(wù)器計(jì)算中，整個(gè)應(yīng)用或應(yīng)用的一部分被分成多個(gè)功能，每個(gè)都會(huì)被一個(gè)事件觸發(fā)，例如HTTP請(qǐng)求，新消息到達(dá)消息隊(duì)列，或保存和修改數(shù)據(jù)。也能夠在某個(gè)特定時(shí)間或周期性地執(zhí)行，這個(gè)特性對(duì)計(jì)劃任務(wù)很有用。

對(duì)于這樣的系統(tǒng)，開發(fā)者只需要寫功能代碼，將它與它的依賴一起打包到一個(gè)壓縮文件，并將壓縮文件發(fā)到無服務(wù)的終端。供應(yīng)商負(fù)責(zé)配置和擴(kuò)展。

無服務(wù)器的一個(gè)關(guān)鍵特性是“即用即付”模型，企業(yè)只需要為他們功能的實(shí)際執(zhí)行時(shí)間付費(fèi)。如今，AWS Lambda是最流行的無服務(wù)器供應(yīng)商。

容器與無服務(wù)器有共通之處嗎？

是的！如今，無服務(wù)器與容器都很流行，因?yàn)樗麄兡茏岄_發(fā)者專注于代碼而不是基礎(chǔ)設(shè)施。這提高了開發(fā)速度。容器與無服務(wù)器都能與微服務(wù)及基于組件的開發(fā)完美契合。相對(duì)于經(jīng)典的一體化架構(gòu)，使用無服務(wù)與容器，開發(fā)部署都會(huì)更快，性價(jià)比也更高，因?yàn)槟阍诓僮鲬?yīng)用的小部分，而不是整體。盡管有這些共性，兩個(gè)技術(shù)都有各自的優(yōu)劣以及各自的使用場(chǎng)景。

容器的優(yōu)勢(shì)

容器的第一大優(yōu)勢(shì)就是可移植性。由于容器包含了運(yùn)行所需的一切依賴，只需要一個(gè)安裝有容器引擎的機(jī)器就可以運(yùn)行。容器是平臺(tái)無關(guān)的，它可以運(yùn)行在Linux, Windows, macOS, Mesos, Docker, Swarm, 或 Kubernetes，甚至可以運(yùn)行在其他容器內(nèi)部。

容器比虛擬機(jī)性能更好。雖然容器與虛擬機(jī)都是虛擬化的，虛擬機(jī)消耗更多的資源，因?yàn)樗麄冞\(yùn)行著整個(gè)操作系統(tǒng)來模擬完整的機(jī)器。而容器可以共享同一個(gè)操作系統(tǒng)，這使它們更小，啟停速度更快。

容器的另一個(gè)好處是運(yùn)行開發(fā)者獲得程序的完全控制。雖然這意味著系統(tǒng)設(shè)置必須手動(dòng)配置，但這也意味著你擁有真正的靈活性。這一點(diǎn)無服務(wù)器是做不到的，因?yàn)閹缀跛械墓芾矶加稍乒?yīng)商負(fù)責(zé)。

容器的使用場(chǎng)景

如果你想重構(gòu)一些大的一體化應(yīng)用到微服務(wù)架構(gòu)，并獲得更好的性能，可測(cè)試性，以及擴(kuò)展速度，容器非常有用。將過去的大應(yīng)用分成幾個(gè)小服務(wù)——一個(gè)負(fù)責(zé)用戶管理，一個(gè)負(fù)責(zé)轉(zhuǎn)換媒體文件等等。每個(gè)服務(wù)都可以在負(fù)載提高時(shí)輕易地?cái)U(kuò)展來提供更好的性能。這些一體化應(yīng)用就辦不到，除非像整個(gè)系統(tǒng)添加一個(gè)新實(shí)例，這樣既不經(jīng)濟(jì)，又耗時(shí)間。

總的來說，容器適合于長(zhǎng)期運(yùn)行的程序，以及對(duì)系統(tǒng)有特殊要求的應(yīng)用。

無服務(wù)器的優(yōu)勢(shì)

由于“即用即付”模式，使用無服務(wù)器的花費(fèi)會(huì)大大降低。在應(yīng)用的空閑時(shí)間你不必付費(fèi)，因此如果沒有流量，你就不用交月費(fèi)。幾乎所有的無服務(wù)供應(yīng)商都有免費(fèi)使用，包含一個(gè)按月的固定請(qǐng)求數(shù)和執(zhí)行時(shí)間。通常提供的數(shù)值對(duì)一個(gè)小型網(wǎng)站來說已經(jīng)足夠了。

使用容器，將應(yīng)用分成微服務(wù)是關(guān)鍵的一步。而使用無服務(wù)器，是將應(yīng)用分成單個(gè)的功能，每個(gè)復(fù)雜一個(gè)特定的邏輯。這大大降低了開發(fā)和部署的速度，因?yàn)閷?duì)于工程師來說這更容易理解。部署功能塊也比部署整個(gè)應(yīng)用所冒的風(fēng)險(xiǎn)更小。

無服務(wù)的另一個(gè)好處是爆發(fā)自動(dòng)伸縮。無服務(wù)器的功能運(yùn)行在小的，無狀態(tài)的，短暫存在的容器中。供應(yīng)商負(fù)責(zé)擴(kuò)展應(yīng)用來應(yīng)對(duì)負(fù)載高峰，可以在幾秒鐘之內(nèi)運(yùn)行起來成百上千個(gè)實(shí)例。記住，你只需要為你的功能的執(zhí)行時(shí)間付費(fèi)。

什么時(shí)候使用無服務(wù)器？

事件驅(qū)動(dòng)的無服務(wù)器對(duì)于那些不需要一直運(yùn)行的應(yīng)用很有用。

假設(shè)你在為一個(gè)已有應(yīng)用開發(fā)一個(gè)媒體處理功能。新的模塊不經(jīng)常使用，但是也需要足夠的計(jì)算能力完成它的任務(wù)。將它放在應(yīng)用里需要遷移到一個(gè)性能更強(qiáng)的實(shí)例——一個(gè)冒險(xiǎn)的舉動(dòng)，因?yàn)?#xff0c;如果一些繁重的任務(wù)一起運(yùn)行，會(huì)給所有的用戶帶來延遲，這時(shí)你就需要性能更好的機(jī)器，而這同樣會(huì)帶來風(fēng)險(xiǎn)。

如果你選擇無服務(wù)器，媒體處理模塊會(huì)與應(yīng)用的其余部分隔離。在不用時(shí)你不需要付費(fèi)并且不會(huì)影響你程序的其余部分。

無服務(wù)器，不是你不需要服務(wù)器，而是供應(yīng)商為你提供服務(wù)器，這個(gè)服務(wù)器在你用的時(shí)候就存在，不用的時(shí)候就不存在(不收費(fèi)),這簡(jiǎn)直就是薛定諤的服務(wù)器。

容器的缺點(diǎn)

即使程序沒人使用，也至少有一個(gè)承載容器的虛擬機(jī)實(shí)例在運(yùn)行。因此，容器比無服務(wù)器更貴。

即使容器可以在共享的機(jī)器上快速擴(kuò)展，額外擴(kuò)展并不快，因?yàn)闄C(jī)器自身也需要擴(kuò)展。不過，利用容器協(xié)調(diào)系統(tǒng)例如Kubernetes,AWS ECS...使擴(kuò)展更容易。

無服務(wù)器的缺點(diǎn)

對(duì)于大部分開發(fā)者，最可怕的事是廠商綁定。使用無服務(wù)器，你不可避免地要選擇一個(gè)云供應(yīng)商，不同供應(yīng)商之間使用的架構(gòu)與API都不相同，如果要改變供應(yīng)商或其他的解決方案，代價(jià)有些高昂。不過，也有一些專家不同意，聲稱廠商綁定不成問題。

使用無服務(wù)器，觀測(cè)，監(jiān)控與調(diào)試都不容易。因?yàn)槌绦蚩赡鼙环殖闪硕鄠€(gè)部分，每一部分都有各自的bug與錯(cuò)誤，掌控全局變得很重要。幸運(yùn)的是，現(xiàn)在可以使用Thundra,一個(gè)為無服務(wù)器提供了完整可觀測(cè)性的工具，聚合了性能指標(biāo)和日志。

容器和無服務(wù)器可以一起使用嗎？

令人驚訝的是，是的！讓主程序功能作為容器化的微服務(wù)運(yùn)行，而對(duì)于一些后臺(tái)操作或很少使用但是消耗CPU的功能使用無服務(wù)器。

另一種又去的結(jié)合方式是使用AWS Fargate。這個(gè)服務(wù)結(jié)合了無服務(wù)器與容器的優(yōu)點(diǎn)，運(yùn)行你更好地控制你的程序而不用擔(dān)心擴(kuò)展——AWS負(fù)責(zé)。如果你對(duì)此感興趣，查看關(guān)于AWS Fargate的這篇文章。

總結(jié)

容器與無服務(wù)器通常被認(rèn)為是相互競(jìng)爭(zhēng)的技術(shù)。通過進(jìn)一步的觀察，發(fā)現(xiàn)他們只是不同的技術(shù)而已——在同一個(gè)項(xiàng)目中一起使用可以優(yōu)勢(shì)互補(bǔ)。記住“舊的”不意味著是“死的”，“新的”不代表“更好”。哪種方案有效取決于你的使用場(chǎng)合，項(xiàng)目需求，團(tuán)隊(duì)經(jīng)驗(yàn)以及團(tuán)隊(duì)偏好。

總結(jié)

以上是生活随笔為你收集整理的容器性能比无容器服务器,【译】容器 vs 无服务器（Serverless）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。