無伺服器計算是雲用例中火熱的技術架構之一。在過去的幾年裡，AWS推出其Lambda平台之後，無伺服器已經成為BBC，Airbnb，Netflix，耐克等品牌的主流架構，並且更多採用新方法來處理其後端。

首先無伺服器這個概念並不代表該技術的實際狀態。因為還有一台伺服器，但你只是不需要購買，管理或維護它。你將所有伺服器管理外包給其他人，在你的雲基礎架構中添加抽象級別。對於開發人員來說，這意味著最終推動了伺服器後台配置的能力和創建應用程序之間更加友好。對於企業來說，帶來了更快的應用上市時間，以及專註於開發和部署的應用程序，而不是如何管理伺服器的後台配置。基本上，無伺服器方法是由業務驅動的，第三方處理你的技術問題，而用戶自己專註於交付。

現在，你可能會想：「我們已經將我們的基礎架構放在了雲中，並且不擁有任何硬體。那麼，這跟無伺服器計算有什麼不同呢？」

使用傳統的雲模式（通常稱為Cloud 1.0），只需將存儲和網路移動到雲中，但仍需通過虛擬機（VM）遠程訪問和監控它。無伺服器的方法將它帶到了另一個級別。程序員選擇編寫代碼的環境（Node.js.Python，C＃等），並上傳代碼文件，然後由系統自動部署。通過使用供應商自己的生態系統，你可以輕鬆描述這些服務如何通信以及他們可以訪問數據的位置。這是一種近乎NoOps的方法，大多數Ops都是外包給供應商的。

圖：應用程序部署如何隨著雲發展而變化

為了更深入地了解它如何工作，以及它帶來的好處，我們首先描述一下無伺服器架構的一些定義特徵。

無伺服器的特徵

Function-as-a-Service

無伺服器計算的另一個名稱是功能即服務（FaaS），指的是開發人員將代碼組裝到稱為功能的構建塊中的方式。這與微服務非常相似，在這種微服務中，一個大型代碼塊被分割成小的，可管理的元素，可以分別並行地進行縮放和更新。然而，FaaS通過進一步分解來將其提升到一個新的水平。

圖：微服務與無伺服器：相同的概念，不同的實現

事件驅動的編程

你顯然不希望家裡安裝的攝像頭記錄你的街道24/7發生的一切。這就是為什麼當我們不在家時，我們使用激活的攝像頭來檢測可疑行為。無伺服器架構的工作原理類似：就像運動感測器一樣，它只在特定的預編程事件觸發時才起作用。無伺服器是無狀態的，這意味著它只執行一個任務，不存儲或重用請求。

可伸縮服務

無伺服器方法非常靈活，是擴展應用程序的理想選擇。FaaS供應商將你的每個功能都分別放在不同的容器中運行。這使你可以無限制地自動調整它們。這是無伺服器和傳統雲之間的另一個區別。在這裡你不必購買預訂的資源量，你可以儘可能地靈活。

每次調用帳單

在傳統的雲模式中，你需要伺服器隨時準備處理請求。不管實際使用的CPU時間和內存如何，持續的伺服器可用性都會導致每月大量的後端成本。或者，無伺服器供應商允許你為每個請求支付一小部分的費用，這意味著你的成本僅取決於你本月的流量。

AWS Lambda，微軟Azure Functions，Google Cloud Functions和IBM Bluemix OpenWhisk等功能即服務供應商提供了類似的解決方案。談到定價，他們在預算上很容易：高達100萬的請求是免費的，給你一個很好的起點。差異主要在於社區支持和支持語言的可用性，這使得選擇更具個性化。

無伺服器計算的優點

在工程方面，無伺服器的好處是顯而易見的。這是一種簡化的開發方法，消除了複雜的層面，簡化了工程設計。但是商業方面呢？你如何說服利益相關者，證明FaaS是未來方向？

比傳統雲便宜

正如我們所提到的，FaaS允許你為每個請求支付一小部分的費用。如果你是一家創業公司，那麼你幾乎可以免費創建一個MVP，並且輕鬆進入市場，而不需要處理大量的賬單以獲得最小的流量。

可擴展

