2024/

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

NATIVE02 Rokid 當(dāng)

Rokid

遇上函數(shù)計(jì)算 14作者：王彬、姚蘭天、聶大鵬ALIBABA

CL03 極氪 ARMS

助力極氪提效服務(wù)應(yīng)急響應(yīng)，為安全出行保駕護(hù)航 21作者：比揚(yáng)04 創(chuàng)米數(shù)聯(lián) 支撐

“千萬設(shè)備日活”

的創(chuàng)米數(shù)聯(lián)

7

年微服務(wù)架構(gòu)演進(jìn)之路 30作者：金兆旭、十眠05 美洽 對比

5

個(gè)開源網(wǎng)關(guān)項(xiàng)目，這家

SaaS

企業(yè)如何統(tǒng)一網(wǎng)關(guān)架構(gòu) 36作者：古建國06 高德 阿里云函數(shù)計(jì)算

FC

助力高德

RTA

廣告投放系統(tǒng)架構(gòu)升級 42作者：趙慶杰、林雪清、杜玲玲、王壁成07 Tim

Hortons 輕松構(gòu)建全棧觀測，從容應(yīng)對咖啡產(chǎn)業(yè)競爭 50作者：郭皛璠08 杭州亞運(yùn) 高光回眸：阿里云容器服務(wù)如何全面助力精彩亞運(yùn) 56作者：劉佳旭

謝乘勝

賢維ES09 阿里影業(yè) 容災(zāi)切換時(shí)間減少

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

STUDI10 TCL TCL

擁抱云原生，實(shí)現(xiàn)

IT

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

8

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

2008

年，起初，茶百道堅(jiān)持一步一個(gè)腳印，用了

8

年時(shí)間門店數(shù)量也只有100

家。轉(zhuǎn)折點(diǎn)發(fā)生在

2018

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

到

2022

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

4

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

OMS、WMS

和

TMS

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

B

端的供應(yīng)鏈中心和面向

C

端的運(yùn)營中心，均部署在自建的

K8s

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

K8s

集群遷移到

ACK

+

ECI，ACK

具備強(qiáng)大的集群管理，包括集群創(chuàng)建、集群升級、多集群管理、授權(quán)管理等能力，提升了集群管理效率；ECI

可根據(jù)業(yè)務(wù)需求，實(shí)現(xiàn)自動(dòng)擴(kuò)容，30s

即可擴(kuò)容

3000

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

50%；通過

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

IT

業(yè)務(wù)系統(tǒng)由外部

SaaS

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

數(shù)字化要能助力好茶鮮做0176茶百道云原生十大經(jīng)典案例二

.

數(shù)字化要能支持加速拓客茶百道目前的拓客資產(chǎn)包括：全國

7000+

線下加盟店，覆蓋超過

330

個(gè)城市，小程序、美團(tuán)、餓了么的線上外賣店，抖音

&

小紅書

&

B

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

MSE

和應(yīng)用實(shí)時(shí)監(jiān)控服務(wù)

ARMS

建立了業(yè)務(wù)連續(xù)性管理體系和可觀測體系。在業(yè)務(wù)連續(xù)性管理體系中，構(gòu)建了故障預(yù)防、快速發(fā)現(xiàn)、系統(tǒng)防護(hù)

3道標(biāo)準(zhǔn)流程。茶百道目前日活訂單超百萬，很多店面是

24

小時(shí)營業(yè)。技術(shù)團(tuán)隊(duì)核心目標(biāo)就是提升拓客效率、線上

0

故障，因此運(yùn)營中心的穩(wěn)定性運(yùn)行成為工作的重中之重。從運(yùn)營中心架構(gòu)和依賴關(guān)系圖可以看到，茶百道的運(yùn)營一體化系統(tǒng)架構(gòu)應(yīng)用繁多，存在以下穩(wěn)定性挑戰(zhàn)：頻繁的迭代和發(fā)布，三方服務(wù)依賴多，線上故障風(fēng)險(xiǎn)增高；服務(wù)間調(diào)用關(guān)系復(fù)雜，線上出現(xiàn)問題后，較難快速發(fā)現(xiàn)和定位故障；全渠道接入全覆蓋的營銷場景，難以預(yù)期的突發(fā)流量，導(dǎo)致保障難度加大。降低發(fā)版過程中的風(fēng)險(xiǎn)升級改造前，茶百道因?yàn)檐浖兏鼛淼木€上事故占比一度超過

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

MSE

微服務(wù)治理建立灰度環(huán)境，控制應(yīng)用發(fā)布時(shí)出現(xiàn)問題的爆炸半徑，以小流量來驗(yàn)證發(fā)版質(zhì)量，逐步覆蓋到全部業(yè)務(wù)節(jié)點(diǎn)；加強(qiáng)無損上下線能力，降低應(yīng)用發(fā)布時(shí)的流量損失，從而加大了軟件的發(fā)布頻次，提升了對業(yè)務(wù)的響應(yīng)訴求，隨時(shí)可發(fā)版，無懼高峰。98茶百道云原生十大經(jīng)典案例這個(gè)過程中，MSE

打通了

Readiness，確保

Pod

與應(yīng)用兩者同步就緒，保障發(fā)布時(shí)業(yè)務(wù)的連續(xù)性；同時(shí)，新Pod

通過小流量預(yù)熱，確保流量的穩(wěn)定增長，避免由于應(yīng)用初始化，代碼冷加載高流量沖擊引起應(yīng)用雪崩的現(xiàn)象；縮容時(shí)，MSE

通過主動(dòng)通知、客戶端刷新等增強(qiáng)能力，解決無損下線問題。并且，通過動(dòng)態(tài)、靜態(tài)流量染色技術(shù)，從網(wǎng)關(guān)、應(yīng)用、消息到數(shù)據(jù)庫，按門店等多種方式進(jìn)行流量分流隔離，確?；叶拳h(huán)境得到全鏈路的驗(yàn)證。此外，茶百道使用

MSE

云原生網(wǎng)關(guān)替代了原有的

Traefik

ingress，整體性能提升

1

倍，并且做到了

ingress

通用規(guī)則的平滑遷移。經(jīng)過以上的改造，茶百道實(shí)現(xiàn)了應(yīng)用發(fā)布效率提升了

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

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

ARMS

構(gòu)建多層次全鏈路的監(jiān)控體系，包括從最底層的系統(tǒng)和云監(jiān)控，再到業(yè)務(wù)層監(jiān)控，指標(biāo)采樣率百分百覆蓋，鏈路全采集，監(jiān)控?cái)?shù)據(jù)準(zhǔn)確率大幅提升，能夠快速實(shí)現(xiàn)業(yè)務(wù)故障的自動(dòng)發(fā)現(xiàn)，有效的配合敏態(tài)業(yè)務(wù)發(fā)展?？傮w來看，故障恢復(fù)效率提升

50%

以上，故障恢復(fù)耗時(shí)縮短

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

ACK

+ECI

配置了多種彈性指標(biāo)，同時(shí)借助

MSE

的限流降級功能設(shè)置了熔斷保護(hù)能力，雙管齊下。例如，對部分非關(guān)鍵服務(wù)消費(fèi)者配置一個(gè)規(guī)則，即當(dāng)一段時(shí)間內(nèi)的慢調(diào)用比例或錯(cuò)誤比例達(dá)到一定條件時(shí)自動(dòng)觸發(fā)熔斷，后續(xù)一段時(shí)間服務(wù)調(diào)用直接返回

Mock

