阿里云：2023云原生實戰指南-以應用為中心構建數字化轉型最短路徑（91頁）.pdf

1、封面頁（此頁面將由下圖全覆蓋，此為編輯稿中的示意，將在終稿 PDF 版中做更新）目錄 一、云原生激活應用構建新范式.4 二、容器服務助力企業精益用云.14 三、云原生可觀測套件:構建無處不在的可觀測基礎設施.27 四、傳音移動互聯可觀測體系設計與落地.32 五、應用 Serverless 化，讓業務開發心無旁騖.38 六、優化 20%資源成本，新東方的 Serverless 實踐之路.46 七、心動網絡算法平臺的 Serverless 探索之路.50 八、以服務治理為基石構建可管可控互聯網應用架構.56 九、禾連云原生微服務治理實踐.67 十、消息隊列 RocketMQ5.0：從消息服務到云原

2、生事件流處理平臺.72 十一、云原生技術中臺 CNStack2.0 正式發布 助力企業高效用云.83 十二、數字化安全生產平臺 DPS 重磅發布.88 一、云原生激活應用構建新范式 4 一、云原生激活應用構建新范式 作者：丁宇，阿里巴巴集團研究員、阿里云智能云原生應用平臺總經理 11 月 5 日，2022 杭州云棲大會上，阿里巴巴研究員、阿里云智能云原生應用平臺總經理丁宇在云原生峰會上發表主題演講，提出云原生激活應用構建新范式，并表示 Serverless 將引領下一代應用架構。阿里云將堅定推進核心產品全面 Serverless化，幫助客戶最大限度的減輕運維工作，更好的實現敏捷創新。云計算時代

3、，企業上云后，應用構建依然面臨很多挑戰，如何保障系統資源的彈性、降本增效；如何做到應用敏捷開發，實現業務快速迭代；如何保障系統的穩定以及業務的連續性，這些問題沒有完全解決。我們看到，云原生已經變成非常流行的技術趨勢，從上云到用云，云原生能夠從 PaaS層面幫助企業解決應用構建的一系列問題。具體有三大范式正在成為現實：一、云原生激活應用構建新范式 5 第一個范式是全面容器化。因為容器形成了運維的標準，成為企業上云用云的新界面，也變成開發者和應用系統交互的新界面，有利于構建高彈性、可伸縮的系統，從而實現降本增效。當下所有的負載都在容器化，包括耳熟能詳的微服務、在線應用到整個數據庫、大數據、AI、中

4、間件等，所有的工作負載都在容器化。通過容器，我們可以享受到運維標準化、彈性架構帶來的好處，也帶來了軟件可以無處不在的部署交付，標準化的管理運維。第二個范式是整個行業應用的核心技術互聯網化。我們正在用互聯網的技術、互聯網的架構思想來重構應用系統，從而帶來了很多好處：分布式可擴展，支撐業務敏捷迭代，構建彈性架構，從容應對流量高峰。舉例來說，準備一場促銷活動、一場跨年晚會，都可能有不可預期的流量高峰，數字化系統需要應對不確定的流量，必須要用互聯網架構來實現；此外保障系統高可用、高可靠，保障業務的連續性，也是互聯網技術能夠帶給企業的紅利。第三個范式是應用的 Serverless 化。從技術角度來看，能

5、夠實現技術組件分層解耦，讓應用可以做到全托管免運維，提升系統的可運維性，降低成本。通過極致彈性，能夠把所有的組件覆蓋，在云上構建應用變得非常簡單。以前構建應用，需要買 ECS 實例，搭建開源軟件體系然后維護它，流量大了擴容，流量小了縮容，整個過程很復雜繁瑣。用了 Serverless 服務以后，這些問題都簡化了，從半托管到全托管，所有的服務 API 化，無限容量充分彈性，可以組裝使用，能夠感受到生產力大幅度的改變。也會在軟件開發的全生命周期進行優化，升級研發模式，讓開發者更多的聚焦在業務上，加速迭代。以上這三個范式代表著云原生非常主流的演進方向。一、云原生激活應用構建新范式 6 1.全面容器化

6、：容器服務進入智能化時代 Gartner 預測，到 2022 年，超過 75%的全球組織會在他們的生產環境中運行容器化的應用，而這一數據在 2020 年才不到 30%。我們看到，容器技術已經跨越鴻溝，從早期的互聯網行業到現在的千行百業，都在生產系統中使用。雖然 ACK 大幅降低了 K8s 的門檻，但管理和運維一個大規模、分布式的集群依然充滿挑戰，比方說，如何調度應用，在保障穩定的同時，提升資源利用率；如何對應用進行成本規劃、分析優化；當集群出現問題后，如何及時的定位和修復。智能化可以解決這些問題，智能化是容器平臺發展的必然趨勢。阿里云基于過去 10年的大規模容器實戰經驗，通過數據化手段和智能化

7、算法，推動容器服務 ACK 走向智能化。其中有三個升級：第一個升級，智能化的混部調度，新一代調度系統 Koordinator，幫助用戶提升整體資源利用率，智能化混部調度助力識貨 App 節省 20%資源成本。第二個升級，智能化的成本治理，容器服務 FinOps 套件，幫助用戶實現上云成本可見、可控、可優化，中華保險基于容器 FinOps 套件實現資源閑置率從 30%降低到 10%。第三個升級，智能化的運維體驗，容器服務 AIOps 套件，幫助用戶實現數據驅動診斷決策，助力故障防御定位，自動化診斷可以覆蓋 90%以上的問題，得物 App 基于容器 AIOps 套件定位問題時間從周縮短到小時。這些

8、能力升級，會進一步降低容器技術的使用門檻，讓 ACK 做到普惠化，服務更廣泛的客戶群體。2.核心技術互聯網化 互聯網中間件產品有三個特點：第一個就是開源全兼容，完全沒有廠商鎖定，像微服務、消息、服務注冊發現、網關等，都是跟開源完全兼容的。一、云原生激活應用構建新范式 7 第二個特點是大量的企業級特性加持，包括性能、穩定性、擴展性等?；ヂ摼W分布式技術的先進性需要非常好的場景錘煉，阿里云的優勢就在于多年雙 11 復雜場景的打磨，基于雙 11 的加持以及海量客戶的應用，使得阿里云互聯網技術在企業級特性上有非常強勁的優勢。第三個特點有豐富的技術類解決方案，包括異地多活，應用容災的方案、技術中臺、業務中

9、臺的方案，以及混部、混沌工程和全鏈路壓測方案等。云原生中間件實現了開源、自研和商業化的三位一體，能夠助力更多企業使用標準開放的技術實現數字化轉型。重磅發布一 微服務再升級：新增云原生網關開源 云原生時代，微服務面臨著新的訴求和技術挑戰，尤其是在性能、高可用性和安全性方面。今天，阿里云正式開源云原生網關 Higress，它是業內首個標準化、高集成、易擴展、熱更新的云原生網關。標準化：隨著 K8s 的普及，K8s Ingress 逐漸成為云原生時代 API 事實標準，Higress全面支持該標準，并且在服務治理方面（包括灰度、限流、預熱、超時、重試）做大幅增強，引領標準演進方向。一、云原生激活應用

10、構建新范式 8 高集成：Higress 首次將流量網關、微服務網關、安全網關三合一，打造高集成網關，在入口建立高性能、安全防線，后端支持 K8s/Nacos/ECS/Serverless 多種運行時路由，打造功能最強大網關實現。易擴展：Higress 提供最豐富插件擴展機制，滿足客戶靈活路由和安全定制需求，支持最全面語言擴展機制；當然我們為了降低客戶使用門檻，默認集成了數十個插件，并且通過插件市場方便開發者貢獻通用能力，產生良性互動。熱更新：由于傳統 Nginx 更新規則需要 reload 會導致鏈接抖動，導致流量損失，對實時通信、視頻、IoT 無法容忍，因此 Higress 從證書、路由、安

11、全規則、插件全部采用熱更新機制，毫秒級生效且業務無感知。除了開源云原生網關之外，阿里云全面升級微服務引擎 MSE3.0，包含三大核心能力：第一大能力是注冊配置中心，相比 Nacos 等主流開源方案，性能提升 40%，提供70+的監控指標，提供健康檢測，幫助客戶實現服務異常自治，例如禾連健康這家醫療行業的SaaS企業，通過MSE注冊配置中心，提升開源注冊配置中心性能達50%，解決了業務高速發展中的擴展性問題，保障全國 200 多個城市、2000 多家醫院體驗業務的穩定性超 99.99%。一、云原生激活應用構建新范式 9 第二大能力是微服務治理，沉淀了阿里巴巴 10+的實踐經驗，幫助客戶縮短 30

12、%微服務治理落地周期，提升 50%開發測試效率，消除 80%線上風險。例如紡織產業互聯網企業致景科技，未修改任何代碼就接入了 MSE 微服務治理所有能力。微服務實施周期下降 30%，構建開發測試環境從天降低到分鐘。第三大能力是云原生網關，阿里云將流量網關、微服務網關、安全網關三合一，架構上也做了升級，將實例級防護升級至路由級防護，整體性能相比傳統網關提升90%。例如移動支付企業費芮互動利用 MSE 構建了零信任架構，大幅提升業務入口安全性，通過軟硬一體完成 TLS 卸載，性能提 90%，并采用軟硬件一體化，響應時間下降 50%。重磅發布二 可觀測再升級：讓可觀測數據價值最大化 云原生時代，系統

13、架構日趨復雜，提升可觀測能力成為降低復雜度的唯一手段。今天可觀測能力成為度量企業 IT 水平的標準，成本治理、業務連續性、業務增長都需要可觀測技術。因此阿里云推出云原生可觀測套件 ACOS，從應用監控到鏈路追蹤，幫助企業實現成本管理、風險治理、智能運維、保障數字化業務高效穩定的運行。本次云棲大會，阿里云云原生可觀測套件 ACOS 三大組件也迎來重要升級。首先，Prometheus 已成為不少企業的觀測首選。作為容器觀測事實標準的Prometheus 監控，已成為阿里云 50 多款云產品的默認觀測基礎設施，并與應用實時監控服務 ARMS 的 APM 指標、eBPF 指標、OpenTelemetr

14、y 指標聯通，將觀測范圍從專精容器延伸到全?？捎^測。其次，作為觀測界面的阿里云 Grafana 服務也將迎來 9.0 煥新升級。全新的Prometheus 和 Loki 查詢語句生成器及強化后的搜索 Explore 功能，讓用戶獲得更強的數據查詢與分析能力。同時，為了應對越來越豐富的異構可觀測數據源，Grafana 服務與日志服務 SLS、Elasticsearch 等 20+款可觀測存儲服務集成，幫助企業更簡單的構建統一觀測界面。一鍵導入/導出自建實例、自動數據導出報表，一鍵數據備份、恢復，用戶操作審計等企業特性得到進一步增強。最后，為了幫助企業的云上應用開啟多維度觀測視角。應用實時監控服務

15、 ARMS 在數據采集方面，OpenTelemetry與Prometheus生態全面融合，通過OpenTelemetry補充業務、自定義組件埋點，在完善觀測維度的同時，實現廠商無鎖定。并借助TraceExplorer 實現多來源 Trace 統一查詢。一、云原生激活應用構建新范式 10 重磅發布三 RocketMQ5.0 全面升級：從消息服務到云原生事件流平臺 消息隊列一直是企業互聯網架構的核心組件，阿里巴巴早在 2012 年就基于電商場景打造了國內流行的消息中間件 RocketMQ，并貢獻到 Apache 社區。歷經十余年的打磨，RocketMQ 取得了眾多成果。Apache RocketM

16、Q 的社區非?；钴S，全球擁有 700+的貢獻者，超過 75%的頭部企業選擇使用 RocketMQ，同時超過 80%的主流云廠商提供了 RocketMQ 的商業托管服務；阿里云作為 RocketMQ 的發起方和核心貢獻者，十多年以來，累計服務了來自互聯網、零售、汽車等 20 多個行業、10w+萬企業客戶；承載千萬級 TPS，萬億級消息洪峰。當下，阿里云 RocketMQ 5.0 正式商業化，從內核到生態全面拓寬，全新升級為云原生事件流平臺，深耕事件驅動和事件流處理兩大核心場景。在未來，企業開發者基于 RocketMQ 事件流平臺，既可以輕松驅動微服務、Serverless 應用；也可以基于Roc

17、ketMQ 重構當下的流處理任務，以更加輕量化、低代碼的形態，高效的完成 CDC、ETL 等流處理需求。3.Serverless 奇點已來：引領下一代應用架構 隨著企業用云的深入，云的能力也在不斷升級，過去企業用云就是去買資源、買實例、買規格、搭應用。我們一直在說“云計算是像水電煤一樣的基礎設施，但是現 一、云原生激活應用構建新范式 11 在這一點還沒有完全實現。阿里云一直在推動產品形態、研發方式的升級，希望從提供資源到提供服務，這個服務就是即插即用的能力，企業不需要管理和維護，可以實現自動伸縮免運維，平臺全托管，按用量計費，真正實現了服務化、模塊化，這也是云產品升級演進的方向?？梢哉f，Ser

18、verless 奇點己來，所謂奇點，就是由平穩發展轉向高速發展的轉折點，預示著行業落地開始爆發。目前，阿里云已經有 20 多款的 Serverless 產品，并且會推進核心產品全面 Serverless 化，Serverless 是云提供能力的最佳實現方式，也是讓云計算基礎設施落地到千行百業的最佳范式?；仡櫚⒗镌圃?Serverless 領域的演進歷程：2017年推出的函數計算是一款FaaS產品，這是一種以事件驅動的全托管計算服務，用戶只需編寫代碼并上傳，函數計算就會自動準備好計算資源，以彈性、可靠的方式運行代碼，并提供完整的可觀測能力，大幅簡化開發運維過程。2018 年推出的 Serverl

19、ess 應用引擎 SAE 是業內首款面向應用的 Serverless PaaS 平臺，屏蔽底層 IaaS 和 Kubernetes 的復雜度，提供了零代碼改造、成本更優、效率更高的應用托管方案，幫用戶實現單體 Web 應用、微服務應用以及定時任務的Serverless 化。一、云原生激活應用構建新范式 12 同年領先業界推出 Serverless 容器服務 ASK，基于彈性容器實例 ECI（Elastic Container Instance），可以實現 1min 擴容 2000 個 pod，降低了 Kubernetes 使用門檻，讓用戶更專注于應用程序，而不是管理底層基礎設施。2020 年阿

20、里云開源 Serverless Devs，成為業內首個支持主流 Serverless 服務/框架的云原生全生命周期管理的平臺。2022 年 9 月該項目正式進入 CNCF Sandbox，也成為業內首個入選的 Serverless 工具項目。除了產品形態的改變之外，Serverless 同樣帶來了軟件研發范式的改變。隨著阿里云提供越來越全面的 Serverless 產品以后，很多云產品都變成模塊化、API化、服務化，它可以進行組裝，通過拖拉拽的方式就能夠構建應用。所以說在Serverless 架構下，研發方式升級到組裝式研發，組裝式研發可以做到流程編排、事件驅動，甚至可以做成可視化，這就徹底顛

