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

—來電科技架構(gòu)師 湯長征

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

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

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

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

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

01

緣起

Cloud Native

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

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

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

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

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

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

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

容器化總結(jié)來說有以下這些優(yōu)勢

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

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

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

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

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

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

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

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

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

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

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

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

• 接入成本高
• 維護成本高

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

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

初見

Cloud Native

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

• 無侵入

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

• 接入簡單

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

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

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

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

• 可視化

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

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

同時對于無損上下線的場景，MSE 提供端到端全生命周期的防護，一眼可以看出流量有無損失，損失在什么部分。

• 擁抱云原生

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

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

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

03

落地

Cloud Native

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

1 MSE 全鏈路灰度場景

場景一：對經(jīng)過機器的流量進行自動染色，實現(xiàn)全鏈路灰度

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

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

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

場景二：通過給流量帶上特定的 header 實現(xiàn)全鏈路灰度

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

場景三：通過自定義路由規(guī)則來進行全鏈路灰度

通過在灰度請求中增加指定的 header，且整條調(diào)用鏈路會將該 header 透傳下去，只需在對應(yīng)的應(yīng)用配置該 header 相關(guān)的路由規(guī)則，帶指定 header 的灰度請求進入灰度機器，即可按需實現(xiàn)全鏈路流量灰度。

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

2 來電全鏈路灰度落地方案

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

3 MSE 服務(wù)預(yù)熱能力
當(dāng)我們在白天高峰期做發(fā)布，通常都會導(dǎo)致業(yè)務(wù)流量出現(xiàn)損失，我們的研發(fā)人員不得不選擇在晚上業(yè)務(wù)低峰期做變更，這大大降低了研發(fā)人員的幸福指數(shù)，因為他們不得不面臨熬夜加班的困境。如果能在白天大流量高峰期也能進行流量無損的變更，那么這對于研發(fā)人員來說將是大大提升研發(fā)效率的事情。

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

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

未來

Cloud Native

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