的結(jié)果。這樣既可以保障調(diào)用端不會被不穩(wěn)定服務(wù)拖垮，又可以給不穩(wěn)定的下游服務(wù)一些喘息時(shí)間，從而保障整個(gè)業(yè)務(wù)鏈路的正常運(yùn)轉(zhuǎn)。系統(tǒng)防護(hù)，應(yīng)對突發(fā)流量指標(biāo)數(shù)據(jù)準(zhǔn)確度與采樣率難以平衡。適當(dāng)?shù)牟蓸硬呗允墙鉀Q鏈路追蹤工具成本與性能的重要手段。在茶百道的龐大微服務(wù)系統(tǒng)規(guī)模下，100%

鏈路采集會造成可觀測平臺存儲成本超出預(yù)期，而且在業(yè)務(wù)高峰期還會對微服務(wù)應(yīng)用本身的性能帶來一定影響。但開源工具在設(shè)定采樣策略的情況下，又會影響指標(biāo)數(shù)據(jù)準(zhǔn)確度，使錯(cuò)誤率、P99

響應(yīng)時(shí)間等重要可觀測指標(biāo)失去觀測與告警價(jià)值。茶百道的應(yīng)用數(shù)量有上百個(gè)規(guī)模，但是在茶百道的研發(fā)成員構(gòu)成上

,

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

IM

群等基本功能。由于茶百道微服務(wù)化后的服務(wù)模塊眾多、依賴復(fù)雜。經(jīng)常因?yàn)槟硞€(gè)組件的異常或不可用導(dǎo)致整條鏈路產(chǎn)生大量冗余告警，形成告警風(fēng)暴。造成的結(jié)果就是運(yùn)維團(tuán)隊(duì)疲于應(yīng)付五花八門且數(shù)量龐大的告警信息，非常容易遺漏真正用于故障排查的重要消息。故障排查手段單一。開源

APM

工具主要基于

Trace

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

N+1

問題，內(nèi)存

OOM，CPU

占用率過高，線程池打滿等。這樣就對技術(shù)團(tuán)隊(duì)提出了極高要求，團(tuán)隊(duì)需要深入了解底層技術(shù)細(xì)節(jié)，并具備豐富SRE

經(jīng)驗(yàn)的工程師，才能快速準(zhǔn)確的定位故障根源。三.

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

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

Dockerfile、Yaml

等細(xì)節(jié)，就能自助地完成構(gòu)建和發(fā)布，并且同時(shí)又能保持足夠的定制化和靈活性，是茶百道一站式

DevOps

工作流程落地的另一問題點(diǎn)。為了解決這一問題，茶百道結(jié)合云效應(yīng)用交付中的變更研發(fā)流程模式，在運(yùn)維人員把研發(fā)流程規(guī)范制定好后，開發(fā)人員只需要去依據(jù)云效項(xiàng)目中的需求或開發(fā)任務(wù)，在應(yīng)用下創(chuàng)建變更，從應(yīng)用關(guān)聯(lián)的云效代碼庫中拉取對應(yīng)的

feature

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

DevOps

工作流程方案的成功落地，建立了產(chǎn)研數(shù)字化模型，提升了業(yè)務(wù)響應(yīng)能力，從而較好的提升了茶百道的企業(yè)研發(fā)效能。整體方案設(shè)計(jì)完成產(chǎn)品選型后，結(jié)合業(yè)務(wù)上云需求，我們明確了整體系統(tǒng)架構(gòu)和切換方案。第一步，優(yōu)先遷移業(yè)務(wù)層應(yīng)用：即將自建

K8s

遷移到阿里云

ACK

集群，并采用云效應(yīng)用交付，以應(yīng)用為中心，集中管理企業(yè)的研發(fā)資產(chǎn)，包括應(yīng)用的配置、代碼、CI/CD

發(fā)布、環(huán)境等。在新環(huán)境部署業(yè)務(wù)系統(tǒng)，并進(jìn)行業(yè)務(wù)驗(yàn)證及壓測。第二步，測試驗(yàn)證通過后，開始生產(chǎn)系統(tǒng)流量遷移：為了保證平滑過度，此時(shí)只遷移系統(tǒng)的接入層和應(yīng)用層，數(shù)據(jù)層和中間件選擇復(fù)用，通過DNS

切流及

MSE

灰度能力逐步進(jìn)行業(yè)務(wù)割接。第三步：分批完成業(yè)務(wù)切流，最終通過數(shù)據(jù)同步方式完成數(shù)據(jù)庫、中間件等產(chǎn)品全量切換，原自建集群下線。業(yè)務(wù)架構(gòu)設(shè)計(jì)實(shí)施過程

-架構(gòu)統(tǒng)計(jì)為了實(shí)現(xiàn)既定目標(biāo)，項(xiàng)目組確定了項(xiàng)目實(shí)施關(guān)鍵里程碑，現(xiàn)場調(diào)研、方案設(shè)計(jì)、

POC

驗(yàn)證、生產(chǎn)部署及驗(yàn)證、業(yè)務(wù)割接切流、回歸測試、正式上線切流等。1312茶百道云原生十大經(jīng)典案例遷移計(jì)劃實(shí)施過程

-

PoC

測試PoC

環(huán)境搭建完成后，項(xiàng)目組通過

PTS

進(jìn)行全鏈路壓測，模擬復(fù)雜的業(yè)務(wù)場景，并快速精準(zhǔn)地調(diào)度不同規(guī)模的流量，通過多維度的監(jiān)控指標(biāo)和日志記錄，全方位地驗(yàn)證業(yè)務(wù)系統(tǒng)的性能、容量和穩(wěn)定性。實(shí)施過程

-

生產(chǎn)系統(tǒng)切換通過

POC

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

ARMS

密切監(jiān)控系統(tǒng)的性能和穩(wěn)定性，在遷移結(jié)束后進(jìn)行充分的驗(yàn)證和測試，以確保系統(tǒng)在新環(huán)境中正常運(yùn)行。生產(chǎn)系統(tǒng)的切換是一個(gè)復(fù)雜的過程，需要考慮到系統(tǒng)的穩(wěn)定性和可靠性，為此我們選擇分批切流，將原有生產(chǎn)系統(tǒng)的流量逐步切換到新系統(tǒng)中，有效降低了系統(tǒng)壓力，減少切換過程中的風(fēng)險(xiǎn)和不確定性。同時(shí)，每一個(gè)批次都要具備門店灰度能力，在分批切流的同時(shí)，新環(huán)境的發(fā)布通過門店

ID

的方式，在部分門店進(jìn)行灰度測試，利用生產(chǎn)環(huán)境真實(shí)流量驗(yàn)證新系統(tǒng)的可用性和性能表現(xiàn)，以確保其能夠滿足實(shí)際業(yè)務(wù)需求。五.

總結(jié)數(shù)字化是傳統(tǒng)企業(yè)突破原有市場天花板的核心競爭力，行業(yè)競爭越是激烈，數(shù)字化升級越是迫切。茶百道預(yù)判到行業(yè)的加速發(fā)展，果斷、及時(shí)、全面的進(jìn)行數(shù)字化升級，并選擇阿里云保障

IT

基礎(chǔ)設(shè)施的先進(jìn)性和穩(wěn)定性，并以此助力好茶鮮做、支持加速拓客、幫助企業(yè)降本增效，為企業(yè)未來的進(jìn)一步發(fā)展打下堅(jiān)實(shí)的基礎(chǔ)。在技術(shù)架構(gòu)上，業(yè)務(wù)系統(tǒng)外部流量渠道很多，其中有五個(gè)主要渠道

,

包括門店,POS，美團(tuán)

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

支付寶等三方渠道。系統(tǒng)接入層，由

DNS

進(jìn)行解析，SLB

