2024/

目錄01 茶百道 奶茶上云，原生的更好喝 04作者：伯衡、望宸OUD

NATIVE02 Rokid 當

Rokid

遇上函數計算 14作者：王彬、姚蘭天、聶大鵬ALIBABA

CL03 極氪 ARMS

助力極氪提效服務應急響應，為安全出行保駕護航 21作者：比揚04 創米數聯 支撐

“千萬設備日活”

的創米數聯

7

年微服務架構演進之路 30作者：金兆旭、十眠05 美洽 對比

5

個開源網關項目，這家

SaaS

企業如何統一網關架構 36作者：古建國06 高德 阿里云函數計算

FC

助力高德

RTA

廣告投放系統架構升級 42作者：趙慶杰、林雪清、杜玲玲、王壁成07 Tim

Hortons 輕松構建全棧觀測，從容應對咖啡產業競爭 50作者：郭皛璠08 杭州亞運 高光回眸：阿里云容器服務如何全面助力精彩亞運 56作者：劉佳旭

謝乘勝

賢維ES09 阿里影業 容災切換時間減少

99%，“云邊協同”如何提升影演服務效率與穩定性 61作者：神蠶、鶴劼CASE

STUDI10 TCL TCL

擁抱云原生，實現

IT

成本治理優化 69作者：行疾54茶百道云原生十大經典案例奶茶上云，原生的更好喝一年賣出

8

億杯，考驗的不僅是奶茶的品牌、口感和性價比，還得有一套打通線上和線下、連接上下游供應鏈、以保障絲滑購買體驗的數字化系統。茶百道成立于

2008

年，起初，茶百道堅持一步一個腳印，用了

8

年時間門店數量也只有100

家。轉折點發生在

2018

年，在這一年，茶百道正式開放全國性加盟，準備用規模來換市場。2020

到

2022

三年期間，營收和凈利潤都增長了

4

倍有余。這三年，也是茶百道數字化系統成功云原生化的演進歷程。茶百道的愿景之一是以好茶為始，持續探索天然食材與茶的搭配，呈現茶飲更多可能。然而，新式茶飲強調手作與新鮮，其產品往往需要多重工序，導致制作流程變得更加復雜，人員成本也隨之大幅上漲。為此，茶百道投資建立了

OMS、WMS

和

TMS

一體的供應鏈信息化、自動化技術系統，實現了庫存、訂單、運輸資源、到店服務等全鏈路數字化轉型。在提高運送質量的同時，做到信息留存可追溯，完善品牌自檢自查和監管部門監管渠道，數字化“護送”食材的出貨、送貨、到貨全流程。但是供應鏈信息化、自動化技術系統背后的基礎架構，并不是茶百道所擅長的。為了提升整體競爭效率，茶百道希望通過云原生，對從上游原材料供應商到終端門店的整套供應鏈體系進行再升級。升級前，茶百道面向

B

端的供應鏈中心和面向

C

端的運營中心，均部署在自建的

K8s

集群上，存在不小的局限性，例如在運維復雜度、穩定性、成本控制等方面，已不能滿足日益增長的業務發展需求。茶百道決定將自建

K8s

集群遷移到

ACK

+

ECI，ACK

具備強大的集群管理，包括集群創建、集群升級、多集群管理、授權管理等能力，提升了集群管理效率；ECI

可根據業務需求，實現自動擴容，30s

即可擴容

3000

Pod，提升閑置資源利用率，算力成本下降

50%；通過

ACK，茶百道有效降低了在節點、集群、應用上的日常維護、安全防護等方面的投入，全面提升供應鏈體系和運營中心的運營效率。01 茶百道早期的

IT

業務系統由外部

SaaS

服務商提供，在滿足業務擴張過程出現的新的業務需求，顯得捉襟見肘。例如：需要在原有的會員、訂單、營銷三中心上，開發更多的業務功能，例如積分商城、外賣系統、加盟招募等；需要新增移動端小程序，并且做到隨時可以發布新版本、以持續提升線上購買體驗；需要應對不定期舉辦的線上和線下營銷活動所帶來的消費波峰，不出現線上故障。02時間就是競爭力，在競爭激烈的茶飲市場，茶百道決定組建自己的軟件開發團隊，并借助阿里云的云原生產品和技術，全面升級包括店務、POS、用戶交易、平臺對接、門店管理、餐飲制作等業務單元在內的數字化體驗，充分利用線上營銷和下單、線下售賣和派送相結合的優勢，迅速占領市場。茶百道為這場數字化戰役定了個目標：數字化要能助力好茶鮮做數字化要能支持加速拓客數字化要能對企業的經營起到降本增效的作用一.

數字化要能助力好茶鮮做0176茶百道云原生十大經典案例二

.

數字化要能支持加速拓客茶百道目前的拓客資產包括：全國

7000+

線下加盟店，覆蓋超過

330

個城市，小程序、美團、餓了么的線上外賣店，抖音

&

小紅書

&

B

站等社區的營銷賬號（近百萬粉絲），以及高頻的各類線上和線下營銷活動。但在進行數字化升級前，茶百道的拓客渠道非常有限，主要是線下加盟店為主，流量成為營收增長的最主要瓶頸。為此，茶百道重新設計了運營中心的業務架構，以線上支持業務的快速增長。新增了訂單中心中的外賣、配送功能，會員中心的促銷、用戶、調度、賬單、門店、商品功能，營銷中心的券功能等，并對三大中心的原有功能進行了全面升級。為此，茶百道借助阿里云微服務引擎

MSE

和應用實時監控服務

ARMS

建立了業務連續性管理體系和可觀測體系。在業務連續性管理體系中，構建了故障預防、快速發現、系統防護

3道標準流程。茶百道目前日活訂單超百萬，很多店面是

24

小時營業。技術團隊核心目標就是提升拓客效率、線上

0

故障，因此運營中心的穩定性運行成為工作的重中之重。從運營中心架構和依賴關系圖可以看到，茶百道的運營一體化系統架構應用繁多，存在以下穩定性挑戰：頻繁的迭代和發布，三方服務依賴多，線上故障風險增高；服務間調用關系復雜，線上出現問題后，較難快速發現和定位故障；全渠道接入全覆蓋的營銷場景，難以預期的突發流量，導致保障難度加大。降低發版過程中的風險升級改造前，茶百道因為軟件變更帶來的線上事故占比一度超過

60%，每次發版，都需要避開高峰，在凌晨發版。升級改造后，通過

MSE

