開邁斯新能源科技有限公司於 2019 年 5 月 16 日成立，目前合資股東分別爲大衆汽車（中國）投資有限公司、中國第一汽車股份有限公司、一汽-大衆汽車有限公司[增資擴股將在取得適當監督（包括反壟斷）審批後完成]、萬幫數字能源股份有限公司和安徽江淮汽車集團控股有限公司，總部位於江蘇常州。開邁斯集車企與充電企業優勢於一體，提供從充電基礎設施的研發製造到軟件的智能互聯，從私人充電用戶到半公共、公共以及商務用戶，從電力供應的行業源頭到服務平臺的終端體驗，實現每一個業態的前後端無縫連接。
開邁斯爲中國新生代消費者而來，不僅注重私家電動車主的充電體驗，還以高端的品質服務提供用戶便捷無憂、智能高效的全新充電體驗，開啓樂享生活的旅程。同時，開邁斯致力於爲電動出行提供全場景充電服務，依託強大的研發實力、先進的核心技術和高質量服務，還收穫了國內新能源汽車充電領域的諸多獎項：2021 年，開邁斯榮膺“中國充電樁行業最佳運營服務創新獎”；2023 年 3 月，開邁斯一舉獲得“高質量充電五星級場站獎“，成爲首批獲得五星級評價的優秀充電運營商（五星級別是最高級別最高標準的場站）；同年 6 月，開邁斯榮獲 2023 中國充換電行業十大影響力運營商品牌獎。開邁斯將持續推動充電網絡建設速度和充電用戶旅程的優化創新，並將聚焦高功率充電設備研發和新能源服務領域的探索，從而推動新能源與新能源汽車深度融合的綠色發展。
業務穩定性挑戰大
2023 年，開邁斯將繼續致力於以用戶爲中心的整合創新，致力打造智能電動出行。截止今年 5 月底，開邁斯充電網絡覆蓋國內 180 城，建設 1,198 座充電站和 10,490 個充電終端，積累用戶超 196 萬。從建設滯後到“適度超前”，未來三年充電樁產業將迎來大發展，市場規模達千億級。現在全國各地很多城市在對充電樁的增設和利用上在不斷升級加碼，隨着新能源汽車的發展，充電用戶羣體的訴求飛速增長，開邁斯伴隨着業務的快速增長，對其架構的穩定性以及可用性也提出了前所未有的挑戰。
開邁斯採用傳統的 SpringBoot 方式進行應用開發，應用間通過 Http 請求方式進行互通互聯，也正是 SpringBoot 架構的簡單性，有效幫助到開邁斯的業務以及微服務數量進行快速擴張。但是隨着微服務規模的增大，逐漸發現應用在發佈、運行等各個階段的都存在一些穩定性與效率上的問題。隨着用戶與的增多，相應的需求也越來越多，業務場景也越來越複雜。在這個時候僅依靠內部測試很難保證可以覆蓋到所有的場景，每次應用的發佈都需要進行充分的測試與足夠的灰度驗證。爲了滿足快速迭代的業務訴求，如何可以做到低成本地進行多個迭代在開發環境並行，並且保證每次業務發版的穩定，成了提效的關鍵。
在大規模之下，再小的問題都會牽一髮而動全身。一方面，我們面對的流量是隨機的、無法預測的，當激增流量超出服務承載上限時，可能會使服務變慢、負載飆高，導致服務崩潰。另一方面，分佈式微服務架構是複雜的網狀架構，調用鏈路錯綜複雜，這時候任何一個服務（包括依賴的外部服務）出現不穩定因素（如慢調用或異常）時，都有可能把上游調用方拖垮，進而形成級聯影響。因此，在微服務治理中，我們需要一些手段來預防這些不穩定的情況。
面對持續演進增長的微服務架構，開邁斯架構同學也意識到需要引入微服務治理能力對當前的微服務進行恰當的治理，從而進一步提升微服務的穩定性與效率。同樣的，業務依舊面臨快速發展的訴求，如果將原先的 Spring Boot 框架升級成 Spring Cloud 並且引入各種高階的服務治理能力，對於目前面對業務快速發展的開邁斯研發同學來說，需要投入成本過於太大。
無感實現微服務架構升級
是否有一種不用改代碼的方式實現我們微服務的治理能力呢？比如通過實施全鏈路灰度發佈來避免變更帶來的穩定性風險；通過限流降級能力保障運行態的穩定性，解決不確定的流量帶來的穩定性風險；通過鑑權能力解決微服務間調用的安全風險。這就好比，我們如何可以在飛機高速運行的過程中，通過更換引擎來提升飛機的性能？更關鍵的是，對於我們飛機上的乘客來說，還要是無感的。
我們將問題進一步抽象，如何可以不改代碼，實現任意 Java 應用的服務治理能力，並且在這個過程中我們需要確保穩定性、問題診斷效率、架構的可持續性、性能等一系列現實的因素。
技術的探索總是爲業務服務的，我們圍繞着開邁斯的方案進行了一步討論，是否可以通過統一南北和東西向流量治理的方案來解決用戶無侵入服務治理的難題？
1. MSE 雲原生網關是兼容 K8s Ingress 標準的下一代網關產品，將流量網關、微服務網關 和 WAF 安全網關三合一，具備高集成、易使用、易擴展、熱更新的特點。它打通了 K8s/Nacos 等多種服務來源，通過無損上下線、全鏈路灰度、過載保護、故障自愈、限流降級等手段，提升整個鏈路的應用穩定性。
2. MSE 雲原生網關採用了全託管的模式，用戶在選擇雲原生網關之後，只需要關心網關的具體使用，無需關心雲原生網關本身的運維、穩定性、監控、報警 等功能， 開箱即用，使用門檻低。
考慮到雲原生網關可以通過路由規則統一流量以及流控，那麼是否能夠通過 Higress 實現服務間調用流量的治理訴求？
服務間的流量轉發與治理
既然思路敲定了，大家評估完了穩定性、安全與成本之後，那麼就快速開始方案的實踐與探索了。我們首先面臨的問題是原先通過域名調用 K8s Service 的方式，我們如何將流量轉發至 Higress 並且通過 Higress 再轉發給真實對應的 Pod 呢？並且在這個過程中我們需要考慮方案的穩定性。
- 直接想到的方式就是修改 K8s 中的 Service 跟 Endpoints 配置，利用 coreDNS 能力將流量轉發至 Higress。
apiVersion: v1
kind: Service
metadata:
name: provider
spec:
type: ClusterIP
clusterIP: None
---
apiVersion: v1
kind: Endpoints
metadata:
name: provider
spec:
subsetS:
ip: ${higress-slb}
port: 80
- 出於商業化穩定性的考慮 CoreDNS，可以使用同類型產品 privatelinkZone DNS 進行替代，同時可以配置 CNAME 類型的 DNS 記錄批量將服務間訪問的域名 *.http://camsnet.com 切換至雲原生網關上。
到目前爲止我們完成了 Order 的流量被先轉發至內部網關 Higress 上，接下來我們需要配置 Higress 路由規則，將流量轉發至真實的目標服務中。
- 我們在 MSE 雲原生網關（Higress 商業版）中同步容器服務的 Service 至網關，並且配置對應的路由規則，實現流量轉發。
流量經過 MSE 雲原生網關轉發之後，我們就可以做更多的治理能力了。
- 這個過程中我們直接可以配置標籤路由實現灰度發佈的能力，再結合鏈路追蹤實現全鏈路灰度的能力。
- 這個過程中我們可以在路由上配置 JWT 鑑權規則，從而達到服務間的安全調用。
可觀測與全鏈路追蹤
開邁斯通過接入應用實時監控服務 ARMS -應用監控，無需修改一行代碼就可以實現應用的監控診斷能力，可以快速瞭解應用最關鍵的響應時間，吞吐量，錯誤率這黃金三指標，同時根據指標的異常利用調用鏈能力對整個微服務進行快速跟蹤。
同時鏈路追蹤能力也爲應用實現全鏈路灰度提供了一個技術底座支持。
全鏈路流量標籤透傳
藉助 Tracing Baggage 機制在全鏈路中傳遞對應染色標識，因爲大部分 Tracing 框架都支持 Baggage 概念及能力，如：OpenTelemetry、Skywalking、Jaeger 等等。當然 ARMS Tracing 能力也是符合這個標準的，我們通過實現 Higress WASM 插件，在 Higress outbound Filter 中將指定的透傳 key 如 x-mse-tag 從 Tracing 協議指定位置的 Baggage 中讀出 x-mse-tag 對應的值，並塞入到 Http 的 Header 中，供 Higress 進行路由。從而實現自定標籤全鏈路透傳的能力。
具備自定標籤全鏈路透傳的能力之後，我們就可以構建完整的全鏈路灰度能力了。什麼是全鏈路灰度呢？
在微服務架構下，有一些需求開發，涉及到微服務調用鏈路上的多個微服務同時發生了改動，通常每個微服務都會有灰度環境或分組來接受灰度流量，我們希望通過進入上游灰度環境的流量，也能進入下游灰度的環境中，確保 1 個請求始終在灰度環境中傳遞，即使這個調用鏈路上有一些微服務沒有灰度環境，這些應用請求下游的時候依然能夠回到灰度環境中。如果一次發佈涉及到鏈路中的多個微服務，我們可以順滑地進行全鏈路灰度發佈，並且不用擔心灰度流量亂竄的風險。
當我們實現全鏈路透傳 x-mse-tag 標籤後，我們可以在 Higress 路由上，配置基於 x-mse-tag 的標籤路由規則，實現帶有特定標籤的流量在應用特定版本的節點內流量閉環，從而實現“流量泳道”的全鏈路灰度能力。
流量防護能力
如何可以不用修改代碼，實現流量防護能力？以常見的流量控制與熔斷降級爲例，下面我們先來介紹一下流量防護能力。
- 流量控制
流量是非常隨機性的、不可預測的。前一秒可能還風平浪靜，後一秒可能就出現流量洪峯了（例如雙十一零點的場景）。每個系統、服務都有其能承載的容量上限，如果突然而來的流量超過了系統的承受能力，就可能會導致請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最後導致系統崩潰。因此，我們需要針對這種突發的流量來進行限制，在儘可能處理請求的同時來保障服務不被打垮，這就是流量控制。
- 熔斷降級
現代微服務架構都是分佈式的，由非常多的服務組成。不同服務之間相互調用，組成複雜的調用鏈路。以上的問題在鏈路調用中會產生放大的效果。複雜鏈路上的某一環不穩定，就可能會層層級聯，最終導致整個鏈路都不可用。因此我們需要對不穩定的弱依賴服務進行熔斷降級，暫時切斷不穩定調用，避免局部不穩定因素導致整體的雪崩。
開邁斯通過接入 MSE 服務治理流量防護能力（Sentinel 企業版），無縫實現流量防護能力。相比社區版本，Sentinel 企業版無論是在使用還是功能層面都有一定的優勢。
更多的探索與實踐
不需要改代碼，我們也能快速具備完整、體系化的微服務治理能力。目前開邁斯基於 Higress 實現了全鏈路灰度、全鏈路追蹤與可觀測、流量防護等一系列能力，使得開邁斯當前的架構可以更加從容地面對快速增長業務帶來的挑戰。
另一方面，對於 Higress 來說，開邁斯方案的落地爲 Higress 生態的發展注入了新鮮的思路，我們也在持續地提升 Higress 的易用性與穩定性，希望可以給更多企業帶來更大的價值。
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。