作者：湯長征、十眠
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 相關資訊！