作者 | 徐進茂（羅離） JAVA 開發工程師

> **導讀**：近年來，Serverless 一詞越來越熱，它已經逐漸成為了一種新型的軟體設計架構。和 DevOps 概念提倡的是透過一系列工具和自動化的技術來降低運維的難度，促進研發運維一體化不同， Serverless 更像是一種 NoOps，即透過“不用做”的方式來解決“如何更高效做”的問題。

## DevOps 概述

DevOps 是一組用於促進開發和運維人員之間協作的過程、方法和系統的統稱。

DevOps 提倡透過一系列的技術和工具降低開發和運維人員之間的隔閡，實現從開發到最終部署的全流程自動化，從而達到開發運維一體化。透過將 DevOps 的理念引入到整個系統的開發過程中，能夠顯著提升軟體的開發效率，縮短軟體交付的週期，更加適應當今快速發展的網際網路時代。

說到 DevOps ，就必然會提到持續整合。持續整合指的是在軟體開發過程中，軟體開發人員持續不斷地將開發出來的程式碼和其他的開發人員的程式碼進行合併，每次合併後自動地進行編譯、構建，並執行自動化測試進行驗證，而不是等到最後各自開發完成後才合併在一起。

持續整合能從根本上提高一個團隊的軟體開發效率。在軟體開發過程中引入持續整合，可以幫助團隊及時的發現系統中的問題，並快速做出修復，不僅可以縮短軟體開發的時間，而且可以交付更具質量的系統。

## 基於 Docker 實現一個 DevOps 開發環境

一個 DevOps 開發環境需要滿足以下 8 點需求。

- **環境一致性**：在本地開發出來的功能，無論在什麼環境下部署都應該能得到一致的結果；

- **程式碼自動檢查**：為了儘早發現問題，每一次程式碼提交後，系統都應該自動對程式碼進行檢查，及早發現潛在的問題，並執行自動化測試；

- **持續整合**：每次程式碼提交後系統可以自動進行程式碼的編譯和打包，無需運維人員手動進行；

- **持續部署**：程式碼整合完畢後，系統可以自動將執行環境中的舊版本應用更新成新版本的應用並且整個過程中不會讓系統不可用；

- **持續反饋**：在程式碼自動檢查、持續整合、持續部署的過程中，一旦出現問題，要能及時將問題反饋給開發人員以及運維人員。開發和運維人員收到反饋後對問題及時進行修復；

- **快速回滾**：當發現本次部署的版本出現問題時，系統應能快速回退到上一個可用版本；

- **彈性伸縮**：當某個服務訪問量增大時，系統應可以對這個服務快速進行擴容，保證使用者的訪問。當訪問量回歸正常時，系統能將擴容的資源釋放回去，實現根據訪問情況對系統進行彈性伸縮；

- **視覺化運維**：提供視覺化的頁面，可實時監控應用、叢集、硬體的各種狀態。

為了滿足以上 8 點要求，設計出的 DevOps 開發環境如下圖所示。