進(jìn)行負(fù)載均衡，自建

Nginx

集群進(jìn)行流量分發(fā)，由

treafix

ingress

作為

NG

和業(yè)務(wù)網(wǎng)關(guān)橋梁，使反向代理和負(fù)載均衡更加高效。業(yè)務(wù)層，除了鑒權(quán)的業(yè)務(wù)網(wǎng)關(guān)外，通過

ECS

搭建了

K8s

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

RDS，Redis，TiDB

等數(shù)據(jù)庫及緩存。中間件使用了

RabbitMQ

和

Kafka

等。為了保證方案的研究性及可行性，除此之外，項(xiàng)目組還詳細(xì)統(tǒng)計(jì)了現(xiàn)有部署資源、內(nèi)外部域名及調(diào)用關(guān)系、定時(shí)任務(wù)使用情況等詳細(xì)情況，為方案設(shè)計(jì)及實(shí)施落地提供有力的支撐。1514Rokid云原生十大經(jīng)典案例當(dāng)

Rokid

遇上函數(shù)計(jì)算Rokid

創(chuàng)立于

2014

年，是一家專注于人機(jī)交互技術(shù)的產(chǎn)品平臺公司。Rokid

通過語音識別、自然語言處理、計(jì)算機(jī)視覺、光學(xué)顯示、芯片平臺、硬件設(shè)計(jì)等多領(lǐng)域研究，將前沿的

Al和

AR

技術(shù)與行業(yè)應(yīng)用相結(jié)合，為不同垂直領(lǐng)域的客戶提供全棧式解決方案，有效提升用戶體驗(yàn)、助力企業(yè)增效、賦能公共安全，其

Al、AR

產(chǎn)品已在全球八十余個(gè)國家和地區(qū)投入使用。Rokid

Air

Pro

這款A(yù)R

眼鏡產(chǎn)品，為旅游景點(diǎn)，大型企業(yè)，國內(nèi)科研機(jī)構(gòu)都提供了服務(wù)支持。目前

Rokid

已和全國百余家博物館和景區(qū)達(dá)成合作，給游客穿越時(shí)空，身臨其境的非凡參觀體驗(yàn)。三維建圖，場景創(chuàng)作，場景體驗(yàn)三個(gè)場景都涉及到了的圖像處理，需要大量的

GPU

資源。其中三維建圖屬于離線任務(wù)，在構(gòu)建展陳模型時(shí)，需要將整個(gè)展陳場所的視頻內(nèi)容進(jìn)行預(yù)處理，是三個(gè)場景中消耗算力最大的部分；場景創(chuàng)作需要配合創(chuàng)作軟件，GPU

資源主要來自開發(fā)機(jī)器；場景體驗(yàn)在設(shè)備真實(shí)運(yùn)行時(shí)提供實(shí)時(shí)服務(wù)，主要功能是定位服務(wù)，對服務(wù)的實(shí)時(shí)性要求很高。為了支撐

GPU

算力的需求，Rokid

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

ECS

的

GPU

機(jī)型，用于業(yè)務(wù)的開發(fā)和測試。這里很大的問題是在三維建圖時(shí)，一般都會一次性采集展陳環(huán)境的所有場景資料，視頻量巨大，通過

ECS串行處理需要時(shí)間很長，一個(gè)

1

小時(shí)的視頻資料，通過一臺

ECS

GPU

機(jī)器需要處理

3

小時(shí)左右。Rokid

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

CPU

和

GPU

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

選擇的

GPU

計(jì)算資源是

ECI，相對

ECS，ECI

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

ECI

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

內(nèi)部平臺還開發(fā)了一套針對阿里云

ECI

資源的調(diào)度模塊，方便內(nèi)部快速的申請和歸還

ECI

資源。通過對

ECI

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

架構(gòu)革新的必要性Rokid

在

AR

的研究可以追溯到公司創(chuàng)立之初，在

2012

年

Google

Glass

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

Rokid

創(chuàng)始團(tuán)隊(duì)。后面雖然因?yàn)槭褂玫膱鼍昂透哳~的價(jià)格原因，Google

Glass

并沒有持續(xù)的火爆普及。但可以預(yù)計(jì)在不久的將來，隨著基礎(chǔ)設(shè)施，生態(tài)應(yīng)用的成熟，和人們持續(xù)提升的對娛樂，辦公的體驗(yàn)要求，AR

技術(shù)一定會得到更廣泛的應(yīng)用。Rokid

在數(shù)字文化領(lǐng)域，圍繞展陳導(dǎo)覽解決方案，主要形成了三維建圖，場景創(chuàng)作，場景體驗(yàn)三個(gè)業(yè)務(wù)模塊，每個(gè)模塊都有不同的后臺平臺支撐。制作展陳導(dǎo)覽的第一步是取景，通過設(shè)備獲取場地的真實(shí)布景，然后通過算法處理，進(jìn)行三維建模，之后可以經(jīng)過創(chuàng)作器進(jìn)行下一步的內(nèi)容創(chuàng)作。場景體驗(yàn)：AR

設(shè)備在使用時(shí)，根據(jù)定位服務(wù)，錨定在場景中的位置，根據(jù)位置的不同會顯示不同的空間內(nèi)容，達(dá)到擴(kuò)展現(xiàn)實(shí)場景的效果。01 三維建圖：02 場景創(chuàng)作：在三維建模生成的視頻流上創(chuàng)作，通過

Web3D

渲染引擎，將創(chuàng)作內(nèi)容與場景緊密結(jié)合，結(jié)合硬件設(shè)備，在

AR

設(shè)備使用時(shí)，形成一體化的體驗(yàn)效果。03ECI

資源的申請和釋放都依靠使用人員主動(dòng)操作，有時(shí)在使用完畢后會忘記及時(shí)釋放資源，導(dǎo)致資源閑置浪費(fèi)。且開發(fā)和維護(hù)

ECI

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

cGPU

技術(shù)，可將單卡

GPU

資源切分成多種更小粒度的資源規(guī)格?？蛻粼诤瘮?shù)計(jì)算選擇

GPU

規(guī)格創(chuàng)建函數(shù)，在有請求時(shí)，函數(shù)計(jì)算會實(shí)時(shí)從預(yù)熱資源池獲取資源，配合對應(yīng)的鏡像程序，啟動(dòng)客戶函數(shù)，啟動(dòng)完畢后對外提供服務(wù)。函數(shù)計(jì)算在第一次運(yùn)行實(shí)例時(shí)會涉及到資源的拉起，彈性交付時(shí)間在

1s（熱啟動(dòng)）～

20s（冷啟動(dòng)）。Rokid

的三維建圖場景是離線任務(wù)，單個(gè)視頻的處理時(shí)間也在分鐘級，對于秒級別的啟動(dòng)時(shí)延完全可以接受。在三維建圖任務(wù)接入函數(shù)計(jì)算后，Rokid

不再需要手動(dòng)申請

ECI

資源，在使用結(jié)束之后也不需要在手動(dòng)釋放。函數(shù)計(jì)算會根據(jù)請求流量，動(dòng)態(tài)的拉起與請求量匹配的后端

GPU

算力資源，在請求處理結(jié)束后，一段時(shí)間沒有新請求的情況下，自動(dòng)釋放資源；整個(gè)三維建模在拆分后涉及好幾個(gè)步驟，每個(gè)步驟都是異步執(zhí)行，通過函數(shù)計(jì)算的異步系統(tǒng)，在一個(gè)步驟的任務(wù)完成后，可以自動(dòng)觸發(fā)下一個(gè)任務(wù)；函數(shù)計(jì)算控制臺內(nèi)置了指標(biāo)監(jiān)控，異常告警，鏈路追蹤，調(diào)用日志，異步配置的功能，可以滿足

