作者 |?許成銘（競霄）
來源 | 阿里巴巴云原生公眾號

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

總結

以上是生活随笔為你收集整理的Serverless 时代 DevOps 的最佳打开方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。