此頁面上的內容需要較新版本的 Adobe Flash Player。

獲取 Adobe Flash Player

CIO 資訊

CIO,讓企業跟上“Serverless”的步伐
作者:   來源:計算機世界   日期:2020-06-08

   無服務器架構的下一步發展趨勢,是將邏輯和數據自動分發到邊緣,可為終端用戶帶來最低的延遲,并且無需考慮為開發人員進行準備、擴展和配置等事情。

   無服務器服務正變得無處不在。作為向新的編程方式發展的推動力,無服務器產品正在以各種形式出現,如應用程序托管平臺、無服務器數據庫、CDN、安全產品等等。

   無服務器產品消除了底層配置、可伸縮性和預置方面的問題,最后剩下的就是分發問題。邊緣無服務器服務通過在多個數據中心之間分發數據和計算的方式提供了一種解決方案。邊緣無服務器通過讓計算更接近用戶的方式減少了延遲。

   邊緣無服務器是15年前開始推出的“基礎設施即服務”云架構發展的一個頂點。其下一發展階段將是進一步推動無服務器“構件”的分發,讓開發人員更容易使用它們。

   現在讓我們回顧一下它們的發展歷程,并展望其未來發展趨勢。

   分層架構

   基礎設施即服務(IaaS)

   隨著基礎設施即服務的出現,云計算革命才算真正開始。借助IaaS,企業可以將其本地基礎設施移至托管的云基礎設施上并從那里進行操作。用戶只需要根據他們使用的存儲和計算時間付費,無需再安裝或管理任何硬件或網絡。

   剛開始,IaaS的收費貌似很貴,但是企業還是很快地采用了它們。因為在保證正常運行時間上,IaaS遠遠超過了本地數據中心。此外,企業自己購買和維護基礎設施在費用上也遠遠超過了IaaS產品。最重要的一個優勢是,云計算消除了硬件維護和配置工作,從而解放了開發人員,使其能夠更加專注于業務價值。

   平臺即服務(PaaS)

   供應商將云計算服務又向前推進了一步,開始提供平臺即服務。用戶可以通過PaaS解決方案租用構建應用程序所需要的一切,而不僅僅是租用服務器。該方案不僅包括服務器,還包括操作系統、編程語言環境、數據庫和數據庫管理工具。

   與IaaS服務提供商讓用戶成為租用服務器的管理員不同,PaaS服務提供商則是接管了服務器管理任務,例如軟件安裝或安全更新,并經常會對用戶代碼的環境要求進行預測。PaaS的目標是為用戶提供一種簡單的方法來部署他們的應用程序。PaaS將開發人員從系統管理任務中解放出來,讓他們能夠專注于最重要的應用程序。與IaaS相比,PaaS又向前邁進了一步。

   在向公眾提供PaaS產品的眾多服務提供商中,AWS Elastic Beanstalk、Google App Engine和Heroku是其中的典型代表。

   軟件即服務(SaaS)

   軟件即服務通常是指可以通過各種訂閱獲得的在線托管應用程序。這些應用程序完全可以在云端運行,并且可以通過互聯網和瀏覽器進行訪問。從本質上說,在云端運行且定價模式采用基于訂閱的所有應用程序都可被視為SaaS應用程序。

   SaaS應用程序有兩種類型:專注于終端用戶的應用程序和專注于開發人員的應用程序。后一種類型旨在為其他應用程序提供一個堅實的基礎。Gmail、Dropbox、Jira、BitBucket和Slack都是典型的專注于終端用戶的SaaS應用程序,Stripe和Slaask還開放了API允許用戶將其SaaS解決方案集成到他們自己的應用程序中。

   容器即服務(CaaS)

   容器平臺是IaaS的最新形式。CaaS服務提供商可讓用戶在容器中托管服務或應用程序,或是讓用戶自己管理容器,而不再提供完整的服務器主機。

   與虛擬機相比,容器可更為高效地利用底層的主機資源。人們可以將容器視為“微型機器”。它們能夠快速啟動,并且可在單個服務器上運行多個實例。

   CaaS服務提供商提供了一些工具,用以在服務器上部署容器以及調整容器實例的數量。最先進的產品完全可為用戶管理底層服務器,讓用戶能夠專注于代碼(或容器)而不是基礎設施。

   如今,CaaS已迅速發展成為了PaaS和SaaS的一個構建模塊,從而形成了一種分層的體系結構。開發應用程序工作也逐步變成了金字塔結構。由于目前可用的平臺還不夠靈活,無法提供應用程序所需的一切,因此許多復雜的應用程序采取的辦法是綜合使用SaaS、PaaS和CaaS。

   通過盡可能地依靠SaaS,用戶可以擺脫配置和可擴展性方面的顧慮。對于其余部分,用戶通常會考慮運行中的容器,這意味著他們仍然需要進行預置和配置。

   為了減少這些顧慮,人們開發出了第五種解決方案,即無服務器架構。無服務器架構填補了這方面的空白。

   無服務器架構

   函數即服務(FaaS)

   在FaaS中,用戶在上載和執行代碼時無需考慮擴展、服務器或容器。從這個意義上講,它們在易用性方面超越了先前的產品,不過它們也存在一些局限性。這些局限性在PaaS中不怎么明顯,但是在FaaS卻被放大了。

   FaaS的最大優勢是擴展。FaaS擴展的粒度比PaaS或CaaS要更出色,并且不需要配置。在收費方面,用戶不使用就不付費。

   ● 粒度:PaaS應用程序通常是按應用程序擴展,而基于CaaS構建的應用程序則按容器擴展。FaaS應用程序可拆分為單獨的函數,因此可以按函數進行擴展。缺點是它們經常需要用戶重新考慮應用程序的架構。用戶必須對許多執行較小任務的函數進行管理,而不再是管理一個應用程序或幾個容器,不過其中的不足是這可能會導致產生大量的編排工作。

   ● 配置:用戶通常需要對擴展的位置,觸發擴展的時機(以進行向上和向下擴展)進行配置,以及手動設置需要運行的應用程序或容器實例的數量,FaaS則不需要用戶配置擴展或預置特定的資源。

   ● 按需付費:在使用容器時(CaaS),無論代碼是否被主動執行,用戶都需要付費。而在使用FaaS時,只有函數被調用時才會產生費用。這種按需付費的定價模式正逐漸成為無服務器定義中一個最重要的方面。

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

   新的邊緣架構

   無服務器架構消除了預置和擴展方面的問題,但是分發仍然是一個具有挑戰性的問題。在理想的情況下,我們希望我們的代碼盡可能靠近終端用戶運行,以減少延遲。然而直到最近,我們在構建應用程序的方式上還存在多個問題:

   ● 分發邏輯:除非用戶將函數或容器部署在不同的區域,并且自己將客戶端路由到最近的函數,否則用戶的函數通常都保留在一個數據中心中。

   ● 分發動態數據:只分發邏輯而不分發數據是無法獲得巨大優勢的,因為延遲會出現在不同的位置。例如,你的用戶可能離后端更近,但是你的后端仍與數據層相距甚遠。

   ● 成本、配置和監控:一個應用程序被分布在兩個或三個以上區域的情況很少見,因為這樣做通常會帶來額外的成本或配置,并且需要用戶監控多個區域的函數或容器。

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

   CDN和JAMstack

   我們已經在使用自動分發的基本服務形式,被稱為內容交付網絡(CDN)。Netlify和Zeit等公司認為,通過盡可能多地預生成應用程序以及使用無服務器函數和SaaS API處理動態部分已經能夠實現自動分發。

   這種被Netlify稱為“JAMstack”的方法正在快速普及,因為內容交付網絡首先帶來了邊緣架構可以提供的功能。當然,JAMstack也存在一些限制,如僅可基于服務器端渲染,新流入的內容必須觸發構建等。這些限制使得將這種方法應用于有著大量構建時間的高度動態的網站非常具有挑戰性。

   增量構建和諸如客戶端激活之類的概念為該問題提供了部分解決方案,但是我們還是希望復雜網站同時能夠具有兩大優勢:終端用戶的延遲(極低)和新內容可立即被訪問。

   分布式服務的興起

   在我們通常使用的架構中,前端與后端進行通信,后端又與數據庫和其他服務進行通信。后端和數據庫通常會一起擴展,以保持后端和數據庫之間的延遲處于很低的狀態。分布式是有可能做到的,不過這通常很麻煩,這也使得它們受到了限制。

   在未來的架構中,對分布式服務的使用將把JAM的理念提升到一個新的層次。這些服務中的每一個都將是一個分布式網絡,其節點不一定必須與其他服務位于同一數據中心中。為了將延遲時間減少到最低,我們必須要重新考慮安全模型,以使前端能夠與數據庫和其他服務網絡進行通信。

   下面讓我們來看看要實現這一目標需要哪些服務。

   分布式服務網絡

   許多SaaS平臺(如Algolia和SendGrid)旨在成為其他應用程序的構建基塊。目前服務提供商已經開發出了特定的服務,以消除典型后端應用程序中的特定問題,其中一些正在發展成為分布式服務,例如Algolia(其自稱為分布式搜索網絡,DSN)。許多其他的Saas平臺也正在緊跟這一發展趨勢,預計我們很快就會對分布式服務網絡是否作為SaaS應用程序的下一個發展趨勢展開討論。

   分布式無服務器數據庫

   Azure Cosmos DB、Google Cloud Spanner和FaunaDB等數據庫正在采用即付即用的無服務器模式,并通過某種形式的ACID保證提供現成的分發。某些數據庫還提供了安全層和原生GraphQL API,這些安全層和本機GraphQL API可以由客戶端應用程序安全使用,并可以與無服務器后端很好地配合使用。這些安全層使得用戶界面可以直接與數據庫進行交互,而不僅僅是與后端進行交互。理想情況下,前端應用程序可以與具有低延遲和ACID保證的全球分布式數據庫進行通信,使用起來就像數據庫在本地運行一樣。

   分布式無服務器邊緣計算

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

   為什么現在這種新的邊緣架構越來越受歡迎呢?在我們考慮由IaaS到邊緣無服務器的轉型演變時,一個絆腳石一直在困擾著,即如何處理動態數據?盡管我們已經有了Amazon S3之類的服務來托管相對靜態的數據,但是真實的數據庫仍然難以提供良好的無服務器體驗。其中的主要原因是構建高度一致的分布式系統目前依然相當困難。

   如今,我們已經擁有了具有內置安全性的無服務器數據庫,這些數據庫為新型應用程序創造了條件。默認情況下,這些應用程序以全球分布式方式進行擴展。自從這扇門打開以來,許多開發人員已經開始尋求用微服務和API替換后端部分的方法,以為眾多SaaS服務提供商打開新的市場。

   這一趨勢的最終成果是生態系統可以運用像Legos一樣的構建模塊搭建。預計不久之后,開發人員將可以組合自己所需的構建模塊,而不必擔心擴展或分發問題。

   作者:Brecht De Rooms現為Fauna公司的高級開發者布道師,其曾經在初創公司和IT咨詢公司擔任過全職開發人員和研究員,在IT領域有著豐富的從業經驗。他的任務是闡明新興的強大技術,讓開發從員能夠更容易地使用這些技術構建可吸引用戶的應用程序和服務。

   編譯:陳琳華


? 吉林棋牌白山麻将 陕西11选五软件 天津11选五一定牛 山东群英会围三最大遗漏 投资平台软件小金库 吉林快三开奖视频 北京快3一定牛 2008上证指数 广东快乐十分选码技巧 上市股票指数 四肖期期中准免费资料