*作者 | 劉宇、田初東、盧萌凱、王仁達*

## 導讀

UC Berkeley 認為 Serverless 架構的出現過程類似於 40 多年前從組合語言轉向高階語言的過程，在未來 Serverless 架構的使用會飆升，或許伺服器式雲端計算並不會消失，但是將促進 BaaS 發展，以更好地為 Serverless 架構提供支援。

## Serverless 架構的應用開發流程

基於 Serverless 架構的應用開發流程將會比基於傳統架構的應用開發更簡單。在 Serverless 架構下進行應用開發，使用者通常只需要按照規範編寫程式碼、構建產物，然後部署到線上即可。

如圖 1 所示，CNCF Serverless Whitepaper v1.0 指出函式的生命週期從編寫程式碼並提供規範後設資料開始，一個 Builder 實體將獲取程式碼和規範，然後編譯並將其轉換為工件，接下來將工件部署在具有控制器實體的叢集上。該控制器實體負責基於事件流量和/或例項上的負載來擴充套件函式例項的數量。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0fc834e52abe4262893eb1ae3a514d68~tplv-k3u1fbpfcp-zoom-1.image "1.png")

圖-1 函式部署流水線示意圖

如圖 2 所示，函式建立和更新的完整流程如下。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/68db671d29324e4991f85158de1dd6f6~tplv-k3u1fbpfcp-zoom-1.image "2.png")

圖-2 函式建立/更新流程示意圖

1）在建立函式時，提供其後設資料作為函式建立的一部分，對其進行編譯使其具有可釋出的特性。接下來啟動、禁用函式。函式部署要能夠支援以下用例。

-   事件流（Event Streaming）：在此用例中，佇列中可能始終存在事件，但是可能需要透過請求暫停/恢復進行處理。

-   熱啟動（Warm Startup）：在任何時候，具有最少例項的函式能使所接收的“第一”事件快速啟動，因為該函式已經部署並準備好為事件服務（而不是冷啟動），其中函式透過“傳入”事件在第一次呼叫時部署。

2）使用者可以釋出一個函式，這將建立一個新版本（最新版本的副本），釋出的版本可能會被標記或有別名。

3）使用者可能希望直接執行/呼叫函式（繞過事件源或 API 閘道器）以進行除錯和開發過程。使用者可以指定呼叫引數，例如所需版本、同步/非同步操作、詳細日誌級別等。

4）使用者可能想要獲得函式統計資料（例如呼叫次數、平均執行時間、平均延遲、失敗次數、重試次數等）。

5）使用者可能想要檢索日誌資料，這可以透過嚴重性級別、時間範圍、內容來過濾。Log 資料是每個函式級別的，它包括諸如函式建立/刪除、警告或除錯訊息之類的事件，以及可選的函式的 Stdout 或 Stderr。優選每次呼叫具有一個日誌條目或者將日誌條目與特定呼叫相關聯的方式（以允許更簡單地跟蹤函式執行流）。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c31dfa11dba84f1bbce595344200412c~tplv-k3u1fbpfcp-zoom-1.image "3.png")

圖-3 開發 Serverless 應用的流程

如圖 3 所示，以阿里雲 Serverless 產品為例，在生產環境中開發 Serverless 應用的流程是：

步驟 1：根據 FaaS 供應商所提供的 Runtime，選擇一個熟悉的程式語言，然後進行專案開發、測試；

步驟 2：完成之後將程式碼上傳到 FaaS 平臺；

步驟 3：上傳完成之後，透過 API/SDK 或者由一些雲端的事件源觸發上傳到 FaaS 平臺的函式；

步驟 4：FaaS 平臺就會根據觸發的併發度等彈性執行對應的函式；

步驟 5：最後使用者根據實際資源使用量按量付費。

## 與 ServerFul 應用開發流程對比

下面我們將透過生產環境中的案例，對傳統架構下的應用開發與 Serverless 架構下的應用開發進行舉例對比。

以一個 Web 應用為例。如圖 4 所示；

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/411b535d91e4407a97687a931127c923~tplv-k3u1fbpfcp-zoom-1.image "4.png")

圖-4 傳統三層 C/S 架構下某電子商務網站應用簡圖

