MSE 服務(wù)治理幫助我們系統(tǒng)以很低的成本無(wú)侵入的方式快速實(shí)現(xiàn)了全鏈路灰度能力，進(jìn)一步提升了我們系統(tǒng)的穩(wěn)定性，讓我們新需求的迭代上線更加地安心。

—來(lái)電科技架構(gòu)師 湯長(zhǎng)征

來(lái)電科技自 2014 年起開始進(jìn)入共享充電領(lǐng)域，定義并開創(chuàng)了行業(yè)，屬于行業(yè)內(nèi)最早的共享充電企業(yè)。主要業(yè)務(wù)覆蓋充電寶自助租賃、定制商場(chǎng)導(dǎo)航機(jī)開發(fā)、廣告展示設(shè)備及廣告?zhèn)鞑サ确?wù)。來(lái)電科技擁有業(yè)內(nèi)立體化產(chǎn)品線，大中小機(jī)柜以及桌面型，目前全國(guó)超過(guò) 90% 的城市實(shí)現(xiàn)業(yè)務(wù)服務(wù)落地，注冊(cè)用戶超2億人，實(shí)現(xiàn)全場(chǎng)景用戶需求。

來(lái)電科技的業(yè)務(wù)場(chǎng)景豐富且系統(tǒng)眾多，在技術(shù)架構(gòu)上已完成容器化以及微服務(wù)化改造，微服務(wù)框架使用的是 Spring Cloud 與 Dubbo。隨著近年來(lái)的高速發(fā)展，充電寶設(shè)備節(jié)點(diǎn)以及業(yè)務(wù)量都在快速增加。來(lái)電科技的整體應(yīng)用架構(gòu)也隨著業(yè)務(wù)的高速發(fā)展，持續(xù)不斷地進(jìn)化。微服務(wù)治理是微服務(wù)化深入的必經(jīng)之路，今天我來(lái)和大家分享一下來(lái)電科技在微服務(wù)化深入過(guò)程中探索的這一歷程：

緣起：回顧來(lái)電科技當(dāng)時(shí)的業(yè)務(wù)、架構(gòu)現(xiàn)狀和痛點(diǎn)。

初見(jiàn)：分享在技術(shù)選型之路上我們?yōu)槭裁催x擇 阿里云微服務(wù)引擎 MSE（Microservices Engine，全文以下簡(jiǎn)稱 MSE） 。
落地：我們是怎么一步步落地、在短時(shí)間內(nèi)低成本落地全鏈路灰度能力以及無(wú)損上下線等能力。

展望：MSE 與來(lái)電科技攜手進(jìn)一步深化微服務(wù)化之路。

01

緣起

Cloud Native

來(lái)電科技內(nèi)部技術(shù)趨勢(shì)滿足如下三點(diǎn)

• 微服務(wù)全面落地
• 全面接入 K8s

• 快速迭代，穩(wěn)定發(fā)布的訴求

來(lái)電科技在 2019 年 10 月開始，服務(wù)開始全面進(jìn)行微服務(wù)改造，容器化改造完成；在 20 年 12 月，此時(shí)來(lái)電科技已經(jīng)全面微服務(wù)化，全面接入 K8s。

可以看到隨著來(lái)電微服務(wù)化進(jìn)程的逐漸深入，在這個(gè)微服務(wù)深化的過(guò)程中，我們逐步會(huì)面臨一系列的挑戰(zhàn)，總的而言，我們講這些挑戰(zhàn)分為三個(gè)大的層面，他們分別是效率，穩(wěn)定和成本。我們進(jìn)行微服務(wù)化，本身的使命是讓業(yè)務(wù)的迭代更加高效，但當(dāng)我們的微服務(wù)數(shù)量逐步增多，鏈路越來(lái)越長(zhǎng)，如果不進(jìn)行進(jìn)一步的治理，那么引發(fā)的效率問(wèn)題可能會(huì)大于微服務(wù)架構(gòu)本身帶來(lái)的架構(gòu)紅利。