微服務治理建立灰度環境，控制應用發布時出現問題的爆炸半徑，以小流量來驗證發版質量，逐步覆蓋到全部業務節點；加強無損上下線能力，降低應用發布時的流量損失，從而加大了軟件的發布頻次，提升了對業務的響應訴求，隨時可發版，無懼高峰。98茶百道云原生十大經典案例這個過程中，MSE

打通了

Readiness，確保

Pod

與應用兩者同步就緒，保障發布時業務的連續性；同時，新Pod

通過小流量預熱，確保流量的穩定增長，避免由于應用初始化，代碼冷加載高流量沖擊引起應用雪崩的現象；縮容時，MSE

通過主動通知、客戶端刷新等增強能力，解決無損下線問題。并且，通過動態、靜態流量染色技術，從網關、應用、消息到數據庫，按門店等多種方式進行流量分流隔離，確保灰度環境得到全鏈路的驗證。此外，茶百道使用

MSE

云原生網關替代了原有的

Traefik

ingress，整體性能提升

1

倍，并且做到了

ingress

通用規則的平滑遷移。經過以上的改造，茶百道實現了應用發布效率提升了

60%，因發版引起的線上故障較少了90%

以上。目前正在直播場景開始實施全鏈路壓測，前端已完成改造。通過

ARMS

構建多層次全鏈路的監控體系，包括從最底層的系統和云監控，再到業務層監控，指標采樣率百分百覆蓋，鏈路全采集，監控數據準確率大幅提升，能夠快速實現業務故障的自動發現，有效的配合敏態業務發展。總體來看，故障恢復效率提升

50%

以上，故障恢復耗時縮短

50%。作為業務高速發展的新興餐飲品牌，茶百道每天都有著海量的在線訂單，這對于業務系統的連續性與可用性有著非常嚴苛的要求，以確保交易鏈路核心服務穩定運行。為了讓用戶有順暢的使用體驗，整個微服務系統每個環節都需保證在高并發大流量下服務質量，但這一過程中，構建可觀測體系存在諸多問題：快讀定位線上故障運維：從需求承接到參與研發流程規則制定在業務高峰期或受到某些營銷活動帶來的突發流量，訂單服務等核心應用會承壓，為了保護核心應用履約流程不受影響，茶百道通過

ACK

+ECI

配置了多種彈性指標，同時借助

MSE

的限流降級功能設置了熔斷保護能力，雙管齊下。例如，對部分非關鍵服務消費者配置一個規則，即當一段時間內的慢調用比例或錯誤比例達到一定條件時自動觸發熔斷，后續一段時間服務調用直接返回

Mock

的結果。這樣既可以保障調用端不會被不穩定服務拖垮，又可以給不穩定的下游服務一些喘息時間，從而保障整個業務鏈路的正常運轉。系統防護，應對突發流量指標數據準確度與采樣率難以平衡。適當的采樣策略是解決鏈路追蹤工具成本與性能的重要手段。在茶百道的龐大微服務系統規模下，100%

鏈路采集會造成可觀測平臺存儲成本超出預期，而且在業務高峰期還會對微服務應用本身的性能帶來一定影響。但開源工具在設定采樣策略的情況下，又會影響指標數據準確度，使錯誤率、P99

響應時間等重要可觀測指標失去觀測與告警價值。茶百道的應用數量有上百個規模，但是在茶百道的研發成員構成上

,

運維占比較少，大多數是開發，而開發并不熟悉代碼構建發布的技術細節。如何讓運維能夠低成本地定義規則和策略，并落地到應用的研發過程中，是落地過程中的問題點之一。為了解決該問題，茶百道結合云效應用交付中的研發流程模板、資源編排模板能力，通過模板實現應用配置的快速初始化。在這其中，運維更多的是作為應用研發流程規范的制定者，定義好應用的研發流程模板、資源編排模板、各階段的代碼分支模式以及集群資源，后續的應用特性發布都可以依據定義好的研發流程，在相應的階段按照規定的發布策略發布到對應的集群資源中。缺少高階告警能力。開源工具在告警方面實現比較簡單，用戶需要自行分別搭建告警處理及告警分派平臺，才能實現告警信息發送到

IM

群等基本功能。由于茶百道微服務化后的服務模塊眾多、依賴復雜。經常因為某個組件的異常或不可用導致整條鏈路產生大量冗余告警，形成告警風暴。造成的結果就是運維團隊疲于應付五花八門且數量龐大的告警信息，非常容易遺漏真正用于故障排查的重要消息。故障排查手段單一。開源

APM

工具主要基于

Trace

鏈路信息幫助用戶實現故障定位，對于簡單的微服務系統性能問題，用戶能夠快速找到性能瓶頸點或故障源。但實際生產環境中的很多疑難雜癥，根本沒有辦法通過簡單的鏈路分析去解決，比如

N+1

問題，內存

OOM，CPU

占用率過高，線程池打滿等。這樣就對技術團隊提出了極高要求，團隊需要深入了解底層技術細節，并具備豐富SRE

經驗的工程師，才能快速準確的定位故障根源。三.

數字化要能支持加速拓客如果說助力好茶鮮做是面向供應鏈的升級，加速拓客是面向市場和銷售端的升級，那么降本增效則是對技術團隊自身的升級了。1110茶百道云原生十大經典案例四.

遷移和實施過程研發：保持定制和靈活，并自助完成構建和發布其次，對于實際要去執行代碼構建發布的開發一線員工，如何能讓他們無需關注

Dockerfile、Yaml

等細節，就能自助地完成構建和發布，并且同時又能保持足夠的定制化和靈活性，是茶百道一站式

DevOps

工作流程落地的另一問題點。為了解決這一問題，茶百道結合云效應用交付中的變更研發流程模式，在運維人員把研發流程規范制定好后，開發人員只需要去依據云效項目中的需求或開發任務，在應用下創建變更，從應用關聯的云效代碼庫中拉取對應的

feature

分支并進行特性的開發，開發完成提交代碼后就按照已設定好的研發流程，基于云效流水線進行各階段的代碼分支構建發布，依據提前設定好的分支模式做分支構建發布，構建過程中，從云效制品倉庫中拉取相應的依賴包，并且把構建產物放在制品倉庫中進行制品版本管理。通過這一模式，一方面可以實現對一線員工應用構建發布細節的隱藏，另一方面也可以隨著業務更迭去定制修改構建發布細節。經過幾個月的實踐，基于云效，茶百道實現了一站式

DevOps

