無服務器服務無處不在。無服務器產品向新的編程方式發展的驅動力來自各種形式的產品，其中包括應用程序托管平臺、無服務器數據庫、內容分發網絡(CDN)、安全產品等。
無服務器產品已經解決了低級別的配置、擴展和資源調配問題，最后一個問題是分發。在這里，邊緣計算的無服務器通過在多個數據中心分布數據和計算提供了一個解決方案。邊緣計算的無服務器通過使計算更接近用戶來減少網絡延遲。
無邊緣服務器是近15年前從“基礎設施即服務”開始的云計算架構演變的頂點。這種發展的下一階段將是進一步推動無服務器“構建塊”的分發，并使開發人員更容易使用它們。
分層架構
(1)基礎設施即服務(IaaS)
云計算革命始于基礎設施即服務(IaaS)的出現。采用基礎設施即服務(IaaS)，企業可以將運行在內部部署基礎設施的業務轉移到云平臺，他們只為使用的存儲容量和計算時間支付費用，而不需要安裝或管理任何硬件或網絡。
基礎設施即服務(IaaS)運營成本起初似乎很高昂，但很多企業很快采用，因為可以提供更高水平的正常運行時間，而購買和維護自己的基礎設施的價格通常超過了基礎設施即服務(IaaS)產品。最重要的優勢是，云計算消除了硬件維護和配置，從而使開發人員專注于業務價值。
(2)平臺即服務(PaaS)
隨后，供應商將云計算技術再向前邁進了一步，并提供了平臺即服務。平臺即服務(PaaS)解決方案不只是租用服務器，而是租用構建應用程序所需的一切。這不僅包括服務器，還包括操作系統、編程語言環境、數據庫和數據庫管理工具。
基礎設施即服務(IaaS)提供程序使用戶成為租用服務器的管理員，而平臺即服務(PaaS)提供程序接管服務器管理任務，例如軟件安裝或安全更新，并經常嘗試預期代碼的環境要求。平臺即服務(PaaS)的目標是為企業提供一種簡單的方法來部署其應用程序。平臺即服務(PaaS)比基礎設施即服務(IaaS)更進一步，將開發人員從系統管理任務中解脫出來，并使他們專注于最重要的應用程序。
AWS Elastic Beanstalk、Google App Engine和Heroku是提供平臺即服務(PaaS)的幾家提供商。
(3)軟件即服務(SaaS)
軟件即服務(SaaS)通常是指可以通過各種訂閱獲得的在線托管應用程序。這些應用程序完全可以在云中運行，并且可以通過全球互聯網和瀏覽器進行訪問。本質上，在云中運行并具有基于訂閱的定價模型的每個應用程序都被認為是一個SaaS應用程序。
SaaS應用程序有兩種類型：面向最終用戶的應用程序和面向開發人員的應用程序。后一種類型旨在為其他應用程序提供基礎。Gmail、Dropbox、Jira、BitBucket和Slack都是專注于最終用戶的SaaS應用程序的示例，而Stripe和Slaask公開的API允許企業將其軟件即服務(SaaS)解決方案集成到自己的應用程序中。
(4)容器即服務(CaaS)
容器平臺是基礎設施即服務(IaaS)的最新形式。容器即服務(CaaS)提供商可以提供容器中的服務或應用程序，并為用戶管理容器。
容器比虛擬機更有效地利用基本主機資源。人們可以把容器看作是“微型服務器”，它們可以快速啟動，多個實例可以在一臺服務器上運行。
容器即服務(CaaS)提供商提供了一些工具，可以在服務器上部署容器以及擴展容器實例的數量。最先進的產品完全為企業管理底層服務器，使其可以專注于代碼(或容器)而不是基礎。
容器即服務(CaaS)已迅速成為平臺即服務(PaaS)和軟件即服務(SaaS)的組成部分之一，從而形成了分層的體系結構。已經發生了向盡可能多地開發應用程序的轉變。許多復雜的應用程序仍然是軟件即服務(SaaS)，平臺即服務(PaaS)和容器即服務(CaaS)的組合，因為可用的平臺不夠靈活，無法提供應用程序所需的一切。
許多復雜的應用程序是軟件即服務(SaaS)，平臺即服務(PaaS)和容器即服務(CaaS)的組合。
通過盡可能多地依賴軟件即服務(SaaS)，企業可以擺脫配置和可擴展性方面的顧慮。對于其余部分，企業通常會使用運行中的容器，這意味著他們仍然有配置和管理方面的問題。
(5)功能即服務(FaaS)：功能即服務(FaaS)使企業無需考慮擴展、服務器或容器問題就可以上傳和執行代碼。從這個意義上講，它超越了先前產品的易用性原則，但是它也具有在平臺即服務(PaaS)中不太突出的局限性。
功能即服務(FaaS)的最大優勢是擴展。擴展功能即服務(FaaS)的粒度可以比平臺即服務(PaaS)或容器即服務(CaaS)的粒度低，并且不需要配置。同樣，企業不用為不使用的服務支付費用。
•粒度：平臺即服務(PaaS)應用程序通常僅按應用程序擴展，而基于容器即服務(CaaS)構建的應用程序僅按容器擴展。功能即服務(FaaS)應用程序細分為單獨的功能，因此可以按功能擴展。缺點是它經常需要企業重新考慮應用程序的架構。除了管理一個應用程序或幾個容器之外，還必須管理執行較小任務的許多功能，這可能會導致許多編排工作。
•配置：通常在何時配置(按比例放大和縮小觸發)或人工設置需要運行的應用程序或容器的實例數量的地方，功能即服務(FaaS)不需要企業擴展或配置特定資源。
•按需付費：與為代碼是否被有效執行而支付費用的容器即服務(CaaS)不同，只是在調用功能時才會產生費用。這種按需付費的定價模式正逐漸成為定義無服務器的最重要方面。
•限制：在典型的應用程序中，企業可以受到代碼定義內存限制或執行時間限制。盡管功能即服務(FaaS)提供程序允許企業配置這些設置，但仍有一些上限可以確保提供程序可以有效地優化這些資源。可以想象，如果可以使用10GB的內存創建功能或可以運行幾個小時的功能，則提供商很難估計要啟動多少臺服務器才能最佳地使用其資源。
新的邊緣架構
無服務器架構消除了調配和擴展問題，但是分發仍然是一個具有挑戰性的問題。在理想情況下，企業希望其代碼盡可能接近最終用戶運行，以減少延遲。直到最近，在構建應用程序的方式存在多個問題：
•分布邏輯：除非將功能或容器部署在不同的區域，并且將客戶端路由到最接近的功能，否則其功能通常將保留在數據中心中。
•分發動態數據：在不分發數據的情況下分發邏輯不會獲得巨大的回報，企業的用戶可能更靠近后端，但后端仍然遠離數據層。
•成本、配置、監視：很少看到應用程序分布到兩個或三個以上的區域，因為這樣做通常會帶來額外的成本或配置，并且需要監視多個區域中的功能或容器。
無服務器的下一個發展是無需配置即可進一步推動分發并交付。這意味著企業的邏輯和數據分布在全球許多地區，并有效地減少了最終用戶的延遲。
CDN和Jamstack
很多企業已經使用了提供自動分發的最基本的服務形式。它稱為內容分發網絡(CDN)。 Netlify和Zeit等公司通過盡可能多地預生成應用程序，并使用無服務器功能和SaaS API處理動態部分，已經可以實現自動分發。
由Netlify公司創造的“Jamstack”方法已經迅速流行起來，因為內容分發網絡提供了邊緣架構所能提供的第一種體驗。當然，純粹基于服務器端呈現的Jamstack也有局限性。例如，必須為新的傳入內容觸發生成。這使得將此方法應用于具有顯著構建時間的高度動態網站非常具有挑戰性。
基于服務器端渲染的Jamstacks面臨著高度動態的網站的挑戰，因為必須為新內容觸發構建。
增量構建和諸如客戶端整合作用之類的概念為該問題提供了一部分解決方案，但最終希望復雜的網站具有兩全其美的優勢：對于最終用戶而言網絡延遲非常低，以及可以立即訪問的新內容。
分布式服務的興起
分布式服務來自這樣一個體系結構：前端與后端通信，后端反過來與數據庫和其他服務通信。后端和數據庫通常一起擴展，以保持后端和數據庫之間的低延遲。分發是可能的，但往往繁瑣，因此比較有限。
后端和數據庫的分發是可能的，但是通常很麻煩，因此受到限制。
在未來的架構中，將通過使用其他分布式服務將Jamstack的思想提升到一個新的高度。這些服務中的每一個都是一個分布式網絡，其節點不必與其他服務位于同一數據中心中。為了將等待時間減少到最小，必須重新考慮安全模型，以使前端與數據庫和其他服務網絡進行通信。
未來的應用程序架構將利用分布式服務網絡、分布式數據庫網絡和分布式無服務器后端。
以下了解一下有助于實現這一點的服務。
分布式服務網絡
許多軟件即服務(SaaS)平臺(例如Algolia和SendGrid)旨在成為其他應用程序的構建基塊。他們開發特定的服務，以消除典型后端應用程序中的特定問題。其中一些正在發展成為分布式服務，例如Algolia，它自稱為分布式搜索網絡(DSN)。隨后將有許多其他的Saas平臺出現，很可能很快將談論分布式服務網絡作為SaaS應用程序的下一個發展。
分布式無服務器數據庫
Azure Cosmos DB、Google Cloud Spanner和FaunaDB等數據庫正在采用即付即用的無服務器模式，并提供現成的分發以及某種形式的ACID保證。一些數據庫提供安全層和本機GraphQL API，這些安全層和原生的GraphQL API可以由客戶端應用程序安全地使用，并且可以與無服務器后端很好地配合使用。安全層使用戶界面可以直接與數據庫進行交互，而不僅僅是與后端進行交互。在理想情況下，前端應用程序可以與具有低延遲和ACID保證的全局分布式數據庫進行通信，就像數據庫在內部部署數據中心運行一樣。
分布式無服務器邊緣計算
新的無服務器功能，例如Cloudflare Workers和StackPath無服務器腳本，正在將無服務器功能推向邊緣計算。它們旨在使功能盡可能接近最終用戶，以將等待時間減少到絕對最小。 Cloudflare Workers擁有194個站點，而StackPath有45個站點。
為什么現在這種新的邊緣架構越來越受歡迎?當考慮從基礎設施即服務(IaaS)到邊緣無服務器的這種轉變的演變時，將會面臨這樣一個問題：如何處理動態數據?盡管已經擁有Amazon S3之類的服務來托管相對靜態的數據，但真實的數據庫仍難以提供無服務器的體驗。這是因為要建立一個高度一致的分布式系統非常困難。
云中的無服務器構建基塊就像搭建樂高積木。
如今，擁有具有內置安全性的無服務器數據庫，這些數據庫為新型應用程序打開了大門，這些應用程序默認情況下會以全球分布式方式進行擴展。自從打開這扇大門以來，許多開發人員已經開始尋求采用微服務和API替換后端部分的方法，從而為許多SaaS提供商打開了新的市場。
最終結果將開發一種像樂高積木一樣工作的生態系統。而開發人員將組合所需的構建塊，而不再擔心擴展或分發。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號