讯飞输入法异地多活架构实践之路 凌 军 自我介绍 • 凌军 • 2010年加入科大讯飞 • 讯飞输入法、灵犀语音助手等产品服务端架构负责人 • 科大讯飞消费者BG基础平台架构负责人 产品介绍 • 稳居国内输入法第一阵营 • 2010-10~至今 • 4亿用户 • 1.1亿月活 来自：中国科学院《互联网周刊》 大纲 • 产品发展中遇到的问题 • 异地多活存在哪些挑战 • • 讯飞输入法异地多活解决方案 • 实际应用效果 • 未来规划 单机房遇到的问题 可用性低 响应时间慢 系统扩容难 可用性低 响应时间慢 系统扩容难 大纲 • 产品发展中遇到的问题 • 异地多活存在哪些技术挑战 • 讯飞输入法解决方案 • 实际应用效果 • 后续规划 技术挑战 几十毫秒的延迟； 跨机房性能较慢 机房天然延迟 专线费用高； 专线不稳定 跨机房专线问题 • 产品发展中遇到的问题 • 异地多活存在哪些技术挑战 • 讯飞输入法异地多活解决方案 • 实际应用效果 • 未来规划 业务特点分析 业务分类 业务举例 业务特点 场景归类 核心业务 皮肤、表情、资源、广告、应用墙译等 读多写少 主从模式 （单点写，多点读） 用户个性化数据同步、账号等 读写均衡 多主模式 （多点读写） 分布式日志收集等 写多读少 汇聚模式 （多点写，单点读）

此简单需求，随着业务规模变大也会变的非常复杂。如何能将数据准确的在 3 秒钟之内推送到每⼀ 个计算节点，这是当时提出的⼀个要求，围绕这个要求，系统要做大量的研发和改造，类似的这种 关键的技术挑战点还非常非常的多。本书就是将面对复杂的分布式计算场景，海量并发的业务场景， 对软负载⼀个系统的进行阐述，通过 Nacos 开源分享阿里软负载最佳实践，希望能够帮助到各位开 发者，各位系统架构师，少走弯路。 阿里巴巴云原生应用平台负责人 性，可观测性等分布式系统指标影 响整个分布式系统的运行。历史上，这个系统在阿里也触发过大故障，经历过数次血与火的考验。 在阿里数次架构升级中，Nacos 都做了大量的功能迭代，用来支持阿里的异地多活，容灾演练，容 器化，Serverless 化。Nacos 经过阿里内部锤炼十年以上，各项指标已经及其先进，稳定，为服务 好全球开发者，Nacos 经过数十名工程师持续努力，以开源形式和大家见面，相信 由于当时 Spring-cloud 的崛起，微服务多个模块逐步被划分，包括注册中心、配置中心，如果从 产品定位上，期望定位简单清晰，利于传播，我们需要分别开源我们内部产品，这样又会分散我们 品牌和运营资源。另外大部分客户没有阿里这么大的体量，模块拆分过细，部署和运维成本都会成 倍上涨，而且阿里巴巴也是从最早⼀个产品逐步演化成 3 个产品的，因此我们最终决定将内部三个 产品合并统⼀开源。定位为：⼀

分布式环境下开发的调测效率问题 应对之道 远程应用服务 契约测试 分布式消息服务 分布式缓存 分布式服务的“租户”隔离策略 总体调测框架实践 分布式环境下调测方法论 单体应用 服务化 微服务 小中型规模应用+小型团队 中大型规模应用+多团队协同 Cache DB NFS Load Balancer website website website server server server server server (超)大型规模应用+契约协同 应用的发展演变历史 服务化后的问题 多团队协同的分布式环境下，不仅环境“重”，而且外部的服务是别的团队开发 的，你很难得到一个稳定、快速的外部服务提供环境，在此背景下进行功能/接口 调测存在如下困难： 开发依赖重 联调成本高 变动把控困难 拆 应用拆分 数据拆分 团队拆分 分布式服务 API 我写了个消息Consumer，布到线上准备测测，结果，别人的消 息先到了，一下把我的预置数据全搞乱了… 7. 我的开发机性能还行，我想自己装一套依赖环境提高开发调测 效率，结果消息服务、缓存服务、服务框架装完一启动，80% 的系统资源就没有了，想想还有一堆的应用服务还没装，直接 泪崩… 8. 办公区断网，所有线上依赖环境都无法访问了，得，今天啥也 干不了了，回家洗洗睡吧…. … ….. ……… 1 2 3 解决之道

