前语
阿里云-达摩院-云小蜜对话机器人产品基于深度机器学习技能、自然语言理解技能和对话管理技能，为企业供给多引擎、多渠道、多模态的对话机器人服务。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 微服务管理才能等等一次次新的挑选与尝试。“世上本没有路，走的人多了便成了路”。经过咱们工程师一次又一次的探究与实践，可以为更多的同学沉淀出一个个最佳实践。我信任这些最佳实践将会如大海中璀璨的明珠般，经过生产实践与时刻的打磨将会变得愈加熠熠生辉。
发布云原生技能最新资讯、聚集云原生技能最全内容，定时举行云原生活动、直播，阿里产品及用户最佳实践发布。与你并肩探究云原生技能点滴，分享你需求的云原生内容。
重视【阿里巴巴云原生】公众号，获取更多云原生实时资讯！