工作流程方案的成功落地，建立了產研數字化模型，提升了業務響應能力，從而較好的提升了茶百道的企業研發效能。整體方案設計完成產品選型后，結合業務上云需求，我們明確了整體系統架構和切換方案。第一步，優先遷移業務層應用：即將自建

K8s

遷移到阿里云

ACK

集群，并采用云效應用交付，以應用為中心，集中管理企業的研發資產，包括應用的配置、代碼、CI/CD

發布、環境等。在新環境部署業務系統，并進行業務驗證及壓測。第二步，測試驗證通過后，開始生產系統流量遷移：為了保證平滑過度，此時只遷移系統的接入層和應用層，數據層和中間件選擇復用，通過DNS

切流及

MSE

灰度能力逐步進行業務割接。第三步：分批完成業務切流，最終通過數據同步方式完成數據庫、中間件等產品全量切換，原自建集群下線。業務架構設計實施過程

-架構統計為了實現既定目標，項目組確定了項目實施關鍵里程碑，現場調研、方案設計、

POC

驗證、生產部署及驗證、業務割接切流、回歸測試、正式上線切流等。1312茶百道云原生十大經典案例遷移計劃實施過程

-

PoC

測試PoC

環境搭建完成后，項目組通過

PTS

進行全鏈路壓測，模擬復雜的業務場景，并快速精準地調度不同規模的流量，通過多維度的監控指標和日志記錄，全方位地驗證業務系統的性能、容量和穩定性。實施過程

-

生產系統切換通過

POC

及全鏈路壓測以后，可以確保新環境具備接管能力，并提前準備好回滾方案。切換過程中，利用

ARMS

密切監控系統的性能和穩定性，在遷移結束后進行充分的驗證和測試，以確保系統在新環境中正常運行。生產系統的切換是一個復雜的過程，需要考慮到系統的穩定性和可靠性，為此我們選擇分批切流，將原有生產系統的流量逐步切換到新系統中，有效降低了系統壓力，減少切換過程中的風險和不確定性。同時，每一個批次都要具備門店灰度能力，在分批切流的同時，新環境的發布通過門店

ID

的方式，在部分門店進行灰度測試，利用生產環境真實流量驗證新系統的可用性和性能表現，以確保其能夠滿足實際業務需求。五.

總結數字化是傳統企業突破原有市場天花板的核心競爭力，行業競爭越是激烈，數字化升級越是迫切。茶百道預判到行業的加速發展，果斷、及時、全面的進行數字化升級，并選擇阿里云保障

IT

基礎設施的先進性和穩定性，并以此助力好茶鮮做、支持加速拓客、幫助企業降本增效，為企業未來的進一步發展打下堅實的基礎。在技術架構上，業務系統外部流量渠道很多，其中有五個主要渠道

,

包括門店,POS，美團

/餓了么，小程序，抖音/

支付寶等三方渠道。系統接入層，由

DNS

進行解析，SLB

進行負載均衡，自建

Nginx

集群進行流量分發，由

treafix

ingress

作為

NG

和業務網關橋梁，使反向代理和負載均衡更加高效。業務層，除了鑒權的業務網關外，通過

ECS

搭建了

K8s

集群，K8s由第三方廠商做了很多定制化改造。數據層，用到了

RDS，Redis，TiDB

等數據庫及緩存。中間件使用了

RabbitMQ

和

Kafka

等。為了保證方案的研究性及可行性，除此之外，項目組還詳細統計了現有部署資源、內外部域名及調用關系、定時任務使用情況等詳細情況，為方案設計及實施落地提供有力的支撐。1514Rokid云原生十大經典案例當

Rokid

遇上函數計算Rokid

創立于

2014

年，是一家專注于人機交互技術的產品平臺公司。Rokid

通過語音識別、自然語言處理、計算機視覺、光學顯示、芯片平臺、硬件設計等多領域研究，將前沿的

Al和

AR

技術與行業應用相結合，為不同垂直領域的客戶提供全棧式解決方案，有效提升用戶體驗、助力企業增效、賦能公共安全，其

Al、AR

產品已在全球八十余個國家和地區投入使用。Rokid

Air

Pro

這款AR

眼鏡產品，為旅游景點，大型企業，國內科研機構都提供了服務支持。目前

Rokid

已和全國百余家博物館和景區達成合作，給游客穿越時空，身臨其境的非凡參觀體驗。三維建圖，場景創作，場景體驗三個場景都涉及到了的圖像處理，需要大量的

GPU

資源。其中三維建圖屬于離線任務，在構建展陳模型時，需要將整個展陳場所的視頻內容進行預處理，是三個場景中消耗算力最大的部分；場景創作需要配合創作軟件，GPU

資源主要來自開發機器；場景體驗在設備真實運行時提供實時服務，主要功能是定位服務，對服務的實時性要求很高。為了支撐

GPU

算力的需求，Rokid

在開發的初期就決定盡可能的使用云資源承載，充分利用云計算的紅利。最初是購買了

ECS

的

GPU

機型，用于業務的開發和測試。這里很大的問題是在三維建圖時，一般都會一次性采集展陳環境的所有場景資料，視頻量巨大，通過

ECS串行處理需要時間很長，一個

1

小時的視頻資料，通過一臺

ECS

GPU

機器需要處理

3

小時左右。Rokid

做的第一步是并行化，通過拆分

CPU

和

GPU

處理邏輯和優化任務編排方式，盡可能的讓可以并發處理的部分拉起更多的資源加大并發量，通過這一系列的優化，視頻的處理時間得到了不錯的提升。在并發資源方面，Rokid

選擇的

GPU

計算資源是

ECI，相對

ECS，ECI

可選的資源粒度更加多樣，特別是在小規格的選擇上，對于切分的小塊視頻，通過并發的使用小規格

ECI

實例并行處理，大大縮短了整體視頻的處理時間。為此，Rokid

內部平臺還開發了一套針對阿里云

ECI

資源的調度模塊，方便內部快速的申請和歸還

ECI

資源。通過對

ECI

資源的靈活使用，在保證高峰期任務處理并發度的同時，也保證了算力成本的可控，使用流程上得到了初步的優化。但是通過一段時間的使用，發現還是有很多的不足之處，主要問題總結如下：一.

架構革新的必要性Rokid

在

AR

的研究可以追溯到公司創立之初，在

2012

年

Google

Glass

橫空出世，其廣闊的想象空間深深震撼了

Rokid

創始團隊。后面雖然因為使用的場景和高額的價格原因，Google

Glass

并沒有持續的火爆普及。但可以預計在不久的將來，隨著基礎設施，生態應用的成熟，和人們持續提升的對娛樂，辦公的體驗要求，AR