21、覆了原有的軟件研發方式，大幅提升研發效率，靈活應對業務挑戰。根據權威機構調研統計，組裝式研發相比傳統模式，可為研發提效 50%以上。以南瓜電影為例，因為一場熱映電影，南瓜電影一小時用戶增加了一百萬，流量暴漲引發網站服務一度中斷，臨時云上擴容也無法及時滿足巨大的流量。傳統架構沒有改變云上的效率，南瓜電影開始轉向 Serverless 架構，三天時間完成了核心應用的上線，第五天 100%的切換，第六到七天把核心的 30 多個應用切換到 Serverless 一、云原生激活應用構建新范式 13 上，最終帶來擴容效率提升 10 倍，成本下降超過 40%，研發效率提升 70%，這就是 Serverles

22、s 帶來的價值：真正讓開發者回歸業務本身，讓企業做得更少而收獲更多。未來，阿里云在云原生領域將持續的引領標準，不斷突破，推動領域和產業快速發展。二、容器服務助力企業精益用云 14 二、容器服務助力企業精益用云 作者：易立，阿里云容器服務負責人 容器技術已經跨越鴻溝，廣泛應用于金融、通訊、制造、交通等千行百業。Kubernetes支撐的工作負載也從早期單一的互聯網應用發展到數據庫、AI、大數據等等，并覆蓋了公共云、專有云、邊緣云等多樣化、動態的云環境。11 月 5 日，2022 杭州云棲大會上，阿里巴巴研究員、阿里云智能云原生應用平臺容器技術負責人易立在云原生峰會上發表主題演講，發布阿里云容器服

23、務全面智能化升級，幫助企業精益用云，以增效促降本，實現 IT 架構在云上的高質量發展。1.容器服務助力企業數字化創新 經過 7 年的發展，阿里云容器服務產品線已經成為企業的云原生操作系統?；诎⒗镌迫萜髌脚_，阿里集團實現了 100%業務云原生上云。二、容器服務助力企業精益用云 15 2021 年，阿里云發布了 ACK Anywhere，進一步拓展產品的寬度，覆蓋從公共云、邊緣云、到本地數據中心的各個場景。讓所有需要云能力的地方，都能基于統一的容器基礎設施之上。得益于阿里集團和阿里云的大規模容器應用實踐，阿里云容器產品能力得到了業界的廣泛認可。2022 年 1 季度，在權威咨詢機構 Forres

24、ter 發布的全球公共云容器平臺分析師報告中，ACK 穩居全球領導者象限，這也是中國科技公司首次進入該象限；2022 年 2 季度，在 Omida 發布的全球容器管理解決方案報告中，由于在公共云、專有云、混合云等環境完善的產品體系，ACK 成為全球領導者，產品能力與規模國內領先；2022 年 8 月，在 CSDN 2022 中國開發者調查報告中，有 52%的國內開發者選擇阿里云容器云平臺。過去幾年，降本增效成為了眾多企業 IT 管理者關注的重要問題。企業已經到了精益用云的時代，提升資源效率、研發效率，IT 管理效率成為關鍵。2.四大全新升級，阿里云容器服務邁入智能化時代 智能化是容器平臺發展的

25、必然趨勢。今天，阿里云基于過去 10 年的大規模容器實戰經驗，通過數據化手段和智能化算法，推動容器服務 ACK 面向基礎設施層、容器編排層、應用架構層和運營治理領域 4 大維度全面升級，邁入智能化新階段。二、容器服務助力企業精益用云 16 升級 1：新算力 在基礎設施層，利用面向云原生優化的新算力，提升計算效率。2021 年，阿里云發布了新一代云原生 CPU，倚天 710，基于 ARMv9 架構，已經在電商、阿里云內部規?；瘧?，實現了卓越性價比。相比 X86 芯片，典型 Web 應用性價比高 50%，視頻編解碼應用性價比高 80%。倚天芯片面向云原生優化，vCPU 采用獨立物理核，沒有超線程

26、架構中的性能爭搶?？梢蕴峁└哟_定性的性能。ACK 通過對芯片微架構的拓撲感知調度優化，相比開源 K8s 實現，幫助 Web 應用吞吐提升 20%。為了更好支持 AI、HPC 等 I/O 密集型應用。ACK 正式提供了對 eRDMA 高性能容器網絡支持。通過軟硬一體優化的網絡實現，可以提供更高的帶寬與更低的延遲。應用在 AI 訓練加速 20%，微服務吞吐提升 10%。ACK 支持多容器高效復用 eRDMA 設備，滿足了容器應用部署密度的需求。二、容器服務助力企業精益用云 17 為了更好支持有狀態應用容器化，阿里云發布新一代容器網絡文件系統 CNFS2.0，它采用全鏈路加速技術，可以實現：容器應

27、用對后端存儲系統的訪問并行化，提升網絡帶寬的利用率。對遠程 NAS存儲的吞吐可以提升 100%，滿足高性能 AI 訓練和基因計算的需求。利用元數據緩存和獨有的 lease 機制，使得遠程文件存儲的元數據訪問性能，提升了 18 倍，非常適合 Web 應用和 CI/CD 等需要對海量小文件進行訪問的場景。支持文件的透明生命周期管理，可以自動將低頻訪問的冷數據放置在低成本的NAS 低頻介質或 OSS 中，降低存儲成本 50%以上。它支持對 NAS/CPFS/OSS 全鏈路可觀測，幫助開發者更好診斷和優化 I/O 性能問題。二、容器服務助力企業精益用云 18 企業與個人對數據隱私保護日益關切，機密計算

28、技術應運而生。其中一個重要的技術是通過芯片的可信執行環境（TEE）實現數據保護。在 TEE 內執行的應用，不用擔心來自其他應用、其他租戶或者平臺方的威脅。為了進一步推動機密計算的普及，阿里、螞蟻團隊在 Kata Container 社區與紅帽、Intel 等公司進行合作，將容器計算與可信執行環境相結合，推出機密容器Confidential Container 項目，同時為 Intel SGX、Intel TDX 等不同的 TEE 實現，提供了一致的容器界面?；谛乱淮臋C密容器架構，開發者可以確保應用是通過可信軟件供應鏈進行構建和分發的；容器應用運行在可信執行環境中，具備更小的攻擊面，而且所有

29、內存中數據是加密的并受完整性保護；應用對數據的訪問是基于加密的可信數據存儲服務。機密容器可以在需要隱私數據處理的場景中，如金融風控、醫療健康等，提供高效的隱私增強型算力。升級 2：新平臺 在容器編排層，通過智能化、云邊端一體的新平臺，提升資源利用率和運維效率。二、容器服務助力企業精益用云 19 K8s 目前已經成為云時代的操作系統。希望充分利用多種應用負載之間的削峰填谷，提升 K8s 集群資源利用率。這也是大家常說的“混部”能力。阿里巴巴早在 2016 年就啟動了云原生混部技術研發，歷經多輪技術架構升級和雙11 錘煉，目前已實現全業務規模超千萬核的云原生混部，日常 CPU 利用率在 50%左右

30、。阿里云今年開源了云原生混部項目 Koordinator，它包含三大核心能力：差異化 SLO 保障：在 Kubernetes 之上提供面向 QoS 的資源調度機制，比如延遲敏感型的在線類任務，和可搶占的計算任務。通過對不同 QoS 應用的合理調度，可以在保障應用的穩定性的同時，提升資源利用率。QoS 感知調度：包括 CPU、GPU 拓撲感知、資源畫像、熱點打散等精細調度能力，幫助應用優化運行時性能效率，提升穩定性。任務調度：提供了大數據與 AI 相關的任務調度，比如批量調度、優先級搶占以及彈性 Quota 等，可以更高效地支持計算任務。Koordinator 項目完全兼容標準的 K8s，無需做

31、任何侵入式修改。ACK 也內建了Koordinator 產品化支持：二、容器服務助力企業精益用云 20 通過混部調度，在典型場景可以提升資源利用率 100%。通過差異化 SLO 保障，在提升資源利用率的同時，讓低優先級的任務對延遲敏感型任務的影響5%。Kubernetes 的復雜性是阻礙很多客戶采用的一個重要因素。為此，ACK 發布 AIOps套件，通過智能化手段實現故障預防與快速定位?；诎⒗飯F隊 10 年大規模容器運維經驗沉淀，通過專家系統和 AI 算法相結合的方式，提供了全棧巡檢、升級檢查，智能診斷等三大功能。智能診斷目前包含 200+診斷項，覆蓋 90%的常見問題場景。以容器網絡問題診

32、斷為例，排查鏈路長，復雜度高，非常耗時耗力。在得物的業務場景中，利用智能診斷，可以快速定位由于網絡棧異常導致的偶發性抖動問題；再如 e 簽寶，利用智能診斷，可以在分鐘級完成對 Ingress、容器網絡、應用和 OS 的全鏈路問題排查。二、容器服務助力企業精益用云 21 ACK One 是面向多地域多集群的分布式容器平臺，可以統一管理中心云、本地云、邊緣云和客戶 IDC 的 K8s 集群。今年阿里云在 ACK One 基礎上，發布如下功能：提供托管的 ArgoCD 服務，開發者可以通過 GitOps 方式來實現應用的跨地域自動化交付。通過彈性感知的調度器實現，為混合云場景提供靈活的彈性算力。支持

33、對多集群安全策略的統一管理，保障企業系統統一安全基線。來看一個具體案例，在智聯招聘的業務高峰期，借助 ACK One 彈性調度策略可以在數分鐘內彈出數萬核 ECS 和 ECI 等計算資源補充到 IDC 的在線服務集群，有效應對流量洪峰。二、容器服務助力企業精益用云 22 ACKEdge 是面向云邊端一體協同的容器應用平臺，基于阿里云開源的 OpenYurt項目，今年對 ACKEdge 進行全新升級：在云邊協同場景，阿里云推出了增強型網絡邊緣節點池，實現安全、穩定的云邊網絡互聯方案。國內知名游戲企業，莉莉絲，利用增強型邊緣網絡節點池，讓海外多地域服務器與云上 VPC 安全互通。相比專線網絡資源成

34、本降低 30%。在云端協同場景，阿里云推出了輕量化接入功能，可以通過 K8s 管理資源受限的設備上的容器應用。元戎啟行是一個自動駕駛 Startup 公司，通過 ACKEdge管理車載設備應用，接入資源開銷占用降低50%，發布運維效率提升60%以上。升級 3：新架構 在應用架構層，利用服務網格等新架構，提升應用的敏捷性、彈性與韌性。服務網格已經成為云原生應用的網絡基礎設施。阿里云服務網格服務 ASM 在 4 個維度進行了全新的升級：支持多種服務治理框架，可以實現 Spring Cloud，Apache Dobbo 等微服務應用與服務網格應用的互聯互通和平滑遷移。二、容器服務助力企業精益用云 2

35、3 為應用服務提供統一的身份定義，簡化零信任策略的構建與實施。提供開箱即用的 Envoy 插件市場，可以拓寬服務網格的應用場景，包括身份認證、AI Serving 等場景?？梢曰诜?SLA 指標，實現更加精準的彈性擴縮容。震坤行工業超市是一家數字化的工業用品服務平臺，為眾多企業復工復產保駕護航。借助于 ASM 服務網格，提升了平臺的性能?；?ASM 的軟硬一體優化技術，提升TLS 握手性能 75%，以及 QPS 30+%。關于相關技術細節，可以參閱 Intel 和阿里云一起編寫的技術白皮書。專注餐飲行業數字化的合闊智云，其業務中臺的核心生產系統 100%全部切換到服務網格 ASM，提升應

36、用發布效率 70%，降低異常排錯成本 80%。升級 4：新實踐 在運營治理領域，將通過一系列最佳實踐的產品沉淀，提升企業 IT 在成本管理、安全治理等方面的管理效率。為了幫助企業上好云、用好云、管好云，阿里云本次發布了云原生 landing zone，為企業云原生上云提供最佳實踐。它包含架構規劃、安全管理、財務管理、自動化運維等等 8 大模塊。二、容器服務助力企業精益用云 24 通過云原生 landing zone 最佳實踐，已經幫助眾多國內外企業客戶構建了上云架構，滿足企業對安全、穩定性和成本等多方面的業務訴求。圍繞 LandingZone 中財務管理部分，阿里云結合業財一體化實踐和 Fin

37、Ops 理念，推出 ACK FinOps 套件。通過數字化手段和智能化方法，幫助企業實現成本可視化、可優化、可控制。中華保險作為國內互聯網金融行業的領導者，通過 ACK FinOps 套件，將企業 IT 成本治理周期從季度縮短到天級別，資源閑置率從 30%降低到 10%以內。識貨團隊通過應用混部和彈性等技術優化，將集群的資源利用率提升 10%；整體降低計算成本 20%以上。圍繞 LandingZone 中安全防護部分，ACK 與 ACR 提供完備的 DevSecOps 的產品能力，為企業提供安全可信的軟件供應鏈。二、容器服務助力企業精益用云 25 今年，阿里云推出了集群容器安全概覽，可以幫助安

38、全管理員對集群安全水位有更好地感知，可以對集群配置、應用鏡像、容器運行時的安全風險，及時發現與處置。全球領先的 SaaS 廠商 Salesforce，在阿里云上提供先進的 CRM 服務應用?；谠圃?DevSecOps 能力，半年內實現數千次風險鏡像攔截阻斷，1 萬次工作負載部署策略阻斷?；谌詣踊浖湴踩鞒?，應用安全交付效率提升 3 倍。二、容器服務助力企業精益用云 26 未來，希望更多的企業能和阿里云一起，利用云原生技術精益用云、增效降本，在云端進行業務創新。三、云原生可觀測套件：構建無處不在的可觀測基礎設施 27 三、云原生可觀測套件：構建無處不在的可觀測基礎設施 作者：周小

39、帆，阿里云智能資深技術專家 1.Gartner：可觀測性成為數據驅動型決策最強支撐 近日，全球權威 IT 研究與顧問咨詢公司 Gartner 發布 2023 年十大戰略技術趨勢報告。報告圍繞優化、擴展和開拓三大主題展開，應用可觀測性再次成為其中熱門趨勢之一。Gartner 杰出研究副總裁 Frances Karamouzis 表示：“為增加盈利，企業 IT 高管在持續加快數字化轉型的同時，需將目光從節約成本轉向新的卓越運維方式?？捎^測性以高度統籌與整合的方式將用戶數字化操作所產生的可觀測數據進行反饋并創造決策循環，提高組織決策有效性。如能在戰略中予以規劃并執行，可觀測性將成為數據驅動型決策的最

40、強支撐?！钡殡S著 IT 技術高速發展，企業在落地可觀測過程中必然遭遇三大阻隘。首先，蓬勃發展的開源/商業可觀測產品生態與逐漸無法滿足云原生 IT 運維需求的傳統企業監控體系，造成新老工具、數據與工具的割裂。如何選擇與平衡成為 CTO、CIO 必須面對的選擇題。其次，當微服務架構以及分布式架構被越來越多應用于企業業務，以日志為例的典型可觀測數據，計算成本與存儲成本以指數級增長。在行業形勢愈發嚴峻的當下，可觀測成本投入高昂且難以預估，應用場景往往停留在單點排查或基礎監控告警上，大張旗鼓的落地可觀測基礎設施，回報價值未知。以上幾點，這都難以說服 CTO、CIO 們投入愈發吃緊的運維預算與人力進行可

