這篇文章將為大家詳細講解有關如何深度解讀Serverless架構及平臺選擇，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

創(chuàng)新互聯(lián)主營樂陵網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,手機APP定制開發(fā),樂陵h5小程序定制開發(fā)搭建,樂陵網(wǎng)站營銷推廣歡迎樂陵等地區(qū)企業(yè)咨詢

在 Serverless 產(chǎn)品層面，從最早的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到國內(nèi)阿里云 Serverless Kubernetes、Serverless 應用引擎、函數(shù)計算等，面向計算的 Serverless 云上基礎設施越來越豐富。

新概念、新產(chǎn)品的產(chǎn)生不是憑空出現(xiàn)，它們誕生之初要解決的是當前問題。隨著實踐者對問題域的理解越來越清晰和深刻，問題的處理方法也會逐步迭代，更接近問題本質(zhì)的解決方案也會出現(xiàn)。若不從問題域出發(fā)來理解解決方案，容易陷入兩個極端，即「它能解決一切問題」和「它太超前了，理解不了」。

從日常迭代看 Serverless

圖 1

上圖是一個常用的項目迭代模型，其目標是滿足客戶需求。在這個模型中，項目組通過 被動迭代滿足客戶提出的需求，同時逐步深刻理解客戶需求的本質(zhì)，通過 主動迭代和客戶一起采用更好的方案或從根源解決面對的問題。每次的需求反饋會加深對客戶需求的理解，提供更滿足需求的服務。每次的 bug 反饋會加深對處理方案的理解，提供更穩(wěn)定的服務。

在模型啟動后，日常的核心問題就集中在了 如何加速迭代。

如果想要解決迭代加速的問題，就需要了解有哪些制約因素，有的放矢。下述是從開發(fā)視角看到的開發(fā)模型：

圖 2

雖然在實際應用中會采用不同的開發(fā)語言和架構，但在每個階段均有通用的問題，如：

圖3

除了要解決上述通用問題，還需要提供標準化的方案，降低開發(fā)者的學習和使用成本，縮短從想法到上線的時間。

若將上述過程中不同階段花費的時間做個分析，在項目整個生命周期中會發(fā)現(xiàn)：

• 部署&運維 占用的時間和精力，會遠大于開發(fā)&測試

• 通用邏輯占用的時間和精力，會接近甚至超過業(yè)務邏輯

為了加速迭代，需要依次解決占用時間和精力多的部分，如圖 4 所示：

圖 4

從左至右，通過下放不同層次的運維工作，降低「部署&運維」成本。在降低了運維工作成本后，在「通用邏輯」層面降低成本。二者結合起來，在迭代過程中更深入聚焦業(yè)務。該過程也是從 Cloud Hosting 到 Cloud Native 的過程，充分享受云原生帶來的技術紅利。

由于軟件設計架構和部署架構與當時環(huán)境耦合度高，面對新的理念和服務、產(chǎn)品，存量應用迭代過程中采用的技術需要有相應調(diào)整，即開發(fā)和部署方式需要有一定的改造。對于新應用進行開發(fā)和部署時，應用新的理念有一定的學習和實踐成本。

故上述過程不能一蹴而就，需要根據(jù)業(yè)務當前的痛點優(yōu)先級來選擇匹配的服務和產(chǎn)品，并根據(jù)未來的規(guī)劃提前進行技術預研，在不同的階段選擇適合的服務和產(chǎn)品。

Serverless 簡介

維基百科對于 Serverless 有較為完備的 定義:

Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

無服務器計算是一種云計算執(zhí)行模型，云廠商提供程序運行的服務器，并動態(tài)管理機器資源的分配。云廠商基于應用程序消耗的實際資源量進行定價，而不是用戶預先購買的容量。

在這種計算模型下，會給用戶帶來如下收益：

Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.

無服務器計算可以簡化代碼部署到生產(chǎn)環(huán)境的過程，且擴縮容、容量規(guī)劃和運維操作可以做到對開發(fā)人員透明化。無服務器代碼可以與以傳統(tǒng)方式（如微服務）部署的代碼結合使用，或者，開發(fā)者可以按照無服務器計算的模式編寫應用，完全不用提前配置服務器.