集群 L4LB BFE平台架构 负载均衡器 vs 名字服务 基于负载均衡器 基于名字服务 方案对比 方案 对流量的控制力 资源消耗 对客户端的要求 适用场景 基于负载均 衡器 强。可以达到单个连 接 / 请求的粒度。 高。负载均衡器引 入了额外的资源消 耗。 低。客户端基本不 需要实现策略。 总体流量规模不大 （从负载均衡器资 源消耗的角度）； 应用场景对流量控 制要求高。 基于名字服 务 + 客户 端策略 弱。客户端直接访问 服务，没有可靠的卡 控点，无法实现精细 的流量控制测量。 低。不需要额外的 资源投入。 高。客户端需要支 持比较复杂的策略， 且涉及升级的问题。 总体流量规模较大； 应用场景对流量控 制要求低；无法使 用负载均衡器的场 景。 负载均衡器 • 负载均衡的趋势 • 硬件 => 软件 • 四层和七层负载均衡器分离 基于Go语言的生 态积累 • 更好的稳定性和安 全性 • 易于开发扩展功能 • 代表：BFE， Traefik API网关 七层负载均衡 BFE主要设计思想 • 转发模型优化 • 支持多租户 • 引入条件表达式，减少正则表达式使用 • 降低动态配置加载的难度 • 区分“常规配置”和“动态配置” • 增强服务状态监控能力 • 向外展现大量内部的执行状态 • 将大存储功能转移到外部

www.163yun.com 设计要点亓：数据库横向扩展 www.163yun.com 设计要点六：缓存的设计 APP缓存 CDN 接入层 静态资源 动态资源静态化 应用本地缓存 分布式缓存 数据库为中心 缓存为中心 www.163yun.com 设计要点七：消息队列与异步化 www.163yun www.163yun.com 设计要点十一：全链路监控 www.163yun.com 设计要点十二：全链路压测 www.163yun.com 微服务平台总览 容器平台 (多集群基础设施) Pod & Deployment 网络 Calico, OVS 存储 Ceph 滚动更新 弹性伸缩 日志中心 基础设施监控 开 发 集 群 测 试 集 概览 知识 库 服务 告警 监控 大屏 账户 审计 注册，发现，调用都提供鉴权 认证鉴权 接口文档统一维护 文档与运行时一致 减少调用沟通成本 知识库 根据平台、租户、项目三个层次区分权限作用域 操作记录，审计日志，事件查询 账户审计 微服务框架负责服务之间的调用——企业级特性 www.163yun.com 某证券公司 持续集成 中台化

prepare() OK prepare() OK commit() OK commit() OK • 提供强⼀一致保障 • 准备阶段完成资源操作 • 如果准备过程中出现问题，可以回滚 • 提交阶段不不允许出错 • 资源层⾯面提供保障业务侵⼊入性低 • 协议成本⾼高，并且存在全局锁的问题 ACID 与 BASE • ACID • 原⼦子性 （Atomicity） cfm?id=1394128 TCC • Try: 尝试执⾏行行业务 • 完成所有业务检查，预留留必须的业务资源 • Confirm：确认执⾏行行业务 • 真正执⾏行行业务，不不做业务检查 • Cancel：取消执⾏行行业务 • 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 原⼦子性（通过Saga协调器器实现） • ⼀一致性 (本地事务 + Saga log) • 隔离性 （Saga不不保证） • 持久性 （Saga log） 缺乏隔离性带来的问题 • 两个Saga事务同时操作⼀一个资源会出现数据语义不不⼀一致的的情况。 • 两个Saga事务同时操作⼀一个订单 ，彼此操作会覆盖对⽅方（更更新丢失） • 两个Saga事务同时访问扣款账号，⽆无法看到退款 （脏读取问题） •

prepare() OK prepare() OK commit() OK commit() OK • 提供强⼀一致保障 • 准备阶段完成资源操作 • 如果准备过程中出现问题，可以回滚 • 提交阶段不不允许出错 • 资源层⾯面提供保障业务侵⼊入性低 • 协议成本⾼高，并且存在全局锁的问题 ACID 与 BASE • ACID • 原⼦子性 （Atomicity） cfm?id=1394128 TCC • Try: 尝试执⾏行行业务 • 完成所有业务检查，预留留必须的业务资源 • Confirm：确认执⾏行行业务 • 真正执⾏行行业务，不不做业务检查 • Cancel：取消执⾏行行业务 • 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 原⼦子性（通过Saga协调器器实现） • ⼀一致性 (本地事务 + Saga log) • 隔离性 （Saga不不保证） • 持久性 （Saga log） 缺乏隔离性带来的问题 • 两个Saga事务同时操作⼀一个资源会出现数据语义不不⼀一致的的情况。 • 两个Saga事务同时操作⼀一个订单 ，彼此操作会覆盖对⽅方（更更新丢失） • 两个Saga事务同时访问扣款账号，⽆无法看到退款 （脏读取问题） •

