無服務(wù)器架構(gòu)的下一步發(fā)展趨勢

Brecht De Rooms

無服務(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ù)和計(jì)算的方式提供了一種解決方案。邊緣無服務(wù)器通過讓計(jì)算更接近用戶的方式減少了延遲。

邊緣無服務(wù)器是15年前開始推出的“基礎(chǔ)設(shè)施即服務(wù)”云架構(gòu)發(fā)展的一個頂點(diǎn)。其下一發(fā)展階段將是進(jìn)一步推動無服務(wù)器“構(gòu)件”的分發(fā)，讓開發(fā)人員更容易使用它們。

現(xiàn)在讓我們回顧一下它們的發(fā)展歷程，并展望其未來發(fā)展趨勢。

分層架構(gòu)基礎(chǔ)設(shè)施即服務(wù)（IaaS）

隨著基礎(chǔ)設(shè)施即服務(wù)的出現(xiàn)，云計(jì)算革命才算真正開始。借助IaaS，企業(yè)可以將其本地基礎(chǔ)設(shè)施移至托管的云基礎(chǔ)設(shè)施上并從那里進(jìn)行操作。用戶只需要根據(jù)他們使用的存儲和計(jì)算時間付費(fèi)，無需再安裝或管理任何硬件或網(wǎng)絡(luò)。

剛開始，IaaS的收費(fèi)貌似很貴，但是企業(yè)還是很快地采用了它們。因?yàn)樵诒ＷC正常運(yùn)行時間上，IaaS遠(yuǎn)遠(yuǎn)超過了本地數(shù)據(jù)中心。此外，企業(yè)自己購買和維護(hù)基礎(chǔ)設(shè)施在費(fèi)用上也遠(yuǎn)遠(yuǎn)超過了IaaS產(chǎn)品。最重要的一個優(yōu)勢是，云計(jì)算消除了硬件維護(hù)和配置工作，從而解放了開發(fā)人員，使其能夠更加專注于業(yè)務(wù)價值。

平臺即服務(wù)（PaaS）

供應(yīng)商將云計(jì)算服務(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)用程序完全可以在云端運(yùn)行，并且可以通過互聯(lián)網(wǎng)和瀏覽器進(jìn)行訪問。從本質(zhì)上說，在云端運(yùn)行且定價模式采用基于訂閱的所有應(yīng)用程序都可被視為SaaS應(yīng)用程序。

SaaS應(yīng)用程序有兩種類型：專注于終端用戶的應(yīng)用程序和專注于開發(fā)人員的應(yīng)用程序。后一種類型旨在為其他應(yīng)用程序提供一個堅(jiān)實(shí)的基礎(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ù)器上運(yùn)行多個實(shí)例。

CaaS服務(wù)提供商提供了一些工具，用以在服務(wù)器上部署容器以及調(diào)整容器實(shí)例的數(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ò)展性方面的顧慮。對于其余部分，用戶通常會考慮運(yùn)行中的容器，這意味著他們?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要更出色，并且不需要配置。在收費(fèi)方面，用戶不使用就不付費(fèi)。

·粒度：PaaS應(yīng)用程序通常是按應(yīng)用程序擴(kuò)展，而基于CaaS構(gòu)建的應(yīng)用程序則按容器擴(kuò)展。FaaS應(yīng)用程序可拆分為單獨(dú)的函數(shù)，因此可以按函數(shù)進(jìn)行擴(kuò)展。缺點(diǎn)是它們經(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ùn)行的應(yīng)用程序或容器實(shí)例的數(shù)量，F(xiàn)aaS則不需要用戶配置擴(kuò)展或預(yù)置特定的資源。

·按需付費(fèi)：在使用容器時（CaaS），無論代碼是否被主動執(zhí)行，用戶都需要付費(fèi)。而在使用FaaS時，只有函數(shù)被調(diào)用時才會產(chǎn)生費(fèi)用。這種按需付費(fèi)的定價模式正逐漸成為無服務(wù)器定義中一個最重要的方面。

