作者 | 許成銘（競霄）
來源 |
阿裡巴巴雲原生公衆号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