因此在 2021 年 6 月，來(lái)電科技對(duì)微服務(wù)進(jìn)行了可觀測(cè)建設(shè)；21 年 9 月開始進(jìn)行微服務(wù)治理能力構(gòu)建。

1 全面容器化的優(yōu)勢(shì)

容器化總結(jié)來(lái)說(shuō)有以下這些優(yōu)勢(shì)

• 部署方便，發(fā)布效率大大提升
• 彈性擴(kuò)縮容

• 大大節(jié)約服務(wù)器成本
• 運(yùn)維成本降低

簡(jiǎn)單講一下全面容器化給來(lái)電科技系統(tǒng)帶來(lái)的好處，首先就是應(yīng)用部署變得非常方便，同時(shí)由于 K8s 的標(biāo)準(zhǔn)化使得 CI/CD 也變得簡(jiǎn)單，整體的發(fā)布效率大大提升；同時(shí)部署在 K8s 上的應(yīng)用天然具備彈性擴(kuò)縮容的能力，可以有效應(yīng)對(duì)流量洪峰；同時(shí)由于上了 K8s 后，服務(wù)按需使用資源，相比原先按照峰值長(zhǎng)期固定保有服務(wù)器，資源利用率相對(duì)比較低，現(xiàn)在可以大大節(jié)約服務(wù)器成本。相比傳統(tǒng)集群運(yùn)維非常繁瑣，同時(shí)對(duì)運(yùn)維人員技能要求也非常高：既要精通 lua /ansible 腳本等，又要懂云產(chǎn)品網(wǎng)絡(luò)配置和監(jiān)控運(yùn)維。系統(tǒng)的運(yùn)維成本非常高，阿里云容器服務(wù) ACK 的標(biāo)準(zhǔn)化界面能很好解決高密部署以及系統(tǒng)運(yùn)維的問(wèn)題，極大降低成本。
2 穩(wěn)定發(fā)布三板斧的訴求
日常發(fā)布中，我們常常會(huì)有如下一些錯(cuò)誤的想法：

• 這次改動(dòng)的內(nèi)容比較小，而且上線要求比較急，就不需要測(cè)試直接發(fā)布上線好了

• 發(fā)布不需要走灰度流程，快速發(fā)布上線即可

• 灰度發(fā)布沒(méi)有什么用，就是一個(gè)流程而已，發(fā)布完就直接發(fā)布線上，不用等待觀察

• 雖然灰度發(fā)布很重要，但是灰度環(huán)境很難搭建，耗時(shí)耗力優(yōu)先級(jí)并不高

這些想法都可能讓我們進(jìn)行一次錯(cuò)誤的發(fā)布。

阿里巴巴內(nèi)部有安全生產(chǎn)三板斧概念: 可灰度、可觀測(cè)、可回滾。所有研發(fā)同學(xué)必須要掌握發(fā)布系統(tǒng)的灰度、觀測(cè)和回滾功能如何使用。

互聯(lián)網(wǎng)頻繁發(fā)布是常態(tài)，對(duì)于來(lái)電科技來(lái)說(shuō)也是如此，系統(tǒng)具備灰度、觀測(cè)、回滾的能力是微服務(wù)系統(tǒng)必須具備的能力，灰度可以說(shuō)是發(fā)布之前的必備流程，也是提升線上穩(wěn)定性的關(guān)鍵因素。當(dāng)服務(wù)有新版本要發(fā)布上線時(shí)，通過(guò)引流一小部分流量到新版本，可以及時(shí)發(fā)現(xiàn)程序問(wèn)題，有效阻止大面積故障的發(fā)生。業(yè)界上已經(jīng)有比較成熟的服務(wù)發(fā)布策略，比如藍(lán)綠發(fā)布、A/B 測(cè)試以及金絲雀發(fā)布，這些發(fā)布策略主要專注于如何對(duì)單個(gè)服務(wù)進(jìn)行發(fā)布。