·限制：在典型的應(yīng)用程序中，用戶可以為代碼定義內(nèi)存限制或執(zhí)行時間限制。盡管FaaS服務(wù)提供商允許用戶配置這些設(shè)置，但仍有一些上限限制以確保提供商能夠有效地優(yōu)化這些資源。我們可以設(shè)想一下，如果函數(shù)可以使用10GB的RAM或可以運(yùn)行幾個小時的功能，那么提供商將很難評估出要啟動多少臺服務(wù)器才能最為高效地使用他們的資源。

新的邊緣架構(gòu)

無服務(wù)器架構(gòu)消除了預(yù)置和擴(kuò)展方面的問題，但是分發(fā)仍然是一個具有挑戰(zhàn)性的問題。在理想的情況下，我們希望我們的代碼盡可能靠近終端用戶運(yùn)行，以減少延遲。然而直到最近，我們在構(gòu)建應(yīng)用程序的方式上還存在多個問題：

·分發(fā)邏輯：除非用戶將函數(shù)或容器部署在不同的區(qū)域，并且自己將客戶端路由到最近的函數(shù)，否則用戶的函數(shù)通常都保留在一個數(shù)據(jù)中心中。

·分發(fā)動態(tài)數(shù)據(jù)：只分發(fā)邏輯而不分發(fā)數(shù)據(jù)是無法獲得巨大優(yōu)勢的，因?yàn)檠舆t會出現(xiàn)在不同的位置。例如，你的用戶可能離后端更近，但是你的后端仍與數(shù)據(jù)層相距甚遠(yuǎn)。

·成本、配置和監(jiān)控：一個應(yīng)用程序被分布在兩個或三個以上區(qū)域的情況很少見，因?yàn)檫@樣做通常會帶來額外的成本或配置，并且需要用戶監(jiān)控多個區(qū)域的函數(shù)或容器。

無服務(wù)器的下一個發(fā)展趨勢是無需配置即可進(jìn)一步推動分發(fā)和交付。這意味著我們的邏輯和數(shù)據(jù)將在全球許多地區(qū)被分發(fā)，并將有效地降低終端用戶的延遲。

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”的方法正在快速普及，因?yàn)閮?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é)點(diǎn)不一定必須與其他服務(wù)位于同一數(shù)據(jù)中心中。為了將延遲時間減少到最低，我們必須要重新考慮安全模型，以使前端能夠與數(shù)據(jù)庫和其他服務(wù)網(wǎng)絡(luò)進(jìn)行通信。

下面讓我們來看看要實(shí)現(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ù)計(jì)我們很快就會對分布式服務(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ù)庫在本地運(yùn)行一樣。

分布式無服務(wù)器邊緣計(jì)算

Cloudflare worker和StackPath Serverless Scripting等新的無服務(wù)器函數(shù)正在將無服務(wù)器函數(shù)推向邊緣，其旨在使函數(shù)盡可能接近終端用戶，以將延遲降低到最低。目前，Cloudflare workers已經(jīng)擁有194個服務(wù)點(diǎn)，StackPath也有45個以上。

為什么現(xiàn)在這種新的邊緣架構(gòu)越來越受歡迎呢？在我們考慮由IaaS到邊緣無服務(wù)器的轉(zhuǎn)型演變時，一個絆腳石一直在困擾著，即如何處理動態(tài)數(shù)據(jù)？盡管我們已經(jīng)有了Amazon S3之類的服務(wù)來托管相對靜態(tài)的數(shù)據(jù)，但是真實(shí)的數(shù)據(jù)庫仍然難以提供良好的無服務(wù)器體驗(yàn)。其中的主要原因是構(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)可以運(yùn)用像Legos一樣的構(gòu)建模塊搭建。預(yù)計(jì)不久之后，開發(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)驗(yàn)。他的任務(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