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