無服務(wù)器服務(wù)正變得無處不在。作為向新的編程方式發(fā)展的推動力，無服務(wù)器產(chǎn)品正在以各種形式出現(xiàn)，如應(yīng)用程序托管平臺、無服務(wù)器數(shù)據(jù)庫、CDN、安全產(chǎn)品等等。
無服務(wù)器產(chǎn)品消除了底層配置、可伸縮性和預(yù)置方面的問題，最后剩下的就是分發(fā)問題。邊緣無服務(wù)器服務(wù)通過在多個數(shù)據(jù)中心之間分發(fā)數(shù)據(jù)和計算的方式提供了一種解決方案。邊緣無服務(wù)器通過讓計算更接近用戶的方式減少了延遲。
邊緣無服務(wù)器是15年前開始推出的“基礎(chǔ)設(shè)施即服務(wù)”云架構(gòu)發(fā)展的一個頂點。其下一發(fā)展階段將是進(jìn)一步推動無服務(wù)器“構(gòu)件”的分發(fā)，讓開發(fā)人員更容易使用它們。
現(xiàn)在讓我們回顧一下它們的發(fā)展歷程，并展望其未來發(fā)展趨勢。
分層架構(gòu)
基礎(chǔ)設(shè)施即服務(wù)（IaaS）
隨著基礎(chǔ)設(shè)施即服務(wù)的出現(xiàn)，云計算革命才算真正開始。借助IaaS，企業(yè)可以將其本地基礎(chǔ)設(shè)施移至托管的云基礎(chǔ)設(shè)施上并從那里進(jìn)行操作。用戶只需要根據(jù)他們使用的存儲和計算時間付費，無需再安裝或管理任何硬件或網(wǎng)絡(luò)。
剛開始，IaaS的收費貌似很貴，但是企業(yè)還是很快地采用了它們。因為在保證正常運行時間上，IaaS遠(yuǎn)遠(yuǎn)超過了本地數(shù)據(jù)中心。此外，企業(yè)自己購買和維護(hù)基礎(chǔ)設(shè)施在費用上也遠(yuǎn)遠(yuǎn)超過了IaaS產(chǎn)品。最重要的一個優(yōu)勢是，云計算消除了硬件維護(hù)和配置工作，從而解放了開發(fā)人員，使其能夠更加專注于業(yè)務(wù)價值。
平臺即服務(wù)（PaaS）
供應(yīng)商將云計算服務(wù)又向前推進(jìn)了一步，開始提供平臺即服務(wù)。用戶可以通過PaaS解決方案租用構(gòu)建應(yīng)用程序所需要的一切，而不僅僅是租用服務(wù)器。該方案不僅包括服務(wù)器，還包括操作系統(tǒng)、編程語言環(huán)境、數(shù)據(jù)庫和數(shù)據(jù)庫管理工具。
與IaaS服務(wù)提供商讓用戶成為租用服務(wù)器的管理員不同，PaaS服務(wù)提供商則是接管了服務(wù)器管理任務(wù)，例如軟件安裝或安全更新，并經(jīng)常會對用戶代碼的環(huán)境要求進(jìn)行預(yù)測。PaaS的目標(biāo)是為用戶提供一種簡單的方法來部署他們的應(yīng)用程序。PaaS將開發(fā)人員從系統(tǒng)管理任務(wù)中解放出來，讓他們能夠?qū)Ｗ⒂谧钪匾膽?yīng)用程序。與IaaS相比，PaaS又向前邁進(jìn)了一步。
在向公眾提供PaaS產(chǎn)品的眾多服務(wù)提供商中，AWS Elastic Beanstalk、Google App Engine和Heroku是其中的典型代表。
軟件即服務(wù)（SaaS）
軟件即服務(wù)通常是指可以通過各種訂閱獲得的在線托管應(yīng)用程序。這些應(yīng)用程序完全可以在云端運行，并且可以通過互聯(lián)網(wǎng)和瀏覽器進(jìn)行訪問。從本質(zhì)上說，在云端運行且定價模式采用基于訂閱的所有應(yīng)用程序都可被視為SaaS應(yīng)用程序。
SaaS應(yīng)用程序有兩種類型：專注于終端用戶的應(yīng)用程序和專注于開發(fā)人員的應(yīng)用程序。后一種類型旨在為其他應(yīng)用程序提供一個堅實的基礎(chǔ)。Gmail、Dropbox、Jira、BitBucket和Slack都是典型的專注于終端用戶的SaaS應(yīng)用程序，Stripe和Slaask還開放了API允許用戶將其SaaS解決方案集成到他們自己的應(yīng)用程序中。
容器即服務(wù)（CaaS）
容器平臺是IaaS的最新形式。CaaS服務(wù)提供商可讓用戶在容器中托管服務(wù)或應(yīng)用程序，或是讓用戶自己管理容器，而不再提供完整的服務(wù)器主機(jī)。
與虛擬機(jī)相比，容器可更為高效地利用底層的主機(jī)資源。人們可以將容器視為“微型機(jī)器”。它們能夠快速啟動，并且可在單個服務(wù)器上運行多個實例。
CaaS服務(wù)提供商提供了一些工具，用以在服務(wù)器上部署容器以及調(diào)整容器實例的數(shù)量。最先進(jìn)的產(chǎn)品完全可為用戶管理底層服務(wù)器，讓用戶能夠?qū)Ｗ⒂诖a（或容器）而不是基礎(chǔ)設(shè)施。
如今，CaaS已迅速發(fā)展成為了PaaS和SaaS的一個構(gòu)建模塊，從而形成了一種分層的體系結(jié)構(gòu)。開發(fā)應(yīng)用程序工作也逐步變成了金字塔結(jié)構(gòu)。由于目前可用的平臺還不夠靈活，無法提供應(yīng)用程序所需的一切，因此許多復(fù)雜的應(yīng)用程序采取的辦法是綜合使用SaaS、PaaS和CaaS。
通過盡可能地依靠SaaS，用戶可以擺脫配置和可擴(kuò)展性方面的顧慮。對于其余部分，用戶通常會考慮運行中的容器，這意味著他們?nèi)匀恍枰M(jìn)行預(yù)置和配置。
為了減少這些顧慮，人們開發(fā)出了第五種解決方案，即無服務(wù)器架構(gòu)。無服務(wù)器架構(gòu)填補(bǔ)了這方面的空白。
無服務(wù)器架構(gòu)
函數(shù)即服務(wù)（FaaS）
在FaaS中，用戶在上載和執(zhí)行代碼時無需考慮擴(kuò)展、服務(wù)器或容器。從這個意義上講，它們在易用性方面超越了先前的產(chǎn)品，不過它們也存在一些局限性。這些局限性在PaaS中不怎么明顯，但是在FaaS卻被放大了。
FaaS的最大優(yōu)勢是擴(kuò)展。FaaS擴(kuò)展的粒度比PaaS或CaaS要更出色，并且不需要配置。在收費方面，用戶不使用就不付費。
● 粒度：PaaS應(yīng)用程序通常是按應(yīng)用程序擴(kuò)展，而基于CaaS構(gòu)建的應(yīng)用程序則按容器擴(kuò)展。FaaS應(yīng)用程序可拆分為單獨的函數(shù)，因此可以按函數(shù)進(jìn)行擴(kuò)展。缺點是它們經(jīng)常需要用戶重新考慮應(yīng)用程序的架構(gòu)。用戶必須對許多執(zhí)行較小任務(wù)的函數(shù)進(jìn)行管理，而不再是管理一個應(yīng)用程序或幾個容器，不過其中的不足是這可能會導(dǎo)致產(chǎn)生大量的編排工作。
● 配置：用戶通常需要對擴(kuò)展的位置，觸發(fā)擴(kuò)展的時機(jī)（以進(jìn)行向上和向下擴(kuò)展）進(jìn)行配置，以及手動設(shè)置需要運行的應(yīng)用程序或容器實例的數(shù)量，F(xiàn)aaS則不需要用戶配置擴(kuò)展或預(yù)置特定的資源。
● 按需付費：在使用容器時（CaaS），無論代碼是否被主動執(zhí)行，用戶都需要付費。而在使用FaaS時，只有函數(shù)被調(diào)用時才會產(chǎn)生費用。這種按需付費的定價模式正逐漸成為無服務(wù)器定義中一個最重要的方面。
● 限制：在典型的應(yīng)用程序中，用戶可以為代碼定義內(nèi)存限制或執(zhí)行時間限制。盡管FaaS服務(wù)提供商允許用戶配置這些設(shè)置，但仍有一些上限限制以確保提供商能夠有效地優(yōu)化這些資源。我們可以設(shè)想一下，如果函數(shù)可以使用10GB的RAM或可以運行幾個小時的功能，那么提供商將很難評估出要啟動多少臺服務(wù)器才能最為高效地使用他們的資源。
新的邊緣架構(gòu)
無服務(wù)器架構(gòu)消除了預(yù)置和擴(kuò)展方面的問題，但是分發(fā)仍然是一個具有挑戰(zhàn)性的問題。在理想的情況下，我們希望我們的代碼盡可能靠近終端用戶運行，以減少延遲。然而直到最近，我們在構(gòu)建應(yīng)用程序的方式上還存在多個問題：
● 分發(fā)邏輯：除非用戶將函數(shù)或容器部署在不同的區(qū)域，并且自己將客戶端路由到最近的函數(shù)，否則用戶的函數(shù)通常都保留在一個數(shù)據(jù)中心中。
CaaS服務(wù)提供商提供了一些工具，用以在服務(wù)器上部署容器以及調(diào)整容器實例的數(shù)量。最先進(jìn)的產(chǎn)品完全可為用戶管理底層服務(wù)器，讓用戶能夠?qū)Ｗ⒂诖a（或容器）而不是基礎(chǔ)設(shè)施。
如今，CaaS已迅速發(fā)展成為了PaaS和SaaS的一個構(gòu)建模塊，從而形成了一種分層的體系結(jié)構(gòu)。開發(fā)應(yīng)用程序工作也逐步變成了金字塔結(jié)構(gòu)。由于目前可用的平臺還不夠靈活，無法提供應(yīng)用程序所需的一切，因此許多復(fù)雜的應(yīng)用程序采取的辦法是綜合使用SaaS、PaaS和CaaS。
通過盡可能地依靠SaaS，用戶可以擺脫配置和可擴(kuò)展性方面的顧慮。對于其余部分，用戶通常會考慮運行中的容器，這意味著他們?nèi)匀恍枰M(jìn)行預(yù)置和配置。
為了減少這些顧慮，人們開發(fā)出了第五種解決方案，即無服務(wù)器架構(gòu)。無服務(wù)器架構(gòu)填補(bǔ)了這方面的空白。
CDN和JAMstack
我們已經(jīng)在使用自動分發(fā)的基本服務(wù)形式，被稱為內(nèi)容交付網(wǎng)絡(luò)（CDN）。Netlify和Zeit等公司認(rèn)為，通過盡可能多地預(yù)生成應(yīng)用程序以及使用無服務(wù)器函數(shù)和SaaS API處理動態(tài)部分已經(jīng)能夠?qū)崿F(xiàn)自動分發(fā)。
這種被Netlify稱為“JAMstack”的方法正在快速普及，因為內(nèi)容交付網(wǎng)絡(luò)首先帶來了邊緣架構(gòu)可以提供的功能。當(dāng)然，JAMstack也存在一些限制，如僅可基于服務(wù)器端渲染，新流入的內(nèi)容必須觸發(fā)構(gòu)建等。這些限制使得將這種方法應(yīng)用于有著大量構(gòu)建時間的高度動態(tài)的網(wǎng)站非常具有挑戰(zhàn)性。
增量構(gòu)建和諸如客戶端激活之類的概念為該問題提供了部分解決方案，但是我們還是希望復(fù)雜網(wǎng)站同時能夠具有兩大優(yōu)勢：終端用戶的延遲（極低）和新內(nèi)容可立即被訪問。
分布式服務(wù)的興起
在我們通常使用的架構(gòu)中，前端與后端進(jìn)行通信，后端又與數(shù)據(jù)庫和其他服務(wù)進(jìn)行通信。后端和數(shù)據(jù)庫通常會一起擴(kuò)展，以保持后端和數(shù)據(jù)庫之間的延遲處于很低的狀態(tài)。分布式是有可能做到的，不過這通常很麻煩，這也使得它們受到了限制。
在未來的架構(gòu)中，對分布式服務(wù)的使用將把JAM的理念提升到一個新的層次。這些服務(wù)中的每一個都將是一個分布式網(wǎng)絡(luò)，其節(jié)點不一定必須與其他服務(wù)位于同一數(shù)據(jù)中心中。為了將延遲時間減少到最低，我們必須要重新考慮安全模型，以使前端能夠與數(shù)據(jù)庫和其他服務(wù)網(wǎng)絡(luò)進(jìn)行通信。
下面讓我們來看看要實現(xiàn)這一目標(biāo)需要哪些服務(wù)。
分布式服務(wù)網(wǎng)絡(luò)
許多SaaS平臺（如Algolia和SendGrid）旨在成為其他應(yīng)用程序的構(gòu)建基塊。目前服務(wù)提供商已經(jīng)開發(fā)出了特定的服務(wù)，以消除典型后端應(yīng)用程序中的特定問題，其中一些正在發(fā)展成為分布式服務(wù)，例如Algolia（其自稱為分布式搜索網(wǎng)絡(luò)，DSN）。許多其他的Saas平臺也正在緊跟這一發(fā)展趨勢，預(yù)計我們很快就會對分布式服務(wù)網(wǎng)絡(luò)是否作為SaaS應(yīng)用程序的下一個發(fā)展趨勢展開討論。
分布式無服務(wù)器數(shù)據(jù)庫
Azure Cosmos DB、Google Cloud Spanner和FaunaDB等數(shù)據(jù)庫正在采用即付即用的無服務(wù)器模式，并通過某種形式的ACID保證提供現(xiàn)成的分發(fā)。某些數(shù)據(jù)庫還提供了安全層和原生GraphQL API，這些安全層和本機(jī)GraphQL API可以由客戶端應(yīng)用程序安全使用，并可以與無服務(wù)器后端很好地配合使用。這些安全層使得用戶界面可以直接與數(shù)據(jù)庫進(jìn)行交互，而不僅僅是與后端進(jìn)行交互。理想情況下，前端應(yīng)用程序可以與具有低延遲和ACID保證的全球分布式數(shù)據(jù)庫進(jìn)行通信，使用起來就像數(shù)據(jù)庫在本地運行一樣。
分布式無服務(wù)器邊緣計算
Cloudflare worker和StackPath Serverless Scripting等新的無服務(wù)器函數(shù)正在將無服務(wù)器函數(shù)推向邊緣，其旨在使函數(shù)盡可能接近終端用戶，以將延遲降低到最低。目前，Cloudflare workers已經(jīng)擁有194個服務(wù)點，StackPath也有45個以上。
為什么現(xiàn)在這種新的邊緣架構(gòu)越來越受歡迎呢？在我們考慮由IaaS到邊緣無服務(wù)器的轉(zhuǎn)型演變時，一個絆腳石一直在困擾著，即如何處理動態(tài)數(shù)據(jù)？盡管我們已經(jīng)有了Amazon S3之類的服務(wù)來托管相對靜態(tài)的數(shù)據(jù)，但是真實的數(shù)據(jù)庫仍然難以提供良好的無服務(wù)器體驗。其中的主要原因是構(gòu)建高度一致的分布式系統(tǒng)目前依然相當(dāng)困難。
如今，我們已經(jīng)擁有了具有內(nèi)置安全性的無服務(wù)器數(shù)據(jù)庫，這些數(shù)據(jù)庫為新型應(yīng)用程序創(chuàng)造了條件。默認(rèn)情況下，這些應(yīng)用程序以全球分布式方式進(jìn)行擴(kuò)展。自從這扇門打開以來，許多開發(fā)人員已經(jīng)開始尋求用微服務(wù)和API替換后端部分的方法，以為眾多SaaS服務(wù)提供商打開新的市場。
這一趨勢的最終成果是生態(tài)系統(tǒng)可以運用像Legos一樣的構(gòu)建模塊搭建。預(yù)計不久之后，開發(fā)人員將可以組合自己所需的構(gòu)建模塊，而不必?fù)?dān)心擴(kuò)展或分發(fā)問題。
作者：Brecht De Rooms現(xiàn)為Fauna公司的高級開發(fā)者布道師，其曾經(jīng)在初創(chuàng)公司和IT咨詢公司擔(dān)任過全職開發(fā)人員和研究員，在IT領(lǐng)域有著豐富的從業(yè)經(jīng)驗。他的任務(wù)是闡明新興的強(qiáng)大技術(shù)，讓開發(fā)從員能夠更容易地使用這些技術(shù)構(gòu)建可吸引用戶的應(yīng)用程序和服務(wù)。
編譯：陳琳華
原文網(wǎng)址：https://www.infoworld.com/article/3526480/whats-next-for-serverless-architecture.html?nsdr=true