![2](https://yqfile.alicdn.com/47122ce11ff296fd77bfd94ddee30a07e703be00.png)

整個環境主要由 6 部分組成：

- 程式碼倉庫 Gitlab

- 容器技術 Docker

- 持續整合工具 Jenkins

- 程式碼質量檢測平臺 SonarQube

- 映象倉庫 Harbor

- 容器叢集管理系統 Kubernetes

整個環境的執行流程主要分為以下 6 步：

- 開發人員在本地開發並驗證好功能後，將程式碼提交到程式碼倉庫；

- 透過事先配置好的 Webhook 通知方式，當開發人員提交完程式碼後，部署在雲端的持續整合工具 Jenkins 會實時感知，並從程式碼倉庫中獲取最新的程式碼；

- 獲取到最新程式碼後，Jenkins 會啟動測試平臺 SonarQube 對最新的程式碼進行程式碼檢查以及執行單元測試，執行完成後在 SonarQube 平臺上生成測試報告。如果測試沒透過，則以郵件的方式通知研發人員進行修改，終止整個流程。若測試透過，將結果反饋給 Jenkins 並進行下一步；

- 程式碼檢查以及單元測試透過後， Jenkins 會將程式碼傳送到持續整合伺服器中，在伺服器上對程式碼進行編譯、構建然後打包成能在容器環境上執行的映象檔案。如果中間有步驟出現問題，則透過郵件的方式通知開發人員和運維人員進行處理，並終止整個流程；

- 將映象檔案上傳到私有映象倉庫 Harbor 中儲存；

- 映象上傳完成後， Jenkins 會啟動持續交付伺服器，對雲環境中執行的應用進行版本更新，整個更新過程會確保服務的訪問不中斷。持續交付伺服器會將最新的映象檔案拉取到 Kubernetes 叢集中，並採用逐步替換容器的方式進行對應用進行更新，在服務不中斷的前提下完成更新。

透過上述幾步，我們就可以簡單實現一個 DevOps 開發環境，實現程式碼從提交到最終部署的全流程自動化。

但是自從 2014 年 AWS 釋出 ASW Lambda 以來， Serverless 的概念開始逐漸火熱起來。各大雲廠商開始紛紛開始推出各自的 Serverless 產品，如 Google 的 Cloud Functions ，阿里雲的函式計算、Serverless應用引擎(SAE)等等。究竟什麼是Serverless 無服務計算呢？

什麼是 Serverless？

根據 CNCF (雲原生計算基金會)釋出的 [**Serverless**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486805&idx=1&sn=030ba4b14bca7fd47eb1b61a1cc50e26&chksm=fae5069acd928f8c34fa2a5e965b806ef6fc54a0f0b68a0c84ba3de857e6b73d0f2e5f4f1eea&scene=21#wechat_redirect) 白皮書裡的定義：

> Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.

首先需要強調一點的是無伺服器計算並不意味著我們不再需要使用伺服器來執行程式碼，程式碼仍需要執行在伺服器上對外提供服務。

在無服務計算時代，研發人員無需對伺服器進行監控、配置、更新、擴容等運維操作。只需要將程式碼上傳到雲廠商提供的無伺服器計算平臺上即可，雲廠商會保證程式碼能正常執行，當流量突增時，自動對伺服器進行擴容，流量減少時，對伺服器進行縮容。

![3](https://yqfile.alicdn.com/348b57cb1560dbb47e617afe1f0dd55e592a0e80.png)

這些運維操作對研發人員來說都是黑盒的，會將開發人員從繁瑣的運維工作中解放出來，只需要按執行時長對資源進行付費即可。

和 DevOps 概念提倡的是透過一系列工具和自動化的技術來降低運維的難度，促進研發運維一體化不同， Serverless 更像是一種 NoOps，即透過“不用做”的方式來解決“如何更高效做”的問題。

## 阿里雲在 Serverless 上的實踐

## 當前阿里雲上實現 Serverless 技術的產品有 Serverless 應用引擎和函式計算 FaaS。

### Serverless 應用引擎

Serverless 應用引擎是面向應用的 Serverless PaaS 平臺，它向上抽象了應用的概念，支援 Spring Cloud、Apache Dubbo、HSF 等流行的開發框架，並透過 WAR 包、JAR 包和映象等多種方式部署應用。它的使用可以透過下面這張圖來了解。

![4](https://yqfile.alicdn.com/e29ef38f90f964467baf18f99ce5bcb760a3a4e8.png)

### 函式計算

## FaaS 是 Serverless 所提供的服務的另一種形態。以阿里雲函式計算為例，阿里雲函式計算的流程大致如下圖所示。

![](http://img.blog.itpub.net/blog/2019/11/15/63eac71826520d0d.png?x-oss-process=style/bb)

- 開發者在本地編寫程式碼；

- 程式碼開發完成後透過命令列工具 fcli、fun 或者視覺化介面控制檯上傳到阿里雲函式計算平臺；

- 開發者上傳完程式碼後，平臺會自動啟動基於 Docker 的 DevOps 流程，對程式碼進行編譯、打包成映象檔案。並上傳到映象倉庫；

- 開發者在平臺是配置事件觸發器，當前阿里雲已經支援 OSS、HTTP、CDN、SLS、定時任務等多種形式的觸發器形式；

- 當觸發器被觸發後，會到達事件排程器。平臺會將映象快速啟動成容器並執行程式碼，根據流量自動對服務進行彈性伸縮。保證程式碼能正常並執行完成。

**伯克利對 Serverless 未來的預測**

儘管 Serverless 仍存在諸多的挑戰，但是我們相信隨著市場規模的不斷擴大，這些挑戰會逐漸被解決。UC 伯克利對 Serverless 未來十年的發展趨勢做了以下幾點預測。

- 新型的 BaSS 儲存服務會被創造出來，這樣更多型別的應用可以遷移到 Serverless 平臺上。這種儲存服務的效能會和本地儲存的效能相當，並提供長期和短期的儲存。更多適用於 Serverless 平臺的硬體會被使用；

- 由於更高階別的程式設計抽象以及更加細粒度的資源隔離，在無伺服器計算平臺上執行的程式碼將會比傳統的方式更加安全可靠；

- 隨著無伺服器計算收費模式的不斷髮展，幾乎任何應用遷移到無伺服器計算平臺都會比原先的有伺服器計算的方式的成本更低；

- 有伺服器計算在未來會促進 BaaS 的發展；

- 雖然現有的有伺服器計算不會消失，但是隨著 Serverless r技術的不斷髮展，有伺服器計算在雲上所佔的比例會逐年下降；

- 無伺服器計算將會成為雲時代預設的程式設計方式，它將大規模取代傳統的基於伺服器的程式設計方式，並終結傳統的 C/S 架構。

## 總結

當前資料中心的資源利用率仍處於一個較低水平，特別是對於線上業務而言，日均資源使用率僅在 10% 左右，主要是由於當今資源都是屬於獨享型的，不管你用不用，這些資源都需要保留。

一旦大規模使用 Serverless 之後，資源的使用由平臺統一排程，按需使用，整體的資源利用率會大幅提升，整個雲端計算資源的使用成本無疑也會大幅降低。

隨著 Serverless 的不斷髮展，未來程式設計方式將會有很大的不同。無論是從成本的角度還是使用的角度，我們有理由相信下一個時代是 Serverless 的時代，並應該朝著這個方向不斷探索。

作者簡介：徐進茂（羅離） Java 開發工程師。現就職於阿里雲智慧基礎設施事業部，主要負責阿里巴巴資料中心運營平臺的研發工作。

---

> “ 阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”

從 DevOps 到 Serverless：透過“不用做”的方式解決“如何更高效做”的問題

相關文章