前言
阿里云-達摩院-云小蜜對話機器人產品基于深度機器學習技術、自然語言理解技術和對話管理技術，為企業提供多引擎、多渠道、多模態的對話機器人服務，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 微服務治理能力等等一次次新的選擇與嘗試，“世上本沒有路，走的人多了便成了路”，經過我們工程師一次又一次的探索與實踐，能夠為更多的同學沉淀出一個個最佳實踐，我相信這些最佳實踐將會如大海中璀璨的明珠般，經過生產實踐與時間的打磨將會變得更加熠熠生輝，
發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，
關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/438024.html
標籤：其他