通常情況下一些 Web 應用都是傳統的三層 C/S 架構，例如一個常見的電子商務應用，假設它的服務端用 Java，客戶端用 HTML/JavaScript；在這個架構下服務端僅為雲伺服器，承載了大量業務功能和業務邏輯，例如，系統中的大部分邏輯（身份驗證、頁面導航、搜尋、交易等）都在服務端實現。

當把它改造成 Serverless 應用形態時，架構如圖 5 所示。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8404050f58444b01ab9abc0b1cf6a26f~tplv-k3u1fbpfcp-zoom-1.image "5.png")

圖-5 Serverless 架構下某電子商務網站應用架構簡圖

步驟 1：在 Serverless 應用形態下，移除最初應用中的身份驗證邏輯，換用一個第三方的  BaaS  服務；

步驟 2：允許客戶端直接訪問一部分資料內容，這部分資料完全由第三方託管，這裡會用一些安全配置來管理客戶端訪問相應資料的許可權。

步驟 3：前面兩點已經隱含了非常重要的第三點，即先前伺服器端的部分邏輯已經轉移到了客戶端，如保持使用者會話、理解應用的 UX 結構、獲取資料並渲染使用者介面等，客戶端實際上已經在逐步演變為單頁應用；

步驟 4：還有一些任務需要保留在伺服器上，比如繁重的計算任務或者需要訪問大量資料的操作。這裡以“搜尋”為例，搜尋功能可以從持續執行的伺服器端拆分出來，以 FaaS 的方式實現，從 API 閘道器（後文做詳細解釋）接收請求並返回響應。這個伺服器端函式可以和客戶端一樣，從同一個資料庫讀取產品資料。原先的搜尋程式碼略做修改就能實現這個“搜尋”函式；

步驟 5：還可以把“購買”功能改寫為另一個 FaaS 函式，出於安全考慮，它需要在伺服器端而非客戶端實現，它同樣由 API 閘道器暴露給外部使用。

傳統雲主機架構下應用的開發和上線如圖 6 所示。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1b0d630997bc4eac884a38f7bf86aaa0~tplv-k3u1fbpfcp-zoom-1.image "6.png")

圖-6 傳統雲主機架構下應用開發和上線流程簡圖

開發者完成程式碼開發之後，需要進行上線前的準備，包括但不限於評估資源、購買伺服器、安裝作業系統、安裝伺服器軟體等，完成之後再進行程式碼部署，之後還需要有專業的人或者團隊，對伺服器等資源進行持續監控和運維等，例如流量突然提升時需要進行伺服器的平滑擴容，流量突然降低時需要進行伺服器的平滑縮容等。

但是在 Serverless 架構下，整個開發模式發生了比較大的改變。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a05e8b7f2929485c85d1ac48c9465a27~tplv-k3u1fbpfcp-zoom-1.image "7.png")

圖-7 Serverless 架構下應用開發和上線流程簡圖

結合上面某電子商務網站見圖 7，在上述應用開發和上線流程中，Serverless 架構開發者實際關心的只剩下函式中的業務邏輯，至於身份驗證邏輯、API 閘道器以及資料庫等原先在伺服器端的一些產品和服務統統由雲廠商提供。

同時，使用者不需要關注伺服器層面的維護，也無須為流量的波峰和波谷進行運維資源的投入。使用者也無須為資源閒置進行額外的支出，Serverless 架構的按量付費以及彈性伸縮能力、服務端低運維/免運維能力，可以讓使用者的資源成本、人力成本降低，整體研發效能大幅提升，讓專案的效能、安全性、穩定性得到極大的保障。

綜上所述，Serverless 架構與傳統架構應用開發流程的明顯區別是，前者讓開發者將更多的精力放在自身業務邏輯上，並強調 Noserver 的心智，將更專業的事情交給更專業的人去做，這有助於業務的創新和效率的提升，降低業務上線及迭代週期等。

## 面臨的挑戰

雖然 Serverless 架構發展迅速，被更多的人認為是真正意義的雲端計算，甚至在 2020 年的雲棲大會上，Serverless 被再次斷言“將會引領雲端計算的下一個十年”。但是，Serverless 架構仍然面臨著諸多挑戰。

