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 技術趨勢變革。

本文整理自【Serverless Live 系列直播】2 月 2 日場
直播回看連接： https://developer.aliyun.com/topic/serverless/practices

Serverless 電子書下載

本書亮點：

• 從架構演進開始，介紹 Serverless 架構及技術選型構建 Serverless 思惟；
• 瞭解業界流行的 Serverless 架構運行原理；
• 掌握 10 大 Serverless 真實落地案例，活學活用。

下載連接：https://developer.aliyun.com/topic/download?id=1128