Rokid

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

Rokid

之前遇到的痛點(diǎn)問題，通過接入函數(shù)計(jì)算單一的產(chǎn)品，就解決了

Rokid

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

內(nèi)部架構(gòu)組尋求優(yōu)化已有的架構(gòu)，針對第

2

點(diǎn)，Rokid

自行維護(hù)了一個(gè)總的調(diào)度系統(tǒng)，進(jìn)行任務(wù)編排；針對第

3

點(diǎn)，通過阿里云

ARMS

Tracing，Prometheus，Grafana

等組件的引入，結(jié)合

ECI

硬件指標(biāo)，統(tǒng)一收集到

SLS，形成統(tǒng)一的監(jiān)控報(bào)表，再配以監(jiān)控指標(biāo)的告警，也能夠初步的滿足

Rokid

使用需求。但第

1

點(diǎn)和第

4點(diǎn)，很難通過增加云產(chǎn)品或者內(nèi)部應(yīng)用程序解決。為此

Rokid

架構(gòu)組開始尋找云上新的產(chǎn)品，以求徹底的解決使用過程中的痛點(diǎn)問題。此時(shí)，Serverless

架構(gòu)的函數(shù)計(jì)算出現(xiàn)在了Rokid

架構(gòu)師的視野，經(jīng)過一段時(shí)間的調(diào)研使用，函數(shù)計(jì)算的各項(xiàng)能力都能夠很好的滿足Rokid

使用場景。三維建模的任務(wù)經(jīng)過拆分后，分成了好幾個(gè)步驟，每個(gè)步驟的任務(wù)都需要異步執(zhí)行，需要一個(gè)系統(tǒng)維持任務(wù)的調(diào)用關(guān)系，在上一個(gè)步驟完成后，拉起下一個(gè)步驟的任務(wù)繼續(xù)運(yùn)行。在運(yùn)行過程中，會存在異常情況，排查下來，有時(shí)是因?yàn)樯暾埖挠?jì)算資源規(guī)格過小導(dǎo)致計(jì)算負(fù)載較高，有時(shí)是存儲異?；虼鎯臻g寫滿，還有些情況是程序本身性能瓶頸。對于程序的整體監(jiān)控缺乏，使得出現(xiàn)問題時(shí)不能第一時(shí)間發(fā)現(xiàn)，發(fā)現(xiàn)有異常排查過程不夠直觀，需要通過多種工具獲取運(yùn)行指標(biāo)分析。GPU

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

ECI

資源彈不出的情況，影響開發(fā)效率。020304函數(shù)計(jì)算是事件驅(qū)動(dòng)的全托管計(jì)算服務(wù)。使用函數(shù)計(jì)算，客戶無需采購與管理服務(wù)器等基礎(chǔ)設(shè)施，只需編寫并上傳代碼或鏡像。函數(shù)計(jì)算會準(zhǔn)備好計(jì)算資源，彈性地、可靠地運(yùn)行任務(wù)，并提供日志查詢、性能監(jiān)控和報(bào)警等功能。函數(shù)計(jì)算提供

CPU，GPU

的算力，秒級計(jì)費(fèi)，客戶只需要為實(shí)際資源使用付費(fèi)。資源彈性可根據(jù)定時(shí)，請求量等指標(biāo)自動(dòng)伸縮，無需維護(hù)調(diào)度，負(fù)載，重試，異步回調(diào)等組件，提供了開箱即用，用完即走，按量付費(fèi)的極致Serverless

能力。函數(shù)計(jì)算

GPU

架構(gòu)如下：二

.

函數(shù)計(jì)算的出現(xiàn)恰逢其時(shí)1918接入函數(shù)計(jì)算后，Rokid

的云產(chǎn)品技術(shù)架構(gòu)如下：函數(shù)計(jì)算資源利用率監(jiān)控圖如下，從監(jiān)控圖可以看出，在有任務(wù)進(jìn)入時(shí)，GPU

計(jì)算利用率可以達(dá)到

60%

甚至接近

100%。三.

體驗(yàn)與架構(gòu)的妥協(xié)Serverless

理念的函數(shù)計(jì)算確實(shí)給

Rokid

帶了很多的便利，在高峰期資源的擴(kuò)展性和成本節(jié)約方面都做到了當(dāng)前云產(chǎn)品的極致，但函數(shù)計(jì)算也并非萬能，對于

Rokid

的場景體驗(yàn)功能，也就是需要實(shí)時(shí)提供定位服務(wù)的模塊，函數(shù)計(jì)算還是存在了一定的問題。函數(shù)計(jì)算在第一次拉起實(shí)例資源時(shí)，會存在

1s（熱啟動(dòng)）～

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

AR

拓展信息，接口響應(yīng)的時(shí)間對客戶的體驗(yàn)非常重要，定位請求需要在

1s

以內(nèi)返回。在成本和服務(wù)質(zhì)量之間，Rokid

選擇了服務(wù)質(zhì)量優(yōu)先，場景體驗(yàn)?zāi)K采用

ECI

部署，通過每天的定時(shí)任務(wù)，在高峰期提前彈出更多的

ECI

實(shí)例，在低峰期時(shí)，保留少量的

ECI

實(shí)例，以此達(dá)到體驗(yàn)和成本的平衡。另一方面，函數(shù)計(jì)算在實(shí)時(shí)的場景也并非完全沒有解決方案。目前

GPU

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

G

級別，所以對于第一次資源拉起，在接下來一段時(shí)間內(nèi)還看不到跟

CPU

資源一樣

100ms

級別的拉起速度。針對實(shí)時(shí)場景，函數(shù)計(jì)算

GPU

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

CPU

實(shí)例上線，閑置時(shí)

CPU

價(jià)格是運(yùn)行態(tài)的

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

版本的預(yù)留能力預(yù)計(jì)年底上線。場景體驗(yàn)采用

ECI

后，Rokid

的業(yè)務(wù)架構(gòu)圖如下：Rokid云原生十大經(jīng)典案例2120四.出色的效果和進(jìn)一步的期待一.

客戶介紹與項(xiàng)目背景通過一系列的云架構(gòu)改造，當(dāng)前

Rokid

三維建圖模塊運(yùn)行在函數(shù)計(jì)算的

GPU

資源上，場景體驗(yàn)?zāi)K運(yùn)行在

ECI

資源，在成本和性能上，都做到了兼顧，且給整個(gè)系統(tǒng)強(qiáng)大的可拓展性，達(dá)到了系統(tǒng)設(shè)計(jì)時(shí)設(shè)定的架構(gòu)目標(biāo)，從

2023/2

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

ECS

架構(gòu)，算力成本降低了

40%，更為重要的是，通過實(shí)時(shí)的并發(fā)處理，大大減少了子任務(wù)的排隊(duì)時(shí)間，加快了整個(gè)任務(wù)的完成時(shí)間。下一步，Rokid

對于函數(shù)計(jì)算的

GPU

預(yù)留實(shí)例還是非常期待，期待函數(shù)計(jì)算能夠盡快上線，這樣

Rokid

內(nèi)部可以將整個(gè)的

GPU

算力都遷移到函數(shù)計(jì)算，達(dá)到架構(gòu)的統(tǒng)一。經(jīng)過展陳展覽項(xiàng)目的實(shí)踐，Rokid

相信以函數(shù)計(jì)算為代表的

Serverless

一定是云計(jì)算的未來，通過

Serverless，云計(jì)算的使用者不再需要關(guān)注底層的

Iaas

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

在

3d