19 年 UC Berkeley 的文章“Cloud Programming Simplified:A Berkeley View on Serverless Computing” ：針對 Serverless 架構總結出了下面五項挑戰。

**1）Abstraction Challenge**

資源需求（Resource Requirement）：透過 Serverless 產品，開發人員可以指定雲功能的記憶體大小和執行時間，而無法指定其他資源需求。這阻礙了那些想要控制更多指定資源的人，例如 CPU、GPU 或其他型別的加速器等資源。

資料依賴（Data dependence）：今天的雲功能平臺不瞭解雲功能之間的資料依賴性，更不瞭解這些功能可能交換的資料量。這可能導致次優放置，從而導致通訊模式效率低下。

**2）System Challenge**

臨時性儲存（Ephemeral Storage）：為 Serverless 應用提供臨時儲存的一種方法是使用最佳化的網路棧構建分散式記憶體服務，以保證微秒級的延遲。

永續性儲存（Durable Storage）：與其他應用程式一樣，Serverless 資料庫應用受到儲存系統的延遲和 IOPS 的限制，需要長期的資料儲存和檔案系統的可變狀態語義。

協調服務（Coordination Service）：功能之間的共享狀態通常使用生產者-消費者設計模式，這需要消費者在生產者獲得資料時立即知道。

最小化啟動時間（Minimize Startup Time）：啟動時間包括 3 個部分，一是排程和啟動資源以執行雲功能的時間，二是下載應用軟體環境（例如作業系統、庫）以執行功能程式碼的時間，三是執行特定於應用程式的啟動任務的時間，例如載入和初始化資料結構和庫的時間。資源排程和初始化可能會因建立隔離的執行環境以及配置客戶的 VPC 和 IAM 策略而產生顯著的延遲和開銷。

**3）Networking Challenge**

雲功能可能會對流行的通訊原語（如廣播、聚合和混洗）產生巨大的開銷。

**4）Security Challenge**

Serverless 架構重新分配了安全責任，將其中許多人從雲使用者轉移到雲提供商，而沒有從根本上改變它們。但是，Serverless 架構還存在應用程式分解多租戶資源固有的風險。

**5）Computer Architecture Challenge**

主宰雲的 x86 微處理器效能提升速度緩慢。

當然，此處所認為的 Serverless 架構面臨的挑戰相對來說是比較抽象的。就目前的工業界實際情況來看，這些挑戰依舊普遍存在，也是當今眾多雲廠商不斷努力的方向。站在 Serverless 開發者角度來說，將上述挑戰與開發者最為關注的幾個問題結合起來，可以認為 Serverless 架構目前所面臨的挑戰包括不限於冷啟動問題、廠商鎖定、配套資源不完善等。

### 冷啟動問題

所謂的冷啟動問題，指的是 Serverless 架構在彈性伸縮時可能會觸發環境準備（初始化工作空間）、下載檔案、配置環境、載入程式碼和配置、函式例項啟動完整的例項啟動流程，導致原本數毫秒或數十毫秒可以得到的請求響應需要在數百毫秒或數秒得到，進而影響業務處理速度。

正如前面所說，任何事物都有兩面性。Serverless 架構具備彈性伸縮優勢的同時，相對 ServerFul 架構而言也引入一個新的問題：冷啟動問題。Serverless 架構下，開發者提交程式碼之後，平臺一般只會對其持久化並不會為其準備執行環境。所以，當函式第一次被觸發時會有一個比較漫長的準備環境的過程，這個過程包括把網路的環境全部打通、將所需的檔案和程式碼等資源準備好。

這個從準備環境開始到函式被執行的過程，被稱為函式的冷啟動。由於 Serverless 架構具有彈性伸縮能力，Serverless 服務的供應商會根據流量波動進行例項的增加或縮減，所以平臺就可能頻繁準備新的環境、下載函式程式碼、啟動例項來應對不斷產生的請求。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e92190b6dfa14e7985aa9f9ec93658c6~tplv-k3u1fbpfcp-zoom-1.image "8.png")

圖-7 函式計算根據流量進行函式擴縮示意圖

