在云計算領域，容器和無服務器計算已經占據了發展前列，
作者 | Emra Samdan
翻譯 | bocloudresearch
一點歷史
在不久以前，應用程式的開發、部署和維護要比現在復雜得多，耗時也多，在最初，維護不僅需要修復應用程式的代碼，還需要修復對物理機器的支持，保持服務器、硬體和軟體的更新也是非常關鍵的任務，
在本世紀初，一種名為“基礎設施即服務(IaaS)”的新模式迅速流行起來，IaaS提供了從第三方提供商租用遠程服務器和虛擬機的可能性，這些提供商可以完全負責管理硬體、網路和預訂，
IaaS出現之后，消除開發人員的所有非編碼職責來簡化開發人員作業，這一想法推動了新方法、模型和服務的創新，
容器是什么?
Docker的官方網站提供了以下簡短而優雅的定義:“容器是一個標準的軟體單元，它將代碼及其所有依賴項打包，從而使應用程式在不同的計算環境之間快速、可靠地運行，換句話說，通過使用容器，開發人員可以確保他們的應用程式可以在任何云平臺或本地服務器上運行，在某些方面，容器類似于虛擬機，比如兩者都是隔離資源，但是，虛擬機模擬物理設備，而容器創建應用程式層的抽象，
無服務器計算是什么？
在無服務器計算中，整個應用程式或應用程式的一部分被解耦為多個函式，每個函式都回應諸如HTTP請求、新訊息到達訊息佇列、或在存盤中保存或修改新物件等時間觸發的，平臺可以在特定的時間或周期運行這些函式，這對cron jobs（定時任務）很有幫助，
要使此系統作業，開發人員只需撰寫功能代碼，并將其及其依賴項打包到zip檔案中，然后將該zip檔案發送到無服務器端點，由提供商負責供應和擴展，
無服務器的關鍵特性之一是“按需付費”模型，在這種模型中，公司僅按函式的實際執行時間付費，如今，AWS Lambda應該是最受歡迎的無服務器提供商，
容器和無服務器有什么共同之處嗎?
是的，現在，無服務器和容器都很流行，它們允許開發人員專注于自己的代碼而不是基礎設施，這極大地提高了開發速度，容器和 serverless 都非常適合于微服務和基于組件的體系結構，在使用它們時，部署和擴展通常比使用傳統的單體架構更快、更具成本效益，因為你操作的是應用程式的一小部分，而不是整個應用程式，雖然容器和serverless 有這些共性，但是每種技術都有自己的優勢、弊端和用例，
容器化的優勢
容器的第一個優勢是可移植性，由于容器已經包含了它需要運行的所有內容，因此只需放置一臺安裝了容器引擎的機器即可運行，容器與平臺無關，因此它們可以運行在Linux、Windows、macOS、Mesos、Docker、Swarm或Kubernetes上，它們甚至可以在另一個容器中運行，
在計算資源使用方面，容器也比虛擬機更高效，盡管容器和虛擬機都是虛擬化的，但是虛擬機會使用自己的作業系統來模擬整個計算機，因此會消耗更多的資源，另一方面，容器可以共享同一作業系統，從而使作業系統更小，更快地啟動和關閉，
容器的另一個好處是允許開發人員完全控制應用程式，雖然這意味著必須手動配置系統設定，但這也意味著擁有真正的靈活性，這在serverless上是無法實作的，因為無服務器的所有內容都是由云提供商管理的，
容器的用例
當我們想要將一些大型的單體應用程式重構為更小的獨立部分， 以便遷移到微服務體系結構并獲得更好的性能、可測驗性和擴展速度時，容器確實是很有幫助的，例如，將以前的大型應用程式拆分為幾個獨立的服務：其中一個負責用戶管理，另一個負責轉換媒體檔案等，每個服務都可以輕松擴展，以便在其職責范圍的負載增加時提供更好的性能，但這對于單體應用程式來說是不可能實作的，在單體應用程式中，需要向整個系統添加新實體，這既昂貴又耗時，
因此，容器適合于長時間運行的應用程式，以及具有特定系統需求的應用程式，如果沒有對系統的完全控制，這些應用程式很難設定，
Serverless的優勢
由于上面提到的“按需付費”模型，托管無服務器應用程式的成本可能比使用任何其他方法都要低得多，無需為功能的空閑時間付費，如果沒有流量，那么每月的賬單上就不會有費用，幾乎所有無服務器的提供商都有免費層，其中包括每月固定數量的請求和執行時間，通常情況下，所提供的數量足以使小網站或初創公司免費運行，
對于容器，將應用程式分發到部件或微服務是關鍵步驟，在serverless中，它是將應用程式或其各個部分分發到單個函式中，每個函式負責特定的邏輯段，工程師更容易理解和開發單個功能的邏輯，這極大地提高了開發和部署速度，與部署整個應用程式相比，部署一小部分功能的風險更小，
無服務器的另一個巨大優勢是自動伸縮，無服務器的函式在提供者控制下的小型、無狀態的臨時容器中運行，提供者對回應負載峰值的擴展承擔全部責任，并且可以在幾秒鐘內啟動數百個實體，而且，仍然只需要為所有函式的總執行時間付費，
什么時候使用無服務器比較好?
Serverless的事件驅動特性使得它對于不總是需要運行的應用程式(或其部分)非常有用，
假設你正在為一個現有的應用程式開發媒體處理功能，新模塊雖然不會經常使用，但是仍然需要足夠的計算能力來完成它的任務，將其放如應用程式中可能需要切換到更強大的實體——這是一個冒險的舉動，因為如果同時運行一些繁重的任務，可能會導致其他所有用戶的延遲，在這種情況下，還需要支付更多的費用，并且仍然面臨由上述瓶頸所導致的一些問題，
相反，如果選擇了serverless，那么媒體處理功能將與應用程式的其余部分隔離，當它不被使用時，就不需要為此付費，并且可以始終確保它不會影響到應用程式的其他部分，
容器的弊端
即使沒有人使用應用程式，也至少有一個承載容器的虛擬機實體始終在運行，由此導致容器比無服務器更昂貴，
即使容器可以在共享計算機中快速擴展，但由于需要對計算機本身進行擴展，因此其他擴展也不很快， 但是，將容器與業務流程系統（如Kubernetes或AWS ECS）一起使用可以使擴展更智能，
無服務器的弊端
對于大多數開發人員來說，serverless最可怕的部分是供應商鎖定，當你提交到serverless時，實際上是在單個云提供商上進行堆疊，這些函式中使用的無服務器應用程式和 api 的體系結構因不同的提供商而有所不同，因此更改提供商或切換到內部解決方案的成本可能很高，盡管如此，有一些專家并不同意這個觀點，他們聲稱廠商鎖定實際上并不是一個問題，
使用無服務器方法不容易實作可觀察性、監視和除錯，由于應用程式可以被分散到多個部分，而每個部分都有自己的 bug 和錯誤，所以控制和查看全域變得非常重要，
容器和無服務器可以一起操作嗎?
容器和無服務器可以一起操作，答案是肯定的，將主要應用程式功能作為一個容器化的微服務來運行，同時將無服務器使用于某些后臺操作或很少使用的功能（但占用CPU），可能會非常有效，
另一個有趣的組合是AWS Fargate提供的，該服務結合了無服務器和容器的優點，允許你更好地控制你的應用程式，而不必擔心伸縮難題，
結論
容器和無服務器通常被認為是相互競爭的技術，但仔細觀察就會發現它們只是不同的技術，當在同一個專案中使用時，它們實際上可以彌補彼此的缺陷，重要的是要記住，“舊的”并不意味著“過時”，“新的”并不意味著“更好”，解決方案的有效性取決于特定的用例、專案需求、團隊經驗和團隊偏好，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/53409.html
標籤：其他
下一篇：unity原生支付