每個人都想要構建下一個優步，但是你會冒險調配基礎設施以防萬一？無伺服器，你不必做出選擇，但你仍然可以為任何增長量做好準備。

降低人力資源成本

就像你不必花費數百或數千美元購買硬體一樣，你可以停止為工程師付費來維護它。

能夠專註於用戶體驗

允許公司投入更多時間和資源來開發和改進面向客戶的功能。

無伺服器計算的缺點

供應商鎖定

當你讓供應商控制你的運維時，你必須按照他們的規則來玩。如果你已將應用程序設置到Lambda上，將應用程序移植到Azure也不是一件容易的事情。同樣的問題涉及編程語言：現在只有Node.js和Python開發人員可以自由選擇現有的無伺服器選項。

學習曲線

儘管有全面的文檔和社區資源，你可能很快就會發現FaaS工具的學習曲線非常陡峭。此外，為了平滑的遷移到無伺服器，你可能希望將你的「龐然大物」分為微服務，這是另一個需要解決的複雜任務。這就是為什麼最好從無伺服器工具經驗豐富的專業人士那裡獲得幫助。

不適合長期任務

Lambda給你五分鐘執行任務，如果花費更長時間，你將不得不調用另一個函數。無伺服器非常適用於發送電子郵件等短實時或接近實時的流程。但長時間操作（如上傳視頻文件）需要額外的FaaS功能，或者更適合「伺服器」的架構。

無伺服器架構用例

目前，大多數技術採用者都是初創公司，他們尋求平滑擴展和降低入口障礙的可能性。無伺服器也是一種完美的方法，適用於不連續運行，但具有安靜時段和高峰流量的應用程序。

物聯網應用

無伺服器方法的實時響應特性非常適合物聯網用例。上面已經提到的激活攝像頭，以及對天氣，溫度或健康狀況變化作出反應的應用程序，對於無伺服器用例而言是完美的，它不會讓你的服務全天候閑置。

虛擬助理和聊天機器人

希望得到即時響應，這就是無伺服器數據處理速度更快的原因。隨著你的應用程序從一百個增加到幾千個用戶，你的處理時間也應該保持不變，FaaS可以自動處理。

圖像豐富的應用

為了保持良好的用戶體驗，開發人員必須為不同的屏幕尺寸提供多個版本的相同圖像，從台式機到平板電腦和智能手機。這顯著減少了載入時間。然而，來自AWS和Google的工具將自動優化你的圖像以滿足任何需求，使其成為適合圖像大量應用的完美解決方案。

敏捷和持續集成管道

僅當某個事件被觸發時才運行代碼的想法完全符合敏捷或持續集成原則。將代碼分離成函數還有助於糾正錯誤和發送更新。無伺服器是實現最大自動化和快速部署過程的整體友好方式。

無伺服器架構選型

隨著各種無伺服器平台的發展，選型時需要注意哪些重要事項？該如何斟酌無伺服器平台的重要功能和監控的注意事項。

開源無伺服器架構

OpenFaaS，Kubeless，Fn，OpenWhisk等等，它們都是目前熱門的無服務架構解決方案。大多數開源產品都在Kubernetes上運行。它們可以運行在雲中的Kubernetes服務（KaaS）或你的內部Kubernetes集群上。如果部署在內部的集群上，運行無伺服器的平台，看上去會不會有點矛盾？

所有這些開源項目仍處於早期階段。目前還沒有特別明顯的區分出哪個解決方案最受歡迎。

對這些開源平台的運行時（runtime）支持，包含廣泛的流行語言以及構建自定義運行時的能力。每個功能通常部署為Docker容器。只要該容器符合介面要求，它就會運行。

對於所有這些無伺服器平台，可觀察性至關重要，因為它們在已經非常複雜的平台Kubernetes之上增加了另一層複雜性。無伺服器平台和Kubernetes的順利運行對託管功能的順利運行至關重要。其中一些項目已經考慮了可觀察性，並提供了Prometheus度量端點。Fn還包括Zipkin和Jaeger的Open Tracing實現。

雲提供商的無伺服器架構