41、觀測性建設。為解決以上難題，深耕可觀測領域的阿里云于今年 6 月推出阿里云云原生可觀測套件 ACOS，該產品套件由阿里云 Prometheus 服務、阿里云 Grafana 服務、鏈路追蹤 OpenTelemetry 組成，這三款開源流行度最高、生態集成最廣的事實標準是云原生可觀測套件 ACOS 的“核心”，旨在通過開放標準打通所有阿里云可觀測產品實現全鏈路數據標準化，并連接企業存量可觀測數據資產，與阿里云應用托管平臺集成。三、云原生可觀測套件：構建無處不在的可觀測基礎設施 28 全面覆蓋用戶體驗（UEM）、應用觀測（APM）、云服務觀測、成本管理、應急協同效率等場景。幫助企業高效構建開放、高

42、質量、低成本的統一可觀測體系。2.云原生可觀測 ACOS 的獨特價值 相較于其他可觀測商業化或開源解決方案，云原生可觀測套件在采集、存儲、計算、告警、查詢、可視化六大環節做到與開源標準的全面兼容與優化提升。同時，將阿里巴巴集團以及阿里云服務海量用戶的可觀測經驗進行產品化輸出。這包含超過 50款阿里云主流云服務的運行指標、大盤和告警規則預置模板。從基礎設施到容器，從應用到用戶體驗，從成本分析到運維效能分析，在接入第一天就做到全鏈路高質量觀測。自發布以來，眾多行業客戶借助阿里云原生可觀測套件 ACOS 快速構建統一可觀測體系。以友邦人壽為例，友邦人壽對應用進行容器化、微服務化改造，以適應業務與性能

43、要求。但隨著訪問鏈路與部署復雜度提升，觀測微服務和 K8s 運行，并構建全?？捎^測能力成為巨大挑戰。借助 ACOS，友邦人壽將可觀測性覆蓋研發生產全周期，將研發態與運維態指標關聯與展現，從而有效度量研發效率。同時，將多容器集群及應用服務的觀測進行統一，將應用性能指標、全局調用鏈、日志相融進行快速根因定位的同時，形成指揮決策、儀表盤展示、告警推送的多維度觀測能力，大幅提升運維服務效率。三、云原生可觀測套件：構建無處不在的可觀測基礎設施 29 3.云原生可觀測 ACOS 煥新升級 本次云棲大會，阿里云云原生可觀測套件 ACOS 三大組件也迎來重要升級。首先，作為容器觀測事實標準的阿里云 Prome

44、theus 監控，觀測范圍從專精容器延伸到全?？捎^測。為了幫助更多企業構建統一觀測體系，Prometheus 監控已成為阿里云 50+款云產品默認觀測基礎設施，并與應用實時監控服務 ARMS 的 APM 指標、eBPF 指標、OpenTelemetry 指標聯通，以及將企業的 ECS（非 K8s 集群）、K8s 集群、非阿里云集群進行 Prometheus 實例聚合，幫助企業一鍵開啟全球與異構架構下的統一可觀測中心。在服務外部客戶同時，阿里云 Prometheus 監控不斷通過內部場景進行打磨，目前已能夠支持千萬核的容器觀測及數十億級別時間線的時序存算能力。對于時序監控場景的核心技術難點，如海

45、量動態監控對象采集能力、高基數時間線發散收斂、長周期查詢、突發流量下誤報漏報等場景進行針對性優化，使得阿里云 Prometheus監控真正成為無處不在，大規模生產可用的可觀測基礎設施。在賦予企業強大觀測能力的同時，Prometheus 推出全新包年包月計費形式，同等業務規模下，平均相較于自建成本降低 60%。滿足不同業務規模用戶的觀測需求，并盡可能減輕企業的運維成本壓力。三、云原生可觀測套件：構建無處不在的可觀測基礎設施 30 其次，作為觀測界面的阿里云 Grafana 服務也將迎來 9.0 煥新升級。全新的Prometheus 和 Loki 查詢語句生成器及強化后的搜索 Explore 功能

46、，讓用戶獲得更強的數據查詢與分析能力，更低門檻的創建可視化大盤與告警。同時，為了應對越來越豐富的異構可觀測數據源，Grafana 服務與日志服務 SLS、Elasticsearch 等 20+款可觀測存儲服務集成，幫助企業更簡單的構建統一運維&業務觀測界面。一鍵導入/導出自建實例、自動數據導出報表，一鍵數據備份、恢復，用戶操作審計等企業特性進一步增強。最后，為了幫助企業的云上應用開啟多維度觀測視角，應用實時監控服務 ARMS 也迎來巨大升級。在數據采集方面，在完整支持 Opentelemetry SDK 的同時，指標數據可完全通過與 Prometheus 標準進行存儲與計算，補充業務、自定義組

47、件埋點。在完善觀測維度的同時，避免廠商鎖定。并借助 TraceExplorer 實現多來源 Trace 統一查詢。與此同時，eBPF 技術以及 Continuous Profiling 作為目前可觀測領域最為熱門的細分領域，阿里云可觀測團隊也進行積極探索。本次大會阿里云可觀測團隊開放基于 三、云原生可觀測套件：構建無處不在的可觀測基礎設施 31 eBPF 技術的“輕量版應用監控”預覽，幫助企業快速獲得無侵入、全語言的應用監控能力，并及時感知集群全局拓撲結構。同時，與 Alibaba Dragonwell 團隊聯合推出 Continuous Profiling 功能，能夠以極低功耗持續分析代碼級

48、別的性能開銷，覆蓋傳統鏈路、指標和日志覆蓋不到的細節，實現代碼級生產環境性能問題定位及全天候主動剖析，讓應用觀測視角更豐富，觀測顆粒度更細致。在不斷探索更多可觀測場景服務阿里巴巴集團以及海量企業用戶的同時，阿里云可觀測憑借其完備的產品能力與良好的生態集成能力及出色的成本優勢，收獲了國內外行業機構的高度認可。阿里云應用實時監控服務 ARMS 在今年獲得中國信通院首批可觀測產品先進級認證。同時，阿里云連續兩年進入 Gartner APM 與可觀測魔力象限，今年更是成為唯一入選的中國廠商。萬物皆云的時代，可觀測性讓云計算更易用高效，最大程度釋放業務穩定性、安全性、經濟性價值?！坝^測力”已成為每個 I

49、T 人的必備核心競爭力。不止于觀測，可觀測幫助企業分析、洞察并實現高質量的決策與業務創新。而阿里云將不斷推動可觀測技術演進與落地實踐，幫助企業獲得最具性價比的可觀測性，真正實現高質量數字化轉型與創新。四、傳音移動互聯可觀測體系設計與落地 32 四、傳音移動互聯可觀測體系設計與落地 傳音控股作為“非洲手機之王”，據 IDC 報告顯示 2021 年占據非洲智能手機出貨量的 47.9%。傳音移動互聯廣告平臺作為傳音控股的重要業務之一，是非洲最為主流的營銷平臺之一。在技術架構方面，傳音控股通過 SpringCloud 進行全面微服務化。同時，使用數據庫、中間件等眾多 PaaS 服務，應用運行在阿里云容

50、器服務 K8S 之上，并分布在歐洲、亞洲等多個 region，真正實現多 region 服務體系。對于該套體系而言，要構建完整可觀測體系，挑戰非常大：首先，觀測對象非常多。觀測對象分布在不同技術棧、架構中，要對于眾多觀測對象實現全覆蓋且有所側重，是非常大的挑戰。其次，調用鏈路復雜。由于已經使用微服務，因此業務結構非常復雜，調用鏈路復雜，出現問題難以排查。最后，業務快速上線帶來的運維工作量。新業務上線頻率極快，如果新上線服務無法自動化地接入這一套可觀測體系，會帶來非常大的運維工作量。四、傳音移動互聯可觀測體系設計與落地 33 要構建觀測系統，首先要梳理出一套指標體系，進行分層設計，同時自上而下對

51、指標體系進行關聯。其次，傳音希望通過告警驅動整個運維流程，需要在 IM 即時通訊工具內完成事件閉環，包括告警收取、認領處理、分析、關閉全流程。另外，傳音的系統非常復雜，因此，傳統登錄到機器查看日志排查問題的方式無法實現，而是需要將全鏈路追蹤作為診斷的主要手段。在此情況下，整個觀測系統必須與鏈路系統打通。同時，我們希望觀測系統基于開源標準進行構建，指標符合 Prometheus 格式，tracing 符合 OpenTelemetry 標準，服務界面通過 Grafana 大盤進行統一呈現。相比于自建，傳音更傾向于使用阿里云上的成熟云服務，因為云服務帶來的全托管、免運維、穩定高效的優勢具有非常大的吸

52、引力?；谝陨蠘I務目標與需求，我們開始進入可觀測系統落地實施。四、傳音移動互聯可觀測體系設計與落地 34 首先，進行指標體系梳理，阿里云與可觀測團隊將所有指標進行拆解分層，分為資源層、容器層、服務層以及應用層。資源層最主要關注節點上的資源水位，包括 CPU、memory、網絡帶寬等。容器層分為工作負載、控制面以及容器的關鍵事件，對于產生的關鍵指標和事件進行收歸。服務層針對應用鏈路中涉及的負載均衡 SLB、云數據庫 Redis、MQ 等可用性以及性能指標進行梳理。應用層主要針對應用健康度以及應用性能本身，包括黃金三指標、運行的 JVM 性能等進行梳理。四、傳音移動互聯可觀測體系設計與落地 35

53、基于以上指標體系，傳音建立觀測系統的過程中，選擇使用阿里云上 Prometheus服務，與阿里云容器服務進行了天然集成，可以采集阿里云 K8S 集群的關鍵性能指標，開箱即用。容器服務運行的應用指標也進行默認集成，將應用層的黃金三指標等非常關鍵的指標收歸至 Prometheus，同時基于 Prometheus 和云監控開箱即用的能力，將鏈路上關鍵云服務指標收歸至 Prometheus。再結合阿里云 Grafana 服務真正實現全局多維度大盤展現。比如，業務關鍵指標、技術的可觀測大盤、關鍵的云服務大盤及應用性能均基于 Grafana 呈現。同時，數據源分布在歐洲、亞洲多個 region，基于 Gr

54、afana 的全球數據源加速能力，使國內同事也可以直接查看全球的監控狀況，真正實現一套觀測產品全球使用。得益于指標體系的梳理，每一層的關鍵指標均已收歸到 Prometheus 服務。而且Prometheus 服務提供開箱即用的基于 PromQL 的告警規則，極大減輕了傳音的運維工作量。所有發出的告警規則會被發送至阿里云上的應用性能監控 ARMS 智能平臺?；谥悄芨婢脚_的智能降噪、智能分組、壓縮等能力，進一步解決了傳音此前告警風暴問題，使得告警更準確、更高效。最終的告警會對接到傳音常用的飛書平臺，實現告警認領、告警追蹤、告警分析、關閉等完整流程。四、傳音移動互聯可觀測體系設計與落地 36 傳

55、音原先告警模式為告警至個人，非常容易丟失。而如今轉變為告警至群，通過群體協作，同事之間互相協作、互相提醒，更有利于告警及時處理。傳音新上的服務無法自動接入原先的鏈路追蹤系統，這會導致極大運維工作量，因此使用阿里云上的應用監控服務進行了替換。應用監控服務與容器服務有著天然集成，可以針對于容器服務需要監控的應用自動注入 Java 探針，將鏈路、APM 數據采集至阿里云上的應用監控服務，同時指標也會收歸至阿里云 Prometheus，真正實現從指標到鏈路以及鏈路中的關鍵報錯日志的完全關聯。同時，ARMS 應用監控也提供全局拓撲，可以查看整個服務關聯情況、調用情況。新服務上線后，可以非常方便地查看服務

56、的健康狀況、依賴等。發現問題節點之后，可以深入拉起全鏈路的調用鏈追蹤，并定位至代碼級別。四、傳音移動互聯可觀測體系設計與落地 37 阿里云和傳音一起構建該套可觀測系統-覆蓋資源層、容器層、PaaS 層、應用層的全球多地域統一的可觀測系統。在實施過程中，我們基于阿里云 Prometheus 服務將云上應用層指標、云服務指標、K8S 監控指標收歸至 Prometheus。通過阿里云 ARMS 應用監控構建了全鏈路追蹤系統，同時基于阿里云 Grafana 提供可觀測的統一視圖，再對接至后面的 ARMS 告警平臺，最終對接至飛書群，真正實現了再告警群內實現協作閉環，真正實現 ChatOps 的運維新范

57、式。后續，傳音計劃引入異常檢測、根因定位等 AIOps 能力，進一步提效，提高問題診斷效率。同時會在用戶側加入用戶體驗的監控能力，更好地區分是用戶側的問題還是數據中心的問題。我們也會將可觀測能力前置至開發態、測試態，與 CI/CD 流程結合，與壓測環境結合，更好地保證應用服務地交付質量。同時，我們也會探索基于可觀測數據做 FinOps、做應用安全，更好地利用可觀測數據，發揮業務價值。最終，我們希望能夠實現面向業務運維的可觀測系統。五、應用 Serverless 化，讓業務開發心無旁騖 38 五、應用 Serverless 化，讓業務開發心無旁騖 作者：司徒放（姬風），阿里巴巴資深技術專家、阿里

58、云可觀測&Serverless 負責人 11 月 5 日，激活應用構建新范式：云原生峰會再次聚焦 Serverless，進一步解讀阿里云核心產品全面 Serverless 化的意義，重磅發布 Serverless 運行時升級，讓云上應用構建更簡單。阿里云智能可觀測&Serverless 負責人司徒放主題演講 1.Serverless 引領下一代應用架構 要談應用 Serverless 架構，首先要從云產品托管形態的演進過程去理解 Serverless?！盎A設施托管”是最基礎的形態，產品交付的是計算、存儲、網絡等云資源，用戶不僅需要自己在云上部署和運維應用軟件和業務邏輯，還要解決軟件運行可能遇

59、到的種種問題?！皯密浖泄堋笔恰盎A設施托管”的向上延伸，客戶依舊需要按“幾核幾 G 服務器”的模式來購買云資源，但由產品去提供常見應用軟件（如 MySQL 等）的部分運維。五、應用 Serverless 化，讓業務開發心無旁騖 39 Serverless 全托管是進一步進化，客戶不再需要關心服務器，服務器由云產品全權管理，并且具備兩個重要特征：一是按實際使用量付費，更加接近“電網”模式：例如按請求調用次數，或者按實際數據存儲量，用多少付多少。二是自適應彈性、免運維：根據使用情況，云產品對底層資源進行自動伸縮，客戶不需要提前預購資源，用完即回收。Serverless 全托管的出現正在深度影響

60、和改變著應用技術架構。從企業級應用架構，到互聯網分布式架構，服務化、可伸縮、松耦合等理念已經深入人心，但分布式技術的實施復雜度卻不斷攀升。而 Serverless 的自適應、免運維能夠大幅降低復雜度，其高彈性又充分發揮了云的優勢。依托 Serverless 全托管產品，業務能力和云服務能力可以被抽象成靈活、通用的模塊形態。用戶可以根據需要從中挑選模塊，按需調整并把他們編排在一起，組裝成自己的應用，從而大幅提升研發效率。從資源到服務，阿里云核心產品全面 Serverless 化 Serverless 并不是不用服務器，它是將服務器全權托管給了云廠商，根據業務流量大小自動彈性伸縮，開箱即用免去維護