概念本質(zhì)上是對問題域的抽象，是對問題域特征的總結。通過特征來理解概念，可以避免注意力集中在文字描述而非概念的價值本身。

站在用戶角度，我們可以抽象出 Serverless 的如下特征：

• 免運維 (服務器運維、容量管理、彈性伸縮等)

• 按資源的使用量付費

在一定規(guī)模的公司中，若嚴格區(qū)分開發(fā)和運維的角色，這種計算形態(tài)其實是已經(jīng)存在的，并非全新的事物。但目前的技術趨勢，是期望借助云的規(guī)模和技術紅利優(yōu)勢，通過上云來降低業(yè)務在技術側的成本，并通過技術紅利反哺業(yè)務。故業(yè)界對于 Serverless 的討論，注意力是集中在云上的服務和產(chǎn)品所體現(xiàn)的 Serverless 能力。

Serverless 開發(fā)模型

Martin Fowler 的 這篇文章站在架構的角度，對 Serverless 開發(fā)模型做了充分的闡述，這里做個簡單的總結，核心圍繞三點：

• Event-driven 開發(fā)模型

• 自動彈性伸縮

• OpenAPI

Serverless 開發(fā)采用 Event-driven 模型，圍繞 HTTP/HTTPS 請求、時間、消息等 Event 的生產(chǎn)和響應進行架構設計。在這樣的模型中，Event 的生產(chǎn)、處理流程是核心，通過 Event 驅動整個服務流程，注意力集中在整個處理流程。對業(yè)務理解越深刻，Event 類型和業(yè)務會越匹配，技術和業(yè)務的相互促進作用會越有效。

Event-driven 模型，使得 服務常駐這種理念從必選項轉變?yōu)榭蛇x項，可以更好應對業(yè)務請求量的變化，如自動彈性伸縮。同時服務非常駐，可以降低所需的資源成本和維護成本，加速項目迭代。

通過 文章的兩幅圖可以更直觀理解：

圖 5

圖 5 是當前常見的開發(fā)模型，Click Processor 服務是個常駐服務，響應來自用戶的所有點擊請求。生產(chǎn)環(huán)境中，通常會多實例部署，常駐是個關鍵特征，日常的運維重點在確保常駐服務的穩(wěn)定性方面。

圖 6

圖 6 是 Event-driven 開發(fā)模型，關注重心前移，集中在 Event 的產(chǎn)生和響應方面，響應服務是否常駐是個可選項。

Serverless 在概念上與 PaaS (Platform as a Service)、CaaS (Container as a Service) 的區(qū)別，重點是在是否將 自動彈性伸縮作為概念誕生之初的核心特征。

結合 Event-driven 的開發(fā)模型，Serverless 場景中自動彈性伸縮需要對開發(fā)者透明度加深，開發(fā)者開發(fā)過程對處理能力的關注重心從靜態(tài)轉為動態(tài)，更好應對上線后業(yè)務請求量的不確定性。

在開發(fā)方面，交付時可以采用鏡像，也可以采用語言層面的打包 (如 Java 中的 war/jar) ，由平臺負責運行時相關的工作。還可以更進一步，采用 FaaS 的理念，依托于平臺或標準化 FaaS 解決方案，只提供業(yè)務邏輯函數(shù)，由平臺負責請求入口、請求調(diào)用和自動彈性伸縮等運行時事宜。

不論哪種交付方式，在云上均可以使用 BaaS 的理念，將部分邏輯通過云平臺或第三方的 OpenAPI 實現(xiàn)，如權限管理、中間件管理等，開發(fā)過程中注意力更加聚焦在業(yè)務層面。

Serverless 服務模型

Serverless 服務模型關注云廠商對于 Serverless 計算形態(tài)的支持，不同的服務和產(chǎn)品形態(tài)主要差異點主要集中在對 Serverless 特征的理解和滿足程度方面：

• 免運維 (服務器運維、容量管理、彈性伸縮等)

• 按資源的使用量付費

在免運維維度，最基本的是免去服務器運維成本，開發(fā)者可以按量申請資源。在容量管理、彈性伸縮、流量管理、日志/監(jiān)控/告警等常規(guī)的運維層面，不同的服務和產(chǎn)品會根據(jù)自身定位、目標客戶特征等，有側重采用適合的方式來滿足。