AWS Lambda，Google Cloud Functions，微軟Azure Function Apps，最近IBM已經通過託管版本的OpenWhisk進入了這個領域。其中AWS Lambda時間最長，是最成熟的產品；它已經在運行亞馬遜Alexa服務的重要部分。

所有這些託管產品都提供了與雲中託管的功能相同的基本功能，在不使用它們時不需要任何費用，並且在執行時按微秒計費。所有平台都提供一個Web用戶界面和CLI工具來管理這些功能。可以將觸發功能引入雲平台的其他服務，AWS擁有目前最豐富的可用服務。

所有平台都提供基本的監控和日誌匯總功能。AWS Lambda是利用X-Ray提供可觀察性的領導者，它提供跨各種AWS服務的端到端跟蹤。Google的Stackdriver追蹤功能目前僅可用作預覽版本，並且尚不支持自動追蹤無伺服器功能。微軟Azure和IBM OpenWhisk不提供任何跟蹤功能。

運行異構服務

有了如此多的無伺服器平台可供選擇，問題是哪一個最適合你的需求？好消息是你不必做出選擇。無伺服器項目提供了用於管理功能的通用工具和用於將事件映射到功能的事件網關。

管理工具

使用一個定義文件和一個命令行工具，可以將無伺服器功能部署到這些提供程序支持的任何語言運行時的許多提供程序中。這種自動化水平使得從一個供應商到另一個供應商的功能不那麼痛苦。但是，函數並不是真正的可移植的，因為目前沒有任何函數入口點標準，返回數據或者在運行時可用的庫。

事件網關

雖然每個雲提供商都有自己的API網關，但它們通常不會為多種提供商解決方案提供多少便利。無伺服器事件網關提供了供應商不可知的解決方案，既可以作為服務提供，也可以作為Docker鏡像在你想要的位置運行。由於此API網關與任何供應商無關，因此可以接收來自任何提供商或外部來源的事件，並路由到任何其他提供商或外部目的地。

圖：無伺服器網關流程。

利用第三方網關可以用最少的配置交換無伺服器端點。

例如，客戶端通過HTTP調用事件網關，事件最初路由到AWS Lambda並進行處理。通過簡單的配置更改，可以將相同的客戶端呼叫路由到Google Cloud Functions進行處理；客戶端不需要重新配置。

無伺服器監控

觀察無伺服器框架及其運行功能的性能對於生產環境至關重要。商業產品的領先者是亞馬遜與CloudWatch和X-Ray。對於開源，領導者是Fn，因為它已經包括Prometheus指標和Jaeger/Zipkin跟蹤。

將開源無伺服器平台部署到Kubernetes會創建大量Deployment，Pod和Container組件。

上面的例子顯示了一個託管的函數OpenFaaS。大多數開源平台的當前實現技術是為每個函數使用單獨的Docker鏡像，從而導致在Kubernetes上單獨部署。

無伺服器功能容器。

憑藉Instana對Kubernetes集群監控的支持，所有這些部署都會自動檢測和監控。隨著通過這些平台的追蹤標準的發展，Instana將採用它們來提供全自動分散式追蹤。

無伺服器是未來嗎？

走向無伺服器不僅僅意味著技術變革，而且意味著業務變革。對於許多在傳統基礎設施上運行的公司而言，遷移將是痛苦的，並不具有成本效益。當你已經建立了工作流程時，採用FaaS工具來徹底擺脫伺服器管理是很難證明的。另外，無伺服器遠非主流，儘管它朝著這個方向發展並且非常快。

作為一個非常有前途的方向，有許多產品並沒有真正的標準。將應用程序碎片化為分散功能確實為CI/CD和計算資源效率提供了優勢，但代價是更高的複雜性和與平台綁定的風險。

開源產品的開發仍處於早期階段，可靠性不符合生產標準。例如，我嘗試使用提供的helm文件將一些項目部署到Google Kubernetes Engine，卻只有一個項目成功部署。

Gartner預測，在2017年的新興技術炒作周期中，無伺服器/FaaS將在未來2-5年內達到如機器學習，VR和物聯網的生產力水平。該技術已經可用，而真正的挑戰是確定可能用例的廣度，並等待來自所有供應商的更大的編程語言和功能支持。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！