模型處理，音視頻后處理方面正在大規(guī)模嘗試函數(shù)計(jì)算，Rokid

相信以函數(shù)計(jì)算為代表的

Serverless

架構(gòu)也一定會在越來越多的云產(chǎn)品上得到應(yīng)用。Rokid極氪云原生十大經(jīng)典案例ARMS

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

2021

年

3

月成立，2021

年

4

月發(fā)布極氪品牌及旗下首款產(chǎn)品——極氪

001。極氪是一家以智能化、數(shù)字化、數(shù)據(jù)驅(qū)動(dòng)的智能出行科技公司，秉承用戶型企業(yè)理念，聚焦智能電動(dòng)出行前瞻技術(shù)的研發(fā)，構(gòu)建科技生態(tài)圈與用戶生態(tài)圈，以“共創(chuàng)極致體驗(yàn)的出行生活”為使命，從產(chǎn)品創(chuàng)新、用戶體驗(yàn)創(chuàng)新到商業(yè)模式創(chuàng)新，致力于為用戶帶來極致的出行體驗(yàn)。截止

2023

年

4

月，極氪量產(chǎn)車交付已經(jīng)突破

10

萬輛，從

0

到

10

萬輛，極氪用時(shí)僅兩年，快于其他新勢力品牌至少四年以上的時(shí)間，持續(xù)刷新新勢力品牌交付記錄，這不僅是對“極氪速度”的展現(xiàn)，也是對“中國速度”最好的詮釋。為了保障好極氪汽車業(yè)務(wù)的快速發(fā)展和用戶體驗(yàn)，技術(shù)團(tuán)隊(duì)除了保持高效的功能迭代的同時(shí)，也在不斷的夯實(shí)其系統(tǒng)穩(wěn)定性和應(yīng)急響應(yīng)能力。自

2023

年開始，大數(shù)據(jù)團(tuán)隊(duì)正試點(diǎn)推行面向極數(shù)

BI

業(yè)務(wù)的數(shù)字化穩(wěn)定性治理建設(shè)。032322極氪云原生十大經(jīng)典案例極數(shù)

BI

是一款面向極氪經(jīng)營管理全體系的可視化數(shù)據(jù)分析系統(tǒng)，已覆蓋多個(gè)核心業(yè)務(wù)場景。極數(shù)

BI

不僅僅是一個(gè)報(bào)表工具，還提供了全域數(shù)據(jù)互聯(lián)互通、智能化數(shù)據(jù)分析和全景數(shù)據(jù)可視化的功能，可以為其他業(yè)務(wù)“發(fā)生了什么、為什么發(fā)生、將要發(fā)生什么、如何應(yīng)對”提供完善的數(shù)據(jù)支撐和輔助決策能力。打破數(shù)字鴻溝，創(chuàng)造數(shù)據(jù)價(jià)值，逐步實(shí)現(xiàn)全業(yè)務(wù)域的經(jīng)營過程觀測與經(jīng)營結(jié)果呈現(xiàn)是極數(shù)

BI

的發(fā)展目標(biāo)。為保障極數(shù)

BI

的數(shù)字化穩(wěn)定性治理建設(shè)落地，極氪通過建設(shè)端到端的全鏈路可觀測體系、企業(yè)級應(yīng)急響應(yīng)機(jī)制和跨部門團(tuán)隊(duì)的人員協(xié)同機(jī)制，以業(yè)務(wù)連續(xù)性保障為目標(biāo)，實(shí)現(xiàn)了極數(shù)BI

業(yè)務(wù)的“X

分鐘的故障發(fā)現(xiàn)與通報(bào)”、“X

分鐘的應(yīng)急響應(yīng)與故障定位”、“X

分鐘的故障恢復(fù)”核心穩(wěn)定性指標(biāo)的達(dá)成。如何構(gòu)建統(tǒng)一的報(bào)警體系、通報(bào)機(jī)制和跨團(tuán)隊(duì)?wèi)?yīng)急協(xié)同機(jī)制系統(tǒng)資源層、云服務(wù)應(yīng)用層、業(yè)務(wù)監(jiān)控層，為了監(jiān)控這些復(fù)雜的

IT

環(huán)境，由于各層資源分屬不同的團(tuán)隊(duì)進(jìn)行管理，導(dǎo)致采用了多種監(jiān)控系統(tǒng)，例如

Prometheus、Grafana、Skywalking、阿里云云監(jiān)控、阿里云ARMS

等，以獲取更全面的監(jiān)控?cái)?shù)據(jù)和更好的了解運(yùn)行狀態(tài)和性能表現(xiàn)。然而多種監(jiān)控系統(tǒng)的并存帶來的其中一個(gè)顯著問題是告警信息的分散，不同的監(jiān)控系統(tǒng)產(chǎn)生不同的告警信息，通過不一致的方式通報(bào)給告警處理人，而告警的排查通常需要多個(gè)團(tuán)隊(duì)共同合作進(jìn)行處理，縱橫交錯(cuò)的告警處理增加了人員響應(yīng)的復(fù)雜性和工作量，疲于應(yīng)付的程度往往遠(yuǎn)超出了告警處理人員的日常負(fù)荷。02如何規(guī)范故障等級定義、應(yīng)急處置流程和故障管理體系業(yè)務(wù)可用率是一套業(yè)務(wù)系統(tǒng)可靠性、維修性和維修保障性的綜合反映。Availability

=

MTBF

/

(MTBF

+

MTTR)，

通常業(yè)界習(xí)慣用

N

個(gè)

9

來表

征

系

統(tǒng)

可

用

性，

比

如

99.9%（3-9

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

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

0。03如何有效度量業(yè)務(wù)穩(wěn)定性指標(biāo)和應(yīng)急響應(yīng)SLA如何查看過去一段時(shí)間系統(tǒng)發(fā)生了哪些告警，哪類告警占比較高；制定了值班機(jī)制，但無法衡量值班人員告警處理的效率，如何確保值班機(jī)制的執(zhí)行效果；一個(gè)服務(wù)在多個(gè)系統(tǒng)中配置了多個(gè)告警，無法從服務(wù)的維度來查看告警的處理效率，查看服務(wù)的

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

.

項(xiàng)目落地時(shí)面臨的挑戰(zhàn)和需求云原生浪潮下，Serverless

因其全托管免運(yùn)維、成本降低和彈性伸縮等特性正逐步在引領(lǐng)下一代的應(yīng)用架構(gòu)。極數(shù)

BI

業(yè)務(wù)從立項(xiàng)之初就確定了

Serverless

化的方向，并基于阿里云

Serverless

應(yīng)用引擎（SAE）成功落地。應(yīng)用

Serverless

化最大化限度減輕了運(yùn)維工作，但是在自身業(yè)務(wù)的數(shù)字化穩(wěn)定性治理方面依然面臨較大挑戰(zhàn)：如何覆蓋和收斂從基礎(chǔ)設(shè)施到業(yè)務(wù)應(yīng)用監(jiān)控的全鏈路告警事件從前臺業(yè)務(wù)數(shù)據(jù)、用戶體驗(yàn)，到后臺應(yīng)用服務(wù)性能，再到云服務(wù)及基礎(chǔ)資源，即系統(tǒng)資源層、云服務(wù)應(yīng)用層、業(yè)務(wù)監(jiān)控層，雖然針對不同的服務(wù)模塊都有對應(yīng)監(jiān)控，構(gòu)建了相對完善的指標(biāo)監(jiān)控體系，但由于微服務(wù)化后的服務(wù)模塊眾多、依賴復(fù)雜，很有可能因?yàn)槟硞€(gè)組件的異常或不可用導(dǎo)致整條鏈路產(chǎn)生大量冗余告警，形成告警風(fēng)暴，從而造成運(yùn)維團(tuán)隊(duì)012524極氪云原生十大經(jīng)典案例三.