61、成本，按使用量計費。用戶無需關心和管理底層 IT 資源，只要聚焦業務代碼，根據實際請求處理業務。要想讓用戶用好 Serverless，單純在應用運行時層面進行 Serverless 化是遠遠不夠的，應用依賴的下游數據庫等系統，如果它們沒有良好的彈性，就會成為系統整體的“短板”。只有鏈路上所有的系統都具備高彈性、高可靠才能發揮出 Serverless最大價值。目前，阿里云上已經有超過 20 款核心產品提供了 Serverless 形態，在彈性速度、計費模型上幫助客戶業務更好的駕馭底層算力，節約成本；同時，圍繞 Serverless架構產品間緊密合作，共同解決產品集成、聯動伸縮等問題，為業務提供更

62、絲滑的全鏈路 Serverless 體驗。阿里云是國內最早提供 Serverless 計算服務的云廠商。五、應用 Serverless 化，讓業務開發心無旁騖 40 2017 年推出的函數計算 FC 是一款 FaaS 產品，這是一種以事件驅動為核心的全托管計算服務，用戶只需編寫代碼并上傳，函數計算就會自動準備好計算資源，以彈性、可靠的方式運行代碼，并提供完整的可觀測能力，大幅簡化開發運維過程。2018年創新推出的Serverless應用引擎SAE是業內首款面向應用的Serverless PaaS 平臺，屏蔽底層 IaaS 和 Kubernetes 的復雜度，提供了零代碼改造遷移、成本更優、效率

63、更高的應用托管方案，幫用戶實現單體 Web 應用、微服務應用以及定時任務的 Serverless 化。2018 年領先業界推出 Serverless 容器服務 ASK，基于彈性容器實例 ECI（Elastic Container Instance），可以實現 1min 擴容 2000 個 Pod，降低了 Kubernetes使用門檻，讓用戶更專注于應用程序，而不是管理底層基礎設施。2020 年，阿里云開源的 Serverless Devs 成為業內首個支持主流 Serverless 服務/框架的云原生全生命周期管理的平臺。今年，Serverless Devs 全程深度參與了信通院基于無服務器架

64、構的工具鏈能力要求的標準制定，并在 9 月正式進入 CNCF Sandbox，成為業內首個入選的 Serverless 工具項目。2.Serverless 運行時升級：云上應用構建更簡單 1)Serverless 應用中心：讓 Serverless 更易開發 Serverless 發展至今已經成為云計算的核心技術，主流場景都在通過 Serverless 解決問題，并且阿里云提供了完整的工具鏈，讓企業通過 Serverless 架構可以更簡單地在云上構建應用，充分享受 Serverless 化帶來的紅利。隨著 Serverless 架構的普及與使用，Serverless 工具鏈體系的匱乏、更新/

65、部署流程復雜、資源零散以及治理難度大等問題也隨之露出。阿里云重磅發布 Serverless 應用中心：海量場景化模板，讓 Serverless 應用全生命周期管理更簡單。通過使用 Serverless 應用中心，用戶在部署應用之前無需進行額外的克隆、構建、打包和發布操作，即可快速部署和管理應用，幫助用戶快速聯動云上的上下游服務，輕松沉淀最佳實踐。五、應用 Serverless 化，讓業務開發心無旁騖 41 Serverless 應用中心進一步覆蓋 Serverless 應用從創建、開發、運維的全生命周期，包括白屏化使用體驗、云端開發、多環境下的應用管理、應用維度的自動資源準備、標準化 DevO

66、ps 流程等企業級特性。后續應用中心會持續沉淀各行各業的典型 Serverless 應用案例模版，讓用戶可以更簡單地了解和掌握。目前應用中心已經加入了事件驅動、Web API、音視頻處理等 9大場景共 100 多款應用模版。2)函數計算 FC：靈活高能，拓寬三大場景 函數計算 FC 自發布至今已經幫助上萬家國內外企業在 Web、移動后端、音視頻、AI 推理、批任務處理等廣泛場景落地現代化應用，今年，函數計算 FC 深入打透音視頻處理、實時數據處理、GPU 三大場景，幫助開發者專注業務、降本提效。音視頻處理能力再突破，函數計算 FC 新增全景錄制模版。通過全景錄制這種所見即所得的模式，可輕松還原

67、直播互動效果，讓用戶開箱即用，既能得到 SaaS 化音視頻快速接入體驗，又能擁有代碼級的定制靈活性。依托強大的彈性能力，函數計算 FC 可以瞬間創建多個實例進行視頻多路并行轉碼，極大縮短了出片時間。同時，函數計算 FC 資源利用率高，算力消耗低，相比傳統方案成本可降低 70%以上。五、應用 Serverless 化，讓業務開發心無旁騖 42 讓消息流動起來，函數計算 FC 實時數據處理能力再增強。函數計算 FC 與阿里云全系消息產品如 RocketMQ、Kafka、EventBridge 進行官方集成，內置上百個觸發源，在消息產品控制臺就可以實現“一鍵”對消息進行數據清洗、富化和轉儲，讓消息發

68、揮更大的價值。函數計算 FC 的自適應彈性可以有效應對海量消息的波峰波谷，達到億級每分鐘的事件吞吐。當前以 GPU 為代表的硬件算力已經逐漸取代傳統 CPU，成為 AI 推理、多媒體處理的算力提供者。經過團隊測算，在以上兩種場景下，選擇使用 GPU，將會比選擇使用傳統 CPU 性能提升達到數十倍甚至百倍以上。然而，GPU 的價格一般比較高，而且使用率普遍低于 30%，這導致很多企業對 GPU 望而卻步。針對這個痛點，函數計算 FC 推出 Serverless GPU，支持最小 1/16 卡的多規格 GPU算力分割，同時提供準實時三秒冷啟動，秒級彈性+秒級計費，讓 GPU 算力更平價，普惠中小企

69、業。3)Serverless 應用引擎：新負載、新場景、新工具 作為業內首款面向應用的 Serverless PaaS 產品，Serverless 應用引擎 SAE 以低門檻微服務+容器化轉型、高彈性免運維等特征成為企業上云和用云的首選。讓流行的開源架構工作負載可以直接 Serverless 化，這是 SAE 一直以來的產品理念。目前SAE 上已經有數萬家企業的 Spring Cloud、Dubbo 微服務應用，沒動一行代碼即可完成 Serverless 化。五、應用 Serverless 化，讓業務開發心無旁騖 43 延續同樣的理念，今年 SAE 又新增了 Job 類型工作負載，開源 K8s

70、 Cronjob、XXL-JOB、Apache ElasticJob 都可以無縫托管。SAE 可以在任務完成后能快速釋放計算資源，成本更低，并且具備失敗重試、并行、分片以及內置可觀測等額外能力增強。此外，SAE 也拓新了對多語言微服務的支持，無論是 PHP、Python 還是 Go，都可以基于 SAE 進行服務注冊發現，最常見的多語言 gRPC 協議也得到了支持。依托業界領先的 eBPF 技術，SAE 可以提供無侵入的多語言應用可觀測性，為容器實例、應用、服務等提供通用指標洞察和調用拓撲視圖。工具鏈事關企業的研發運維流程，以及開發者習慣的延續。今年 SAE 進一步豐富了對企業常用工具鏈的支持：

71、通過 Serverless Devs 融入命令行工具和腳本體系，通過Terraform 融入“配置即代碼”（IaC）體系，通過 Jenkins 插件融入持續集成（CI）的體系。3.全面降價：讓 Serverless 成為普惠大眾的云上水電煤 函數計算迎來全面降價，vCPU 單價降幅 11%，其他的各個獨立計費項最高降幅達37.5%。函數計算 FC 計費粒度精細，按執行環境的內存和執行時間計費，計費粒度可達毫秒級，用戶可以只為請求產生的資源消耗買單，計費規則最低可達到 1 毫秒粒度的計費時長，0.05 核 vCPU、1/16 GPU 卡。函數規格 vCPU、內存、磁盤等各個計費項的綁定徹底解綁，

72、讓用戶可以按需自由選配，貼合自己的應用運行時開銷選取規格，進一步降低資源閑置比例。預留模式作為函數計算 FC 消除冷啟動的利器，新增了閑置計費僅 1/10 價格更加讓業務能免除高成本的后顧之憂。五、應用 Serverless 化，讓業務開發心無旁騖 44 據團隊測算，一個集群的資源如果日均利用率在 30%以下，或者有明顯的閑置浪費，就適合使用函數計算 FC。采用函數計算 FC 之后資源利用率能夠提高到 60%甚至90%以上，綜合成本降低 15%到 70%。以企業使用為例：視頻直播是戀愛社交APP伊對最為重要的業務，峰谷特征明顯。為了保障業務平穩，伊對需要準備大量機器去處理任務，在流量低峰期機器

73、資源會大量空閑浪費，而某些節假日帶來的高峰卻會超過集群的最大承受能力，任務排隊不得不對部分業務做降級處理。在使用函數計算 FC 之后，峰谷期資源問題得到徹底解決，資源成本開支減少了 20%?；ヂ摼W營銷推廣服務商魚傳科技，業務主要基于支付寶小程序進行承載，具有訪問量波動大、流量突發預測難等特點，尤其是活動期間訪問突增對小程序后端服務的穩定和彈性也是一個很大的考驗。為了應對無法預測的突發流量，魚傳科技進行全系統 Serverless 化，一天只用 200 元即可支撐日活超過 50 萬人的小程序，能承受突發上萬 QPS。函數計算 FC 全面降價讓 Serverless 成為普及大眾的水電煤，隨用隨取

74、，按量計費，將會成為創新企業上云的首選。五、應用 Serverless 化，讓業務開發心無旁騖 45 4.千行百業背后的 Serverless 力量 也許對很多人來說，Serverless 仍然是一個新概念，但當你發出一條微博，當你點開一首歌，當你進入一個直播間，當你在超市買單的時候，也許就有 Serverless 的力量在默默支持。Serverless 覆蓋的技術場景正在不斷變廣。目前 Serverless 在微服務、在線應用、事件驅動、任務處理等眾多場景已經被驗證并且廣泛應用。如果你業務的流量不可預測，或者有潮汐波動，或者有明顯資源閑置，資源利用率低于 30%以下，Serverless一定

75、會成為適合你降本增效的利器。六、優化 20%資源成本，新東方的 Serverless 實踐之路 46 六、優化 20%資源成本，新東方的 Serverless 實踐之路 作者：么敬國，新東方教育科技集團云教室直播平臺技術負責人 新東方教育科技集團定位于以學生全面成長為核心，以科技為驅動力的綜合性教育集團。新東方線上教育業務的云教室系統支持了視頻直播、轉碼、點播等新東方所有在線教育場景。隨著業務量的增大，由于直播轉錄及視頻轉碼任務處理平臺具有明顯的波峰波谷特性，自建機房較低的資源利用率成為了業務的核心痛點。為了提升計算資源利用率，進一步實現降本提效目標，在幾次嘗試之后，新東方踏上了Serverl

76、ess 實踐之路。以下內容是由新東方教育科技集團云教室直播平臺技術負責人么敬國在云棲大會的分享。1.如何應對難以預測的業務量？新東方除了自己的線上教育業務使用云教室平臺以外，還通過美刻云直播對外開放了新東方的直播能力。云教室直播平臺主要支持四種業務模式：云教室：在線直播互動課，講究互動性。云點播：錄播課。云直播：大型直播，以主播為主。智慧教室：軟硬件結合的方案，提供類似于雙師的教育模式。直播+錄播是新東方主推的課程交付模式。直播課程互動性強，可以實現良好的課堂互動，激發學生的學習興趣；教師可以基于學生的課堂反饋或互動直接與學生進行互評，便于教師及時對教學環境作出微調，從而讓教學過程更有針對性；

77、通過互動和課堂答疑，可以讓教學過程和效果更有保障，直播課程比較適合低幼年齡段的學生。而面對高中及高中以上年齡段的學生，錄播課更為合適，錄播課特點為學習時間靈活，學生可以自主對學習內容進行檢索，進行有選擇性的學習，一般適用于高中和高中以上年齡段學生。錄播課的優點在于可以對授課內容不斷進行打磨、編輯，制作精品課程，需求量逐步加大。六、優化 20%資源成本，新東方的 Serverless 實踐之路 47 最初團隊采用地錄制技術方案為客戶端錄屏，將老師的直播進行錄制，方便學生反復觀看，但這樣的方式出錯率高，CPU 占用率也較高，無法對錄制 UI 布局進行靈活定制，只能是看到什么錄什么，這樣的方式僅能滿

78、足低幼年齡段的課程需求。今年，新東方開始對接大學生線上教育業務，對錄播課程的質量提出了更高的要求。團隊開始考慮采用服務端錄制的方式解決問題。服務端錄制的兩個核心點在于直播錄制和視頻標準化生產。我們的業務模式決定了我們很難準確預測業務量，因此，新東方關鍵的技術任務是實現計算彈性。2.三種選擇，函數計算脫穎而出 三種選擇，函數計算脫穎而出要解決服務端錄制的問題，擺在團隊面前的有三個可選的技術路線：直接使用 ECS 自建，該方案的優勢是靈活性比較高，但問題在于計算沒有彈性，雖然云廠商提供了彈性分配 ECS 資源 API，但是自己實現整個計算彈性需要巨大的開發量，同時后續運維比較復雜，資源成本高，難以

79、做到標準化。云錄屏 SaaS 方案，這個方案的優勢是具備標準化的服務，研發投入比較少，運維工作也較少，但是問題在于靈活性差，資源成本極高，難以進行進一步的性能優化。我們希望尋找一家成熟的 SaaS 廠商提供地服務以快速支持業務，但是經過試用，這些平臺的成熟度和技術指標等均無法滿足我們的需求。采用阿里云函數計算 FC，我們發現阿里云的函數計算產品可以完美滿足計算的彈性需求，只需要關注具體需求在平臺上做開發即可，研發投入小同時免運維，開發過程自主可控，靈活性高，可按需使用極大降低了使用成本，實現標準化相對容易。不過函數計算是一個比較新的技術，團隊需要一段時間來熟悉。經過反復比對，新東方團隊選擇使用

80、函數計算來解決服務端錄制問題。3.新東方的 Serverless 實踐 錄播轉碼，函數計算小試牛刀 我們首先在錄播轉碼場景下進行了嘗試。錄播轉碼的核心訴求是對直播流進行實時轉碼，保存為標準的視頻格式，方便后續加工使用。六、優化 20%資源成本，新東方的 Serverless 實踐之路 48 在這個場景中，我們第一次感受到了函數計算 FC 帶來的彈性優勢。在老師進入房間發起轉碼請求后，可快速啟動函數實例進行轉碼。在上課結束后，結束轉碼任務，將臨時音視頻結果上傳至云存儲后即可立即釋放函數實例，不會存在任何計算資源的浪費。有了在錄播轉碼項目中應用函數計算的經驗以后，我們對函數計算方案有了更大的信心。

81、初露鋒芒，函數計算直播合流轉碼方案 之后，我們啟動了云端錄制項目。使用 Chrome 瀏覽器加入直播房間，對瀏覽器界面進行截屏錄制，該方案的關鍵在于彈性提供瀏覽器實例。因此，我們利用阿里云函數計算啟動 Linux 容器，在 Linux 容器運行 Chrome 瀏覽器實現彈性提供瀏覽器實例。整個的錄制流程是這樣的：老師進入教室以后，開始進行音視頻推流以及白板操作。同時，錄制平臺發起錄制請求，啟動函數處理，開始接收教室的音視頻流和白板操作，并在瀏覽器展現整個教室的畫面，同時做截屏。六、優化 20%資源成本，新東方的 Serverless 實踐之路 49 課程結束后，平臺發起結束錄制請求，函數計算平

