Serverless 時代 DevOps 的最佳開啟方式

DevOps 簡析

傳統軟體開發過程中，開發和運維是極其分裂的兩個環節，運維人員不關心程式碼是怎樣運作的，開發人員也不知道程式碼是如何運行的。

而對於網際網路公司而言，其業務發展迅速，需要快速更新以滿足使用者差異化的需求或者競對的產品策略，需要進行產品的快速迭代，通過小步快跑的方式進行敏捷開發。

對於這種每週釋出 n 次甚至每天釋出 n 次的場景，高效的協作文化就顯得尤為重要。DevOps 就在這種場景下應運而生，它打破了開發人員和運維人員之間的壁壘。

DevOps 是一種重視「軟體開發人員（Dev）」和「IT 運維技術人員（Ops）」之間溝通合作的文化、運動或慣例。通過自動化「軟體交付」和「架構變更」的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。

上圖是一個完整的軟體開發生命週期，DevOps 運動的主要特點是倡導對構建軟體的整個生命週期進行全面的管理。

DevOps 工程師的職責：

管理應用的全生命週期，比如需求、設計、開發、QA、釋出、運行；關注全流程效率提升，挖掘瓶頸點並將其解決；通過標準化、自動化、平臺化的工具來解決問題。DevOps 的關注點在於縮短開發週期，增加部署頻率，更可靠地釋出。通過將 DevOps 的理念引入到整個系統的開發過程中，能夠顯著提升軟體的開發效率，縮短軟體交付的週期，更加適應當今快速發展的網際網路時代。

Serverless 簡析

上圖左側是谷歌趨勢，對比了 Serverless 和微服務的關鍵詞趨勢走向，可看出隨著時間變化，Serverless 的熱度已經逐漸超過微服務，這說明全世界的開發人員及公司對 Serverless 非常青睞。

那 Serverless 究竟是什麼？上圖右側是軟體邏輯架構圖，有開發工程師寫的應用，也有應用部署的 Server（伺服器），還有 Server 的維護操作，比如資源申請、環境搭建、負載均衡、擴縮容、監控、日誌、告警、容災、安全、許可權等。而 Serverless 實際上是把 Server 的維護工作遮蔽了，對於開發者是黑盒，這些工作都由平臺方支援，對業務來說只需關注核心邏輯即可。

總得來說，Serverless 架構是「無伺服器」架構，是雲端計算時代的一種架構模式，能夠讓開發者在構建應用的過程中無需關注計算資源的獲取和運維，降低運營成本，縮短上線時間。

Serverless 時代 DevOps 的變化

1. Serverless 的特性

上圖左側為 2020 年中國雲原生使用者調查報告中 Serverless 技術在國內的採用情況，圖中顯示近三成使用者已經把 Serverless 應用在生產環境中，16% 的使用者已經將 Serverless 應用在核心業務的生產環境，12% 的使用者也已經在非核心業務的生產環境中用到 Serverless，可見國內對 Serverless 接受度較高。

上圖右側為諮詢公司 O'Reilly 對全球不同地區不同行業的公司進行的調查報告結果，圖中顯示一馬當先使用 Serverless 架構的就是 DevOps 人員。

那麼當 Serverless 遇上 DevOps，會發生哪些變化呢？首先我們看一下雲原生架構白皮書中對 Serverless 特性的歸納總結：

全託管的計算服務使用者只需要編寫自己的程式碼來構建應用，無需關注同質化的複雜的基礎設施的開發運維工作。

通用性能夠在雲上構建普適的各種類型應用。

自動的彈性伸縮使用者無需對資源進行預先的容量規劃，業務如果有明顯的波峰波谷或臨時容量需求，Serverless 平臺都能夠及時且穩定地提供對應資源。

按量計費企業可以使成本管理更加有效，不用為閒置資源付費。

Serverless 讓運維行為對開發透明，開發人員只需關注核心業務邏輯的開發，進而精益整個產品開發流程，快速適應市場變化。而上述 Serverless 的這些特性與 DevOps 的文化理念及目標是天然契合的。

2. Serverless 開發運維體驗

傳統應用構建的流程中，DevOps 人員管理整個生命週期的步驟非常多：

在資源準備階段，要購買 ECS 進行機器初始化等系列操作；在研發部署階段，需要把業務應用、監控系統、日誌系統等旁路系統部署在 ECS 上；在運維階段，你不僅需要運維自己的應用，還需運維 Iaas 及其他旁路的監控、日誌、告警元件。而如果遷到 Serverless，其開發體驗是怎麼樣的呢？