如圖 7 所示，當 Serverless 架構的 FaaS 平臺中某函式被觸發時，FaaS 平臺將會根據具體情況進行例項的複用或者新例項的啟動。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/df6db006de0644b5aa2d8b74d4d045fd~tplv-k3u1fbpfcp-zoom-1.image "9.png")

圖-8 FaaS 平臺例項啟動流程簡圖

如圖 8 所示，當有空閒且符合複用要求的例項時，FaaS 平臺將會優先使用，這個過程是所謂的熱啟動過程。否則，FaaS 平臺將啟動新的例項來應對此時的請求，這個過程則是對應的冷啟動過程。

Serverless 架構這種自動的零管理水平縮放，將持續到有足夠的程式碼例項來處理所有的工作負載為止。

其中，“新例項的啟動”包括初始化工作空間、下載檔案和配置環境、載入程式碼和依賴、函式例項啟動等幾個步驟。相對於熱啟動在數毫秒或者幾十毫秒內的啟動，冷啟動所多出來的這幾個步驟耗時可能是數百毫秒甚至數秒。這種在生產時出現的新例項啟動，並導致業務響應速度受到影響的情況，通常就是大家所關注的冷啟動帶來的影響，如圖 9 所示。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6082bd65b03643069ac160d1cc2774d0~tplv-k3u1fbpfcp-zoom-1.image "10.png")

圖-9 函式冷啟動產生示意圖

綜上所述，不難分析和總結出冷啟動問題出現的常見場景。

函式的第一次啟動：函式部署後的第一次啟動，通常是不存在已有例項，所以此時極易出現冷啟動問題。

請求併發：當前一個請求還沒有完成，就收到了新的請求，此時 FaaS 平臺會啟動新的例項來應對新的請求，進而出現冷啟動問題。

前後兩次觸發間隔太久：函式的前後兩次觸發時間間隔超過了例項釋放時間的閾值，也會引發函式的冷啟動問題。目前來看，Serverless 架構所面臨的冷啟動挑戰雖然嚴峻，但並不致命，因為各個雲廠商都正在努力推出冷啟動問題的解決方案，包括但不限於例項的預熱、例項的預留、資源池化、單例項多併發等。

### 廠商鎖定

所謂的廠商鎖定，指的是不同廠商開發的 Serverless 架構的表現形式是不同的，包括產品的形態、功能的維度、事件的資料結構等，所以一旦使用了某個廠商的 Serverless 架構，通常意味著 FaaS 部分和相對應的配套後端基礎設施也都要使用該廠商的，若想進行多雲部署、專案跨雲廠商遷移等將會困難重重，成本極高。

眾所周知，函式是由事件觸發的，所以 FaaS 平臺與配套的基礎設施服務所約定的資料結構往往決定了函式的處理邏輯。如果每個廠商相同型別的觸發器所約定的事件結構不同，那麼在進行多雲部署、專案跨雲廠商遷移時就會產生巨大的成本。

當開發者開發一個功能，在不同雲廠商所提供的 Serverless 架構中實現時，涉及的程式碼邏輯、產品能力均是不同的，甚至業務邏輯、運維工具等也是完全不同的。

所以想要跨廠商進行業務遷移、業務的多雲部署，企業將面臨極高的相容成本、業務邏輯改造成本、多產品的學習成本、資料遷移風險等。

由於目前沒有完整、統一的且被各雲廠商所遵循的規範，不同廠商的 Serverless 架構與自身產品、業務邏輯繫結嚴重，開發者的跨雲容災、跨雲遷移非常困難。目前來看，各雲廠商對 Serverless 架構鎖定嚴重的問題也是開發者抱怨最多、擔憂最多的問題之一。

當然就該問題而言，無論 CNCF 還是其他一些組織、團隊都努力在上層透過更規範、更科學的方法進行完善和處理。

### 配套資源不完善

所謂的配套資源不完善，指的是 Serverless 架構的核心思想之一是將更多、更專業的事情交給雲廠商來做，但是在實際過程中，雲廠商會礙於一些需求優先以及自身業務素質等問題，沒有辦法做更多“在 Serverless 架構中該做的事情”，導致開發者對基於 Serverless 架構開發專案、運維應用過程中困難重重，抱怨不斷。

