前言

阿里雲-達摩院-雲小蜜對話機器人產品基於深度機器學習技術、自然語言理解技術和對話管理技術，為企業提供多引擎、多渠道、多模態的對話機器人服務。17 年雲小蜜對話機器人在公共雲開始公測，同期在混合雲場景也不斷拓展。為了同時保證公共雲、混合雲發版效率和穩定性，權衡再三我們採用了 1-2 個月一個大版本迭代。

經過幾年發展，為了更好支撐業務發展，架構升級、重構總是一個繞不過去的坎，為了保證穩定性每次公共雲發版研發同學都要做兩件事：

1.梳理各個模組相較線上版本介面依賴變化情況，決定十幾個應用的上線順序、每批次釋出比例；

2.模擬演練上述1產出的釋出順序，保證後端服務平滑升級，客戶無感知。

上述動作每次都需要 2-3 周左右的時間梳理、集中演練，但是也只能保證開放的 PaaS API 平滑更新。
控制檯服務因為需要前端、API、後端保持版本一致才能做到體驗無損（如果每次迭代統一升級 API 版本開發、協同成本又會非常大），權衡之下之前都是流量低谷期上線，儘量縮短髮布時間，避免部分控制檯模組偶發報錯帶來業務問題。

針對上面問題，很早之前就考慮過用藍綠髮布、灰度等手段解決，但是無奈之前對話機器人在阿里雲內部業務區域，該不再允許普通雲產品擴容，沒有冗餘的機器，流量治理完全沒法做。

遷移阿里云云上

帶著上面的問題，終於迎來的 2021 年 9 月份，雲小蜜將業務遷移至阿里云云上。

Dubbo 3.0 的實踐

“當時印象最深的就是這張圖，雖然當時不知道中介軟體團隊具體要做什麼事情，但是記住了兩個關鍵詞：三位一體、紅利。沒想到在 2021 年底，真真切切享受到了這個紅利。”

雲小蜜使用的是集團內部的 HSF 服務框架，需要遷移至阿里云云上，並且存在阿里云云上與阿里內部業務域的互通、互相治理的訴求。雲小蜜的公共服務部署在公有云 VPC，部分依賴的資料服務部署在內部，內部與雲上服務存在 RPC 互調的訴求，其實屬於混合雲的典型場景。

簡單整理了下他們的核心訴求，概括起來有以下三點：

希望儘可能採用開源方案，方便後續業務推廣；
在網路通訊層面需要保障安全性；
對於業務升級改造來說需要做到低成本。

在此場景下，經過許多討論與探索，方案也敲定了下來：
• 全鏈路升級至開源 Dubbo3.0，雲原生閘道器預設支援 Dubbo3.0，實現透明轉發，閘道器轉發 RT 小於 1ms；
• 利用 Dubbo3.0 支援 HTTP2 特性，雲原生閘道器之間採用 mTLS 保障安全；
• 利用雲原生閘道器預設支援多種註冊中心的能力，實現跨域服務發現對使用者透明，業務側無需做任何額外改動；
• 業務側升級 SDK 到支援 Dubbo3.0，配置釋出 Triple 服務即可，無需額外改動。

解決了互通、服務註冊發現的問題之後，就是開始看如何進行服務治理方案了。

阿里云云上流量治理

遷移至阿里云云上之後，流量控制方案有非常多，比如集團內部的全鏈路方案、集團內單元化方案等等。

設計目標和原則

要引入一套流量隔離方案，上線過程中，新、舊兩個版本服務同時存在時，流量能保證在同一個版本的“叢集”裡流轉，這樣就能解決重構帶來的內部介面不相容問題；
要解決上線過程中控制檯的平滑性問題，避免前端、後端、API更新不一致帶來的問題；
無上線需求的應用，可以不參與上線；
資源消耗要儘量少，畢竟做產品最終還是要考慮成本和利潤。

方案選型

集團內部的全鏈路方案：目前不支援阿里云云上；
集團內單元化方案：主要解決業務規模、容災等問題，和我們碰到的問題不一樣；
搭建獨立叢集，版本迭代時切叢集：成本太大；
自建：在同一個叢集隔離新、老服務，保證同一個使用者的流量只在同版本服務內流轉

以 RPC 為例：

方案一：通過開發保證，當介面不相容升級時，強制要求升級 HSF version，並行提供兩個版本的服務；缺點是一個服務變更，關聯使用方都要變更，協同成本特別大，並且為了保持平滑，新老介面要同時提供服務，維護成本也比較高。方案二：給服務（機器）按版本打標，通過 RPC 框架的路由規則，保證流量優先在同版本內流轉。

全鏈路灰度方案

就當 1、2、3、4 都覺得不完美，一邊調研一邊準備自建方案 5 的時候，兜兜繞繞拿到了阿里雲 MSE 微服務治理團隊《如何用20分鐘就能獲得同款企業級全鏈路灰度能力？》，方案中思路和準備自建的思路完全一致，也是利用了 RPC 框架的路由策略實現的流量治理，並且實現了產品化（微服務引擎-微服務治理中心），同時，聊了兩次後得到幾個“支援”，以及幾個“後續可以支援”後，好像很多事情變得簡單了…

