0　引言

隨著以容器、微服務(wù)、DevOps為代表的云原生架構(gòu)的不斷豐富和落地，各大企業(yè)業(yè)務(wù)服務(wù)云原生架構(gòu)轉(zhuǎn)型不斷推進(jìn)，企業(yè)服務(wù)架構(gòu)和服務(wù)之間的依賴關(guān)系更加錯(cuò)綜復(fù)雜。云原生架構(gòu)幫助企業(yè)實(shí)現(xiàn)云服務(wù)高可用、快速部署等能力，但是面對(duì)云原生架構(gòu)下多版本多服務(wù)的快速迭代，傳統(tǒng)灰度發(fā)布方案已經(jīng)不滿足需求。因此,對(duì)云原生架構(gòu)下的灰度發(fā)布能力也提出了新的挑戰(zhàn)。

傳統(tǒng)灰度發(fā)布方案的實(shí)現(xiàn)方式主要是在負(fù)載均衡器處實(shí)現(xiàn)，如服務(wù)端負(fù)載均衡服務(wù)器Nginx或者客戶端負(fù)載均衡器Dubbo，最后通過(guò)人工手段控制灰度策略。但是在云原生架構(gòu)下現(xiàn)有的灰度發(fā)布模式越來(lái)越不滿足需求，主要挑戰(zhàn)有如下3點(diǎn)：

（1）云原生架構(gòu)面臨多版本多服務(wù)快速迭代相互影響的挑戰(zhàn)。在云原生架構(gòu)線上灰度發(fā)布時(shí)難以實(shí)現(xiàn)需求范圍內(nèi)的單獨(dú)版本、服務(wù)驗(yàn)證，并且不影響其他版本服務(wù)。出現(xiàn)問(wèn)題時(shí)難以在多版本多服務(wù)間快速準(zhǔn)確定位，導(dǎo)致發(fā)布過(guò)程中問(wèn)題排查時(shí)間長(zhǎng)、影響范圍大，最終導(dǎo)致發(fā)布速度慢。

（2）云原生架構(gòu)面臨灰度發(fā)布技術(shù)精細(xì)化控制的挑戰(zhàn)，在云原生架構(gòu)線上灰度發(fā)布時(shí)不能像虛擬機(jī)或?qū)嶓w機(jī)發(fā)布時(shí)一樣，可以單獨(dú)控制某一臺(tái)機(jī)器的流量訪問(wèn)。并且傳統(tǒng)的灰度發(fā)布技術(shù)在控制能力、配置靈活度上也不能滿足云原生架構(gòu)的快速發(fā)布、生效需求。

（3）全鏈路灰度發(fā)布是云原生架構(gòu)下的另一大挑戰(zhàn)，各大企業(yè)在云原生轉(zhuǎn)型時(shí)，將單體服務(wù)進(jìn)行微服務(wù)拆分和分層，導(dǎo)致一個(gè)業(yè)務(wù)需求發(fā)布時(shí)需要多服務(wù)同時(shí)發(fā)布，此時(shí)在云原生架構(gòu)下，傳統(tǒng)灰度發(fā)布方案不支持所有發(fā)布服務(wù)的端到端詳細(xì)控制。同時(shí)通過(guò)人工維護(hù)負(fù)載均衡器上的灰度策略出現(xiàn)問(wèn)題的概率大、效率低，無(wú)法有效支撐云原生架構(gòu)下業(yè)務(wù)服務(wù)的快速驗(yàn)證、發(fā)布。

本文詳細(xì)內(nèi)容請(qǐng)下載：http://www.shi-ke.cn/resource/share/2000005286

作者信息：

劉軍1，2，李雄清1，2，孫瓊巍1，2，劉利3，李永1，2

（1.中國(guó)民航信息網(wǎng)絡(luò)股份有限公司，北京 101318；2.民航旅客服務(wù)智能化應(yīng)用技術(shù)重點(diǎn)實(shí)驗(yàn)室，北京 101318；
3.歐普杰科技（大連）有限公司，遼寧 大連 116000）