基于

ARMS

的企業(yè)級應(yīng)急響應(yīng)解決方案針對上述面臨的問題和挑戰(zhàn)，阿里云云原生可觀測團(tuán)隊(duì)與大數(shù)據(jù)團(tuán)隊(duì)經(jīng)過多輪溝通對焦，通力合作共同輸出了基于

ARMS

構(gòu)建企業(yè)級應(yīng)急響應(yīng)體系的最佳實(shí)踐，并成功在極數(shù)

BI

業(yè)務(wù)中落地，實(shí)現(xiàn)了全業(yè)務(wù)、全場景的監(jiān)控和告警。同時(shí)全面提升了監(jiān)控的覆蓋率和告警有效率，其中按照極氪現(xiàn)行推廣的應(yīng)急響應(yīng)機(jī)制，全團(tuán)隊(duì)事件接手率顯著提升，告警平均認(rèn)領(lǐng)耗時(shí)（MTTA）大幅降低，告警平均恢復(fù)耗時(shí)（MTTR）明顯縮短，跨團(tuán)隊(duì)協(xié)同效率得到有效提升。采用

ARMS

智能告警建設(shè)統(tǒng)一的告警事件管理中心極氪技術(shù)團(tuán)隊(duì)根據(jù)自身業(yè)務(wù)屬性使用了多種監(jiān)控系統(tǒng)，例如阿里云應(yīng)用監(jiān)控

ARMS、阿里云日志服務(wù)

SLS、Zabbix、Prometheus、Grafana

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

ARMS

智能告警作為多告警源統(tǒng)一管理的事件管理中心。ARMS

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

智能告警參考開源

Prometheus

告警定義，使用一個(gè)半結(jié)構(gòu)化的數(shù)據(jù)結(jié)構(gòu)來描述告警。通過高度可擴(kuò)展的鍵值對來描述告警，這樣就可以非常靈活的對告警內(nèi)容進(jìn)行擴(kuò)展從而接入不同的數(shù)據(jù)源產(chǎn)生的告警。通過告警集成的字段映射能力，即可將自定義的告警內(nèi)容中的關(guān)鍵信息映射到

ARMS

告警數(shù)據(jù)結(jié)構(gòu)中。同時(shí)也提供了多種監(jiān)控工具的快捷接入能力，像極氪這邊使用的阿里云應(yīng)用監(jiān)控

ARMS、阿里云日志服務(wù)

SLS、Zabbix、Prometheus、Grafana

等均已覆蓋。告警等級統(tǒng)一定義。根據(jù)影響面的不同、業(yè)務(wù)受損程度的不同,一般需要定義不同的告警等級，告警處理人員需要根據(jù)不同的告警等級執(zhí)行不同的應(yīng)急處理過程。按照極氪的故障等級規(guī)范

,

配置告警時(shí)根據(jù)業(yè)務(wù)情況將告警歸一到

P0、P1、P2、P3

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

ARMS

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

認(rèn)領(lǐng)告警有些告警觸發(fā)屬于預(yù)期內(nèi)的行為，且不會造成業(yè)務(wù)影響，但是又不能直接關(guān)閉告警。這種情況下可以通過屏蔽告警來降低告警通知的打擾。02

屏蔽告警關(guān)注告警后，會將被關(guān)注告警的狀態(tài)變更以短信的形式推送給關(guān)注人。對于重大故障的情況下，團(tuán)隊(duì)負(fù)責(zé)人可以通過關(guān)注告警的能力實(shí)時(shí)訂閱關(guān)注告警處理的進(jìn)展，從而為指揮決策提供數(shù)據(jù)支撐。03關(guān)注告警關(guān)閉告警并在群聊中發(fā)送一個(gè)告警關(guān)閉的通知，被關(guān)閉的告警狀態(tài)會變成已恢復(fù)。04

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

ChatOps

掌上運(yùn)維能力ChatOps

是一種集成了聊天和自動(dòng)化工具的協(xié)作方法和文化，旨在提高團(tuán)隊(duì)的協(xié)作效率和可見性。ChatOps

的目標(biāo)是提高工作流程的效率和可見性，并促進(jìn)團(tuán)隊(duì)成員之間的協(xié)作和溝通。極氪內(nèi)部使用企業(yè)微信作為辦公協(xié)同工具，ARMS

智能告警支持對接企業(yè)微信，通過創(chuàng)建企業(yè)微信機(jī)器人，即可在通知策略中指定對應(yīng)的企業(yè)微信群用于接收告警，相關(guān)告警信息僅在企業(yè)微信的極氪內(nèi)部企業(yè)組織內(nèi)流轉(zhuǎn)。當(dāng)通知策略的匹配規(guī)則被觸發(fā)時(shí)，系統(tǒng)會自動(dòng)向指定的企業(yè)微信群發(fā)送告警通知。企業(yè)微信群收到通知后，便可以隨時(shí)隨地在企業(yè)微信群中對告警進(jìn)行管理。源于ITIL理念且適用于極氪組織架構(gòu)和業(yè)務(wù)屬性的事件管理體系大數(shù)據(jù)團(tuán)隊(duì)目前正在極數(shù)

BI

業(yè)務(wù)推廣的數(shù)字化穩(wěn)定性治理機(jī)制最核心的部分就是構(gòu)建一套標(biāo)準(zhǔn)規(guī)范的事件管理流程。流程上包含告警發(fā)現(xiàn)、告警通報(bào)、告警響應(yīng)/

接手、告警定位、指揮決策、告警恢復(fù)、故障復(fù)盤和持續(xù)改進(jìn)。從人員組織上包括運(yùn)維團(tuán)隊(duì)、告警值班人員、告警處置技術(shù)人員、應(yīng)急指揮人員等。當(dāng)告警觸發(fā)接收到通報(bào)后，告警值班人員需要迅速建立針對告警關(guān)聯(lián)團(tuán)隊(duì)的高效協(xié)同渠道，故障應(yīng)急啟動(dòng)后。技術(shù)同學(xué)需要盡快完成簽到，同時(shí)同步進(jìn)行故障快速止血、根因定位排查、信息同步，如果在預(yù)期時(shí)間內(nèi)未接手簽到，告警通知將逐步升級。運(yùn)維團(tuán)隊(duì)和應(yīng)急指揮人員要負(fù)責(zé)統(tǒng)籌收集相關(guān)數(shù)據(jù)并同步影響面、處理進(jìn)展和恢復(fù)進(jìn)展，定時(shí)播報(bào)，更新告警處理情況。當(dāng)告警以卡片的形式發(fā)送到

IM

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

IM

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

@

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

ARMS

聯(lián)系人、通知策略中配置的通知對象和綁定處理人手機(jī)號相同即可實(shí)現(xiàn)告警通知時(shí)根據(jù)排班情況

@

值班人員。2928極氪云原生十大經(jīng)典案例ARMS

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

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

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

智能告警提供了告警手動(dòng)恢復(fù)的能力，當(dāng)告警事件在告警集成中設(shè)置的自動(dòng)恢復(fù)時(shí)間內(nèi)都沒有再觸發(fā)，告警不會自動(dòng)恢復(fù)，必須人工干預(yù)調(diào)整狀態(tài)。滿足極氪對值班人員接手率考核和度量的要求。02

通知策略靈活、自定義的

ARMS

Grafana