來(lái)電科技的微服務(wù)數(shù)目眾多，服務(wù)之間的依賴關(guān)系錯(cuò)綜復(fù)雜，如果采用多套環(huán)境的硬隔離，會(huì)使得成本大幅升高，發(fā)布方式變得復(fù)雜。有時(shí)某個(gè)功能發(fā)版依賴多個(gè)服務(wù)同時(shí)升級(jí)上線。希望可以對(duì)這些服務(wù)的新版本同時(shí)進(jìn)行小流量灰度驗(yàn)證，通過(guò)構(gòu)建從 Ingress 網(wǎng)關(guān)到整個(gè)后端服務(wù)的環(huán)境隔離來(lái)對(duì)多個(gè)不同版本的服務(wù)進(jìn)行灰度驗(yàn)證，這就是微服務(wù)治理中的全鏈路灰度的能力。
3 自研的挑戰(zhàn)

來(lái)電科技有考慮過(guò)自研微服務(wù)治理，來(lái)電科技架構(gòu)師 湯長(zhǎng)征 同學(xué)也參與過(guò) Dubbo 的開源社區(qū)，微服務(wù)治理研發(fā)對(duì)于來(lái)電科技來(lái)說(shuō)并不是非常困難的事情，但是自研微服務(wù)治理組件還是存在以下必不可少的成本問(wèn)題。

• 接入成本高
• 維護(hù)成本高

• 功能單一，不靈活，可擴(kuò)展性低
• 可定位性變差

考慮到對(duì)生產(chǎn)應(yīng)用進(jìn)行微服務(wù)治理，微服務(wù)框架通常會(huì)引入服務(wù)治理的邏輯，而這些邏輯通常會(huì)以 SDK 的方式被業(yè)務(wù)代碼所依賴，而這些邏輯的變更和升級(jí)，都需要每一個(gè)微服務(wù)業(yè)務(wù)通過(guò)修改代碼的方式來(lái)實(shí)現(xiàn)，這樣的變更造成了非常大的接入與升級(jí)成本。同時(shí)需要對(duì)開源的服務(wù)框架做治理功能的研發(fā)，就意味著需要出人力對(duì)微服務(wù)治理的組件進(jìn)行管理與運(yùn)維，同時(shí)自建會(huì)使得功能非常貼近業(yè)務(wù)，也意味著功能將會(huì)做得比較薄比較單一，未來(lái)的可擴(kuò)展性就顯得比較弱。同時(shí)全鏈路灰度的實(shí)現(xiàn)技術(shù)細(xì)節(jié)也是非常之多，動(dòng)態(tài)路由，節(jié)點(diǎn)打標(biāo)，流量打標(biāo)，分布式鏈路追蹤，技術(shù)的實(shí)現(xiàn)成本高。由于 Dubbo、Spring Cloud 等服務(wù)框架本身的復(fù)雜性，同時(shí)隨著微服務(wù)數(shù)量逐步增多，鏈路越來(lái)越長(zhǎng)，相關(guān)的微服務(wù)治理問(wèn)題的定位與解決也成了讓人頭疼的問(wèn)題，如果有 Spring Cloud Alibaba、Dubbo 等專業(yè)的團(tuán)隊(duì)支持，微服務(wù)化深入也會(huì)變得更加從容。
02

初見(jiàn)

Cloud Native

第一次接觸MSE服務(wù)治理這塊產(chǎn)品，就有許多的點(diǎn)命中我們的訴求，以下幾點(diǎn)對(duì)我們微服務(wù)治理改造來(lái)說(shuō)都是很吸引的點(diǎn)

• 無(wú)侵入

MSE 微服務(wù)治理能力基于Java Agent字節(jié)碼增強(qiáng)的技術(shù)實(shí)現(xiàn)，無(wú)縫支持市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，用戶不用改一行代碼就可以使用。只需開啟 MSE 微服務(wù)治理專業(yè)版，在線配置，實(shí)時(shí)生效。

