隨著各種無服務器平臺的發展，選型時需要注意哪些重要事項？該如何斟酌無服務器平臺的重要功能和監控的注意事項。本文討論選型時下火熱的無服務器平臺的重要考慮因素，可從私有云提供商和自主託管的開源解決方案兩個方面考慮。
開源
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進行處理；客戶端不需要重新配置。
無服務器的未來
它仍然是一個非常有前途的方向，有許多產品並沒有真正的標準。將應用程序碎片化為分散功能確實為CI/CD和計算資源效率提供了優勢，但代價是更高的複雜性和與平臺綁定的風險。
開源產品的開發仍處於早期階段，可靠性不符合生產標準。例如，我嘗試使用提供的helm文件將一些項目部署到Google Kubernetes Engine，卻只有一個項目成功部署。
無服務器監控
觀察無服務器框架及其運行功能的性能對於生產環境至關重要。商業產品的領先者是亞馬遜與CloudWatch和X-Ray。對於開源，領導者是Fn，因為它已經包括Prometheus指標和Jaeger/Zipkin跟蹤。
將開源無服務器平臺部署到Kubernetes會創建大量Deployment，Pod和Container組件。
上面的例子顯示了一個託管的函數OpenFaaS。大多數開源平臺的當前實現技術是為每個函數使用單獨的Docker鏡像，從而導致在Kubernetes上單獨部署。
無服務器功能容器。
憑藉Instana對Kubernetes集群監控的支持，所有這些部署都會自動檢測和監控。隨著通過這些平臺的追蹤標準的發展，Instana將採用它們來提供全自動分佈式追蹤。
閱讀更多 雲智時代 的文章