在計費形態(tài)方面，云廠商一方面會根據(jù)自身定位確定收費維度，如資源、請求量等，一方面也會根據(jù)當前的技術能力確定收費的粒度。

通過上述分析可知，云廠商不同 Serverless 服務模型不是靜態(tài)的，會伴隨產(chǎn)品定位、目標客戶特征、技術能力等持續(xù)迭代，和客戶共同成長。

Serverless 服務模型需要滿足實際需求，再回到圖 4，云廠商的 Serverless 服務模型可以分為如下幾類：

• 資源實例平臺

• 調(diào)度平臺

• 應用管理平臺

• 業(yè)務邏輯管理平臺

綜合起來，即：

圖7

業(yè)界 Serverless 產(chǎn)品

目前國內(nèi)外云廠商均提供有不同維度的 Serverless 產(chǎn)品，如下做個簡單的總結：

圖 8

資源實例平臺

國外 AWS Fargate / Azure ACI、國內(nèi)阿里云 ECI / 華為 CCI 影響力較大，對用戶提供容器組服務。容器組作為一個整體，提供類似 Kubernetes 中 Pod 的概念。用戶可以通過 OpenAPI 調(diào)用直接創(chuàng)建容器組，不用在部署服務前進行服務器的購買、配置等工作，下放資源相關的容量管理運維工作。用戶可以將資源實例平臺作為容量足夠大的資源池使用，在容器組級別進行細粒度的資源申請，配合動態(tài)擴縮容進行應用級別的容量管理。

一般在生產(chǎn)環(huán)境中，用戶通常不會直接使用此類資源管理服務，而是借助應用編排服務，將這類服務透明化，關注重點放在應用編排維度。

調(diào)度平臺

Kubernetes 是容器調(diào)度的事實標準，國外 AWS EKS、國內(nèi)阿里云 Serverless Kubernetes 等一方面托管 Kubernetes Master 組件，一方面借助資源管理服務，如 VirtualKubelet + AWS Fargate 或 VirtualKubelet + 阿里云 ECI，提供 Kubernetes Node 層服務。

對于期望直接使用 Kubernetes 能力，同時希望低成本運維 Kubernetes、不保有資源池的用戶，此類產(chǎn)品比較契合需求。

應用管理平臺

國外 Google GAE / CloudRun、國內(nèi)阿里云 Serverless 應用引擎等進一步將運維工作服務化，如發(fā)布管理 (打包/灰度/分批/回滾/版本控制等)、日志/監(jiān)控/告警、流量管理、彈性伸縮等，用戶可以進一步專注在業(yè)務需求，低成本運維。

對于期望零成本改造存量應用、低學習成本使用，又期望最大限度減少運維工作的用戶，此類平臺與需求匹配度較高。但由于應用管理層面的運維工作在業(yè)界暫無標準化方案，不同的項目會存在個性化需求，故采用此類產(chǎn)品過程中需要加強溝通，不斷向平臺反饋，通過共建的方式磨合 Serverless 平臺和自身業(yè)務。

業(yè)務邏輯管理平臺

國外 AWS Lambda / Azure Functions / Google Functions、國內(nèi)阿里云函數(shù)計算 / 騰訊云云函數(shù) / 華為函數(shù)工作流等在應用管理的基礎上，進一步將開發(fā)過程中的通用邏輯透明化，用戶僅用關心業(yè)務邏輯的實現(xiàn)。這個過程可以類比開發(fā)過程中的單元測試編寫過程，輸入、輸出是通用的，僅在處理邏輯存在差異。這類 Serverless 產(chǎn)品也是業(yè)界討論最多的形態(tài)，代表業(yè)界對于理想的開發(fā)流程的抽象，可以進一步加快迭代流程，縮短想法到上線的時間。這類 Serverless 產(chǎn)品與云平臺其他類型的產(chǎn)品集成更緊密，以 BaaS 形態(tài)使用云平臺的服務實現(xiàn)通用邏輯，如存儲、緩存等，對云平臺產(chǎn)品豐富度有一定隱性需求。