技術一定會得到更廣泛的應用。Rokid

在數字文化領域，圍繞展陳導覽解決方案，主要形成了三維建圖，場景創作，場景體驗三個業務模塊，每個模塊都有不同的后臺平臺支撐。制作展陳導覽的第一步是取景，通過設備獲取場地的真實布景，然后通過算法處理，進行三維建模，之后可以經過創作器進行下一步的內容創作。場景體驗：AR

設備在使用時，根據定位服務，錨定在場景中的位置，根據位置的不同會顯示不同的空間內容，達到擴展現實場景的效果。01 三維建圖：02 場景創作：在三維建模生成的視頻流上創作，通過

Web3D

渲染引擎，將創作內容與場景緊密結合，結合硬件設備，在

AR

設備使用時，形成一體化的體驗效果。03ECI

資源的申請和釋放都依靠使用人員主動操作，有時在使用完畢后會忘記及時釋放資源，導致資源閑置浪費。且開發和維護

ECI

的調度程序也需要占據對應同學一定的精力，帶來了一些額外的運維工作。01021716Rokid云原生十大經典案例底層依托阿里云的大計算池，提供近乎無限的計算資源，通過阿里云的

cGPU

技術，可將單卡

GPU

資源切分成多種更小粒度的資源規格。客戶在函數計算選擇

GPU

規格創建函數，在有請求時，函數計算會實時從預熱資源池獲取資源，配合對應的鏡像程序，啟動客戶函數，啟動完畢后對外提供服務。函數計算在第一次運行實例時會涉及到資源的拉起，彈性交付時間在

1s（熱啟動）～

20s（冷啟動）。Rokid

的三維建圖場景是離線任務，單個視頻的處理時間也在分鐘級，對于秒級別的啟動時延完全可以接受。在三維建圖任務接入函數計算后，Rokid

不再需要手動申請

ECI

資源，在使用結束之后也不需要在手動釋放。函數計算會根據請求流量，動態的拉起與請求量匹配的后端

GPU

算力資源，在請求處理結束后，一段時間沒有新請求的情況下，自動釋放資源；整個三維建模在拆分后涉及好幾個步驟，每個步驟都是異步執行，通過函數計算的異步系統，在一個步驟的任務完成后，可以自動觸發下一個任務；函數計算控制臺內置了指標監控，異常告警，鏈路追蹤，調用日志，異步配置的功能，可以滿足

Rokid

從開發，運行監控到運維全函數生命周期的功能需求；函數計算底層依托阿里云大計算池，加上預熱和資源評估的后端算法，可以最大程度的保證資源供給；這幾點正是

Rokid

之前遇到的痛點問題，通過接入函數計算單一的產品，就解決了

Rokid

近乎全部的主要問題。為了解決上面問題，Rokid

內部架構組尋求優化已有的架構，針對第

2

點，Rokid

自行維護了一個總的調度系統，進行任務編排；針對第

3

點，通過阿里云

ARMS

Tracing，Prometheus，Grafana

等組件的引入，結合

ECI

硬件指標，統一收集到

SLS，形成統一的監控報表，再配以監控指標的告警，也能夠初步的滿足

Rokid

使用需求。但第

1

點和第

4點，很難通過增加云產品或者內部應用程序解決。為此

Rokid

架構組開始尋找云上新的產品，以求徹底的解決使用過程中的痛點問題。此時，Serverless

架構的函數計算出現在了Rokid

架構師的視野，經過一段時間的調研使用，函數計算的各項能力都能夠很好的滿足Rokid

使用場景。三維建模的任務經過拆分后，分成了好幾個步驟，每個步驟的任務都需要異步執行，需要一個系統維持任務的調用關系，在上一個步驟完成后，拉起下一個步驟的任務繼續運行。在運行過程中，會存在異常情況，排查下來，有時是因為申請的計算資源規格過小導致計算負載較高，有時是存儲異常或存儲空間寫滿，還有些情況是程序本身性能瓶頸。對于程序的整體監控缺乏，使得出現問題時不能第一時間發現，發現有異常排查過程不夠直觀，需要通過多種工具獲取運行指標分析。GPU

算力在云上規模有限，在高峰期會偶爾存在

ECI

資源彈不出的情況，影響開發效率。020304函數計算是事件驅動的全托管計算服務。使用函數計算，客戶無需采購與管理服務器等基礎設施，只需編寫并上傳代碼或鏡像。函數計算會準備好計算資源，彈性地、可靠地運行任務，并提供日志查詢、性能監控和報警等功能。函數計算提供

CPU，GPU

的算力，秒級計費，客戶只需要為實際資源使用付費。資源彈性可根據定時，請求量等指標自動伸縮，無需維護調度，負載，重試，異步回調等組件，提供了開箱即用，用完即走，按量付費的極致Serverless

能力。函數計算

GPU

架構如下：二

.

函數計算的出現恰逢其時1918接入函數計算后，Rokid

的云產品技術架構如下：函數計算資源利用率監控圖如下，從監控圖可以看出，在有任務進入時，GPU

計算利用率可以達到

60%

甚至接近

100%。三.

體驗與架構的妥協Serverless

理念的函數計算確實給

Rokid

帶了很多的便利，在高峰期資源的擴展性和成本節約方面都做到了當前云產品的極致，但函數計算也并非萬能，對于

Rokid

的場景體驗功能，也就是需要實時提供定位服務的模塊，函數計算還是存在了一定的問題。函數計算在第一次拉起實例資源時，會存在

1s（熱啟動）～

20s（冷啟動）的啟動時間，這個時間對于實時定位服務模塊是不可接受的，實時定位是在使用者身處展陳場地時，AR設備通過實時定位，獲取空間位置的

AR

拓展信息，接口響應的時間對客戶的體驗非常重要，定位請求需要在

1s

以內返回。在成本和服務質量之間，Rokid

選擇了服務質量優先，場景體驗模塊采用

ECI

部署，通過每天的定時任務，在高峰期提前彈出更多的

ECI

實例，在低峰期時，保留少量的

ECI

實例，以此達到體驗和成本的平衡。另一方面，函數計算在實時的場景也并非完全沒有解決方案。目前

GPU

的模型一般都很大，鏡像都在

G

級別，所以對于第一次資源拉起，在接下來一段時間內還看不到跟

CPU

資源一樣

100ms

級別的拉起速度。針對實時場景，函數計算

GPU