• 接入簡(jiǎn)單

只需在阿里云容器的應(yīng)用市場(chǎng)安裝 mse-pilot，然后在 MSE 控制臺(tái)開啟命名空間級(jí)別的服務(wù)治理，重啟應(yīng)用即可接入，當(dāng)然卸載服務(wù)治理也是非常容易的，只需在控制臺(tái)關(guān)閉服務(wù)治理，卸載 mse-pilot 即可，不需要改變業(yè)務(wù)的現(xiàn)有架構(gòu)，隨時(shí)可上可下，沒(méi)有綁定。

• 功能強(qiáng)大，持續(xù)發(fā)展

從開發(fā)態(tài)、測(cè)試態(tài)到運(yùn)行態(tài)全生命周期的服務(wù)治理覆蓋，使得研發(fā)同學(xué)可更加專注于業(yè)務(wù)本身。

MSE 微服務(wù)治理還提供了以下解決方案，解決微服務(wù)治理難點(diǎn)，快速提升企業(yè)的微服務(wù)治理能力。穩(wěn)定性領(lǐng)域：線上故障緊急診斷排查與恢復(fù)、線上發(fā)布穩(wěn)定性解決方案、微服務(wù)全鏈路灰度解決方案。降本增效領(lǐng)域：日常測(cè)試環(huán)境降本隔離解決方案、微服務(wù)無(wú)縫遷移上云解決方案、微服務(wù)開發(fā)測(cè)試提效解決方案。

• 可視化

MSE 服務(wù)治理專業(yè)版提供了微服務(wù)治理流量的可視化視圖

對(duì)于灰度流量灰沒(méi)灰到，灰了多少，配完路由規(guī)則后流量實(shí)時(shí)生效，做到一眼可見(jiàn)，心中有數(shù)。

同時(shí)對(duì)于無(wú)損上下線的場(chǎng)景，MSE 提供端到端全生命周期的防護(hù)，一眼可以看出流量有無(wú)損失，損失在什么部分。

• 擁抱云原生

進(jìn)入云原生體系之后，以 K8s 為主的云原生體系強(qiáng)調(diào)集群之間的靈活調(diào)度型，以 POD 為單位任意的調(diào)度資源，在被調(diào)度后 POD 的 IP 也將相應(yīng)的發(fā)生變化，傳統(tǒng)的服務(wù)治理體系，通常以 IP 為維度進(jìn)行治理策略的配置，MSE 使用更加云原生的方式使用標(biāo)簽為維度進(jìn)行微服務(wù)治理策略的配置。

同時(shí)在 K8s 環(huán)境下與 K8s 的體系深度集成，推出多種完整解決方案，無(wú)損上下線使得應(yīng)用在彈性伸縮的過(guò)程中保持流量無(wú)損，通過(guò) Jenkins 構(gòu)建 CI/CD 實(shí)現(xiàn)在 K8s 環(huán)境下的金絲雀發(fā)布，基于 Ingress 實(shí)現(xiàn)全鏈路灰度等。

1 當(dāng)時(shí) MSE 的一些局限
當(dāng)然在 21 年 9 月剛接觸 MSE 微服務(wù)治理的過(guò)程中發(fā)現(xiàn) MSE 為服務(wù)治理的全鏈路能力還是存在一些局限性的，首先就是只支持微服務(wù)網(wǎng)關(guān) Spring Cloud Gateway 與 Zuul 以及云網(wǎng)關(guān)，當(dāng)時(shí)并不能支持自建的 Nginx 網(wǎng)關(guān)，同時(shí)在 Dubbo 的場(chǎng)景下只支持按照接口參數(shù)維度的路由，對(duì)于運(yùn)維同學(xué)來(lái)說(shuō)還需要了解業(yè)務(wù)接口的實(shí)現(xiàn)，過(guò)于精細(xì)化控制，上生產(chǎn)的成本過(guò)高；同時(shí)全鏈路灰度的入口僅僅支持 Http 網(wǎng)關(guān)或者應(yīng)用作為灰度流量的入口，并不能支持 TCP 網(wǎng)關(guān)作為流量的入口。