82、臺會優雅地終止實例。終止之前，實例會將臨時結果上傳至云存儲，隨后函數實例被銷毀，不存在任何資源浪費。開箱即用的可觀測能力 我們認為，可觀測能力對于函數計算平臺至關重要。首先，業務高峰期需要啟動大量函數實例，因此，必須要完整的 metrics、log 和 trace 才能有效對海量實例進行監控。其次，因為函數計算實例按需創建，完成任務之后被銷毀，平臺必須保存完整的日志，以便發現問題后開發人員進行排錯。我們曾在開發錄制服務的過程中面臨的問題是：啟動函數實例以后，Chrome 瀏覽器要訪問直播服務，此時網絡出現問題，導致錄制失敗。后續我們使用阿里云 SLS 日志平臺查看日志，發現 Chrome 瀏覽

83、器內核對網絡處理過于敏感。找出問題后，對癥下藥，加入了重試機制，問題得以解決。4.超出預期，函數計算帶來更多驚喜 在使用函數計算技術之前，我們期望它能通過百毫秒拉起上萬個實例，定時預熱徹底解決冷啟動困難，幫助我們承載直播轉碼和錄屏業務業務洪峰。有效應對大規模突發在線流量，按量付費，提高資源利用率，減少 20%資源成本開支，極大程度降低運維成本，讓我們可以只專注業務創新。在實際使用的過程中，我們發現函數計算不但能夠中我們完美滿足我們的需求，還帶來了驚喜：讓我們的開發人員只需掌握幾個新概念、使用幾個 API，即可輕松使用平臺。函數計算方案運行一段時間以來，云資源費用得到較大降低。另外，函數計算允許

84、根據自己的業務場景制作模板，并且可供其他業務方使用，也為我們帶來意外收獲。七、心動網絡算法平臺的 Serverless 探索之路 50 七、心動網絡算法平臺的 Serverless 探索之路 作者：陳欣昊，TapTap/IEM/AI 平臺負責人 Serverless 在構建應用上為我們節省了大量的運維與開發人力，在基本沒投入基建人力的情況下，直接把我們非常原始的基建，或者說是資源管理水平拉到了業界相對前沿的標準。最直觀的數據是，我們組僅投入了個位數的人力，就可以為 TapTap整個搜廣推相關的所有業務提供全套 AI 和大數據方面的支持。陳欣昊 1.心動介紹 心動創立于 2003 年，是一家全球

85、游戲開發和發行商，擁有豐富的研發、發行和代理運營經驗。截至 2022 年中，心動運營 38 款免費和付費游戲，在全世界擁有 5,000萬月活躍用戶，主要分布在大中華地區、東南亞、北美和南美。2016 年，心動推出手機游戲社區和應用商店 TapTap，玩家可以通過官方渠道免費或付費購買下載手機游戲，亦可在社區中與其他玩家交流，截至 2022 年 6 月，TapTap 在全球已擁有超過 5,000 萬月活躍用戶。2.業務背景 TapTap 不同于傳統的應用商店的分成模式，至今一直堅持做渠道零分成，這也決定了，TapTap 目前的商業化，主要由廣告驅動。TapTap 的廣告屬于站內的原生廣告，與其他

86、非商業化在內容上形態保持高度一致，給用戶更好的體驗。比如首頁的游戲推薦，發現頁的內容推薦，搜索引導頁的底紋詞，以及搜索輸入時會出現的搜索建議詞，還有搜索最后的落地頁等等，廣告的部分就穿插在這些戰略內容之間。我們的 serverless 實踐也是基于這幾個業務場景的實際需求來進行推進的。例如，目前搜廣推都依賴的深度學習模型自動化更新/部署，以及組內算法同學都需要依賴的模型實驗記錄平臺，還有站內新內容的一些 NLP 分析處理等。早期，我們絕大部分的后端服務都是部署在ECS，通過Rundeck來進行管理和部署，在效率和管理上并不是那么理想。在基建升級方案的需求上，我總結了 4 點：七、心動網絡算法平

87、臺的 Serverless 探索之路 51 能大幅提升開發運維效率。以較低的人力成本來滿足業務需求。服務足夠可靠，能夠具備良好的性能。因為我們工程目前主要是以 Go 語言為主，所以在后續基建升級上需要對 Go 有良好的支持。3.方案對比 我們考慮了兩種主流的方案架構，一個是云主機+自建 K8s 全套的解決方案，還有一種就是 Serverless 架構，使用 Serveless 應用引擎（SAE）和函數計算 FC。經過對比后，我們選擇了后者。一方面是 Serverless 可以免去機器的購買流程，不需要提前購買 ECS。而且本身也自帶了一些可選的默認環境，如果沒有特殊需求的話，可以基本免去環境搭

88、建的繁瑣；另一方面是 Serverless 已經集成了很多基礎組件，基本上可以說是做到免運維直接上線的程度。然后在后續維護上，Serverless 產品在計費精度上相比 ECS 有更高的精度，可以做到分鐘級，甚至秒級的計費，做到真正業務使用資源時才進行付費，相比 K8s+ECS的模式，在早期開發和后續運維上，都能節省較大的人力成本。從我們自己實際實驗的體驗來理解 Serverless 的兩個產品的話。函數計算 FC 把業務的調度和觸發邏輯與業務邏輯本身解耦，開發、算法同學可以先在函數計算控制臺控制整個業務邏輯的觸發與調度邏輯，就不需要再額外地開發，可以更加專注業務邏輯本身的設計，這也決定了函數

89、計算更加適用于有業務驅動的場景，在事件真正發生時去申請資源進行業務邏輯的運行。七、心動網絡算法平臺的 Serverless 探索之路 52 而 Serverless 應用引擎 SAE 在我們看來類似于功能更豐富的、提供了全套微服務能力的增強版 K8s，可以極大降低維護成本，并做到真正的開箱即用。這個就比較適合做微服務改造，把原先在 ECS 上的舊服務直接遷移上來，可以在不投入運維人力的情況下獲得一套完整的容器化運維方案?；旧贤ㄟ^兩者結合，可以覆蓋掉我們絕大多數的業務場景，實現所有應用服務 All On Serverless。4.業務實踐 1)函數計算 FC a)通過 OSS 觸發的全自動模型

90、部署/小時級更新服務。我們有一個通過 OSS 觸發的模型自動部署與更新服務，實現模型導出及部署。算法同學在訓練完自己的模型，無論是 TensorFlow 還是 PyTorch 以及其他格式的機器學習模型，只需要導出到指定的 OSS B 存儲空間 ucket，就會觸發模型的更新與部署服務，實現完整的導出即部署。這樣算法同學哪怕在不依賴其他工程人力的情況下也能自行進行模型的部署、更新以及后續的彈性縮擴容。b)通過 HTTP 觸發的模型實驗管理平臺（WEB 服務）。七、心動網絡算法平臺的 Serverless 探索之路 53 法同學通過 HTTP 觸發器實現的內部模型實驗管理與參數平臺提交模型訓練任

91、務之后，我們會自動地將它訓練的參數以及日志地址、日志實例記錄下來，實現所有的實驗可追溯、可管理，這本身是一個 Web 服務，它是有前端的，但又是一個對內的服務，對 QPS 和性能要求不是很高，于是就放到函數計算上，在管理成本上相當有優勢，尤其是近期函數計算有免費額度，所以基本沒花錢。c)通過 Kafka 觸發新內容 NLP 處理/解析服務。當我們站內的用戶發了一個新的帖子，我們會通過 Kafka 推送到 NLP 分析服務商進行 NLP 的處理與解析，存下來用于之后的搜索，這可以實現用戶發一條內容調一次服務，精確地控制成本。d)每周/每日定時統計資源消費。每周/每日定時觸發的 MaxComput

92、e、EAS 資源消費統計，我們會自動拉取阿里云后臺的非結構化消費賬單，然后將它聚合到每一位同學，每個任務以及每個模型上，推送給組內的同學，協助組內同學提升自己的成本意識，也幫助各個業務線更好地做成本管理。2)Serverless 應用引擎 SAE 在 SAE 的落地上，我們選擇了組內的預估服務，這個服務本身整合了搜索、推薦、廣告都需要的模型推理、特征開發以及樣本回傳的能力，本身是一個中臺型微服務，七、心動網絡算法平臺的 Serverless 探索之路 54 所有業務線都可以非常低成本的接入目前組內最成熟的線上預估服務。例如現在的搜索頁的推薦詞的點擊率預估，國際版的游戲點擊率預估等。通過 SAE

93、，我們的服務快速具備了 Serverless 的能力，因為 SAE 本身屏蔽了很多資源管理、環境管理以及基礎運維組件管理工作，使得我們可以快速地為國內國外的新場景、新業務上線一套獨立的預估服務。與此同時，我們也集成了 SAE 的告警平臺，事件中心以及日志服務，我們通過釘釘告警就可以實時感知線上業務的狀態，例如是否發生了 OOM 還是重啟、錯誤日志之類的。另外，本身這個服務也是接入了 Dubbo Go 框架使服務直接具備了服務注冊發現，IP 直連，優雅上下線等微服務能力。相比之前使用 ECS 的模式，這套方案在運維管理以及開發上線和后續的成本管控上都有較大的優勢，基本可以覆蓋從開發上線后續運維的

94、全流程，大大節省的組內的開發成本。5.業務價值 簡單運維，省心省力：開發可以輕松搞定應用開發、部署、管理全流程，讓自己更專注于業務，也大大節省了運維的投入和成本。不停機發布+分鐘級上線：SAE 支持灰度發布、滾動發布的能力，還提供了較為完善的 Open API，可以集成到 Git 中快速部署，使我們的服務具備了分鐘級發版的能力，這個對于新業務尤其具有吸引力。七、心動網絡算法平臺的 Serverless 探索之路 55 秒級彈性縮擴容：SAE 支持配置像 CPU、內存、QPS、RT、定時等不同維度指標的擴縮策略，可以幫助提升資源利用率。尤其是業務規模大了之后，通過配置更加精細的彈性策略，可以顯著

95、降低機器成本。多語言微服務能力：SAE 提供了 PHP、Python、GO 等多種運行時，并且基于K8s Service 多語言服務注冊發現，實現了 Go 語言低成本微服務化 八、以服務治理為基石構建可管可控互聯網應用架構 56 八、以服務治理為基石構建可管可控互聯網應用架構 作者：董振華，阿里云智能高級產品專家 1.微服務落地與挑戰 CSDN 今年發布的中國開發者報告顯示，有 40%的云原生開發者專注于微服務領域，其中有不少開發者非常關注服務編排、服務治理，這也符合阿里云典型用戶上云過程的特點。云上部署作為第一階段，主要解決的是如何將 IDC 內傳統應用平滑遷移至云上。此階段一般關注計算資源

96、，應用往往不會做任何修改。用戶上云以后，為了能夠更好地利用云上強大的調度、彈性、容錯能力，會進行云原生化改造，將原先虛機的部署方式轉為容器化部署。隨著業務發展，傳統單體應用已經無法滿足業務需求。用戶需要進行微服務化改造，進一步提升開發迭代的效率。但隨著微服數量越來越多，調用鏈路越發復雜，用戶需要進入第四階段：服務治理。從開發聯調到上線發布，從流量管控到錯誤故障排查，進行全方位的服務治理，進一步提升效率、穩定和安全性。八、以服務治理為基石構建可管可控互聯網應用架構 57 眾所周知，微服務并不是銀彈，從微服務的開發、測試到運行，用戶會面臨各種問題和挑戰。在開發階段，如果微服務沒有很好地進行拆分，所

97、帶來的問題可能會超過微服務架構本身帶來的紅利。開發人員需要非常規范的 API 接口以及統一的配置管理才能提高開發迭代效率。而微服務之間的調用鏈路非常復雜，會帶來很多不確定因素，排查故障也愈發困難。因此，我們需要有可靠的微服務組件以及專業的治理能力來提高整個系統的性能和穩定性，并且需要為用戶建立可觀測以及故障排查能力。通過服務集團內部項目以及外部商業化客戶，阿里針對此類挑戰積累了大量豐富的經驗，同時也開源了比如 Dubbo、SpringCloudAlibaba、Nacos、Sentinel、Arthas等優秀的開源項目。2.微服務引擎 MSE3.0 發布 微服務引擎 MSE 正是結合了阿里云微服

98、務開源項目、商業化方案以及雙 11 大規模落地的最佳實踐，提供了面向業界主流的開源微服務生態一站式平臺，包含了云原生網關、注冊配置中心和微服治理三大能力。八、以服務治理為基石構建可管可控互聯網應用架構 58 用戶可以自由選擇一個或多個能力，并與其他云產品結合構建自己的微服架構。業務應用無論是部署在 ECS 還是容器服務上，或是托管在 EDAS、SAE 等 PaaS 平臺上，都可以使用云原生網關作為統一的服務出口。再利用監控服務、日志服務等可觀測組件，獲取從網關入口到業務應用的全鏈路可觀測數據。注冊配置中心解決了微服務間同步調用的注冊發現以及配置管理的需求。異步邏輯通過消息隊列實現。微服務治理，

99、則支持了 SpringCloud、Dubbo 近五年的版本，用戶無需修改任何一行業務代碼，即可獲得全鏈路的流量控制能力，提升微服務系統的穩定性和安全性。八、以服務治理為基石構建可管可控互聯網應用架構 59 2020 年初，阿里云發布了 MSE 商業化服務。1.0 版本提供了注冊中心，主要解決服務間的注冊發現以及通信問題，幫助用戶快速構建應用。2.0 版本新增了配置中心以及服務治理的基本功能，比如服務查詢以及無損下線，幫助用戶快速提升開發、運維效率，落地企業級能力。今年，阿里云推出了 MSE3.0，包括云原生網關以及全新的服務治理中心。注冊配置中心也全面升級，讓用戶享受到云原生時代下微服務的最佳

100、實踐。注冊配置中心提供了 Nacos 以及 ZooKeeper 的商業化托管服務，并且兼容 Eureka協議。在微服務場景下，除了服務的注冊發現，Nacos 還能集中管理分布式架構的環境配置信息，降低用戶的管理配置成本。也有很多用戶使用 ZooKeeper 托管服務，在大數據場景下比如 HBase、Kafka、Hadoop、Flink 集群中，使用專業的 ZooKeeper 組件實現穩定、高性能的分布式協調、分布式鎖。全新的注冊配置中心基于阿里巴巴 DragonWell 構建，且進行了深度調優，性能較開源自建提升 40%以上?？捎^測方面，我們開放了 70 多個資源和業務監控指標，讓用戶對整個系

101、統的運行了如指掌，且可與用戶自建 Grafana 大盤進行對接，并且提供服務推送以及配置變更推送的軌跡查詢能力。如果用戶遇到了服務發現或配置變更沒有生效等問題，可以通過白屏化的方式快速進行問題排查，提升效率。另外，在日常運維中，很多用戶在實例的容量、節點配置以及客戶端、服務端版本方面均存在不少問題。最新推出的健康自檢功能能夠對風險點進行自動評估，并將優化建議推送給用戶，使用戶的實例處于健康狀態。八、以服務治理為基石構建可管可控互聯網應用架構 60 MSE3.0 提供了全新的白屏化遷移工具，使 Nacos、Eureka 和 ZooKeeper 一鍵熱遷移至托管實例，整個過程無需停機，避免對業務應