在 Serverless 架構飛速發展的過程中，各個廠商也在努力完善自身的配套資源和設施。儘管如此，Serverless 架構還是有很多配套資源不完善，並不能讓開發者更順利地完成 Serverless 應用的開發、更輕鬆地對 Serverless 應用進行運維，主要表現在以下幾個方面。

**1）配套的開發者工具複雜多樣，且功能匱乏**

一方面表現在市面上開發者工具鏈匱乏，這導致開發和部署難度大，進而增加成本；另一方面表現在缺乏相關的工具鏈在體驗層對 Serverless 體驗進一步提升，優質工具鏈的匱乏導致本來就擔心被廠商繫結的 Serverless 開發者變得更難與廠商解綁。

2020 年信通院釋出的國內首個《雲原生使用者調查報告》明確指出在使用  Serverless  架構之前，49% 的使用者考慮部署成本，26% 的使用者考慮廠商繫結情況，24% 的使用者考慮相關工具集完善程度。

這些資料背後透露的實際是：開發者對於完善工具鏈的強烈需求。就目前情況來看，並沒有絕對統一、一致的 Serverless 開發者工具，每個廠商都有自己的開發者工具，而且使用形式、行為表現並不相同，這就導致開發者在開發前的調研、開發中的除錯、部署後的運維等多個層面面臨很嚴峻的挑戰。

另外，絕大部分的 Serverless 開發者工具更多是資源編排、部署工具，並不能真正稱為開發工具、運維工具，尤其在除錯中不能保證線上和線下環境的一致；在運維時不能快速對業務進行除錯，不能保證更簡單地排查錯誤；在定位問題等方面並沒有統一、完整的方案，這就導致 Serverless 架構的學習成本、使用成本對開發者來說會變得非常高。

**2）配套的幫助文件、學習資源並不完善，學習成本過高**

就目前情況來看，Serverless 架構的學習資源相對來說是匱乏的，無論從文字、影片、實驗等角度，還是從廠商提供的案例、教程、最佳實踐等角度，都沒有完善的學習資源和參考案例。正是由於 Serverless 學習資源比較少，開發經驗案例比較少，開發者在學習階段很難找到適合自己的學習資源，開發過程中經常會遇到未知錯誤，嚴重阻塞了 Serverless 架構在開發者側的心智建設。

當然，上述幾個方面也只是 Serverless 架構在配套資源、設施層面不完善的部分表現。除此之外，Serverless 架構如何與傳統框架更緊密地結合；傳統業務如何更容易地遷移到 Serverless 架構；Serverless 架構如何做監控、告警；如何管理 Serverless 應用與 Serverless 資源；Serverless 架構的科學釋出、運維的最佳實踐是什麼樣子的……這些問題也都是需要研究與探索的。

時至今日，對於 Serverless 架構儘管還有很多的挑戰需要面對，但是大家都在努力希望透過更好的體驗助力使用者將業務程式碼更簡單、更快速地部署到 Serverless 架構，例如阿里雲 Serverless 團隊開源的 [Serverless Devs ](http://mp.weixin.qq.com/s?__biz=MzI4NzI5MDM1MQ==&mid=2247492693&idx=1&sn=03d9ca923a1afefc621468a9ae731872&chksm=ebcd42d5dcbacbc320b9cd82921300185615371d5e9ba0263fea028d9809ea39abf1502facef&scene=21#wechat_redirect)就是一款無廠商鎖定的 Serverless 應用全生命週期管理工具。

如圖所示，Serverless Devs 可參與到專案的建立、開發、除錯、部署與運維的全流程，以阿里雲函式計算元件為例。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f6ab649851f444e4a5f7718cc3f7f1cb~tplv-k3u1fbpfcp-zoom-1.image "11.png")

圖-10 Serverless Devs 專案全生命週期管理 Serverless 應用示意圖

-   在專案的建立環節，可透過開發者工具或者應用中心進行專案的最初建立。

-   在專案開發環節，可以透過本地開發、除錯等能力來驗證本地開發的正確性。

