納海 阿裡雲雲栖号 2023-07-20 19:01 發表于北京
作 者 | 納海
01 微服務應用雲原生化
微服務是一個廣泛使用的應用架構，而如何使得微服務應用雲原生化卻是近些年一直在演進的課題。國内外雲廠商對雲原生概念的诠釋大同小異，基本都會遵循 CNCF 基金會的定義：
雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，建構和運作可彈性擴充的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。
這些技術能夠建構容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。
彈性可擴充，是企業選擇上雲的一個重要原因。它可以為企業節省大量成本，同時保障服務穩定性。我們有個電商客戶，平時隻有 200 多個服務節點，但在大促時輕松擴容到上千個節點。這個擴容動作通過平台一鍵完成，隻需要秒級的時間。操作之簡單、時間之短是在上雲之前是不可想象的，那些複雜漫長的硬體采購、環境搭建和服務部署流程被自動化完成。
在雲原生領域，有一個廣泛知曉的 Pets vs Cattle 比喻：在傳統運維上，我們習慣把伺服器當做“寵物”，這些伺服器一旦出現問題我們會非常緊張；而在雲原生階段，伺服器更應該被當做“牛群”，它不再具有特殊性，出現問題後可以通過自動化機制進行替換修複。在 Kubernetes 上，這一點尤其展現的淋漓盡緻。如果某個 Pod 容器出現問題，那麼我們應該能通過 Liveness 探針檢測到容器異常，然後完成容器退出，并自動重新開機容器。
02 雲原生浪潮的新問題
雲原生浪潮釋放了巨大的技術能量，但同時也帶來了許多新的問題，這些問題廣泛存在于企業的開發、測試、CICD 和運維場景。首當其沖的是 DevOps 實踐。
圖檔來源于：https://www.atlassian.com/devops
DevOps 理念倡導的是，通過加強研發和運維團隊在應用研發聲明周期内的溝通合作，和配合自動化工具的使用，提高軟體傳遞的速度和品質。甚至研發和運維這兩個角色往往是由同一個團隊承擔，達到 “Who Builds，Who Runs” 的境界。
但理想很美好，現實很骨感，DevOps 在很多企業中落地實踐逐漸變了樣，甚至出現了一些反模式。研發團隊承擔運維角色之後，需要學習 Kubernetes 編排、容器化、基礎設施即代碼、GitOps 等雲原生運維知識，并負責各個環境的運維。這占用了本來用來實作業務需求的時間，反而降低研發團隊的生産力。另外由于生産環境的特殊性，往往會由團隊内較為資深的研發人員來承擔運維責任，這導緻了一個很奇怪的局面：生産力低的員工在寫代碼，并交給生産力高的員工來運維。
很多人沒有意識到這些問題，以為通過 DevOps 減少了運維成本，但實際上付出的隐形成本并不小。這不是危言聳聽，有許多研究已經證明了這個問題的存在。例如 Humanitec 曾對使用 DevOps 的組織進行了調查，發現有 44% 的組織存在這種反模式，即開發人員不僅需要完成自己的 DevOps 任務，還需要花費大量的時間承擔幫助團隊的職責。
圖檔來源于：https://humanitec.com/whitepapers/2021-devops-setups-benchmarking-report
問題不在于 DevOps 本身，而是我們是否提供了一個好用的平台和工具鍊來支援研發團隊進行自服務(Self-Service)。這個平台屏蔽了下層複雜的基礎設施、各種各樣的雲原生定義和yaml規範，向研發、測試和安全團隊提供簡單而清晰的平台互動，以加快上層業務疊代速度和提升産品品質。
如何建構這樣的平台和工具鍊，稱為平台工程(Platform Engineering)。如果說雲原生和 DevOps 帶來了各種各樣的定義，對研發人員是一個熵增的過程，那麼平台工程就是屏蔽複雜定義、提供簡單清晰互動的熵減工程。
03 平台工程
平台工程概念并非最近才誕生，這個詞早在 2011 年已經有人開始使用(見 what-is-platform-engineering[1])，并在 2017 年見之于技術雷達(見 platform-engineering-product-teams[2])。而在雲原生技術日益繁雜的今天，容器、編排、服務網格、可觀測等各種産品及工具湧現，CNCF 雲原生版圖已經有超過 1000 個産品，在這種背景下平台工程的訴求愈加強烈。
Gartner 之前釋出了 2023 年 10 大技術趨勢，其中平台工程占有一席之地：
圖檔來自：https://www.gartner.com/en/articles/gartner-top-10-strategic-technology-trends-for-2023
如何實施平台工程呢？這個問題也同樣充滿了争議。引用一段來自于平台工程社群[3]的描述：
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.
翻譯過來也就是，平台工程是設計和建構工具鍊和工作流的學科，使軟體研發組織能夠在雲原生時代具備自服務能力。平台工程師提供一個稱為“内部開發者平台”（IDP，Interal Developer Platform）的內建産品，涵蓋整個應用生命周期的運維需求。
您可能會發現，這個定義和 PaaS（Platform-as-a-Service）的定義相差無幾。按照一般的區分，PaaS 是由供應商提供，而 IDP 則是面向内部的平台。但是 IDP 是否等同于自建 PaaS？這個問題并沒有标準答案，每個人都可能有自己的看法。
但有一個很明确的點是，企業的确需要這樣的平台來解放研發和運維團隊的生産力，無論它是 IDP 還是 PaaS。對于像谷歌、亞馬遜和 Netflix 這樣的公司來說，他們有足夠的規模、資本和人才儲備來建構自己的 IDP 平台。而在社群，也存在如 Backstage、KubeVela 等産品來幫助建構内部平台。
問題是，大部分企業是否有足夠的人力、時間和成本來完全從 0 建構這樣的内部平台？在如今越來越卷的競争環境下，快是制勝之道。更快的疊代可以更快地驗證産品功能、市場和進行安全問題修複，如何提高研發團隊的生産力一直都是每個企業的核心考慮點。
在平台工程上，谷歌、亞馬遜或 Netflix 等公司或許獲益頗豐，但同時也有很多公司陷入泥潭。前不久一篇《通用電氣在平台工程上浪費 70 億美元的教訓》[4]的文章介紹了通用電氣的平台工程實踐，每個人可能從中學到的教訓不同，但至少證明了一點：平台工程需要因地制宜的制定政策。
如果你問我廣大中小型企業或者傳統行業應該如何走向雲原生之路、如何利用 DevOps 提升疊代效率，我會謹慎地建議：如果時間對你很重要，那麼在找到更好的方案之前，不妨基于主流雲廠商的 IaaS 或者 PaaS 來建構自己的産品疊代流程。
在這個領域，主流雲廠商基本都有較為成熟的沉澱，大多數能力都是開箱即用。EDAS 很早就進入了微服務和雲原生領域，經過了八年左右的疊代，目前具備了如下大體能力：
由于篇幅所限，上圖未完全展現所有平台能力。對于很多企業來說，這些平台特性不是一朝一夕就能實作的。從底層基礎設施的統一管理，到核心的應用管控，再到上層的工具鍊互動入口，每一個層次都需要投入大量的人力和時間進行打磨。
在這幾個層次中，研發人員互動最多、卻又最容易忽視的莫過于工具鍊。無論是雲産商提供的 PaaS，還是企業自建的 IDP，如果忽略了研發、測試和運維團隊最常用的工具，那麼這樣的平台使用起來是難以得心應手的。我們堅定的認為，隻有結合工具鍊，雲的能力才能最大化的傳遞到一線研發手裡。工具鍊是連接配接開發者和 IDP/PaaS 平台的重要粘合劑。
到目前為止，我們建構了如下三大場景的工具鍊：
- 開發場景；
- 測試場景
- CI/CD 場景；
這裡并不是否定基礎設施管理和應用管控的重要性，恰恰相反它們是工具鍊的基石，缺乏它們一切無從談起。下文旨在分享開發、測試和 CI/CD 等場景工具鍊，希望對廣大希望采用 PaaS 或者 IDP 的企業有所幫助。
04 開發場景工具鍊
在開發場景上，我們認為工具鍊的核心是程式員的 IDE。在方向上，Cloud IDE 當然是酷炫的，它是一種線上內建開發環境，允許開發人員通過浏覽器即可完成開發、測試和應用部署。但實際上國内采用 Cloud IDE 進行開發的企業并不多見，根本原因在于 Cloud IDE 的體驗還比不上本地 IDE 的體驗。當然在某些場景下 Cloud IDE 可能是唯一方案，例如要求代碼不落盤的高密項目。但在綜合考慮下，我們還是暫不提供 Cloud IDE 的解決方案。
經過慎重考慮，我們選擇通過 IDE 插件來提供平台能力。這種方式可能不那麼高大上，但一定是最接地氣的，實際上也是研發人員最容易接受的。整體上我們通過 IDE 插件提供了三大能力：開發聯調、應用部署和 API 調試。在使用上，研發人員基本都會優先在本地完成開發聯調，聯調通過後再進行應用部署和驗證，這個效率是最高的。
開發聯調
這個能力是我們首先關注的，傳統應用進行雲原生化改造，如何進行高效開發調試一定是首先需要面對的問題。對此我們提供了本地調試和端雲互聯兩種模式。
- 本地調試：通過 IDE 一鍵啟動本地 Nacos 注冊中心[5]，完成本地開發調試。對于簡單的應用，開發人員在本地就可以通過這個注冊中心完成調試，無其他外部依賴，簡單且高效。
- 端雲互聯：通過 IDE 在本地啟動應用，底層通過插件代理自動跟雲上網絡打通，本地節點跟雲上其他微服務節點具備同樣的能力，可互相調用。這種方式對于複雜微服務開發調試非常有用，研發人員的調試效率大大提高。
根據實際使用情況來看，這兩個能力都備受客戶青睐，而端雲互聯能力更是命中微服務開發調試的痛點。端雲互聯不僅可以使得應用跟雲上互聯互通，還把雲的能力下沉到研發人員的開發端，比如分布式鍊路跟蹤和全鍊路流量控制等等。
此外，我們還支援容器級和程序級流量轉發、ECS 和 Kubernetes 多種代理、适配 Windows 和 MacOS 系統等等，感興趣可查閱 EDAS 端雲互聯文檔[6]，此處不再展開。
應用部署
我們早在 2018 年就支援通過 IDE 部署應用[7]，對于開發測試環境來說，通過 IDE 完成建構、上傳和部署是很爽的事情。當然我們也支援多種 CI/CD 工具內建（下面會進行展開），CI/CD 流程可以使得代碼內建和應用釋出更安全，尤其适用于集測和生産等穩态環境中。而在開發測試環境中，首要目的是快速驗證代碼是否符合預期，如果所有變動都需要先送出，再通過 CI/CD 流程部署，那麼這個效率肯定是非常低下的。
通過 IDE 部署後，如何确認部署是否成功？最常用的手段就是終端和日志。這兩個操作我們也可以通過 IDE 來一鍵完成。如果應用日志打到标準輸出，那麼直接通過 IDE 在目标節點上選擇檢視日志即可：
如果日志打到檔案、或者需要通過終端登入目标節點，那麼隻需通過 IDE 輕按兩下目标節點，即可完成終端打開：
更多能力可參考 EDAS 微服務開發側邊欄[8]，不再展開。
API 調試
我們在 IDE 中內建了雲端 API 調試能力，你可以通過 IDE 來快速調試雲端應用的接口。這個能力解決了從本地到環境間快速通路通路的問題，這個通路為開發人員節省了寶貴的時間。當出現上下遊接口聯調問題時，直接通過 IDE 打開 API 調試，現場發起請求測試便一目了然。
API 調試也內建了分布式鍊路追蹤能力，如果中間鍊路調用出錯，點選界面上的調用鍊即可一鍵打開調用鍊頁面，異常資訊一清二楚。
05 測試場景工具鍊
在測試場景，我們優先關注接口級别測試和內建測試。而內建測試本身也是依賴對每一個系統接口的測試，并且對接口響應結果進行斷言，最終生成整個系統的品質報告。
是以，接口級别測試是上層業務測試的基礎。對此我們開放了接口調試能力，你可以通過我們提供的多種工具插件來完成對雲上應用接口的測試，整體鍊路如下所示：
例如，安裝完 Jmeter 插件[9]後，你即可通過界面配置接口測試用例，并完成整個系統或子產品的內建用例編寫：
EDAS 平台引擎已經處理底層網絡的複雜性，你隻需要關注上層的業務測試結果即可。在每個工具運作過程中，我們都會列印請求參數、響應日志和鍊路追蹤連結，這樣在測試異常時能快速定位問題并改進。
06 CI/CD 場景工具鍊
CI/CD 即持續內建(Continuous Integration)和持續傳遞(Continuous Delivery)，《The Product Managers’ Guide to Continuous Delivery and DevOps》[10]對持續內建、持續傳遞和持續部署三個概念定義如下：
- 持續內建：強調開發人員送出了新代碼之後，立刻進行建構和單元測試。根據測試結果來确定新代碼和原有代碼能否正确地內建在一起。
- 持續傳遞：在持續內建的基礎上，将內建後的代碼部署到類生産環境，并完成自動化測試，確定可以以可持續的方式快速向客戶釋出新的更改。如果在類生産環境驗證通過後，證明該制品已達到可傳遞狀态，可手工部署至生産環境。
- 持續部署：在持續傳遞的基礎上，把部署到生産環境的過程自動化。
CI/CD 領域的産品有 ArgoCD、Jenkins 和雲效等開源和商業化産品，這些産品都具備了很高的成熟度。開發者隻需要在這些産品的流水線上設定建構、單元測試、內建測試和環境部署等多個流程即可。而在這些流程中，最容易出錯、損失最大的莫過于生産環境部署。
根據經驗統計，在所有的線上問題中，由于部署變更導緻的故障比例相當高。我們非常重視客戶應用變更的穩定性，目前支援如下幾種釋出動作：
- 單批部署：一次性把應用中所有節點都更新到新版本。此部署動作常用于開發測試環境，生産環境不建議使用。
- 分批部署：按照所設定的批次和間隔來逐漸更新應用節點，可以在完成上一批次後，選擇手動或自動進行下一批次釋出。
- 金絲雀部署：在分批部署基礎上，将第一批節點設定為金絲雀節點，支援設定金絲雀節點的流量比例、接口參數或者泳道政策，在滿足條件的情況下生産流量才會轉發到金絲雀節點。比如，如果我們希望隻有廣東地域的用戶端請求才轉發到金絲雀節點，那麼就可以針對流量中的特征（例如參數中帶有 Guangdong 字元）來制定金絲雀流量政策。
目前我們支援 Intellij IDEA、Maven、Jenkins 和雲效等多種工具來部署至環境中：
- Intellij IDEA
- https://help.aliyun.com/document_detail/2362337.html
- Maven
- https://help.aliyun.com/document_detail/186680.html
- Jenkins
- https://help.aliyun.com/document_detail/171313.html
- 雲效
- https://help.aliyun.com/document_detail/199501.html
例如使用雲效實作應用的持續內建和部署，我們隻需要将開發好的新版本應用代碼送出到代碼庫，雲效流水線 Flow 會監聽代碼事件，當滿足觸發事件時會觸發流水線運作，部署新版本應用到 EDAS K8s 環境。
07 總結
事情從來都不是一蹴而就的，搭建平台需要相關領域的專業知識和持續的人力投入才有可能做好。當我們選擇建構一個平台時，我們建構的是一個有生命的東西，組織架構變遷和技術的更新換代都會對 IDP 産生影響。建構 IDP 不是一錘子買賣，這些變量在最初就要有充分考慮，否則 IDP 最終會演變成一個爛攤子。在雲原生化改造過程中，我們可能會遇到很多新的概念，諸如 Helm、IaC、Terraform、Kubernetes 等等。如果時間和成本對你比較重要，而且團隊不是這方面的專家，那麼選擇一個成熟的 PaaS 平台可能是一個更好的選擇。
而如果出于其他原因，希望建構自己的内部平台，那麼可以遵循平台工程的五大準則，這樣可能會讓你更容易朝着正确的方向前進：
- 明确使命和角色。
- 像對待産品一樣對待你的平台。
- 關注共同問題。
- 粘合劑是有價值的。
- 不要重複造輪子。
除此之外，我們提出一點建議：雲原生已經非常複雜，平台工程應當在保留靈活性的同時盡量暴露簡單清晰的互動，而非一味增加新的邏輯定義以增加研發團隊負擔。EDAS 産品一直遵循着這個設計理念。一方面我們支援松管控，支援你可以用最雲原生的方式來靈活運維；另一方面，我們暴露最簡單的上層應用模型，屏蔽底層的複雜定義，并将雲的能力內建到研發團隊最熟悉的工具裡，做到潤物細無聲。
相關連結：
[1] what-is-platform-engineering
https://diff.wikimedia.org/2011/08/17/what-is-platform-engineering/
[2] platform-engineering-product-teams
https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams
[3] 平台工程社群
https://platformengineering.org/blog/what-is-platform-engineering
[4] 《通用電氣在平台工程上浪費 70 億美元的教訓》
https://www.infoq.cn/article/qepvmrlawsw735wwunmb
[5] Nacos 注冊中心
https://github.com/alibaba/nacos
[6] EDAS 端雲互聯文檔
https://help.aliyun.com/document_detail/2362342.html
[7] 通過 IDE 部署應用
https://help.aliyun.com/document_detail/2362337.html
[8] EDAS 微服務開發側邊欄
https://help.aliyun.com/document_detail/2362352.html
[9] Jmeter 插件
https://help.aliyun.com/document_detail/2264132.html
[10] 《The Product Managers’ Guide to Continuous Delivery and DevOps》
https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/