實例在做的是預留實例，該功能可以在資源閑置時，釋放計算資源的同時，保留程序的內存運行鏡像，在有新的請求進來時，只需要供給算力資源，函數就能提供服務，免去了中間硬件資源拉起，函數鏡像拉取和啟動的時間，可以提供實時的服務。預留實例已經在

CPU

實例上線，閑置時

CPU

價格是運行態的

1/10，在保證實時能力的情況下，大大降低了資源成本。GPU

版本的預留能力預計年底上線。場景體驗采用

ECI

后，Rokid

的業務架構圖如下：Rokid云原生十大經典案例2120四.出色的效果和進一步的期待一.

客戶介紹與項目背景通過一系列的云架構改造，當前

Rokid

三維建圖模塊運行在函數計算的

GPU

資源上，場景體驗模塊運行在

ECI

資源，在成本和性能上，都做到了兼顧，且給整個系統強大的可拓展性，達到了系統設計時設定的架構目標，從

2023/2

上線提供服務以來，達到了不錯的效果。其中三維建圖模塊降本明顯，相比最初的

ECS

架構，算力成本降低了

40%，更為重要的是，通過實時的并發處理，大大減少了子任務的排隊時間，加快了整個任務的完成時間。下一步，Rokid

對于函數計算的

GPU

預留實例還是非常期待，期待函數計算能夠盡快上線，這樣

Rokid

內部可以將整個的

GPU

算力都遷移到函數計算，達到架構的統一。經過展陳展覽項目的實踐，Rokid

相信以函數計算為代表的

Serverless

一定是云計算的未來，通過

Serverless，云計算的使用者不再需要關注底層的

Iaas

層運維和調度，在保證成本最優的情況下能夠得到最大限度的拓展能力，且在整服務的生命周期，都能使用云產品提供的原生能力，簡單，快速的定位，解決問題。Rokid

在

3d

模型處理，音視頻后處理方面正在大規模嘗試函數計算，Rokid

相信以函數計算為代表的

Serverless

架構也一定會在越來越多的云產品上得到應用。Rokid極氪云原生十大經典案例ARMS

助力極氪提效服務應急響應，為安全出行保駕護航浙江極氪智能科技有限公司于

2021

年

3

月成立，2021

年

4

月發布極氪品牌及旗下首款產品——極氪

001。極氪是一家以智能化、數字化、數據驅動的智能出行科技公司，秉承用戶型企業理念，聚焦智能電動出行前瞻技術的研發，構建科技生態圈與用戶生態圈，以“共創極致體驗的出行生活”為使命，從產品創新、用戶體驗創新到商業模式創新，致力于為用戶帶來極致的出行體驗。截止

2023

年

4

月，極氪量產車交付已經突破

10

萬輛，從

0

到

10

萬輛，極氪用時僅兩年，快于其他新勢力品牌至少四年以上的時間，持續刷新新勢力品牌交付記錄，這不僅是對“極氪速度”的展現，也是對“中國速度”最好的詮釋。為了保障好極氪汽車業務的快速發展和用戶體驗，技術團隊除了保持高效的功能迭代的同時，也在不斷的夯實其系統穩定性和應急響應能力。自

2023

年開始，大數據團隊正試點推行面向極數

BI

業務的數字化穩定性治理建設。032322極氪云原生十大經典案例極數

BI

是一款面向極氪經營管理全體系的可視化數據分析系統，已覆蓋多個核心業務場景。極數

BI

不僅僅是一個報表工具，還提供了全域數據互聯互通、智能化數據分析和全景數據可視化的功能，可以為其他業務“發生了什么、為什么發生、將要發生什么、如何應對”提供完善的數據支撐和輔助決策能力。打破數字鴻溝，創造數據價值，逐步實現全業務域的經營過程觀測與經營結果呈現是極數

BI

的發展目標。為保障極數

BI

的數字化穩定性治理建設落地，極氪通過建設端到端的全鏈路可觀測體系、企業級應急響應機制和跨部門團隊的人員協同機制，以業務連續性保障為目標，實現了極數BI

業務的“X

分鐘的故障發現與通報”、“X

分鐘的應急響應與故障定位”、“X

分鐘的故障恢復”核心穩定性指標的達成。如何構建統一的報警體系、通報機制和跨團隊應急協同機制系統資源層、云服務應用層、業務監控層，為了監控這些復雜的

IT

環境，由于各層資源分屬不同的團隊進行管理，導致采用了多種監控系統，例如

Prometheus、Grafana、Skywalking、阿里云云監控、阿里云ARMS

等，以獲取更全面的監控數據和更好的了解運行狀態和性能表現。然而多種監控系統的并存帶來的其中一個顯著問題是告警信息的分散，不同的監控系統產生不同的告警信息，通過不一致的方式通報給告警處理人，而告警的排查通常需要多個團隊共同合作進行處理，縱橫交錯的告警處理增加了人員響應的復雜性和工作量，疲于應付的程度往往遠超出了告警處理人員的日常負荷。02如何規范故障等級定義、應急處置流程和故障管理體系業務可用率是一套業務系統可靠性、維修性和維修保障性的綜合反映。Availability

=

MTBF

/

(MTBF

+

MTTR)，

通常業界習慣用

N

個

9

來表

征

系

統

可

用

性，

比

如

99.9%（3-9

availability），99.999%（5-9availability），系統出現故障的停機時間直接反映了業務可用率。如何定義一套適用于極氪自身業務的故障等級定義、應急處置流程和故障管理體系將是保障極氪對外承諾的業務可用率的重要支撐手段。通過建立一個可遵循的規范、全流程閉環的故障管理體系，配合技術手段的提升，可以有效降低故障發生的幾率，縮短故障的

MTTR，最終使故障造成的破壞性趨近于

0。03如何有效度量業務穩定性指標和應急響應SLA如何查看過去一段時間系統發生了哪些告警，哪類告警占比較高；制定了值班機制，但無法衡量值班人員告警處理的效率，如何確保值班機制的執行效果；一個服務在多個系統中配置了多個告警，無法從服務的維度來查看告警的處理效率，查看服務的

SLA；在針對性的系統優化后告警占比是否降低，告警的持續時間占比是否得到改善。這些都是在日常運維過程中衡量告警的處理效率和服務的穩定性面臨的典型問題。這些重要數據都需要完善的數據報表和統一的大盤來呈現。04疲于應付海量告警信息，并且非常容易遺漏真正用于故障排查的重要消息。因此，針對海量持續告警信息，如何進行告警合并，在保證不錯過核心告警消息的前提下抑制告警消息數量，成為了面臨的重要運維難題。二

.