框架型接⼝测试 引⼊平台型接⼝测试 ⾃研型接⼝测试 优势： 简单，易⽤，普及度⼴； 缺点： 规范难以制定，依赖个⼈的测试 习惯； 场景： 灵活，适合个⼈。 优势： 灵活度⾼，功能多； 缺点： 维护与编写成本⾼，更加依赖测 试⼈员个⼈能⼒； 场景： 灵活的业务场景与测试⽅式。 02 03 04 优势： 适合团队，⽅便度量和集成； 缺点： 闭源商业化平台价格较贵，开源 • 测试报告内容导出 性能测试脚本 • 完全兼容 JMeter 脚本 • ⾃由上传测试依赖⽂件 • 通过浏览器插件快速录制 性能测试环境 • 压测机统⼀管控 • 分布式、⼤规模压测资源池 JMeter-Pod-1 JMeter-Pod-2 JMeter-Pod-N JMeter-Pod-3 Kafka-1 Kafka-2 Kafka-n 主机-1 Node-Controller Node-Controller MySQL 数据库 DS-1 DS-2 DS-n Data-Streaming 集群 Kafka 集群 Kubernetes 集群 独⽴主机集群 多压测任务同时下发 结果⽇志回传 Kafka 结果⽇志回传 Kafka Data-Streaming 消费 Kafka Data-Streaming 计算后 的数据落库 被压测系统 被压测系统

从Loki=>Menicus • 提供日志的搜索/报警/处理等功能 系统介绍 • 为什么放弃 Loki • 资源占用过大 • 统计/计算能力比较弱 • 组件过多，排查问题比较困难 • 商业使用不友好的开源协议 • 为什么选择Mencius+ClickHouse • 存储计算与业务分离 • 计算/统计能力更强 • 资源占用更小，性能更好 • 更友好的开源协议 系统介绍 • 多种接入方式 • Agent Agent • Client • 查询 • LogQL • OpenTSDB • 其他功能 • 多租户 • 自定义索引 • 多维度统计 • 鉴权 • ... 系统介绍 • 写入 • 每天 100G • 磁盘 • 压缩比 1:13 • 内存 • Mencius • 200M左右 • ClickHouse • 2G以下 • 接入端 • API Gateway • 日志服务(Mencius)

历了无数的悲喜，也留下了满满的回忆。 也许生活就是这样，只有历尽波澜，才能欣赏茫茫大海的辽阔和无边， 才能感受到漫天星辰的光芒和温暖。 在2023年春节到来之际，我们从去年美团技术团队公众号上精选了60多 篇技术文章，整理制作成一本1300多页的电子书，作为新年礼物赠送给 大家。 这本电子书内容覆盖算法、前端、后端、数据、安全等多个技术领域， 希望能对同学们的工作和学习有所帮助。 也欢迎大家转给更多有相同兴趣、积极上进的同事和朋友们，一起切 目标检测开源框架 YOLOv6 全面升级，更快更准的 2.0 版本来啦 13 通用目标检测开源框架 YOLOv6 在美团的量化部署实战 17 7 次 KDD Cup&Kaggle 冠军的经验分享：从多领域优化到 AutoML 框架 37 图神经网络训练框架的实践和探索 66 图技术在美团外卖下的场景化应用及探索 83 大规模异构图召回在美团到店推荐广告的应用 102 美团搜索粗排优化的探索与实践 879 工程效能 CI/CD 之流水线引擎的建设实践 912 美团外卖搜索基于 Elasticsearch 的优化实践 933 美团图灵机器学习平台性能起飞的秘密（一） 953 提升资源利用率与保障服务质量，鱼与熊掌不可兼得？ 971 标准化思想及组装式架构在后端 BFF 中的实践 992 外卖广告大规模深度学习模型工程实践 | 美团外卖广告工程实践专题连载 1013 数据库全量