-   在專案除錯環節，可以透過本地除錯與遠端呼叫、日誌查詢等能力進行專案的最終除錯。

-   在專案部署環節，可以先透過依賴安裝、專案構建等流程構建完整的部署包，再進行專案的部署。

-   在後期運維環節，可以透過指標查詢進行專案健康度檢查，透過日誌查詢等進行問題定位，透過專案釋出等能力進行版本釋出、別名釋出以及灰度釋出等。

除此之外，在學習資源層面也有大力扶持。圖 11 是阿里雲開發者社群提供的大量 Serverless 課程。（見 [2021版技術圖譜](http://mp.weixin.qq.com/s?__biz=MzI4NzI5MDM1MQ==&mid=2247493344&idx=1&sn=657d7fa85c24139d892d41f976358adf&chksm=ebcd4060dcbac976e13a8f1f2ef9165f63898317c9ef077a4c8f5c08e7ae976c515698c58d9f&scene=21#wechat_redirect)）

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/429df18feb514a3691ea6b598962bafa~tplv-k3u1fbpfcp-zoom-1.image "12.png")

圖-11 阿里雲開發者社群提供的大量 Serverless 課程

後面我們還籌備了“Serverless 實戰攻略”等系列課程，歡迎大家持續關注。

### 其它挑戰

Serverless 架構如今已經非常熱門，各個廠商也都在付諸更大的努力完善自身的 Serverless 產品，推動 Serverless 生態和心智建設。但是客觀地說，Serverless 架構所暴露出的挑戰，並不只有前面所描述的。

**1）Serverless 架構在某些安全層面會有更大的挑戰？**

把更專業的事情交給更專業的人，讓 Serverless 架構在安全層面有了更大的保障，但是由於 Serverless 架構的極致彈效能力讓開發者產生了更多的擔心，“如果有人惡意對我的業務進行流量攻擊，Serverless 架構的極致彈性和按量付費會不會讓我迅速產生巨大的損失？”這與傳統雲主機所表現出的“無法提供服務”是不同的，但是更讓開發者擔憂。

儘管現在很多廠商都在透過 API 閘道器的白名單與黑名單功能、函式計算的例項資源上限配置等相關功能解決該問題，但仍有很多開發者會有擔憂和顧慮。

**2）出現錯誤-難以感知也難以排查？**

由於 Serverless 架構相對傳統雲主機架構更有“黑盒”即視感，所以在 Serverless 架構下進行應用的開發，往往會出現一些難以感知的錯誤。

例如某些經驗不足的 Serverless 應用開發者在使用物件儲存觸發器時就可能會面臨嚴重的迴圈觸發問題，具體為“客戶端上傳圖片到物件儲存，物件儲存觸發函式執行圖片壓縮操作，之後將結果圖片回寫到物件儲存，如果這裡的觸發條件設定不清晰，就可能導致迴圈觸發壓縮、回寫操作”。除了描述的錯誤難以感知之外，Serverless 架構還存在錯誤難以排查的挑戰。常見的情況是，使用者在本地進行業務邏輯開發並除錯完成，將程式碼部署到線上後出現偶然性錯誤，此時由於無法登入機器進行除錯，並且例項可能在觸發之後被釋放，出現了問題難以定位、難以溯源等挑戰。

綜上所述，與 Serverless 架構的優勢一樣，雖然在[前文](http://mp.weixin.qq.com/s?__biz=MzI4NzI5MDM1MQ==&mid=2247518969&idx=1&sn=88617a9c801fd440d5baf71eb8325f71&chksm=ebcd2c79dcbaa56f7348bf325c86fda90b02766e6b09f87ae24736fae227896746898203f2f3&scene=21#wechat_redirect)中已經舉例說明很多 Serverless 架構所面臨的挑戰，但其實一些挑戰也已經有了很好的解決方案，我們這系列文章也會詳細為大家介紹如何解決這些。Serverless 架構雖然面臨的挑戰很多，但也會因為這些挑戰給更多組織、團隊帶來新的機會！

## 點選[此處](https://www.aliyun.com/product/fc?spm)，直達阿里雲函式計算 FC！

實戰指南 | Serverless 架構下的應用開發

相關文章