項目落地時面臨的挑戰和需求云原生浪潮下，Serverless

因其全托管免運維、成本降低和彈性伸縮等特性正逐步在引領下一代的應用架構。極數

BI

業務從立項之初就確定了

Serverless

化的方向，并基于阿里云

Serverless

應用引擎（SAE）成功落地。應用

Serverless

化最大化限度減輕了運維工作，但是在自身業務的數字化穩定性治理方面依然面臨較大挑戰：如何覆蓋和收斂從基礎設施到業務應用監控的全鏈路告警事件從前臺業務數據、用戶體驗，到后臺應用服務性能，再到云服務及基礎資源，即系統資源層、云服務應用層、業務監控層，雖然針對不同的服務模塊都有對應監控，構建了相對完善的指標監控體系，但由于微服務化后的服務模塊眾多、依賴復雜，很有可能因為某個組件的異常或不可用導致整條鏈路產生大量冗余告警，形成告警風暴，從而造成運維團隊012524極氪云原生十大經典案例三.

基于

ARMS

的企業級應急響應解決方案針對上述面臨的問題和挑戰，阿里云云原生可觀測團隊與大數據團隊經過多輪溝通對焦，通力合作共同輸出了基于

ARMS

構建企業級應急響應體系的最佳實踐，并成功在極數

BI

業務中落地，實現了全業務、全場景的監控和告警。同時全面提升了監控的覆蓋率和告警有效率，其中按照極氪現行推廣的應急響應機制，全團隊事件接手率顯著提升，告警平均認領耗時（MTTA）大幅降低，告警平均恢復耗時（MTTR）明顯縮短，跨團隊協同效率得到有效提升。采用

ARMS

智能告警建設統一的告警事件管理中心極氪技術團隊根據自身業務屬性使用了多種監控系統，例如阿里云應用監控

ARMS、阿里云日志服務

SLS、Zabbix、Prometheus、Grafana

和自定義告警集成等，為了簡化聯系人、通知方式、值班等運維配置；統一告警信息格式、告警等級定義和告警事件的統一管理，極氪采用了

ARMS

智能告警作為多告警源統一管理的事件管理中心。ARMS

智能告警設計的集成、事件處理流、通知策略等功能專門針對告警統一管理的場景，解決了統一管理過程中遇到的諸多問題。以下重點介紹下整體方案中圍繞“告警、接手”兩項落地的“以事件為中心的告警全生命周期管理”解決方案。接入不同格式的告警。ARMS

智能告警參考開源

Prometheus

告警定義，使用一個半結構化的數據結構來描述告警。通過高度可擴展的鍵值對來描述告警，這樣就可以非常靈活的對告警內容進行擴展從而接入不同的數據源產生的告警。通過告警集成的字段映射能力，即可將自定義的告警內容中的關鍵信息映射到

ARMS

告警數據結構中。同時也提供了多種監控工具的快捷接入能力，像極氪這邊使用的阿里云應用監控

ARMS、阿里云日志服務

SLS、Zabbix、Prometheus、Grafana

等均已覆蓋。告警等級統一定義。根據影響面的不同、業務受損程度的不同,一般需要定義不同的告警等級，告警處理人員需要根據不同的告警等級執行不同的應急處理過程。按照極氪的故障等級規范

,

配置告警時根據業務情況將告警歸一到

P0、P1、P2、P3

四個等級。01022726極氪云原生十大經典案例事件和告警的歸一化管理。多告警事件源通過集成的方式統一到

ARMS

智能告警，通過統一的事件處理流、通知策略、通知對象、升級策略等對告警事件進行歸一化管理。一份通知對象、一套通知策略、一致的告警管理模式，滿足極氪統一的告警事件中心需求。通過認領告警的消息廣播可以讓群成員之間明確的知道當前告警是誰在處理。01

認領告警有些告警觸發屬于預期內的行為，且不會造成業務影響，但是又不能直接關閉告警。這種情況下可以通過屏蔽告警來降低告警通知的打擾。02

屏蔽告警關注告警后，會將被關注告警的狀態變更以短信的形式推送給關注人。對于重大故障的情況下，團隊負責人可以通過關注告警的能力實時訂閱關注告警處理的進展，從而為指揮決策提供數據支撐。03關注告警關閉告警并在群聊中發送一個告警關閉的通知，被關閉的告警狀態會變成已恢復。04

解決告警03基于極氪使用的企業微信建設便捷高效的

ChatOps

掌上運維能力ChatOps

是一種集成了聊天和自動化工具的協作方法和文化，旨在提高團隊的協作效率和可見性。ChatOps

的目標是提高工作流程的效率和可見性，并促進團隊成員之間的協作和溝通。極氪內部使用企業微信作為辦公協同工具，ARMS

智能告警支持對接企業微信，通過創建企業微信機器人，即可在通知策略中指定對應的企業微信群用于接收告警，相關告警信息僅在企業微信的極氪內部企業組織內流轉。當通知策略的匹配規則被觸發時，系統會自動向指定的企業微信群發送告警通知。企業微信群收到通知后，便可以隨時隨地在企業微信群中對告警進行管理。源于ITIL理念且適用于極氪組織架構和業務屬性的事件管理體系大數據團隊目前正在極數

BI

業務推廣的數字化穩定性治理機制最核心的部分就是構建一套標準規范的事件管理流程。流程上包含告警發現、告警通報、告警響應/

接手、告警定位、指揮決策、告警恢復、故障復盤和持續改進。從人員組織上包括運維團隊、告警值班人員、告警處置技術人員、應急指揮人員等。當告警觸發接收到通報后，告警值班人員需要迅速建立針對告警關聯團隊的高效協同渠道，故障應急啟動后。技術同學需要盡快完成簽到，同時同步進行故障快速止血、根因定位排查、信息同步，如果在預期時間內未接手簽到，告警通知將逐步升級。運維團隊和應急指揮人員要負責統籌收集相關數據并同步影響面、處理進展和恢復進展，定時播報，更新告警處理情況。當告警以卡片的形式發送到

IM

群聊中，可以通過訂正卡片的樣式來添加一組操作進行告警的處理。通過

IM

的告警卡片即可便捷進行告警的全生命周期管理：同時為了方便極氪告警值班人員快速知悉告警通告情況，防止群消息過多被忽略，告警通知支持在告警通知群中

@

指定處理人。通過將告警處理人添加為

ARMS

聯系人、通知策略中配置的通知對象和綁定處理人手機號相同即可實現告警通知時根據排班情況

@

值班人員。2928極氪云原生十大經典案例ARMS