在資源準備階段，不需要任何資源準備，因為 Serverless 是按需使用、按量付費的，不用關注底層 Server；在研發部署階段，只需要將自己的業務部署到對應的 Serverless 平臺上；在運維階段，徹底做到了免運維。可以看到，傳統應用構建流程中的 Iaas 及監控、日誌、告警，在 Serverless 上完全沒有，它以全託管、免運維的形式展現給使用者。

Serverless 時代 DevOps 的最佳實踐

上文介紹的體驗其實就是基於阿里雲的一款 Serverless 產品——SAE 來實現的。Serverless 應用引擎（SAE）是阿里雲 Serverless 產品矩陣中提供的 DevOps 最佳實踐。先簡單介紹一下 SAE：

1. Serverless 應用引擎（SAE）

SAE 是一款面向應用 Serverless PaaS 平臺，支援 Spring Cloud、Dubbo、HSF 等主流的應用開發框架。使用者可以零程式碼改造，直接將應用部署到 SAE 上，並且按需使用、按量付費、秒級彈性，可以充分發揮 Serverless 的優勢，為使用者節省閒置的資源成本。

在體驗上，SAE 採用全託管、免運維的方式，使用者可以聚焦於核心的業務邏輯開發，而應用的整個生命週期管理，如監控、日誌、告警，這些都由 SAE 完成。可以說，SAE 提供了一個成本更優、效率更高的一站式應用託管方案，使用者可以做到零門檻、零改造、零容器基礎就可以享受到 Serverless 帶來的技術紅利。

Serverless 應用引擎（SAE）三大特點：

0 程式碼改造：微服務無縫遷移，開箱即用，支援 War/Jar 自動構建映象；15s 彈性效率：應用端到端快速擴容，應對突發流量；57% 降本提效：多套環境按需啟停，降本且提效。2. 構建高效閉環的 DevOps 體系

SAE 內構建了高效閉環 DevOps 體系，覆蓋開發態、部署態和運維態的整個過程。

中大型企業一般都使用企業級的 CICD 工具（如 Jenkins 或雲效）部署到 SAE，從而完成從源碼到構建再到部署的整個流程。

對於個人開發者或者中小企業，更傾向於使用 Maven 插件或 IDEA 插件一鍵部署到雲端，方便本地偵錯，也提升了整個的使用者體驗。

當部署到 SAE 之後，可以進行視覺化的智慧運維操作，比如高可用運維（服務治理、效能壓測、限流降級等）、應用診斷（執行緒診斷、日誌診斷、資料庫診斷等）以及資料化運營。以上操作都是部署到 SAE 之後，使用者可以開箱即用的現成的功能。

使用者通過 SAE 可以非常方便地實現整體的開發運維流程，感受 Serverless 帶來的全方位體驗和效率上的提升。下面介紹幾個 SAE 的最佳實踐：

3. 部署態最佳實踐：CI/CD

SAE 目前支援三種部署方式，分別是 War、Jar 和映象。

如果使用者使用 Spring Cloud、Dubbo 或 HSF 這類應用，可以直接打包或者填寫對應的 URL 地址，就可以直接部署到 SAE 上。而對於非 Java 語言的場景，可以通過映象方式進行部署。後續我們也會支援其他的語言包以自動化構建的方式進行部署。

除了直接部署之外，SAE 也支援本地部署、雲效部署和自建部署這三種方式。

本地部署依賴 CloudToolkit 插件，對 IDEA/Eclipse 進行了支援，使用者可以在 IDEA 裡一鍵部署到 SAE 上，無需登入，方便地進行自動化操作。

雲效部署是阿里雲提供的企業級一體化 CICD 平臺型產品，通過雲效可以監聽程式碼庫的變動，如果進行 Push 操作，就會觸發雲效的整個釋出流程。比如進行程式碼檢查或者單元測試，在對這個程式碼進行編譯、打包、構建，構建好後會生成對應的構建物，之後它會呼叫 SAE 的 API，然後執行整體的部署操作。這一整套流程也是開箱即用的，使用者只需要在雲效控制檯上進行視覺化配置就可以把整個流程串起來。

自建部署指使用者的公司如果是直接通過 Jenkins 進行構建的話，也可以直接使用 SAE。Jenkins 作為開源的最大的 CICD 平臺，我們也提供了有力支援，許多使用者也通過 Jenkins 成功地部署到 SAE 上。

4. 部署態最佳實踐：應用釋出三板斧

