烟台网站制作公司在线咨询,做网站外包价格,网站维护年费,宁波效果图公司简介#xff1a;阿里云-达摩院-云小蜜对话机器人产品基于深度机器学习技术、自然语言理解技术和对话管理技术#xff0c;为企业提供多引擎、多渠道、多模态的对话机器人服务。17 年云小蜜对话机器人在公共云开始公测#xff0c;同期在混合云场景也不断拓展。为了同时保证公共…简介阿里云-达摩院-云小蜜对话机器人产品基于深度机器学习技术、自然语言理解技术和对话管理技术为企业提供多引擎、多渠道、多模态的对话机器人服务。17 年云小蜜对话机器人在公共云开始公测同期在混合云场景也不断拓展。为了同时保证公共云、混合云发版效率和稳定性权衡再三我们采用了 1-2 个月一个大版本迭代。
前言
阿里云-达摩院-云小蜜对话机器人产品基于深度机器学习技术、自然语言理解技术和对话管理技术为企业提供多引擎、多渠道、多模态的对话机器人服务。17 年云小蜜对话机器人在公共云开始公测同期在混合云场景也不断拓展。为了同时保证公共云、混合云发版效率和稳定性权衡再三我们采用了 1-2 个月一个大版本迭代。
经过几年发展为了更好支撑业务发展架构升级、重构总是一个绕不过去的坎为了保证稳定性每次公共云发版研发同学都要做两件事
1. 梳理各个模块相较线上版本接口依赖变化情况决定十几个应用的上线顺序、每批次发布比例
2. 模拟演练上述1产出的发布顺序保证后端服务平滑升级客户无感知。
上述动作每次都需要 2-3 周左右的时间梳理、集中演练但是也只能保证开放的 PaaS API 平滑更新。
控制台服务因为需要前端、API、后端保持版本一致才能做到体验无损如果每次迭代统一升级 API 版本开发、协同成本又会非常大权衡之下之前都是流量低谷期上线尽量缩短发布时间避免部分控制台模块偶发报错带来业务问题。
针对上面问题很早之前就考虑过用蓝绿发布、灰度等手段解决但是无奈之前对话机器人在阿里云内部业务区域该不再允许普通云产品扩容没有冗余的机器流量治理完全没法做。
迁移阿里云云上
带着上面的问题终于迎来的 2021 年 9 月份云小蜜将业务迁移至阿里云云上。
Dubbo 3.0 的实践
“当时印象最深的就是这张图虽然当时不知道中间件团队具体要做什么事情但是记住了两个关键词三位一体、红利。没想到在 2021 年底真真切切享受到了这个红利。” 云小蜜使用的是集团内部的 HSF 服务框架需要迁移至阿里云云上并且存在阿里云云上与阿里内部业务域的互通、互相治理的诉求。云小蜜的公共服务部署在公有云 VPC部分依赖的数据服务部署在内部内部与云上服务存在 RPC 互调的诉求其实属于混合云的典型场景。
简单整理了下他们的核心诉求概括起来有以下三点
1. 希望尽可能采用开源方案方便后续业务推广
2. 在网络通信层面需要保障安全性
3. 对于业务升级改造来说需要做到低成本。 在此场景下经过许多讨论与探索方案也敲定了下来
全链路升级至开源 Dubbo3.0云原生网关默认支持 Dubbo3.0实现透明转发网关转发 RT 小于 1ms利用 Dubbo3.0 支持 HTTP2 特性云原生网关之间采用 mTLS 保障安全利用云原生网关默认支持多种注册中心的能力实现跨域服务发现对用户透明业务侧无需做任何额外改动业务侧升级 SDK 到支持 Dubbo3.0配置发布 Triple 服务即可无需额外改动。
解决了互通、服务注册发现的问题之后就是开始看如何进行服务治理方案了。
阿里云云上流量治理
迁移至阿里云云上之后流量控制方案有非常多比如集团内部的全链路方案、集团内单元化方案等等。
设计目标和原则
1. 要引入一套流量隔离方案上线过程中新、旧两个版本服务同时存在时流量能保证在同一个版本的“集群”里流转这样就能解决重构带来的内部接口不兼容问题2. 要解决上线过程中控制台的平滑性问题避免前端、后端、API更新不一致带来的问题3. 无上线需求的应用可以不参与上线4. 资源消耗要尽量少毕竟做产品最终还是要考虑成本和利润。
方案选型
1. 集团内部的全链路方案目前不支持阿里云云上
2. 集团内单元化方案主要解决业务规模、容灾等问题和我们碰到的问题不一样
3. 搭建独立集群版本迭代时切集群成本太大
4. 自建在同一个集群隔离新、老服务保证同一个用户的流量只在同版本服务内流转
以 RPC 为例
方案一通过开发保证当接口不兼容升级时强制要求升级 HSF version并行提供两个版本的服务缺点是一个服务变更关联使用方都要变更协同成本特别大并且为了保持平滑新老接口要同时提供服务维护成本也比较高。方案二给服务机器按版本打标通过 RPC 框架的路由规则保证流量优先在同版本内流转。
全链路灰度方案
就当 1、2、3、4 都觉得不完美一边调研一边准备自建方案 5 的时候兜兜绕绕拿到了阿里云 MSE 微服务治理团队《如何用20分钟就能获得同款企业级全链路灰度能力》方案中思路和准备自建的思路完全一致也是利用了 RPC 框架的路由策略实现的流量治理并且实现了产品化微服务引擎-微服务治理中心同时聊了两次后得到几个“支持”以及几个“后续可以支持”后好像很多事情变得简单了... 从上图可以看到各个应用均需要搭建基线base环境和灰度gray环境除了流量入口-业务网关以外下游各个业务模块按需部署灰度gray环境如果某次上线某模块没有变更则无需部署。
各个中间件的治理方案
1. Mysql、ElasticSearch持久化或半持久化数据由业务模块自身保证数据结构兼容升级
2. Redis由于对话产品会有多轮问答场景问答上下文是在 Redis 里如果不兼容则上线会导致会话过程中的 C 端用户受影响因此目前 Redis 由业务模块自身保证数据结构兼容升级
3. 配置中心基线base环境、灰度gray环境维护两套全量配置会带来较大工作量为了避免人工保证数据一致性成本基线base环境监听 dataId灰度gray环境监听 gray.dataId 如果未配置 gray.dataId 则自动监听 dataId云小蜜因为在 18 年做混合云项目为了保证混合云、公共云使用一套业务代码建立了中间件适配层本能力是在适配层实现
4. RPC 服务使用阿里云 one agent 基于 Java Agent 技术利用 Dubbo 框架的路由规则实现无需修改业务代码
应用只需要加一点配置
1linux 环境变量 alicloud.service.taggray 标识灰度基线无需打标profiler.micro.service.tag.trace.enabletrue 标识经过该机器的流量如果没有标签则自动染上和机器相同的标签并向后透传
2JVM 参数标识开启 MSE 微服务流量治理能力SERVICE_OPTS${SERVICE_OPTS} -Dmse.enabletrue
流量管理方案
流量的分发模块决定流量治理的粒度和管理的灵活程度。
对话机器人产品需要灰度发布、蓝绿发布目前分别用下面两种方案实现
1. 灰度发布
部分应用单独更新使用 POP 的灰度引流机制该机制支持按百分比、UID 的策略引流到灰度环境
2. 蓝绿发布
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 微服务治理能力等等一次次新的选择与尝试。“世上本没有路走的人多了便成了路”。经过我们工程师一次又一次的探索与实践能够为更多的同学沉淀出一个个最佳实践。我相信这些最佳实践将会如大海中璀璨的明珠般经过生产实践与时间的打磨将会变得更加熠熠生辉。
原文链接
本文为阿里云原创内容未经允许不得转载。
