共计 3641 个字符，预计需要花费 10 分钟才能阅读完成。
简介：阿里云 - 达摩院 - 云小蜜对话机器人产品基于深度机器学习技术、自然语言了解技术和对话治理技术，为企业提供多引擎、多渠道、多模态的对话机器人服务。17 年云小蜜对话机器人在公共云开始公测，同期在混合云场景也一直拓展。为了同时保障公共云、混合云发版效率和稳定性，权衡再三咱们采纳了 1-2 个月一个大版本迭代。
前言
阿里云 - 达摩院 - 云小蜜对话机器人产品基于深度机器学习技术、自然语言了解技术和对话治理技术，为企业提供多引擎、多渠道、多模态的对话机器人服务。17 年云小蜜对话机器人在公共云开始公测，同期在混合云场景也一直拓展。为了同时保障公共云、混合云发版效率和稳定性，权衡再三咱们采纳了 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 服务即可，无需额定改变。
解决了互通、服务注册发现的问题之后，就是开始看如何进行服务治理计划了。
阿里云云上流量治理
迁徙至阿里云云上之后，流量管制计划有十分多，比方团体外部的全链路计划、团体内单元化计划等等。
设计指标和准则
- 要引入一套流量隔离计划，上线过程中，新、旧两个版本服务同时存在时，流量能保障在同一个版本的“集群”里流转，这样就能解决重构带来的外部接口不兼容问题；2. 要解决上线过程中控制台的平滑性问题，防止前端、后端、API 更新不统一带来的问题；3. 无上线需要的利用，能够不参加上线；4. 资源耗费要尽量少，毕竟做产品最终还是要思考老本和利润。
计划选型
- 团体外部的全链路计划：目前不反对阿里云云上；
- 团体内单元化计划：次要解决业务规模、容灾等问题，和咱们碰到的问题不一样；
- 搭建独立集群，版本迭代时切集群：老本太大；
- 自建：在同一个集群隔离新、老服务，保障同一个用户的流量只在同版本服务内流转
以 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 微服务治理能力等等一次次新的抉择与尝试。“世上本没有路，走的人多了便成了路”。通过咱们工程师一次又一次的摸索与实际，可能为更多的同学积淀出一个个最佳实际。我置信这些最佳实际将会如大海中璀璨的明珠般，通过生产实践与工夫的打磨将会变得更加熠熠生辉。
原文链接
本文为阿里云原创内容，未经容许不得转载。