102、用造成影響。MSE3.0 推出的云原生網關，兼容了 K8s ingress 標準，將負責南北向路由的流量網關、東西向調度的微服網關以及安全網關三合一。集成了 13 種阿里云產品，包括數字證書服務、web 應用防火墻、AHAS 流量防護、IDaaS、SLS、ARMS 等，從安全、高可用、可觀測方面提供了全方位的能力。支持 8 種服務來源，無論是容器服務上的 service，還是注冊在 Nacos、ZooKeeper上的微服務，亦或是托管在 EDAS、SAE 上的各種應用，甚至是傳統通過固定地址暴露的服務，都可以一鍵導入至云原生網關中做統一管理，非常適合各種應用架構、部署方式并存的場景。性能方面，

103、云原生網關經過了阿里雙 11 高流量洪峰的檢驗，可以輕松應對數十萬筆/秒的交易，相比于自建 NGINX Ingress 的 TPS 高出 90%，相比于微服網關 ZUUL高出 400%。通過硬件加速能力，HTTPS 請求的 RT 會進一步下降 50%。通過插件市場的機制，用戶可以做多語言擴展，滿足用戶在安全、流量管控以及請求響應方面的個性化需求。而且插件的更新以及安全路由策略的更新均毫秒級生效，對業務應用無感。八、以服務治理為基石構建可管可控互聯網應用架構 61 目前在阿里云 EDAS 以及容器服務 ACK 控制臺上，ingress 入口選型中已經提供了MSE 云原生網關的選擇。需要特別提出的

104、是，云生網關兼容 Nginx ingress 核心注解，用戶已有的 Nginx ingress 路由規則無需更改，云原生網關可以自動監聽，并在網關側生效，實現幾乎零成本的平滑遷移。我們的客戶費芮互動原來使用的 Nginx ingress 與業務應用混部，有穩定性問題，而且缺少 TLS 版本設置、IP 黑名單等功能，通過上述平滑遷移方式更換成云原生網，關完美解決了這些問題，高效支撐了大規模業務。微服務規模發展到一定階段，用戶會出現服務治理的需求。但相關技術實現較復雜，是困擾開發和運維同學的難題。以變更發布為例，很多 IT 從業者都會有熬夜做新版本上線發布的經歷。這種方式一方面對開發運維人員的工作

105、帶來了極大不便，另一方面也無法滿足業務快速迭代的需求。CNDN 的報告也顯示，有 44%用戶需要做不定時發布，更有甚者一周需要做上百次發布。如此頻繁發布下前提下，應用啟停會對線上流量造成巨大影響，另外如果新版本有 bug 引發大面積生產故障也是災難性的事故。而微服務治理無損上下線和全鏈路灰度可以完美解決上述問題。阿里在微服務治理方面積累了近十年的經驗，我們將微服務治理能力產品化，產品基于 Java agent 且全面兼容開源，擁抱 K8s。用戶無需修改業務代碼，也無需擔心被廠商鎖定，只需在 K8S 集群中安裝組件，就可以針對命名空間或應用開啟治理。八、以服務治理為基石構建可管可控互聯網應用架構

106、 62 微服務治理覆蓋了微服務開發、測試到運行的整個生命周期，提供了數十種功能。技術同學無需再花費大量精力自己實現相關功能，幫助開發測試提效 50%，微服落地周期降低 30%。3.利用 MSE 落地微服務最佳實踐 生產環境的絕大多數故障來自于變更發布，阿里提出的安全生產三板斧包括可灰度、可觀測、可回滾，首要是可灰度。在微服務數量眾多的情況下，如果為每一個新版本都構建一套獨立的灰度環境，需要付出巨大的運維成本和資源成本。而現在，通過 MSE 的全鏈路灰度能力，只用部署一套穩定的基線環境，再針對有新版本的服務，額外部署對應的實例節點并進行打標，同時對灰度流量進行特征規則設置?；叶攘髁拷浻稍圃W關

107、可以動態路由至對應版本的實例節點，并向下傳遞。如果沒有新版本，則選擇基線環境，再往后傳遞，最終形成了一條一條邏輯隔離的流量泳道。該方案支持了多種網關，SpringCloud、Dubbo 微服務框架，以及 RocketMQ 和數據庫組件，用戶能夠快速低成本地驗證自己的新版本，消除 80%以上的變更風險。來電科技使用 MSE 構建了全鏈路灰度能力，大幅提高了發布效率和穩定性，降低了運維成本。八、以服務治理為基石構建可管可控互聯網應用架構 63 除了線上灰度發布，流量治理也可以拓展至開發環境隔離的場景。在微服務開發環節，feature 變更點可能分散在不同的微服務應用，涉及不同的開發團隊，多個fea

108、ture 可能同時進行開發測試，所以需要非常好地進行協同，又不互相干擾。最簡單的辦法是為每個 feature 提供一套獨立的物理資源，但成本過高。與全鏈路灰度發布同理，在開發測試環境中只用部署一套穩定的基線環境，再單獨部署各 feature 需要改動的應用。通過打標及流量特征設置，讓不同流量能夠在不同 feature 環境和基線環境中正確地流轉。對于開發人員而言，這與獨立環境的效果相差無幾。致景科技正是利用云原生網關和微服務治理構建開發測試環境，將構建周期從天級降至分鐘級，開發測試的資源使用量降低 80%，實現了其數智化綜合服務平臺的快速迭代。穩定性治理方面，MSE 覆蓋了從云原生網關到應用層

109、、緩存、數據庫以及第三方依賴的全方位高可用防護。比如通過服務預熱以及無損上線，對于新啟動的應用節點，可以實現流量漸進遞增，避免了應用在啟動時因為來不及初始化被大流量擊垮。通過無損下線的主動通知能力，使得服務提供方停止時不會再被調用，防止流量受損。在大流量場景下，通過網關層的粗粒度規則設置以及應用層接口級細粒度的防護規則，可以進行整體的流量防護。對于慢 SQL 以及不穩定的第三方應用，可以快速識別隔離，避免 DB 連接池打滿、線程資源無法釋放等各種問題。八、以服務治理為基石構建可管可控互聯網應用架構 64 萬師傅和云貨優選使用 MSE 的無損上下線以及流量防護能力，實現了應用發布以及擴縮容時流量

110、無損，大促業務高峰期保證系統的穩定性。零信任安全也是現在企業越發關注的問題。MSE 在原生網關入口層面，支持了從入口以及出口后端的 TLS 雙向認證。在認證鑒權上，除了 JWT、OIDC 等標準認證服務，也支持用戶自定義鑒權，且集成了 IDaaS，可支持第三方認證機制。對于惡意流量，云原生網關集成了阿里云 web 應用防火墻，可以實現路由級別細粒度的安全防護。通過插件市場，可以選用數十種安全插件或自定義插件進行能力擴展。在應用層，用戶可以在微服務治理中心配置服務間的調用策略，進一步降低應用內部的安全風險。注冊配置中心支持 RAM 鑒權以及基于 KMS 的配置加密，可以防止應用實例信息、配置信息

111、等敏感數據被惡意篡改和訪問。4.擁抱開源、貢獻開源 MSE產品全面擁抱開源，近期重磅發布了兩個開源新項目OpernSergo和Higress。在微服務治理領域，各家企業更多的是在落地解決一個又一個的問題，而最終能夠實現的能力和邊界，業界并沒有統一的標準，這也使得開發人員在溝通和理解上存在一定的成本。而且，微服務領域存在很多組件以及開源框架，不同框架的配置和規則下發邏輯不兼容，導致各種組件和框架無法進行統一治理和協調。八、以服務治理為基石構建可管可控互聯網應用架構 65 OpenSergo 旨在提供一套開放通用、面向云原生服務、覆蓋微服務上下游組件的治理標準與實現。在控制面，用戶可以通過 CRD

112、 方式查詢更新服務治理的配置，并下發管控規則至數據面。OpenSergo Spec規定了控制面和數據面的通信約定，確保用戶使用一種Spec即可描述不同框架、不同協議、不同語言的微服務架構。在數據面，無論用戶是通過SDK、Java agent還是Sidecar的方式接入OpenSergo，都可以正確接收到控制面下發的治理規則，進而應用在自己的業務流量中，最終實現異構微服務之間的相互通信以及統一治理。阿里已經聯合了字節、B 站等多家企業、多個社區一起合作，共同建立開放標準，計劃覆蓋網關、服務框架、消息、數據庫、緩存等更多開源組件。我們也歡迎更多微服務領域的開源方加入我們，豐富 OpenSergo

113、的覆蓋范圍，幫助更多企業落地微服治理。八、以服務治理為基石構建可管可控互聯網應用架構 66 本次云棲大會也重磅開源了云原生網關 Higress。Higress 從阿里內部孵化、開發，到電商交易等核心場景進行大規模生產驗證，到MSE 進行商業化，至今已有兩年半的歷程。Higress 以開源 Istio 和 Envoy 為核心，除了兼容 K8s ingress，也遵循了社區正在推進的新一代 Gateway API，可以通過K8S CRD 方式管理實例的生命周期，進行規則以及策略的配置和更新，也支持OpenKruise Roolout 灰度發布。Higress 將流量網關+微服務網關+安全網關三合一

114、，能夠極大的降低網關的部署及運維成本。通過支持開源注冊中心，限流降級，以及監控組件，它可以統一訂閱廣泛的服務來源，并提供完善的大流量防護和可觀測能力。Higress 的插件市場，提供豐富的默認插件，包括 WAF 防護、認證鑒權、協議轉換等，方便用戶在安全、服務管理等方面進行擴展。除了 Wasm、Lua 插件，它還將支持進程外插件擴展機制，讓用戶可以用自己熟悉的語言編寫插件。很多開源網關做配置變更，需要 reload 引起流量抖動。Higress 的路由、安全規則，WASM 插件都支持熱更新，規則變更毫秒級生效且業務無感知。上述所有特點均經過生產驗證，讓 Higress 有了很好的起點。也歡迎感

115、興趣的小伙伴加入我們，一起將 Higress 不斷迭代演進。最后，也希望通過 MSE 產品的持續演進，微服務開源項目的社區共建，以及用戶們的支持和參與，將互聯網應用架構推向新的階段。九、禾連云原生微服務治理實踐 67 九、禾連云原生微服務治理實踐 作者：鄧志豪，禾連健康 CTO 禾連健康成立于 2014 年，是一家從體檢場景切入的健康管理服務公司。對于醫院，我們提供的是圍繞體檢檢前、檢中、檢后的一套 SaaS 服務；對于企業，我們提供了團體體檢、健康管理，國家電網、普華永道都是我們的客戶；對于家庭，我們提供的是健康管理 APP。我們需要打通醫院內 IT，連接醫院內 IT 到禾連云端服務，再到用

116、戶端，過程中需要面對復雜的醫學領域邏輯。另外，對于大多數人而言，體檢的頻率至多一年 1-2 次，是非常低頻的場景，因此流量也非常低。而低流量帶來的問題在于，灰度發布對于我們幾乎無效，甚至全量發布都可能無法發現 bug，有些 bug 會在代碼發布一年以后才被發現。另外，低容錯也是我們的業務特點。比如用戶到醫院體檢，由于 IT 設施信息沒有同步導致無法完成預約的項目，會對用戶體驗造成極大的影響。同時，醫院內部 IT 非常脆弱，通常軟件質量比較低下。九、禾連云原生微服務治理實踐 68 因此，我們首先要解決復雜邏輯的問題，必須做模塊化塊、做解耦。如果只做業務解耦，則實現模塊化便足夠。比如如果使用的是

117、Java 語言，將 Java 模塊分為 jar 包，用 Maven 管理不同依賴即可。但是早期很多技術架構是通過單一的包支撐不同業務，業務模塊多，業務不隔離。沒有做微服務拆分時，可能會出現企業業務代碼有問題，導致醫院容錯較低的業務崩潰，這對業務來說難以接受。因此，我們直接實現了服務化，將服務拆分開，有公共的基礎服務可以調用，不同業務之間不會互相影響。服務化不僅實現了業務解耦，也實現了服務分層，保障履約的核心服務。比如針對容錯率非常低的業務可以構建專門針對問題場景的保障服務。同時可以對服務做獨立質檢，而如果打包在一起則無法做獨立的質檢。服務拆分主要有兩種模式，一種為按照業務拆分，一種為按照能力拆

118、分，不同業務可以互相調用。最終，我們的架構如上圖所示。以按照能力拆分為主，按照業務拆分為輔。比如最前端是 web 服務，藍色塊是業務核心迭代的業務服務，底層按照能力拆分訂單、支付、消息三種服務。往下一層與業務較遠的比如醫院數據同步服務、人工履約服務，是自建的獨立服務。業務迭代最頻繁的服務與相對穩定的服務各自區分獨立，兩邊通過 http 打通。業務集群內使用 Dubbo、Nacos 做 RPC，使用 RocketMQ 做消息。九、禾連云原生微服務治理實踐 69 Dubbo 是一個 RPC 框架，基于 Java Interface。對于 Java 程序員而言，只需加簡單的注解即可成為微服務，便于在

119、團隊中推行。同時，調用幾乎不侵入代碼，將service 改為dubboReference 即可注入服務。Nacos 在 SpringCloud 的集成非常完善，只需幾行配置即可使用?？刂泼姘搴唵我子?，與 Dubbo 一樣均為中文社區，對于程序員的門檻更低。早期禾連自行搭建社區版 Nacos 曾遇到較大性能瓶頸，當時的 Dubbo2 服務模型基于接口，一個接口、一個函數就會帶來一個服務，流量非常大。因此，我們最終選擇了阿里云 MSE 服務，扛住了 Dubbo 的壓力，而且它具有良好的兼容性，后續我們跟隨社區遷移至 Dubbo3，解決了 Dubbo2 服務模型的問題。一個 service 可以作為

120、一個服務，一個應用可以作為一個服務，使得注冊流量大幅減少，Nacos 注冊中心的壓力減小。另外，MSE 免運維以及阿里云持續的服務支持，為我們帶來極佳的使用體驗。從內存視角看，MSE 具有出色的調優能力，使業務性能提升 4 倍。九、禾連云原生微服務治理實踐 70 微服務治理中，服務觀測尤為重要。目前，我們使用的是阿里云的 ARMS 商業版。MSE 特性開關是 Nacos 的功能，可以做動態配置，無需重啟應用。我們需要面對大量醫院，每個醫院的需求不確定也不盡相同，因此會存在大量特性開關。此類開關的操作非常危險，一般由開發人員進行配置，而 MSE 很好地解決了我們的痛點。同時，MSE 可以一鍵與

121、KMS 阿里云密鑰管理服務相結合，對數據進行加密存儲但是用戶無感知。HTTP 網關主要解決協議轉換的問題。禾連的 App 前端業務邏輯重，無需做任何結果封裝，只要暴露服務能力即可。因此，我們基于開源的 Apache ShenYu 做了改造，將 HTTP 協議轉為 Dubbo，同時支持 POST/GET，將鑒權和授權邏輯都放至網關。DevOps 方面，K8S+鏡像發布回滾使用了 ACK，持續集成使用了云效 CI，為我們帶來了極高的發布效率，一周最多時可能發布 20-30 次，單次發布時間從原先的 2-3小時降低至 8 分鐘內。另外，我們基于 Dubbo 做了服務隔離。比如同一個服務可以部署兩個版