從上圖可以看到，各個應用均需要搭建基線（base）環境和灰度（gray）環境，除了流量入口-業務閘道器以外，下游各個業務模組按需部署灰度（gray）環境，如果某次上線某模組沒有變更則無需部署。

• 各個中介軟體的治理方案

Mysql、ElasticSearch：持久化或半持久化資料，由業務模組自身保證資料結構相容升級；
Redis：由於對話產品會有多輪問答場景，問答上下文是在 Redis 裡，如果不相容則上線會導致會話過程中的 C 端使用者受影響，因此目前 Redis 由業務模組自身保證資料結構相容升級；
配置中心：基線（base）環境、灰度（gray）環境維護兩套全量配置會帶來較大工作量，為了避免人工保證資料一致性成本，基線（base）環境監聽 dataId，灰度（gray）環境監聽 gray.dataId 如果未配置 gray.dataId 則自動監聽 dataId；（雲小蜜因為在 18 年做混合雲專案為了保證混合雲、公共雲使用一套業務程式碼，建立了中介軟體適配層，本能力是在適配層實現）
RPC 服務：使用阿里雲 one agent 基於 Java Agent 技術利用 Dubbo 框架的路由規則實現，無需修改業務程式碼；
應用只需要加一點配置：

1）linux 環境變數 alicloud.service.tag=gray 標識灰度，基線無需打標profiler.micro.service.tag.trace.enable=true 標識經過該機器的流量，如果沒有標籤則自動染上和機器相同的標籤，並向後透傳
2）JVM 引數，標識開啟 MSE 微服務流量治理能力SERVICE_OPTS="${SERVICE_OPTS} -Dmse.enable=true"

• 流量管理方案

流量的分發模組決定流量治理的粒度和管理的靈活程度。
對話機器人產品需要灰度釋出、藍綠髮布目前分別用下面兩種方案實現：

灰度釋出：
部分應用單獨更新，使用 POP 的灰度引流機制，該機制支援按百分比、UID 的策略引流到灰度環境

藍綠髮布：
1）部署灰度（gray）叢集並測試：測試賬號流量在灰度（gray）叢集，其他賬號流量在基線（base）叢集
2）線上版本更新：所有賬號流量在灰度（gray）叢集
3）部署基線（base）叢集並測試：測試賬號流量在基線（base）叢集，其他賬號流量在灰度（gray）叢集
4）流量回切到基線（base）叢集並縮容灰度（gray）環境：所有賬號流量在基線（base）叢集

全鏈路落地效果

上線後第一次釋出的效果：“目前各個模組新版本的程式碼已經完成上線，含釋出、功能迴歸一共大約花費 2.5 小時，相較之前每次上線到凌晨有很大提升。”

MSE 微服務治理全鏈路灰度方案滿足了雲小蜜業務在高速發展情況下快速迭代和小心驗證的訴求，通過 JavaAgent 技術幫助雲小蜜快速落地了企業級全鏈路灰度能力。

流量治理隨著業務發展會有更多的需求，下一步，我們也會不斷和微服務治理產品團隊，擴充此解決方案的能力和使用場景，比如：RocketMQ、SchedulerX 的灰度治理能力。

更多的微服務治理能力

使用 MSE 服務治理後，發現還有更多開箱即用的治理能力，能夠大大提升研發的效率。包含服務查詢、服務契約、服務測試等等。這裡要特別提一下就是雲上的服務測試，服務測試即為使用者提供一個雲上私網 Postman ，讓我們這邊能夠輕鬆呼叫自己的服務。我們可以忽略感知雲上覆雜的網路拓撲結構，無需關係服務的協議，無需自建測試工具，只需要通過控制檯即可實現服務呼叫。支援 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 協議。

結束語

最終雲小蜜對話機器人團隊成功落地了全鏈路灰度功能，解決了困擾團隊許久的釋出效率問題。在這個過程中我們做了將部分業務遷移至阿里云云上、服務框架升級至 Dubbo3.0、選擇 MSE 微服務治理能力等等一次次新的選擇與嘗試。“世上本沒有路，走的人多了便成了路”。經過我們工程師一次又一次的探索與實踐，能夠為更多的同學沉澱出一個個最佳實踐。我相信這些最佳實踐將會如大海中璀璨的明珠般，經過生產實踐與時間的打磨將會變得更加熠熠生輝。

釋出雲原生技術最新資訊、彙集雲原生技術最全內容，定期舉辦雲原生活動、直播，阿里產品及使用者最佳實踐釋出。與你並肩探索雲原生技術點滴，分享你需要的雲原生內容。

關注【阿里巴巴雲原生】公眾號，獲取更多雲原生實時資訊！