處理過程對外部依賴較少或偏計算類的場景，如前端、多媒體處理處理等，采用此類 Serverless 產(chǎn)品學習和使用成本相對低，易于上手。隨著服務、組件的抽象程度越來越高，會有越來越多的業(yè)務場景適用，用戶的運維工作會更為透明化，同時開發(fā)過程中可以直接享受到業(yè)界的最佳實踐，服務的穩(wěn)定性、性能、吞吐等方面借助平臺的能力做到最大化。

選型

綜上，用戶在進行 Serverless 產(chǎn)品選型時，需要先整理當前業(yè)務技術所處的階段和痛點，確定對云上方案的需求，然后再根據(jù)云廠商的產(chǎn)品形態(tài)做對應，選擇適合當前階段的服務和云產(chǎn)品。

該對應關系重點是了解云產(chǎn)品定位是否可以長期滿足業(yè)務需求，如：

• 業(yè)務技術目前所處的階段是否與云產(chǎn)品定位匹配

• 業(yè)務快速迭代是否會受限于云產(chǎn)品自身的發(fā)展

• 云產(chǎn)品的穩(wěn)定如何

• 云產(chǎn)品是否可以持續(xù)為業(yè)務帶來技術紅利

  同時還需要了解云產(chǎn)品是否可以伴隨業(yè)務發(fā)展，重點是業(yè)務對技術的需求中，哪些是云產(chǎn)品層面由于定位帶來的限制，哪些是當前云產(chǎn)品的技術實現(xiàn)帶來的限制。

若是云產(chǎn)品定位帶來的限制，那么就需要考慮使用和業(yè)務需求定位更匹配的云產(chǎn)品。若是當前技術實現(xiàn)的限制，那么有機會和云產(chǎn)品共同成長，及時給云產(chǎn)品反饋，使得云產(chǎn)品可以更好滿足自身的業(yè)務需求。

除此之外，業(yè)務層面還需關注云廠商自身服務類型的豐富性，云廠商自身服務越豐富，規(guī)模越大，越會產(chǎn)生規(guī)模效應，進而給業(yè)務帶來更豐富的技術紅利和成本優(yōu)勢。

幸運的是，云產(chǎn)品通常都會有豐富的文檔，也有相應的用戶群，可以直面產(chǎn)品經(jīng)理和研發(fā)，及時反饋需求，以共建的理念協(xié)同發(fā)展。

Serverless 本質(zhì)上是一個問題域，將研發(fā)流程中非業(yè)務核心卻影響業(yè)務迭代的問題抽象化，并提出相應的解決方案。該概念不是突然產(chǎn)生的，大家或多或少已經(jīng)將其理念應用到日常的工作中 ，只是伴隨著云計算浪潮，云上的 Serverless 服務和產(chǎn)品更系統(tǒng)、更具有競爭力，可以基于規(guī)模優(yōu)勢和豐富的產(chǎn)品線，面對問題域持續(xù)提供更滿足業(yè)務需求的服務。

Serverless 理念不僅在中心化的云端蓬勃發(fā)展，目前也逐步在邊緣端發(fā)展，使得服務的運行更加廣泛化，更好滿足業(yè)務自身的客戶，提供更低延時、穩(wěn)定的服務。

本篇文章嘗試從項目、開發(fā)的日常流程出發(fā)，協(xié)助讀者從日常實踐角度來理解 Serverless 概念，根據(jù)所處的階段選擇適合的 Serverless 服務和產(chǎn)品。同時作者本人在阿里云 Serverless 應用引擎中負責底層研發(fā)工作，嘗試從云產(chǎn)品內(nèi)部的視角，傳遞云產(chǎn)品和用戶共建的觀念，通過協(xié)同更好傳遞和創(chuàng)造價值。

關于如何深度解讀Serverless架構及平臺選擇就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

網(wǎng)站名稱：如何深度解讀Serverless架構及平臺選擇
URL鏈接：http://www.rwnh.cn/article10/jgpogo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供云服務器、搜索引擎優(yōu)化、響應式網(wǎng)站、網(wǎng)站建設、企業(yè)建站、服務器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)