智能管理提供排班管理功能，告警通知可以按照運維人員的值班時間設置告警發送的排班表，再通過通知策略將告警通知以電話、短信、郵件或企微消息的方式發送至對應的值班人員，而不會打擾到非值班時間的運維人員。告警值班人員再根據事件管理標準流程進行告警接手和處置。01

排班管理對于長期未解決的告警，可以選擇升級通知來提醒值班人員及時解決。在通知策略中添加升級策略后，系統會以指定的通知方式向處理人發送告警信息，以提醒處理人采取必要的問題解決措施。極氪的事件管理流程規定長期未處置的告警需要進行兩層升級，一層到業務部門主管，再一層到應急指揮主管。通過這種方式也是為了盡可能提高告警接手率，降低告警處理和恢復時長。03

升級策略通過設置通知策略，可以制定針對告警事件的匹配規則。當匹配規則被觸發時，系統會以指定的通知方式向通知對象發送告警信息，以提醒通知對象采取必要的問題解決措施。通知策略中可以選擇排班表，匹配到通知策略的事件將會按照排班表中的人員進行告警通報。為了保障告警的接手率，防止值班人員遺漏告警，還可以在配置重復通知策略，當告警未恢復時，告警會以設置的重復頻率循環發送告警信息直至告警恢復。另外極氪的事件管理流程規定告警必須值班人員干預和接手，哪怕告警已經自動恢復。ARMS

智能告警提供了告警手動恢復的能力，當告警事件在告警集成中設置的自動恢復時間內都沒有再觸發，告警不會自動恢復，必須人工干預調整狀態。滿足極氪對值班人員接手率考核和度量的要求。02

通知策略靈活、自定義的

ARMS

Grafana

應急響應數據大盤如果沒有數據報告和持續運營，那么對現狀的了解就會充滿了模糊和不確定性，事件管理對整體業務的提升就沒法落到實處。客觀的數據雖然不能替代溝通和觀察，但是通過數據共享和信息的可視化，能夠有效的促進共識的達成，大家都能夠共同的看到和了解數據變化和現狀，促進相互協作。ARMS

智能告警默認提供歷史告警總覽和告警處理效率兩張數據大盤，大盤提供了告警統計、告警趨勢、MTTx

指標、人員效率等一系列告警度量數據，這些數據存儲在默認的

Prometheus

實例中。極氪則根據自身運維訴求基于原始數據在

ARMSGrafana

服務中配置了自定義的應急響應度量大盤，包括值班狀態、告警概覽、告警接手情況和

MTTx

指標等，幫助運維團隊能夠實時了解業務告警狀態及應急處置情況，大幅提升了應急響應效率。測試數據大盤示意圖四.

后續合作的方向和規劃極氪全業務推行的數字化穩定性治理正在如火如荼的進行著，整體應急響應效率得到大幅提升的同時，也挖掘了更多的能夠進一步提升效率的需求點，阿里云云原生可觀測團隊將繼續跟大數據團隊在提升告警規則配置效率和進一步縮短告警恢復時間上深度合作共建。近期

ARMS

智能告警新發布的靜態閾值推薦、告警數預測、區間檢測和告警規則測試等能力將借助智能化的手段幫助極氪進一步提升告警規則配置效率。同時

ARMS

智能告警新增支持行動集成，提供函數計算

FC

和自定義

Webhook

的行動集成能力，基于行動集成提供的可執行的任務能夠作為告警快速止血的預案，對于具有確定性特征的告警，能夠提供快速的止血恢復手段，可以有效縮短實際的告警恢復時長。業務系統的穩定性和應急響應效率，是品牌口碑和用戶體驗的基石，阿里云將堅定不移的為客戶提供極致“穩定、安全、性能、成本”的產品和方案，助力客戶業務再攀高峰。3130創米數聯云原生十大經典案例支撐

“千萬設備日活”

的創米數聯

7

年微服務架構演進之路創米數聯是小米生態鏈首批億元俱樂部成員，主營業務為智能家居產品的研發、設計、生產和銷售，致力于成為以居家安全為核心的產品和服務提供商，提供多品類的全屋智能家居產品及服務。公司以居家安全為核心，洞察用戶在居住環境下的智能化需求，建立物理安全、環境安全、系統安全三類場景及服務體系，主要產品包括智能攝像機、智慧門、智能貓眼、智能門鈴、智能插座等。公司旨在實現“看得見的全屋智能”，以智能家庭安全為切入點，提供多品類覆蓋的智能家居解決方案。截至

2021

年

12

月

31

日，創米數聯已經在全世界150

多個國家，銷售了超過

5500

萬臺設備，擁有了

1600

萬設備和

500

萬設備用戶日活。作為小米生態鏈的一員，創米采用微服務架構支撐其千萬日活的

IOT

設備。隨著智能家居市場的快速迭代，創米面臨著發布和迭代的穩定性挑戰，同時需要解決多方

IOT

接入面臨的性能和安全挑戰。本文將為您一一道來創米是如何應對這些挑戰的。從

2019

年伊始，創米數聯提出了研發自有

APP

和適配自有

APP

的智能家居設備的發展戰略。云服務部將研發重心轉向自有

APP

云端業務，并逐步接入自有品牌設備。為了實現全球業務，創米云服務部將相關服務部署在阿里云的

4

個

Region

的

ACK

Pro

專有版

Kubernetes

集群上。阿里云

ACK

為創米云提供了可靠穩定的基礎設施，向下封裝好的數十款云產品，降低了云端運維人員的運維壓力，快速對接其他云產品的能力也對開發人員十分友好，能夠讓創米云服務在極短的時間內搭建一套線上可用的環境。在自有業務研發開始階段，我們選擇了

Spring

Cloud、Eureka

和Apollo

等技術棧來搭建我們的微服務基礎架構。然而，經過一年半的摸索，我們發現當前的混合架構存在著不穩定、上線部署風險大以及高人力維護成本等問題。因此，從

2021

年開始，創米云服務決定改變現有的微服務架構，逐步擁抱云原生。我們的目標是在滿足穩定性和低維護成本等需求的基礎上，實現所有組件的可觀測性、全鏈路的流量治理以及更加便捷高效的DevOps

流程。首先我們將當前的

Spring

Cloud

體系全面轉向

Spring

CloudAlibaba，使用

Nacos

替換

Eureka，以解決

Eureka

服務端壓力過大的問題，并滿足單注冊中心多環境分組的需求。由于

Apollo

在某些情況下存在容器磁盤壓力大的問題，我們逐步將配置中心從