03

落地

Cloud Native

我們與來(lái)電科技的架構(gòu)師深入了解后，對(duì)用戶的灰度場(chǎng)景進(jìn)行了進(jìn)一步的抽象與總結(jié)，只有深入到業(yè)務(wù)中去才能更加了解客戶的需求。我們總結(jié)出如下三個(gè)場(chǎng)景

1 MSE 全鏈路灰度場(chǎng)景

場(chǎng)景一：對(duì)經(jīng)過(guò)機(jī)器的流量進(jìn)行自動(dòng)染色，實(shí)現(xiàn)全鏈路灰度

• 進(jìn)入帶 tag 的節(jié)點(diǎn)后續(xù)調(diào)用優(yōu)先選擇帶有相同 tag 的節(jié)點(diǎn)，即對(duì)經(jīng)過(guò) tag 節(jié)點(diǎn)的流量進(jìn)行"染色"

• 有 tag 的調(diào)用鏈路上找不到相同 tag 的節(jié)點(diǎn)，則 fallback 到無(wú) tag 的節(jié)點(diǎn)

• 有 tag 的調(diào)用鏈路經(jīng)過(guò)無(wú) tag 的節(jié)點(diǎn)，如果鏈路后續(xù)調(diào)用有 tag 的節(jié)點(diǎn)，則恢復(fù) tag 調(diào)用的模式

場(chǎng)景二：通過(guò)給流量帶上特定的 header 實(shí)現(xiàn)全鏈路灰度

客戶端通過(guò)在請(qǐng)求中增加制定環(huán)境的標(biāo)識(shí)，接入層根基表示進(jìn)行轉(zhuǎn)發(fā)至表示對(duì)應(yīng)環(huán)境的網(wǎng)關(guān)，對(duì)應(yīng)環(huán)境的網(wǎng)關(guān)通過(guò)隔離插件調(diào)用標(biāo)識(shí)對(duì)應(yīng)的項(xiàng)目隔離環(huán)境，請(qǐng)求在業(yè)務(wù)項(xiàng)目隔離環(huán)境中閉環(huán)。

場(chǎng)景三：通過(guò)自定義路由規(guī)則來(lái)進(jìn)行全鏈路灰度

通過(guò)在灰度請(qǐng)求中增加指定的 header，且整條調(diào)用鏈路會(huì)將該 header 透?jìng)飨氯?，只需在?duì)應(yīng)的應(yīng)用配置該 header 相關(guān)的路由規(guī)則，帶指定 header 的灰度請(qǐng)求進(jìn)入灰度機(jī)器，即可按需實(shí)現(xiàn)全鏈路流量灰度。

我們考慮到場(chǎng)景一其實(shí)就能完美滿足來(lái)電科技全鏈路灰度的場(chǎng)景，同時(shí)它也是絕大部分云上客戶的訴求，場(chǎng)景二和三可以作為更加高階的玩法。
由于對(duì)經(jīng)過(guò)應(yīng)用的流量打標(biāo)染色并進(jìn)行全鏈路灰度，所以我們支持了任意的流量入口，也支持 Ingress、自建網(wǎng)關(guān)的灰度，在支持應(yīng)用級(jí)別的灰度的同時(shí)兼容自定義的路由，更加靈活的方式滿足了來(lái)電科技全鏈路灰度的場(chǎng)景。

2 來(lái)電全鏈路灰度落地方案