122、本，代碼和使用方式均一致，但實例不同。兩個服務均有獨立內存，一個服務故障時，不會影響到另外一個相同的服務。該能力目前依然較弱，控制面能力的增強是我們未來的發展方向。九、禾連云原生微服務治理實踐 71 未來，我們希望能夠實現 Service Mesh 的控制面。如上圖所示，比如服務請求到達時，如果是req*，則希望它路由至特殊版本ServiceA*。請求經過 MQ 之后發出的消息不能被 Service 消息接收，而是應被 Service*接收，實現全鏈路的路由能力。目前阿里云提供的 Istio 具備以上能力，但尚未能與 Dubbo 很好地結合，我們也十分期待 Istio 未來的演進。實現 Ser

123、viceMesh 的目的是降低測試環境成本。當前，我們的大集群里有 7-8 套測試環境供各個業務小組使用，每個小組各用一套，互不干擾，但成本過高。如果能實現全鏈路的路由，每個開發小組只要做服務的測試環境發布，使用打標流量即可實現發布。另外，我們將實現全量 HTTP 網關。從未來趨勢看，前端越來越重，無需后端做 web層，將后端服務直接暴露給前端即可。因此，我們考慮將所有 web 層替換成網關。我們期待緊密跟進社區的步伐，聯合云原生社區一起向前發展。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 72 十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺

124、 作者：楊秋弟（曼紅），阿里云智能高級產品專家、Apache RocketMQ 聯合創始人 1.前言 回顧 RocketMQ 的發展歷程，至今已十年有余。2022 年 RocketMQ5.0 正式發布，全面邁進云原生時代。11 月 5 日，2022 杭州云棲大會上，阿里云智能高級產品專家楊秋弟在云原生峰會上發表主題演講，發布消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺。阿里云智能高級產品專家&Apache RocketMQ 聯合創始人楊秋弟 2.Apache RocketMQ 發展史 回顧 Apache RocketMQ 過去十年的發展歷程，可分為“誕生于互聯網”與“成長

125、于云計算”兩大階段。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 73 第一個階段是 RocketMQ 的從 0 到 1，在阿里內部規?；涞?。2012 年，為了支撐超大規模電商互聯網架構，阿里中間件研發了 RocketMQ，并在產品誕生初期開源，2017 年 RocketMQ 統一了阿里消息技術體系。第二個階段是云計算。2015 年 RocketMQ 上云，這也是業界首個提供公共云 SaaS形態的開源消息隊列；2016 年，阿里把 RocketMQ 捐贈給 Apache，2017 年孵化畢業，成為國內首個 TLP 的互聯網中間件。十年磨一劍，出鞘必鋒芒。在這十年的過

126、程中，通過集團打磨穩定性，依托云計算孵化創新，開源共建加速標準化建立與生態連接，RocketMQ 始終堅持開源、集團、商業三位一體的發展思路，內核演進和產品迭代齊頭并進。2022 年 RocketMQ5.0正式發布宣告著全面邁進云原生時代。3.RocketMQ5.0：從消息服務到云原生事件流平臺 十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 74 回顧過去這十年，RocketMQ 服務于集團幾乎所有的業務，在阿里云上更是累計服務了 10 萬余家企業客戶，覆蓋互聯網、零售、金融、汽車等 20 多個行業，大規模的生產實踐持續累積產品的核心優勢。多樣性，企業級應用復雜的業務

127、訴求，催生 RocketMQ 提供豐富的消息類型，比如定時消息、事務消息、順序消息等等。此外，也提供了像消息軌跡、消息回溯等一系列的消息治理能力。一致性，無論是淘寶交易還是螞蟻支付都天然對數據一致性有著極高的要求，RocketMQ 提供的分布式事務消息是業內第一個提供該特性的消息產品，將異步解耦與數據一致性完美融合，是金融客戶中不可或缺的產品能力。穩定性，穩定性是產品的根基，更是一個系統工程，RocketMQ 長期在電商和金融領域中打磨，不僅提供最高達 99.99%SLA，更是幫助客戶提供全方位的健康巡檢與故障排查能力，如消息軌跡、消息回溯、死信機制等等，提供多樣化的穩定性兜底手段。高性能，在

128、雙十一的極限流量下，RocketMQ 具備無限擴展能力，支持千萬級并發與萬億級消息洪峰，P9999 寫延遲在 1ms 內，100%在 100ms 內?？梢哉f，在消息領域，尤其在業務消息領域，RocketMQ 在國內已經做到頂尖，成為企業客戶的首選。而隨著云原生以及數字化時代的到來，RocketMQ 也在快速的發生著變化，那么變化主要體現在哪些方面呢？首先，全面擁抱云原生。向下，消息系統自身實現云原生架構的演進，充分釋放云基礎設施的池化能力，全方位提高消息的核心技術指標。向上，消息產品形態持續演進，成為云原生應用架構的核心引擎。比如微服務、事件驅動、Serverless 等現代化應用架構。其次，

129、全面擁抱實時數據。企業的數字化轉型從原來的業務數字化邁向了數字業務化。對業務數據的實時洞察、實時決策成為指導業務成功的關鍵要素。消息隊列也將從在線業務架構的基礎設施，延伸到實時數據架構的基礎設施，從而實現事務分析一體化。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 75 隨著 5.0 的發布，RocketMQ 也正式從消息服務升級到云原生事件流處理平臺。4.RocketMQ5.0：云原生架構升級 首先來看 RocketMQ 自身的云原生架構演進。從下面的全景圖可以看出，RocketMQ從客戶端到服務端都進行了全方位的改造，具體體現在以下幾個方面：輕量化 RocketM

130、Q4.0 誕生于 2012 年的淘寶電商，當時大部分的業務還跑在物理機上，單節點計算能力強，客戶端節點數少且較為穩定，因此，富客戶端的接入方式不僅更加高效，更可以提供諸如客戶端側負載均衡、消息緩存、故障轉移等一系列企業級特性。但這種模式在云原生時代發生了改變，輕量客戶端更容易被云原生技術棧所集成。因此，RocketMQ5.0 客戶端采用輕量 SDK 設計理念，將原來富客戶端的邏輯下沉到服務端，滿足現代化應用輕量化、Serverless 化以及 Mesh 化的趨勢，更容易被集成；同時也正是因為輕量化，使得 SDK 多語言開發成本低了很多，快速覆蓋當下主流的多語言版本。彈性 存算分離架構讓無狀態計

131、算節點可以快速伸縮，而分級存儲以及冷熱分離架構更是讓消息存儲具備更強的彈性能力。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 76 高可用 基于全新的 Leaderless 架構，去 ZK 依賴的同時，可以做到副本數靈活選擇，同步異步自動升降級，實現秒級故障轉移；面向云的多可用區、多地域組建全局高可用能力。云原生基礎設施 最后，RocketMQ 整體架構走向 Kubernetes 化，擁抱 OpenTelemetry，依托于阿里云提供的 ARMS、Prometheus 以及 Grafana 實現可觀測能力的云原生化。而 RocketMQ5.0 本次的升級，除了在技術架

132、構云原生化之外，在產品能力以及成本優化方面都有著重大的提升，我們來逐一分解。輕量無狀態消費模型 RocketMQ4.0 采用按隊列消費模型，消費者完全按照隊列負載均衡，非常適合批量拉取快速消費，對單一消息狀態不敏感的場景，比如流計算。然而在業務消息領域，尤其是金融場景以及事件驅動架構之下，每一條消息狀態都是極為重要的。再加上不同業務類型的消息處理耗時也是各不相同，從毫秒級、到秒級甚至到分鐘級，隊列的負載不均衡或者短暫的 Block 都可能會引發消息的局部堆積，從而影響到最終用戶的體驗。因此，RocketMQ5.0 全新推出按消息負載的輕量無狀態消費模型，通過 PoP 機制巧妙地在隊列模型之上構

133、建了消息模型，業務只需要關心消息而無需關心隊列，所有API 都能夠支持單條消息級別控制，如消息的消費、重試、刪除等。而基于消息消費 十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 77 模型，客戶端、連接和消費都是無狀態的，可在任意 Proxy 節點上飄移，真正做到輕量化。RocketMQ5.0 提供按隊列消費模型以及按消息消費模型，更好的滿足事件與流的業務場景，正可謂魚與熊掌兼得。海量消息分級存儲 RocketMQ5.0 的另一個重大升級則是海量消息的分級存儲。對消息隊列了解的同學都知道，消息通常都是流動的短時間的存儲，業內大部分消息產品對消息的保留時間都比較優先，3

134、 天、7 天，最長 15 天不等。有限的存儲空間使不僅限制了消息的保留時長，更在某些場景下可能會導致業務資損，比如在消息還沒有被消費的時候，因為磁盤空間不足或者消息過期而被清除，這在金融等領域都是不可接受的。所以，RocketMQ 一直想要解決這樣的問題，讓存儲變得更有彈性。RocketMQ5.0 基于 ESSD、對象存儲打造冷熱分離以及分級存儲架構，提供低成本的無限存儲能力，確保消息不會因為本地磁盤空間不足而提前被清除，造成業務資損。我們提供消息存儲的 Serverless，客戶只需按實際存儲使用量付費，而無需預購存儲空間。此外，流量削峰是消息隊列極為常見的場景，而由此帶來的海量消息堆積能力

135、以及在堆積情況下的性能穩定性成為衡量產品性能的核心指標。RocketMQ5.0 基于冷熱數據分離架構進一步做到讀寫隔離，避免在堆積的場景下影響熱數據的寫入性能。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 78 分級存儲的冷數據碎片規整能力更是提高了冷數據的讀取性能，為用戶提供一致的冷讀 SLA。售賣系列全線升級，最高降本 50%從前面的介紹我們已經了解到，RocketMQ5.0 在技術架構以及產品能力上都有著明顯提升。而 5.0 推出全新的售賣形態與計費策略相比 4.0 更簡單、更靈活也更為普惠。實例的綜合成本最高可降低 50%。接入門檻最低可降至 390 元/月，

136、遠低于自建成本。消息存儲支持 Serverless 彈性能力，按需付費可大幅降低閑置成本。結合冷熱分離的多級存儲能力，相比開源自建可降低 67%，大幅降低消息隊列的使用成本。5.EventBridge：云上事件樞紐 十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 79 事件驅動是一個起源很早的概念，早在幾十年前，無論是操作系統內核的設計、還是客戶端編程框架都大量采用了事件驅動技術。RocketMQ PushConsumer 提供的API 其實就是一種事件驅動的編程范式，但在微服務應用架構當中，集成與通信才是剛需，事件驅動的價值并沒有那么明顯的體現。而隨著云原生時代的到來

137、，計算力的構成越來越多樣化。作為云原生的代表技術，Serverless 架構范式也是事件驅動的。無論是阿里云的函數計算、還是 AWS 的Lambda，它們的主要觸發源都是各種形態的事件，云產品事件，如 OSS 文件上傳觸發用戶基于函數進行文件加工處理；用戶業務事件，如 RocketMQ 觸發函數運行消費邏輯處理等等。以事件驅動為核心理念，阿里云推出了 EventBridge 產品，其使命就是打造云上的事件樞紐。通過 EventBridge 可以兌現四大業務價值：統一事件樞紐。阿里云從 IaaS、PaaS 到第三方的 SaaS，每天都有數以億計的事件產生，但卻沒有一種簡單和統一的方式來觸達這些事

138、件；這些事件散落在各個地方形成 事件孤島，很難挖掘出有用的業務價值。只有充分發揮數據的規模效應，建立起數據之間的血緣關系，我們才能更好的發掘出數據的價值；所以 EventBridge 首要任務便是統一阿里云上的事件規范，擁抱 CloudEvents 事件標準，打造阿里云統一的事件樞紐。事件驅動引擎。當 EventBridge 連接了海量的事件源后，基于 RocketMQ 毫秒級的事件觸發能力，必將加速企業 EDA/Serverless 的架構升級。開放與集成。EventBridge 提供豐富的跨云、跨平臺、跨產品、跨地域以及跨賬號的連接能力，能夠促進云產品、應用程序、SaaS 服務的相互集成。

139、低代碼。EventBridge 借助 Serverless 的應用中心，通過簡單的規則匹配以及豐富的模板，即可實現事件的分發、過濾、轉換等處理，進一步提升事件驅動的效率。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 80 6.讓消息無處不在，讓事件無所不及 依托于 EventBridge、RocketMQ 以及函數計算 FC 的強強聯合，目前 EventBridge的事件生態已初具規模。在云產品事件集成方面，目前已經集成 200+云產品事件源，3000 多種事件類型。在數據集成與處理方面，EventBridge 與微服務應用、大數據、IoT 等場景深度集成。比如與消息

140、生態的融合，阿里云 6 款消息隊列產品通過 EventBridge 實現消息數據的互聯互通，并且通過 EventBridge 的全球事件網絡賦予消息全球消息路由的能力，同時也可以通過 EventBridge 提供的豐富的模板，實現 ETL 數據處理能力。在 SaaS 應用集成方面，包括釘釘、聚石塔以及云上 50 多個 SaaS 服務都可以通過EventBridgehook 方式連接到 EventBridge。在事件觸發方面，EventBridge 目前已經觸達 10 多個事件目標，海量的事件源都可以通過 EventBridge 觸發包括 FC/SAE 等在內的 10 多款事件目標云產品。除此之

141、外，目前 EventBridge 已經對接了阿里云全量的云產品 API，任何一個事件都可以通過云產品 API 的方式進行觸達。未來還有會更多的事件源以及事件目標接入到 EventBridge 上來。十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 81 7.RocketMQ Streams：輕量級計算的新選擇 正如開篇所提到的，基于云原生架構的全面升級，RocketMQ5.0 也將從在線業務架構的基礎設施，延伸到實時數據架構的基礎設施，實現事務分析一體化。將RocketMQ Streams 打造成為輕量級計算的新選擇。業內最常見如 Flink、Spark 等大數據框架大多

142、采用中心化的 Master-Slave 架構，依賴和部署比較重，每個任務的執行都需要很大的開銷，有較高的使用成本。而與之不同的是，RocketMQ Streams 著重打造輕資源，高性能的輕量計算引擎，無額外依賴，最低 1core，1g 即可完成部署，適用于大數據量、高過濾、輕窗口計算的場景，在資源敏感型場景，如消息隊列流計算、安全風控，邊緣計算等，RocketMQ Streams 具有有很大優勢。阿里云消息團隊與安全團隊合作，通過對過濾場景做大量優化，性能提升 3-5 倍，資源節省 50%-80%。目前，RocketMQ Streams 已經在開源社區發布，未來計劃在 2023 年 4 月在

143、阿里云完成商業化。8.RocketMQ 這十年，我們一同向前 十、消息隊列 RocketMQ5.0：從消息服務到云原生事件流處理平臺 82 RocketMQ 歷經十余年的打磨，已經取得了眾多成果。全球擁有 700+的貢獻者，1.8w Star 數，超過 80%的主流云廠商提供了 RocketMQ 的商業托管服務，Apache RocketMQ 社區始終保持著極高的活躍度，因此，也榮獲了科創中國“開源創新榜”，中日韓開源軟件優秀技術獎等十多個國內外開源獎項。而阿里云作為 RocketMQ 的起源和核心貢獻者，不僅 100%覆蓋全集團業務，承載千萬級并發萬億級消息洪峰。十多年以來更是累計服務 10