應(yīng)急響應(yīng)數(shù)據(jù)大盤如果沒有數(shù)據(jù)報(bào)告和持續(xù)運(yùn)營，那么對現(xiàn)狀的了解就會充滿了模糊和不確定性，事件管理對整體業(yè)務(wù)的提升就沒法落到實(shí)處?？陀^的數(shù)據(jù)雖然不能替代溝通和觀察，但是通過數(shù)據(jù)共享和信息的可視化，能夠有效的促進(jìn)共識的達(dá)成，大家都能夠共同的看到和了解數(shù)據(jù)變化和現(xiàn)狀，促進(jìn)相互協(xié)作。ARMS

智能告警默認(rèn)提供歷史告警總覽和告警處理效率兩張數(shù)據(jù)大盤，大盤提供了告警統(tǒng)計(jì)、告警趨勢、MTTx

指標(biāo)、人員效率等一系列告警度量數(shù)據(jù)，這些數(shù)據(jù)存儲在默認(rèn)的

Prometheus

實(shí)例中。極氪則根據(jù)自身運(yùn)維訴求基于原始數(shù)據(jù)在

ARMSGrafana

服務(wù)中配置了自定義的應(yīng)急響應(yīng)度量大盤，包括值班狀態(tài)、告警概覽、告警接手情況和

MTTx

指標(biāo)等，幫助運(yùn)維團(tuán)隊(duì)能夠?qū)崟r(shí)了解業(yè)務(wù)告警狀態(tài)及應(yīng)急處置情況，大幅提升了應(yīng)急響應(yīng)效率。測試數(shù)據(jù)大盤示意圖四.

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

ARMS

智能告警新發(fā)布的靜態(tài)閾值推薦、告警數(shù)預(yù)測、區(qū)間檢測和告警規(guī)則測試等能力將借助智能化的手段幫助極氪進(jìn)一步提升告警規(guī)則配置效率。同時(shí)

ARMS

智能告警新增支持行動(dòng)集成，提供函數(shù)計(jì)算

FC

和自定義

Webhook

的行動(dòng)集成能力，基于行動(dòng)集成提供的可執(zhí)行的任務(wù)能夠作為告警快速止血的預(yù)案，對于具有確定性特征的告警，能夠提供快速的止血恢復(fù)手段，可以有效縮短實(shí)際的告警恢復(fù)時(shí)長。業(yè)務(wù)系統(tǒng)的穩(wěn)定性和應(yīng)急響應(yīng)效率，是品牌口碑和用戶體驗(yàn)的基石，阿里云將堅(jiān)定不移的為客戶提供極致“穩(wěn)定、安全、性能、成本”的產(chǎn)品和方案，助力客戶業(yè)務(wù)再攀高峰。3130創(chuàng)米數(shù)聯(lián)云原生十大經(jīng)典案例支撐

“千萬設(shè)備日活”

的創(chuàng)米數(shù)聯(lián)

7

年微服務(wù)架構(gòu)演進(jìn)之路創(chuàng)米數(shù)聯(lián)是小米生態(tài)鏈?zhǔn)着鷥|元俱樂部成員，主營業(yè)務(wù)為智能家居產(chǎn)品的研發(fā)、設(shè)計(jì)、生產(chǎn)和銷售，致力于成為以居家安全為核心的產(chǎn)品和服務(wù)提供商，提供多品類的全屋智能家居產(chǎn)品及服務(wù)。公司以居家安全為核心，洞察用戶在居住環(huán)境下的智能化需求，建立物理安全、環(huán)境安全、系統(tǒng)安全三類場景及服務(wù)體系，主要產(chǎn)品包括智能攝像機(jī)、智慧門、智能貓眼、智能門鈴、智能插座等。公司旨在實(shí)現(xiàn)“看得見的全屋智能”，以智能家庭安全為切入點(diǎn)，提供多品類覆蓋的智能家居解決方案。截至

2021

年

12

月

31

日，創(chuàng)米數(shù)聯(lián)已經(jīng)在全世界150

多個(gè)國家，銷售了超過

5500

萬臺設(shè)備，擁有了

1600

萬設(shè)備和

500

萬設(shè)備用戶日活。作為小米生態(tài)鏈的一員，創(chuàng)米采用微服務(wù)架構(gòu)支撐其千萬日活的

IOT

設(shè)備。隨著智能家居市場的快速迭代，創(chuàng)米面臨著發(fā)布和迭代的穩(wěn)定性挑戰(zhàn)，同時(shí)需要解決多方

IOT

接入面臨的性能和安全挑戰(zhàn)。本文將為您一一道來創(chuàng)米是如何應(yīng)對這些挑戰(zhàn)的。從

2019

年伊始，創(chuàng)米數(shù)聯(lián)提出了研發(fā)自有

APP

和適配自有

APP

的智能家居設(shè)備的發(fā)展戰(zhàn)略。云服務(wù)部將研發(fā)重心轉(zhuǎn)向自有

APP

云端業(yè)務(wù)，并逐步接入自有品牌設(shè)備。為了實(shí)現(xiàn)全球業(yè)務(wù)，創(chuàng)米云服務(wù)部將相關(guān)服務(wù)部署在阿里云的

4

個(gè)

Region

的

ACK

Pro

專有版

Kubernetes

集群上。阿里云

ACK

為創(chuàng)米云提供了可靠穩(wěn)定的基礎(chǔ)設(shè)施，向下封裝好的數(shù)十款云產(chǎn)品，降低了云端運(yùn)維人員的運(yùn)維壓力，快速對接其他云產(chǎn)品的能力也對開發(fā)人員十分友好，能夠讓創(chuàng)米云服務(wù)在極短的時(shí)間內(nèi)搭建一套線上可用的環(huán)境。在自有業(yè)務(wù)研發(fā)開始階段，我們選擇了

Spring

Cloud、Eureka

和Apollo

等技術(shù)棧來搭建我們的微服務(wù)基礎(chǔ)架構(gòu)。然而，經(jīng)過一年半的摸索，我們發(fā)現(xiàn)當(dāng)前的混合架構(gòu)存在著不穩(wěn)定、上線部署風(fēng)險(xiǎn)大以及高人力維護(hù)成本等問題。因此，從

2021

年開始，創(chuàng)米云服務(wù)決定改變現(xiàn)有的微服務(wù)架構(gòu)，逐步擁抱云原生。我們的目標(biāo)是在滿足穩(wěn)定性和低維護(hù)成本等需求的基礎(chǔ)上，實(shí)現(xiàn)所有組件的可觀測性、全鏈路的流量治理以及更加便捷高效的DevOps

流程。首先我們將當(dāng)前的

Spring

Cloud

體系全面轉(zhuǎn)向

Spring

CloudAlibaba，使用

Nacos

替換

Eureka，以解決

Eureka

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

Apollo

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

Apollo

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

Apollo

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

Nacos

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

Nacos

服務(wù)，而是直接使用了阿里云

MSE

Nacos

專業(yè)版服務(wù)。至今，該服務(wù)一直穩(wěn)定運(yùn)行，沒有出現(xiàn)可用性問題。云計(jì)算時(shí)代的蹣跚學(xué)步創(chuàng)米云服務(wù)從

2016

年創(chuàng)始之初就選擇了云計(jì)算

+

微服務(wù)的技術(shù)路線，以應(yīng)對面臨的大量線上用戶和設(shè)備帶來的流量挑戰(zhàn)。構(gòu)建微服務(wù)之初，市面上可選用的解決方案并不多，我們自主實(shí)現(xiàn)了一些微服務(wù)組件，如

frontend

業(yè)務(wù)網(wǎng)關(guān)和配置中心，并在小米生態(tài)云上部署容器服務(wù)來處理設(shè)備消息、設(shè)備插件