Apollo

替換為Nacos。針對之前定制化的

Apollo

配置同步和本地特殊配置緩存，同樣我們也對

Nacos

客戶端進行了部分定制化改造。初版上線時，考慮到注冊中心和配置中心的高可用性、熱升級、成本、可觀測配套等因素，我們沒有選擇自建有狀態的開源

Nacos

服務，而是直接使用了阿里云

MSE

Nacos

專業版服務。至今，該服務一直穩定運行，沒有出現可用性問題。云計算時代的蹣跚學步創米云服務從

2016

年創始之初就選擇了云計算

+

微服務的技術路線，以應對面臨的大量線上用戶和設備帶來的流量挑戰。構建微服務之初，市面上可選用的解決方案并不多，我們自主實現了一些微服務組件，如

frontend

業務網關和配置中心，并在小米生態云上部署容器服務來處理設備消息、設備插件

API

和微信公眾號等相關業務，并利用

HPA

及

CronHPA等容器彈性伸縮策略來應對動態的海量線上流量。自此創米數聯在云計算時代踏上了探索服務容器化的第一步。新業務及新挑戰云原生體系探索043332針對全鏈路的流量治理，由于創米云服務所處的

AIoT

行業不同于傳統互聯網行業，我們在南北向流量時不僅需要治理下游用戶手機端

APP

及Web

端的

HTTP

請求，還需要處理來自設備端的

MQTT、第三方

AMQP和

HTTP

2

長連接

Push

消息的流量治理。這些消息通常經由統一的上游消息網關（消息總線）監聽，經過多級過濾器，如消息來源、消息限流和產品或特定設備級別的白名單等，對消息進行分類和打標簽，然后對消息

Topic

正則路由并進行

HTTP

異步或

rpc

請求。只有經過這些請求后，我們才能對其進行流量治理。因此，創米云服務的流量治理整體較為復雜。我們曾考慮過采用侵入式代碼和自定義負載均衡器，并開發控制臺來實現高度自定義的流量方案。我們還考慮過使用

Istio

Service

Mesh

的方案治理流量。然而，前者在當前百萬級別設備消息的情況下性能嚴重受限，后者由于設備消息鏈路較長、打標較多，導致實現全鏈路灰度時配置文件實現較為復雜，而且Envoy

代理無法完整攔截消息總線請求等問題，因此我們否定了這兩種方案。之后在選型過程中，我們采用了

MSE

微服務治理。我們傳統的

API

業務流量治理選用了多域名、多租戶環境、節點隔離加多業務網關的方案配合

MSE

微服務治理來實現多個環境服務的測試開發及線上灰度部署。我們使用多域名加

DNS

流量劃分的方式對服務重構后的業務網關新路由進行測試，保證服務重構后的安全上線。我們利用多個

K8s

集群、K8s

namespace

以及多個

namespace

的注冊配置中心的隔離構建了不同的線上環境，分別用來線上開發、線上測試、灰度以及基線環境部署。對于同一集群不同

namespace

的應用

pod

使用多集群隔離、應用節點親和性、反親和性以及節點污點等集群調度手段保證環境的安全性，避免不同環境間出現的資源異常導致基線環境不可用的情況。基線環境和灰度環境同屬不同命名空間的相同節點池內，測試和開發環境應用

pod

部署在不同的

K8s

集群或節點池中。我們的整體流程通常是在

feature

及

bug

修復后涉及的服務在開發環境聯調完畢，在每次測試流程前將

feature

服務部署至測試環境，通過藍綠測試將測試人員的流量導向測試環境，在多輪的覆蓋及回歸測試完成后，將服務部署至灰度環境，再將測試人員及

Beta

測試用戶的流量導向灰度環境，經過一定時間的檢驗后，逐步將線上基線流量導向灰度環境，灰度環境流量完成

100%

灰度后，替換基線環境鏡像，最后逐步將灰度流量倒流至基線環境。在核心業務接入

MSE

微服務治理之后，創米云服務對部分多云部署及老項目通過

DNS

流量切分

+

全鏈路灰度的方式進行灰度，逐漸將自有

APP

及自有設備的所有業務重構遷移至新項目中并全部接入

MSE

微服務，實現了云上

API

業務的

100%

安全發布。在設備消息業務的流量治理的推進過程中，為了解決無法攔截消息請求的問題，我們首先將消息總線拆分為控制器和路由器兩部分。控制器監聽各個通道的消息后僅對消息進行打標簽和分類，然后通過異步

HTTP

請求經由統一的路由器轉發到各個服務中。我們將路由器服務定義為流量治理的入口，從而解決了消息無法治理的問題。然后，我們使用統一的全鏈路灰度對打標簽后的

HTTP

請求進行藍綠和灰度的流量治理，并將其分發到指定的命名空間的指定服務中進行消息處理。MSE

微服務治理接入非常簡單，只需要在

Helm

或組件中心安裝

ack-onepilot

組件，重啟服務便可自動注入服務，除此之外

MSE

提供了較為友好的全鏈路灰度配置界面，較

Istio方案更加易于配置和上手。通過這樣的流程，創米云服務成功實現了設備服務的更新、云云設備的對接以及固件

OTA

版本的迭代過程中的安全發布。創米數聯云原生十大經典案例全鏈路流量治理3534在之前的服務發版部署或

pod

彈性伸縮過程中經常會有部分請求出現超時或不可用的情況，由于創米云服務承載了大量的用戶設備請求，這些流量損失輕則導致設備消息重試，嚴重時會影響部分用戶設備的可用性，后續我們了解了

MSE

微服務治理提供了無損上下線及服務預熱功能，決定將相關服務全部接入了

MSE

微服務治理的無損上下線，并調整對應服務的就緒檢查，在后續的服務上下線過程中經觀察再未出現因為流量損失導致的請求不可用的情況，一定程度上避免了由部署發布和服務縮容引起的線上流量損失問題。為了實現可觀測性，我們早期就將阿里云

SLS

日志服務集成到自有業務框架中。然而，我們遇到了業務索引不規范、唯一

RequestId

索引異步丟失以及

Spring

Cloud

Gateway

等

Reactive

框架應用日志異步寫入

Location

導致

CPU

占用過高等問題。因此，我們對當前的日志規范進行了改進，并在多個鏈路追蹤方案中選擇了

Skywalking。我們將Skywalking

的

TraceId

寫入

SLS

日志索引中，并通過對

ThreadLocal無損上下線解決發布擴縮容流量損失問題無損下線邏輯圖新