144、w+萬企業客戶，覆蓋互聯網、零售、汽車等 20 多個行業，超過 75%的頭部企業選擇使用 RocketMQ。期望阿里云的消息隊列 RocketMQ 可以成為廣大企業客戶的心之所選。也誠邀更廣大的開發者來積極參與 RocketMQ 的開源社區建設，一起將 RocketMQ 打造為消息領域的引領者。十一、云原生技術中臺 CNStack2.0 正式發布 助力企業高效用云 83 十一、云原生技術中臺 CNStack2.0 正式發布 助力企業高效用云 作者：謝吉寶（唐三），阿里云智能資深技術專家 11 月 5 日，在 2022 杭州云棲大會上，云原生技術中臺 CNStack2.0 正式發布。阿里巴巴資深

145、技術專家謝吉寶介紹 CNStack2.0 企業在數字化轉型的過程中，一部分問題得到了解決，但隨著 IT 水平的不斷提升，新問題也在逐漸顯現。業務系統越加復雜，所需的計算、存儲和網絡設施也變得越來越難以管理。以往一臺虛擬機、一個數據庫便能部署應用的時代已經一去不復返了。復雜的系統架構需要更多基礎軟件的支持才能良好運行，而開源社區的蓬勃發展，雖然為決策者提供了更多選擇的可能性，但從選型開始問題就接踵而至。交付、運維、故障處理和選型后維護，所有這些都與業務價值無關，但又必不可少，基礎軟件出現問題對上層業務系統來說將是致命的，而這對于缺少豐富生產經驗的運維人員來說，更是雪上加霜。十一、云原生技術中臺

146、CNStack2.0 正式發布 助力企業高效用云 84 隨著云原生技術的深入發展和行業解決方案的不斷落地，企業越來越希望看到這樣一種平臺，依托云原生技術能力，不但可以支撐大規模業務系統的發布與運行，也可以將內部各種復雜、零散、不統一和不標準的軟硬件體系給集中管理起來，以中臺化的運作方式，向企業內部源源不斷的輸出經過實踐檢驗的成熟技術能力與標準體系，推動企業數字化建設向著更高效的方向發展。在這樣一個趨勢背景下，云原生技術中臺 CNStack 隆重發布了其具有革新意義的新一代 2.0 版本。接下來我們將從幾個企業數字化轉型遇到的常見困難開始，向大家逐一介紹CNStack2.0 所具備的突破性能力，

147、以及能給企業帶來哪些核心價值。1.異構資源管理困難 大部分企業已經從“建好云”的階段過渡到了“用好云”，不管是共有云還是私有云，用云和上云的理念已經深入人心。但云平臺的種類和數量都在不斷增加，尤其是基礎設施部分，這就如同 PC 時代的主機硬件，需要有更通用的操作系統加以屏蔽和提升，否則面對形形色色的 IaaS 基礎設施，管理、運維和適配都將是重復且效率低下的工作?？缭?、混合云和分布式云早已從理論步入生產，對異構資源的管理能力也需要更上一層樓。在某些局點的實踐中，我們發現客戶現場有存在多家云廠商的平臺，且都 十一、云原生技術中臺 CNStack2.0 正式發布 助力企業高效用云 85 分布在不同

148、機房中，單開通資源這一項操作，就需要經歷繁瑣的申請過程，更不必說對整個環境體系的維護了。CNStack2.0 面向基礎設施提供了云原生化的管理手段，可以對不同廠商、不同架構（x86/ARM）、不同計算類型（CPU/GPU）和不同地域（公有云/本地云/邊緣云）的資源進行管理。多集群納管可以將分散的基礎設施統一納管到平臺下，并能進行跨集群的資源分配、統一調度和集中運維，極大降低了異構基礎設施的管理難度。不僅如此，CNStack 在項目實踐中可以管控上千節點或上萬核規模的集群資源，特別適用于零售和互聯網行業等對于大規模、高并發和低成本管控的要求。而且在超融合及混部等能力的加持下，系統資源利用率可以由

149、通常水平的 6%12%，提升到45%。2.系統軟件選型與維護困難 一個平臺如果只能解決資源問題，其實還無法為業務提供可用的環境，因為在資源之上還存在各種系統軟件，對這些系統軟件進行技術選型并解決選型后的持續維護問題，也是平臺必須要解決的?，F如今，開源技術在軟件領域有著舉足輕重的地位，單 CNCF 下注冊的項目就已經超過了 140 個，是否使用開源技術已經成為了評估軟件標準化和開放性的必要條件之一。但問題是，這么多開源項目，該如何進行技術選型？哪些項目能滿足需要？哪些版本能用于生產？哪些技術經歷過大規模實戰？這些都是技術選型需要考慮的問題。與此同時，對技術選型的持續維護也同樣重要。版本迭代、技術

150、革新，每次都需要投入新的人力、物力和財力才能跟得上開源社區的快速發展，否則就會面臨版本生命周期終結、功能落后和性能低下等問題，更有甚者會遺留嚴重的安全風險，這些都是數字化決策者所不得不考慮的問題。CNStack2.0 可以從兩個方面來解決技術選型時遇到的問題。首先，平臺提供了很多內置的、開箱即用的產品組件和中間件，正是這些內置組件所提供的能力才使我們所倡導的“讓企業數字創新只需專注業務本身”變為可能。十一、云原生技術中臺 CNStack2.0 正式發布 助力企業高效用云 86 這些內置組件從資源管理到應用管理，從服務管理到流量管理，從可觀測到可運維，從平臺穩定性到數字化安全生產滲透到了平臺和業

151、務系統的方方面面。如果想要通過開源產品搭建具備同等能力的技術中臺，其投入將是無比巨大的。CNStack 背靠阿里云云原生團隊，其所提供的中間件產品無論在功能、性能、規模還是可靠性方面都是有目共睹的，且經歷過非常多的生產實踐檢驗，能默默地為業務系統保駕護航。另外，在能力中心里，CNStack 還精選了各種原廠和伙伴提供的產品及組件，當內置功能不足以滿足業務需要的時候可以在此進行無限擴展，并享受平臺提供的一致化產品體驗。3.多環境交付困難 基于云原生技術的 PaaS 平臺是近年來管理 IaaS 的首選方案。從開源到商業化，企業總能找到滿足業務需要的解決方案，但也不是全然沒有問題。比如，既往的工作模

152、式和管理規范都是建立在非云原生的基礎設施之上，簡言之，就是以物理機或虛擬機為單元進行資源管理的。那個時候環境的申請幾乎等同于準備主機節點，但這并不意味著一個環境處于可用狀態，最終使用者還需要在上面部署很多系統軟件和基礎組件，這些軟件系統的重復部署，不僅浪費人力和時間，后續維護也是一筆持續的開銷，更不利于環境的復用、開支的節省和標準的建立，整體成本非常之高。當開發和測試等工作涉及多個系統和集成商的時候，環境獲取成本將成倍增長，甚至失控。CNStack2.0 的環境交付是基于容器來實現的。在系統建設之初，交付人員將基礎設施資源整合成資源池（即容器集群），之后資源的申請便等同于在集群中劃分配額。這些

153、被分配的配額僅用于部署實際業務系統即可，系統軟件的交付則是通過能力中心來完成。能力中心里分發的產品與組件是開箱即用的，平臺管理員只需輕點鼠標即可實現全自動的安裝與部署，交付即可用。能力中心分發的是組件能力，不再是資源本身，完全有可能在企業內部復用這些能力，并依此建立完善的基礎軟件使用標準。在實踐中，資源分配和能力供給是有嚴格權限隔離的，完全適用于多地域、多組織和多項目的企業級管理模式。環境搭建周期從月變為天或小時，而且使用能力中心交付的組件會天然具備平臺級的運維能力，不但能夠提升環境搭建的效率，長期運維的成本也會一降再降。十一、云原生技術中臺 CNStack2.0 正式發布 助力企業高效用云

154、87 4.生產運維困難 環境交付和應用部署都是一次性投入，而環境自身和其上業務系統的運維卻是需要持續投入的。對大多數的運維人員來說，由于缺乏大規模訪問下的生產運維經驗，在突發狀況時想做到系統的平穩運行是非常困難的，這往往不僅需要難得的實踐經驗，更需要專業工具或產品能力的支持。即便在正常情況下，想要確保系統穩定也是看似簡單，實則困難的目標。倘若沒有平臺的支持，運維人員將無法預知問題的產生，產生問題時也無法做到及時止血或快速定位，最后迅速恢復和平穩升級才能讓系統回歸到往日的正常狀態。所有這些遠非“一個有經驗的運維人員”所能輕易做到的。但依托 CNStack2.0 的產品能力，保障線上系統的穩定運行

155、只需要一個普通運維人員即可，這全都依靠了平臺提供的一站式應用管理能力。復雜的業務系統催生了應用形態的多樣化，微服務應用、多語言應用、批處理或定時任務應用、AI 應用和大數據應用等，所有這些在完成上線之后都需要針對性的運維和管理能力。CNStack 提供了完備的圖形化運維控制臺，不出平臺即可完成 80%的運維工作。同時，應用系統在發布態和運行態的穩定性也是由平臺來自動保障的，運維人員僅需對規則進行配置，CNStack 的諸多特色能力，就可以讓發布如絲般順滑，讓系統在突發狀況時也能平穩度過并發出告警。最后，在應用故障逃脫平臺的管控能力之后，系統提供的各種輔助工具和產品能力，也可以幫助運維團隊精準定

156、位故障，快速恢復系統，為研發部門介入修復贏得寶貴時間。5.總結 誠然，在云原生運動的驅使下，將會有越來越多的企業嘗試擁抱這項技術，以新的理念、新的架構和新的能力為業務注入新的活力，在這期間既往的平臺解決了一些問題，又產生了一些問題，在不斷的更新迭代中，加速釋放創新的力量。CNStack2.0 讓企業以最低的成本和門檻享受來自技術革新的發展紅利，而在遇到種種必然的困難阻礙時，也能提供強有力的支撐手段，終究能以更開放、更全面和更輕量的形態為客戶打造更具競爭力的云原生技術中臺產品，進而服務企業數字化轉型步入下一個階段。十二、數字化安全生產平臺 DPS 重磅發布 88 十二、數字化安全生產平臺 DPS

157、 重磅發布 作者：周洋，阿里云智能資深技術專家、高可用架構負責人 11 月 5 日，在 2022 杭州云棲大會上，數字化安全生產平臺 DPS 重磅發布，助力傳統運維向 SRE 轉型。阿里巴巴資深技術專家周洋 十四五規劃下，各行各業全面加速數字化轉型與升級。隨著企業數字化業務規模變大，迭代速度加快，系統復雜度越來越高，如何保障業務穩定性這一話題也變得愈發重要。下述有幾點典型場景和挑戰：場景一：分布式系統面臨穩定性保障新挑戰 近年來，雖然穩定性關注度日益提高，新技術蓬勃發展，重大故障依然頻發且影響巨大。例如，2021 年，某證券 IDC 故障 2 小時，導致客戶無法交易，產生資損；某視頻網站，服務

158、器故障 3 小時無法訪問，引發輿論技術的不恰當使用、人為操作失誤、硬件故障、自然災害、安全攻擊依然給生產帶來極大風險。十二、數字化安全生產平臺 DPS 重磅發布 89 場景二：政策引導 IT 系統穩定性建設平穩推進 隨著數字化轉型政策的推進，越來越多國民級應用誕生，大大方便了人們的日常生活，各個企業也相繼推出自己的客戶端。然而，大多數企業沒有經歷過多年互聯網發展的錘煉，應對線上風險能力不足，亟需以最短時間完成穩定性運維能力的積累，少走彎路。場景三：傳統運維手段已無法滿足要求 傳統運維存在運維工具割裂、面向基礎設施而非業務、被動運維、缺乏規范化的流程機制體系等問題。企業應遵循 SRE（Site

159、Reliability Engineering）和平臺運維（Platform Ops）的創新理念，通過軟件來實現系統管理、問題發現、問題解決和自動化運維工作。在現實生活中，無論建造摩天大樓還是家庭工程維護，在保證工程質量的同時，更重要的是避免出現安全事故，造成人員傷害，因此需要一套標準化的工藝流程、技術標準和驗收手段等。在軟件行業中，同樣需要標準化的技術能力和方法論，來保障線上業務穩定性。于是，從 2018 年起，阿里巴巴集團便致力于 IT 軟件領域的安全生產建設：一方面加強高可用架構的基礎建設，另一方面，提供 SRE 轉型的流程機制體系，配合可用性能力、組織能力和災難恢復能力等目標，形成一套

160、完整的安全生產方法體系。為此，數字化安全生產平臺（DPS）應勢而生。DPS 濃縮了阿里巴巴十年運維經驗，以 PlatformOps 為理念，以保障業務連續性為目標的一站式管控 SRE 運維平臺，具備場景化、數字化和云原生化三大典型特征。場景化：DPS 以應急場景為中心，弱化組織架構帶來的運維限制，同時，DPS 全面的監控和告警規則配置可以支持涵蓋業務的各個場景。數字化：DPS 提供數字化監控大屏、智能化告警、智能故障定位、白屏化故障快恢手段和數字化度量、人員管理等能力，為企業數字化進程添磚加瓦。云原生化：DPS 以阿里云豐富的云原生產品作為技術支撐，且具備足夠的開放性，可以與阿里云一方、二方和

161、開源系統等進行關聯。十二、數字化安全生產平臺 DPS 重磅發布 90 數字化安全生產平臺（DPS）作為阿里巴巴集團數十年互聯網探索的沉淀，在平臺的架構和演進方面主要關注以下幾點：明確目標和場景：安全生產是全局工程，其能力取決于木桶最短板。因此安全生產需要有明確的目標和場景，且保證主體框架的完整。打通組織架構：安全生產不僅要解決人和系統、代碼的問題，還需要解決人和人、人和制度的問題。因此安全生產需要阿里和行業的優秀技術在一個體系內集成和打通。面向未來架構：安全生產同時關注成本和減少損失。因此，安全生產需具有一定的抗技術周期性，架構設計除了要兼容最新的技術棧，也要面向未來架構進行設計。數字化安全生

162、產 DPS 支持兩大典型業務場景：“1-5-10”故障快恢和“變更三板斧”故障預防。1.“1-5-10”故障快恢 數字化安全生產平臺提供對應急事件和故障的發現、響應和恢復的全生命周期管理?！?-5-10”對應故障的“1 分鐘發現-5 分鐘響應-10 分鐘恢復”，是定義故障處理的時效性目標。十二、數字化安全生產平臺 DPS 重磅發布 91 1 分鐘發現：通過建立圍繞業務應用的全鏈路監控能力，能夠實時監控業務健康度，如發現穩定性問題將秒級通報至應急保障服務組進行排查，降低故障發生的可能性。5 分鐘響應：通過建立應急響應渠道和全鏈路故障定位能力，能夠快速拉通故障排查人員，基于 AIOps 智能故障定

163、位和基于 ChatOps 進行故障狀態更新和通知流轉，提升故障處理效率。10 分鐘恢復：通過建立完善的故障快恢體系，基于方案內置豐富的快恢能力，能夠根據不同的故障類型智能化推薦合適的快恢預案，縮短故障恢復時長。2.“變更三板斧”故障預防 數字化安全生產平臺 DPS 將極易引發線上故障的變更操作納入穩定性管控體系，做到對變更操作的“可觀測、可灰度、可回滾”。在“變更可管”方面，我們覆蓋完善的變更系統，極大程度減少對變更系統的改造成本；在“變更可控”方面，我們提供基于時間、人員等維度的變更管控規則，預防可能出現的風險；在“變更可用”方面，我們可自動發現變更引發的故障，提供變更回滾等智能化快恢能力。十二、數字化安全生產平臺 DPS 重磅發布 92