API

和微信公眾號等相關(guān)業(yè)務(wù)，并利用

HPA

及

CronHPA等容器彈性伸縮策略來應(yīng)對動(dòng)態(tài)的海量線上流量。自此創(chuàng)米數(shù)聯(lián)在云計(jì)算時(shí)代踏上了探索服務(wù)容器化的第一步。新業(yè)務(wù)及新挑戰(zhàn)云原生體系探索043332針對全鏈路的流量治理，由于創(chuàng)米云服務(wù)所處的

AIoT

行業(yè)不同于傳統(tǒng)互聯(lián)網(wǎng)行業(yè)，我們在南北向流量時(shí)不僅需要治理下游用戶手機(jī)端

APP

及Web

端的

HTTP

請求，還需要處理來自設(shè)備端的

MQTT、第三方

AMQP和

HTTP

2

長連接

Push

消息的流量治理。這些消息通常經(jīng)由統(tǒng)一的上游消息網(wǎng)關(guān)（消息總線）監(jiān)聽，經(jīng)過多級過濾器，如消息來源、消息限流和產(chǎn)品或特定設(shè)備級別的白名單等，對消息進(jìn)行分類和打標(biāo)簽，然后對消息

Topic

正則路由并進(jìn)行

HTTP

異步或

rpc

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

Istio

Service

Mesh

的方案治理流量。然而，前者在當(dāng)前百萬級別設(shè)備消息的情況下性能嚴(yán)重受限，后者由于設(shè)備消息鏈路較長、打標(biāo)較多，導(dǎo)致實(shí)現(xiàn)全鏈路灰度時(shí)配置文件實(shí)現(xiàn)較為復(fù)雜，而且Envoy

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

MSE

微服務(wù)治理。我們傳統(tǒng)的

API

業(yè)務(wù)流量治理選用了多域名、多租戶環(huán)境、節(jié)點(diǎn)隔離加多業(yè)務(wù)網(wǎng)關(guān)的方案配合

MSE

微服務(wù)治理來實(shí)現(xiàn)多個(gè)環(huán)境服務(wù)的測試開發(fā)及線上灰度部署。我們使用多域名加

DNS

流量劃分的方式對服務(wù)重構(gòu)后的業(yè)務(wù)網(wǎng)關(guān)新路由進(jìn)行測試，保證服務(wù)重構(gòu)后的安全上線。我們利用多個(gè)

K8s

集群、K8s

namespace

以及多個(gè)

namespace

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

namespace

的應(yīng)用

pod

使用多集群隔離、應(yīng)用節(jié)點(diǎn)親和性、反親和性以及節(jié)點(diǎn)污點(diǎn)等集群調(diào)度手段保證環(huán)境的安全性，避免不同環(huán)境間出現(xiàn)的資源異常導(dǎo)致基線環(huán)境不可用的情況?；€環(huán)境和灰度環(huán)境同屬不同命名空間的相同節(jié)點(diǎn)池內(nèi)，測試和開發(fā)環(huán)境應(yīng)用

pod

部署在不同的

K8s

集群或節(jié)點(diǎn)池中。我們的整體流程通常是在

feature

及

bug

修復(fù)后涉及的服務(wù)在開發(fā)環(huán)境聯(lián)調(diào)完畢，在每次測試流程前將

feature

服務(wù)部署至測試環(huán)境，通過藍(lán)綠測試將測試人員的流量導(dǎo)向測試環(huán)境，在多輪的覆蓋及回歸測試完成后，將服務(wù)部署至灰度環(huán)境，再將測試人員及

Beta

測試用戶的流量導(dǎo)向灰度環(huán)境，經(jīng)過一定時(shí)間的檢驗(yàn)后，逐步將線上基線流量導(dǎo)向灰度環(huán)境，灰度環(huán)境流量完成

100%

灰度后，替換基線環(huán)境鏡像，最后逐步將灰度流量倒流至基線環(huán)境。在核心業(yè)務(wù)接入

MSE

微服務(wù)治理之后，創(chuàng)米云服務(wù)對部分多云部署及老項(xiàng)目通過

DNS

流量切分

+

全鏈路灰度的方式進(jìn)行灰度，逐漸將自有

APP

及自有設(shè)備的所有業(yè)務(wù)重構(gòu)遷移至新項(xiàng)目中并全部接入

MSE

微服務(wù)，實(shí)現(xiàn)了云上

API

業(yè)務(wù)的

100%

安全發(fā)布。在設(shè)備消息業(yè)務(wù)的流量治理的推進(jìn)過程中，為了解決無法攔截消息請求的問題，我們首先將消息總線拆分為控制器和路由器兩部分?？刂破鞅O(jiān)聽各個(gè)通道的消息后僅對消息進(jìn)行打標(biāo)簽和分類，然后通過異步

HTTP

請求經(jīng)由統(tǒng)一的路由器轉(zhuǎn)發(fā)到各個(gè)服務(wù)中。我們將路由器服務(wù)定義為流量治理的入口，從而解決了消息無法治理的問題。然后，我們使用統(tǒng)一的全鏈路灰度對打標(biāo)簽后的

HTTP

請求進(jìn)行藍(lán)綠和灰度的流量治理，并將其分發(fā)到指定的命名空間的指定服務(wù)中進(jìn)行消息處理。MSE

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

Helm

或組件中心安裝

ack-onepilot

組件，重啟服務(wù)便可自動(dòng)注入服務(wù)，除此之外

MSE

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

Istio方案更加易于配置和上手。通過這樣的流程，創(chuàng)米云服務(wù)成功實(shí)現(xiàn)了設(shè)備服務(wù)的更新、云云設(shè)備的對接以及固件

OTA

版本的迭代過程中的安全發(fā)布。創(chuàng)米數(shù)聯(lián)云原生十大經(jīng)典案例全鏈路流量治理3534在之前的服務(wù)發(fā)版部署或

pod

彈性伸縮過程中經(jīng)常會有部分請求出現(xiàn)超時(shí)或不可用的情況，由于創(chuàng)米云服務(wù)承載了大量的用戶設(shè)備請求，這些流量損失輕則導(dǎo)致設(shè)備消息重試，嚴(yán)重時(shí)會影響部分用戶設(shè)備的可用性，后續(xù)我們了解了

MSE

微服務(wù)治理提供了無損上下線及服務(wù)預(yù)熱功能，決定將相關(guān)服務(wù)全部接入了

MSE

微服務(wù)治理的無損上下線，并調(diào)整對應(yīng)服務(wù)的就緒檢查，在后續(xù)的服務(wù)上下線過程中經(jīng)觀察再未出現(xiàn)因?yàn)榱髁繐p失導(dǎo)致的請求不可用的情況，一定程度上避免了由部署發(fā)布和服務(wù)縮容引起的線上流量損失問題。為了實(shí)現(xiàn)可觀測性，我們早期就將阿里云

SLS

日志服務(wù)集成到自有業(yè)務(wù)框架中。然而，我們遇到了業(yè)務(wù)索引不規(guī)范、唯一

RequestId

索引異步丟失以及

Spring

Cloud

Gateway

等

Reactive

框架應(yīng)用日志異步寫入

Location

導(dǎo)致

CPU

占用過高等問題。因此，我們對當(dāng)前的日志規(guī)范進(jìn)行了改進(jìn)，并在多個(gè)鏈路追蹤方案中選擇了

Skywalking。我們將Skywalking

的

TraceId

寫入

SLS

日志索引中，并通過對

ThreadLocal無損上下線解決發(fā)布擴(kuò)縮容流量損失問題無損下線邏輯圖新