作者：湯長征、十眠

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

—來電科技架構師 湯長征

來電科技自 2014 年起開始進入共享充電領域，定義并開創了行業，屬于行業內最早的共享充電企業。主要業務覆蓋充電寶自助租賃、定制商場導航機開發、廣告展示設備及廣告傳播等服務。來電科技擁有業內立體化產品線，大中小機柜以及桌面型，目前全國超過 90% 的城市實現業務服務落地，注冊用戶超2億人，實現全場景用戶需求。

來電科技的業務場景豐富且系統眾多，在技術架構上已完成容器化以及微服務化改造，微服務框架使用的是 Spring Cloud 與 Dubbo。隨著近年來的高速發展，充電寶設備節點以及業務量都在快速增加。來電科技的整體應用架構也隨著業務的高速發展，持續不斷地進化。微服務治理是微服務化深入的必經之路，今天我來和大家分享一下來電科技在微服務化深入過程中探索的這一歷程：緣起： 回顧來電科技當時的業務、架構現狀和痛點。初見： 分享在技術選型之路上我們為什么選擇 阿里云微服務引擎 MSE（Microservices Engine，全文以下簡稱 MSE） 。落地： 我們是怎么一步步落地、在短時間內低成本落地全鏈路灰度能力以及無損上下線等能力。

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

緣起

來電科技內部技術趨勢滿足如下三點

• 微服務全面落地
• 全面接入 K8s
• 快速迭代，穩定發布的訴求

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

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

因此在 2021 年 6 月，來電科技對微服務進行了可觀測建設；21 年 9 月開始進行微服務治理能力構建。

全面容器化的優勢

容器化總結來說有以下這些優勢

• 部署方便，發布效率大大提升
• 彈性擴縮容
• 大大節約服務器成本
• 運維成本降低

簡單講一下全面容器化給來電科技系統帶來的好處，首先就是應用部署變得非常方便，同時由于 K8s 的標準化使得 CI/CD 也變得簡單，整體的發布效率大大提升；同時部署在 K8s 上的應用天然具備彈性擴縮容的能力，可以有效應對流量洪峰；同時由于上了 K8s 后，服務按需使用資源，相比原先按照峰值長期固定保有服務器，資源利用率相對比較低，現在可以大大節約服務器成本。相比傳統集群運維非常繁瑣，同時對運維人員技能要求也非常高：既要精通 lua /ansible 腳本等，又要懂云產品網絡配置和監控運維。系統的運維成本非常高，阿里云容器服務 ACK 的標準化界面能很好解決高密部署以及系統運維的問題，極大降低成本。

穩定發布三板斧的訴求

日常發布中，我們常常會有如下一些錯誤的想法：

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

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

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

• 雖然灰度發布很重要，但是灰度環境很難搭建，耗時耗力優先級并不高

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

阿里巴巴內部有安全生產三板斧概念: 可灰度、可觀測、可回滾。所有研發同學必須要掌握發布系統的灰度、觀測和回滾功能如何使用。

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

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

自研的挑戰

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

• 接入成本高
• 維護成本高
• 功能單一，不靈活，可擴展性低
• 可定位性變差

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

初見

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

• 無侵入

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

• 接入簡單

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

• 功能強大，持續發展

從開發態、測試態到運行態全生命周期的服務治理覆蓋，使得研發同學可更加專注于業務本身。

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

• 可視化

MSE 服務治理專業版提供了微服務治理流量的可視化視圖

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

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

• 擁抱云原生

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

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

當時 MSE 的一些局限

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

落地

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

MSE 全鏈路灰度場景

場景一：對經過機器的流量進行自動染色，實現全鏈路灰度

• 進入帶 tag 的節點后續調用優先選擇帶有相同 tag 的節點，即對經過 tag 節點的流量進行"染色"

• 有 tag 的調用鏈路上找不到相同 tag 的節點，則 fallback 到無 tag 的節點

• 有 tag 的調用鏈路經過無 tag 的節點，如果鏈路后續調用有 tag 的節點，則恢復 tag 調用的模式

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

客戶端通過在請求中增加制定環境的標識，接入層根基表示進行轉發至表示對應環境的網關，對應環境的網關通過隔離插件調用標識對應的項目隔離環境，請求在業務項目隔離環境中閉環。

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

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

我們考慮到場景一其實就能完美滿足來電科技全鏈路灰度的場景，同時它也是絕大部分云上客戶的訴求，場景二和三可以作為更加高階的玩法。

由于對經過應用的流量打標染色并進行全鏈路灰度，所以我們支持了任意的流量入口，也支持 Ingress、自建網關的灰度，在支持應用級別的灰度的同時兼容自定義的路由，更加靈活的方式滿足了來電科技全鏈路灰度的場景。

來電全鏈路灰度落地方案

來電的業務架構如下，最上層是移動端等用戶界面，自建的 Nginx 網關作為接入層，服務層就是各種服務，使用的是 Spring Cloud 與 Dubbo 作為服務框架。

來電科技全鏈路灰度落地的架構如下：

在 Nginx 層配置流量分流的配置，10% 的流量進入灰度環境，90% 的流量進入未打標即線上正式環境，然后經過灰度環境的流量會自動被 MSE 染上對應環境的顏色，從而進行全鏈路的灰度路由，保證流量在灰度環境中閉環，如果沒有灰度環境的機器，比如支付中心只有線上的機器，那么流量會走線上環境，當我們數據中心又存在灰度環境的機器，那么灰度流量還會重新回到數據中心的灰度環境中。

MSE 服務預熱能力

當我們在白天高峰期做發布，通常都會導致業務流量出現損失，我們的研發人員不得不選擇在晚上業務低峰期做變更，這大大降低了研發人員的幸福指數，因為他們不得不面臨熬夜加班的困境。如果能在白天大流量高峰期也能進行流量無損的變更，那么這對于研發人員來說將是大大提升研發效率的事情。

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

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

未來

MSE 服務治理專業版以無侵入的方式提供了全鏈路灰度、離群實例摘除、金絲雀發布、微服務治理流量可觀測等核心能力，以更經濟的方式、更高效的路徑幫助來電科技在云上快速構建起完整微服務治理體系，有效提升線上穩定性，保證服務 99.9% 的可用率。

隨著來電科技微服務化的深入，除了全鏈路灰度、無損上下線還有更多的場景逐漸出現，微服務全生命周期的治理將覆蓋從發布、運行、故障排查、故障恢復以及全鏈路流量的治理，MSE 微服務治理將攜手幫助來電科技持續提升微服務研發效能與服務的高可用率。

點擊??此處??，查看更多 MSE 相關信息！

總結

以上是生活随笔為你收集整理的全面容器化之后，来电科技如何实现微服务治理？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。