應用釋出三板斧包括：可灰度、可監控、可回滾。在阿里內部所有的變更都需要嚴格做到上述的「三板斧」，而 SAE 作為一款雲產品，也是把阿里巴巴的最佳實踐對外輸出進行產品化的整合。

可灰度：支援單批、分批、金絲雀等多種釋出策略；支援按流量灰度，批次間自動/手動釋出，分批間隔等多種釋出選項；可監控：釋出過程中清晰對比不同批次基礎監控與應用監控指標異動，及時暴露問題，定位變更風險；可回滾：在釋出過程中，允許人工介入控制釋出流程，如異常中止、一鍵回滾。

上圖為控制檯截圖，可以看到在部署上我們支援單批、分批和灰度三種方式進行釋出。

執行釋出的過程都是通過釋出端進行，每個釋出端都有具體的步驟，首先進行構建映象，然後初始化環境，接著創建和更新部署配置。使用者可以清晰地看到釋出端當前的運行進度與狀態，方便排查。

5. 運維態最佳實踐：全方位可觀測

SAE 提供全方位可觀測，可以對分散式系統中的任何變化進行觀測。當系統出現問題時，可以便捷地定位問題、排查問題、分析問題；當系統平穩運行時，也可以提前暴露風險，預測可能出現的問題。通過 SAE 使用者可以對自己的應用瞭如指掌。

這裡列舉了可觀測性的三個方面：Metrics、Logging 、Tracing。

Metrics代表聚合的資料，SAE 提供如下基礎監控指標：

1）基礎監控：CPU、MEM、Load、Network、Disk、IO；2）應用監控：QPS、RT、異常數、HTTP 狀態碼、JVM 指標；3）監控告警：豐富的告警源上報、告警收斂處理、多種告警渠道觸達（如郵箱、簡訊、電話等）。

Logging代表離散的資料，提供以下功能：

1）實時日誌：Stdout、Stderr 實時檢視；2）檔案日誌：自定義採集規則、持久化儲存、高效查詢；3）事件：釋出單變更事件、應用生命週期事件、事件通知回撥機制。

Tracing意味著可以按請求維度進行排查，提供如下開箱即用的功能：

1）請求呼叫鏈堆棧查詢；2）應用拓撲自動發現；3）常用診斷場景的指標下鑽分析；4）事務快照查詢；5）異常事務和慢事務捕捉。

6. 運維態最佳實踐：線上偵錯

通過 SAE 線上偵錯可以訪問單例項的目標埠，相當於使用者在本地可以直接訪問雲端某個應用的某個具體例項，原理是為例項提供了埠對映的 SLB，通過這個能力使用者可以實現如下功能：

SSH / SFTP 訪問例項可以在本地通過 SSH 直接連到應用的具體的例項上，或者通過 SFTP 進行上傳/下載檔案。

Java retmote debug相當於在 IDEA 裡配置一個斷點，再遠端連線到對應的 SAE 的例項上，這樣就可以通過斷點來檢視整個方法的呼叫站與上下文資訊，對線上正在運行的應用進行診斷。

其他診斷工具連線例項其他診斷工具也可以通過線上偵錯的手段連線到 SAE 的例項上，進而看到 Java 的一些資訊，比如堆棧或者執行緒等。 適用場景：針對運行時線上應用的實時觀測運維及問題排查求解。

7. 開發態最佳實踐：端雲聯調

針對微服務場景，我們提供了一個非常好用的能力：端雲聯調。它基於 CloudToolkit 插件+ 跳板機，可以實現：

1）本地服務訂閱並註冊到雲端 SAE 內建的註冊中心；2）本地服務可以和雲端 SAE 服務互相呼叫。

適用場景：

1）微服務應用遷移到雲端 SAE，遷移過程中的開發聯調；2）本地開發測試驗證。

這個功能的原理是需要在使用者的 VPC 內，然後通過 ECS 代理伺服器作為跳板機，ECS 可以和同一個 VPC 內的 SAE 應用進行互調，然後這臺 ECS 通過反應代理的方式，可以與本地進行連線。

CloudToolkit 插件會在應用啟動時就注入對應 SAE 註冊中心的地址，以及微服務的一些上下文參數，使得使用者本地的應用通過跳板機連到 SAE 的應用上，從而進行整個端雲聯調的過程。

作者簡介

許成銘，花名：競霄，先後參與 aPaaS 領域 EDAS 和 SAE 後端研發工作，經歷雲原生與 Serverless 技術趨勢變革。

本文為阿里雲原創內容，未經允許不得轉載。