來(lái)電的業(yè)務(wù)架構(gòu)如下，最上層是移動(dòng)端等用戶界面，自建的 Nginx 網(wǎng)關(guān)作為接入層，服務(wù)層就是各種服務(wù)，使用的是 Spring Cloud 與 Dubbo 作為服務(wù)框架。在 Nginx 層配置流量分流的配置，10% 的流量進(jìn)入灰度環(huán)境，90% 的流量進(jìn)入未打標(biāo)即線上正式環(huán)境，然后經(jīng)過(guò)灰度環(huán)境的流量會(huì)自動(dòng)被 MSE 染上對(duì)應(yīng)環(huán)境的顏色，從而進(jìn)行全鏈路的灰度路由，保證流量在灰度環(huán)境中閉環(huán)，如果沒(méi)有灰度環(huán)境的機(jī)器，比如支付中心只有線上的機(jī)器，那么流量會(huì)走線上環(huán)境，當(dāng)我們數(shù)據(jù)中心又存在灰度環(huán)境的機(jī)器，那么灰度流量還會(huì)重新回到數(shù)據(jù)中心的灰度環(huán)境中。

3 MSE 服務(wù)預(yù)熱能力
當(dāng)我們?cè)诎滋旄叻迤谧霭l(fā)布，通常都會(huì)導(dǎo)致業(yè)務(wù)流量出現(xiàn)損失，我們的研發(fā)人員不得不選擇在晚上業(yè)務(wù)低峰期做變更，這大大降低了研發(fā)人員的幸福指數(shù)，因?yàn)樗麄儾坏貌幻媾R熬夜加班的困境。如果能在白天大流量高峰期也能進(jìn)行流量無(wú)損的變更，那么這對(duì)于研發(fā)人員來(lái)說(shuō)將是大大提升研發(fā)效率的事情。

來(lái)電科技也遇到類似的問(wèn)題，當(dāng)業(yè)務(wù)流量過(guò)大的場(chǎng)景下，進(jìn)行應(yīng)用發(fā)布，系統(tǒng)服務(wù)剛啟動(dòng)階段，應(yīng)用由于存在冷啟動(dòng)的過(guò)程，此時(shí)的應(yīng)用容量往往會(huì)比正常情況下低，但是線上的流量是無(wú)法區(qū)分當(dāng)前的服務(wù)是否是剛啟動(dòng)的，依舊會(huì)有大流量持續(xù)涌入，此時(shí)就會(huì)導(dǎo)致系統(tǒng)過(guò)載而崩潰，出現(xiàn)流量損失。如果我們的微服務(wù)應(yīng)用具備服務(wù)預(yù)熱的能力，使得流量按照一定的曲線進(jìn)行緩慢增長(zhǎng)，從而保證服務(wù)進(jìn)行充分的預(yù)熱，即使是在高并發(fā)大流量場(chǎng)景中，保護(hù)應(yīng)用在安全啟動(dòng)。

MSE 提供的一種基于 Agent 的無(wú)侵入預(yù)熱微服務(wù)應(yīng)用的方法能有效讓用戶在不修改任何代碼的情況下即可為應(yīng)用提供服務(wù)預(yù)熱能力。
04

未來(lái)

Cloud Native

MSE 服務(wù)治理專業(yè)版以無(wú)侵入的方式提供了全鏈路灰度、離群實(shí)例摘除、金絲雀發(fā)布、微服務(wù)治理流量可觀測(cè)等核心能力，以更經(jīng)濟(jì)的方式、更高效的路徑幫助來(lái)電科技在云上快速構(gòu)建起完整微服務(wù)治理體系，有效提升線上穩(wěn)定性，保證服務(wù) 99.9% 的可用率。
隨著來(lái)電科技微服務(wù)化的深入，除了全鏈路灰度、無(wú)損上下線還有更多的場(chǎng)景逐漸出現(xiàn)，微服務(wù)全生命周期的治理將覆蓋從發(fā)布、運(yùn)行、故障排查、故障恢復(fù)以及全鏈路流量的治理，MSE 微服務(wù)治理將攜手幫助來(lái)電科技持續(xù)提升微服務(wù)研發(fā)效能與服務(wù)的高可用率。