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

设计要点八：熔断，限流，降级 www.163yun.com 设计要点九：配置中心 www.163yun.com 设计要点十：日志中心 www.163yun.com 设计要点十一：全链路监控 www.163yun.com 设计要点十二：全链路压测 www.163yun.com 微服务平台总览 容器平台 (多集群基础设施) Pod & Deployment 网络 Calico API 监控 认证 鉴权 治理 文档 报表 微服务框架 (服务治理) 服务 目录 注册 发现 限流 熔断 降级 容错 路由 负载 均衡 参数 分流 拓扑 依赖 配置 中心 服务 监控 服务 告警 认证 鉴权 统计 概览 知识 库 APM (应用运行期监控) 运行时 拓扑 性能 监控 服务 筛选 调用 链 调用 栈 com 开发集群 测试集群 CICD (开发流程管理) 流水线管理 代码 检出 代码 编译 镜像 构建 集成 测试 部署 测试平台 (集成，场景测试) 单接口 用例 场景 用例 执行 集 定时 执行 接口 Mock 覆盖 率 生产镜像 仓库 测试镜像 仓库 历史 管理 批量 导入 接口 监控 生产集群 镜像

AND/IOS/H5/Open 静态站 网贷服务 借款流程 Cache集群 安全加密 网贷服务 CDN 支付结算 订单 DB从 批 处 理 系 统 活动 DB主 DB从 版本管理 产品 ... 同步 …... 网站、基础服务 移动后台 业务和团队规模迅速扩张 粗粒度服务化，基础设施完善 CDN/页面缓存/静态站/缓存集群 移动后台旁路 流程double，冗余开始出现 继续成长,瓶颈明显 后台日益庞大，业务冗余严重 N多业务排队上线，瓶颈明显 热点场景频发，影响单体稳定 2pizza团队，系统单体制约 商城 核心服务 业务 网贷 保险 基金 商城 财富圈 健康财富 加密 验签 拦截 校验 安全 性能 并发 幂等 交易 缓存 基础服务 消息 监控 配置 报警 MIS OpenAPI 微信 财富圈 标签 用户 管理平台 产品 理财单 渠道 版本 5G 措施:剥组件,拆单体,合冗余 移动后台打散 轻业务上浮 重业务下沉 API接入 指标监控 配置管理 业务前置配置 日志 配置系统 安全控制 拦截、校验 接口签名 加解密 防刷 攻击类 接口缓存 接口重写 热点活动支持 热点功能前置 接口版本控制 业务前置控制 Ng+ LUA 流量调度

IP还支持消息模式) 统一配置、统一监控、统一管理 VIP弹性调度系统 -- Saturn 开源地址： Github.com/vipshop/Saturn 体系中的定位 服务化框OSP 开发框架Venus 唯品会基础架构体系 消息队列 VMS 全链路监控 Mercury 统一日志平台 dragonfly 任务调度平台 Saturn 统一配置中心 CfgCenter 部署模型(跨机房) IDC-A IDC-B 接入域-A 执行结点 作业实现 ZK saturn-zk-* saturn.vip.com 控制台集群 (Tomcat) ZK Observe r ob-saturn-zk-* 2台 3台 x台 调度器集群 接入域-B 执行结点 作业实现 功能地图 01 02 03 多种作业类型与 作业模式 资源动态平衡 框架与业务隔离 三大功能特性 提供多种业务开发模式，满足不同的业务需求 • 多种业务运行模式，即可分布式管理也可本地管理 • 通过异步消息实现业务编排* 多种作业类型 人工指定 运行节点 系统自动 平衡负载 资源利用 • 灵活的运维配置与部署 • 高效资源利用 • 简便的管理 人工指定 自动平衡 资源平衡调度算法 框架代码 与业务代 码隔离 集中化动 态增加与 删除作业 • 简化开发，避免冲突，业务无侵入 • 易于发布与维护

固化策略略，需线下修改代码，测试，发布，线上应急策略略响应不不 友好 • ⽆无法⽀支撑多系统的复合指标计算，业务降级⽀支持不不友好 • ⼤大量量应⽤用各⾃自实现降级熔断，代码散落在各应⽤用，没有统⼀一的管 理理和治理理。久⽽而久之，⽆无⼈人知道系统内有多少降级点，降级是如 何实现的 • 缺乏UI、没有灵活的参数、策略略配置，没有预案制定管理理能⼒力力 业务保障平台建设之路路 业务保障平台建设之路路 服务管理理 策略略管理理 预案制定 线上演练 • 降级服务统⼀一注册管理理，通过降 级服务质量量数据从整体反映各应 ⽤用的降级点和可⽤用性保障措施 • 降级策略略集中管理理，通过参数 化、配置化、脚本化⽅方式实现线 上策略略的灵活调整 • 依据服务重要程度，从全局制定 分级预案，对降级点进⾏行行预案编 排，并跟踪监控降级链路路的执⾏行行 • 发现潜在故障，多维度验证预案 有效性，评估系统可靠性，提供 ⻓长链接，数据流⽅方式实时发送 • 本地多队列列轮循，数据缓冲，合并异步发送 指标如何计算处理理 数据采集 KAFKA ETL 复合指标 ⾃自定义指标 系统指标 业务指标 指标脚本计算 指标规则计算 指标脚本 规则表达式 熔断 降级 条件 计算 降级消息 数据 存储 实时告警 规则配置 开发 ⽇日志解析规则 控制中⼼心 ETCD 降级服务 降级处理理 流处理理集群（Flink） HBase

新技术的应用 目录 关于极光 36.9 万 开发者 107.6 万 APP 198 亿 移动终端 10.4 亿 月独立 活跃设备 90 % 覆盖率 亿级长连接用户 SDK多版本并存 消息实时性 触达率要求 移动网络环境复杂性 海量用户数据存储 消息推送系统面临的挑战 极光推送服务架构 系统通道 API 用户筛选 用户分发 推送通道 极光通道 共享通道 • IDC数据同步 • 异步RPC • ICE - 负载均衡，AMI，AMD，多线程 极光推送后台系统架构 02 并行化 • 横向扩展处理能力 • 数据分片存储 • 多节点+分片+多副本架构 • 数据读写动态路由 • 请求并行处理 • 模块级别并行 • 代码级别并行 极光推送后台系统架构 03 MQ Segment OnlineMsg OnlineMsg OnlineMsg Couchbase, LevelDB(PIKA), 定制化 极光推送后台系统架构 04 程序及系统优化 • 内存 • 静态分配 • 内存池 • 内存对齐 • CPU Affinity • 网卡多队列 • 用户态协议栈（DPDK） 极光推送后台系统架构 05 基础组件服务化 • 业务方透明 • 统一管理 • 屏蔽后端变化 • AutoScale，Failover，AutoRecover

各国法律法规(版权,协议,第三方,accessibility), 安全性和隐私… • 地域不同: 服务器的部署, 用户的访问, 组织架构, 团队沟通… 项目实例 -- XA项目背景及需求 • 多设备协作 PC, Mobile, Pad, Cloud… • 跨设备及云智能搜索 • 语音等多种输入方式 用例示意图 用户输入支持举例 3D Camera 项目实例 -- 项目开发团队 用户访问量对应的web架构 用户访问量 服务器架构 百万以下 单台或多台的简单架构,可以简单通过升级服务器 配置支持更多用户 百万到千万 增加Nginx(反向代理)或DNS负载均衡,redis内存 cache,数据库(Mysql)多台(数据在一个数据中心) 千万到亿 增加Web服务器内存缓存,集群,IP负载均衡,基于内 容请求分发,Mysql优化(如减少写,2/8原则),数据在 一个数据中心 亿以上 -- Threat Model 端到端的安全设计I 端到端的安全设计II 端到端的安全设计III 端到端的安全设计IV 端到端的安全设计 • 只Admin可以写(避免提升权限) • 验证配置文件(如xml)的签名 • 专业工具扫描 总结 • 国际化项目的特点导致架构工作的不同 • 一些应用实例 一句话分享 • 不要用战术上的勤奋来弥补战略上的懒惰

固定HASH算 法 固定数目 数据分片 桶->存储节点 对照表 Cellar起源—Tair架构 服务层 请求 mdb 响应 ldb fdb rdb 引擎层 迁移 复制 • 中心化集群问题 • 可用性问题 • 性能问题 • 运维问题 Cellar起源—Tair问题 Cellar起源 架构升级 性能优化 可用性优 化 可运维性 Cellar 开源 Tair • Cellar起源 2分片主 分片1复制 回写增量log 分片2复制 分片2复制 分片1复制 客户端 分片1&2 log Cellar—异地容灾 • 多机房建设 网络延迟大 专线稳定性差 • 异地容灾需求 跨集群数据同步 Cellar—异地容灾 集群节点同步 消息队列同步 复制延迟 低 高 系统复杂度 低 高 运维成本 低 高 实现难度 高 低 扩展性 低 高 • 低延迟 • 低复杂度（运维成本） 耗时接口（range···） • value过大 • 单请求key过多 • ··· • Cellar起源 • 中心节点架构演进 • 节点高可用和异地容灾 • 服务可用性提升 • Cellar规划 目录 系统研发 • 异地多活 • 跨机房自动容灾 • 磁盘粒度容灾 • 数据迁移优化 可运维性 • 容器化 • 自动扩缩容 Cellar规划 谢谢

Ø 设计和验证高可用分布式系统的案例分享 Ø 高可用系统的最佳实践总结 依据声明式自愈的理念设计系统 有一个统一的状 态持久化接口， 所有有状态模块 通过统一的接口 对应统一的对象 模型 配置模块对象只 需要包括 Desired State 每个领域的控 制器模块的逻 辑保证自己领 域独立自愈的 能力 改变状态的操作 必须是幂等的声 明式操作，没有 新声明时各模块 按照之前的声明 State u 创建1个新的Pod Ø Controller观察特定领域的 系统状态 Ø 协调Desired State跟 Realized State之间的差 距，维持最终一致性 Ø 定期处理集群中的事件 Ø 系统必须是幂等的 控制器的设计理念 控制逻辑应该只依赖于当前状态 假设任何错误的可能，并做容错处理 尽量避免复杂状态机，逻辑不要依赖无法监控的内部状 态 每个模块都可以在必要时优雅地降级服务 错误回复缓存，过期时间不能太长，而且有清晰的 修复建议 Ø 数据库更新与缓存失效的策略 最佳实践分享 有关配置文件 Ø 集群使用统一的配置来源 Ø 定义正常的默认配置，满足读取不到配置的正 常运行 Ø 支持可扩展的配置命令格式 Ø 尽量支持更改配置不需要重启服务 Ø 注意配置项之间的关联性 欢迎与我交流 王昕个人微信 欢迎与我交流 王昕个人微信

百度文件系统BFS - 万亿量级实时数据库Tera - 集群调度系统Galaxy • 个人主页&Blog - https://github.com/bluebore - http://bluebore.cn 提纲 • 百度文件系统简介 • 分布式系统设计实践 • 总结与致谢 百度的集群环境 • 单个集群通常几千台机器 • 百度文件系统(BFS)、集群调度系统（Galaxy）、分布式协 调服务（Nexus）是核心服务 master BFS master Nexus lock service 分布式软件栈中的BFS The Baidu Stack 网络通信框架Sofa-pbrpc 分布式文件系统 BFS 集群调度系统 Galaxy 分布式协调服务 Nexus 分布式数据库 Tera 分布式计算框架 Shuttle Apps(Spider/Index/Search) 数据中心操作系统(DCOS) 交换机故障： 几十台机器突然消失 - 磁盘、单机故障 • 通过冗余应对故障 一个典型的数据处理场景 数据处理模块 数据接收模块 存储 主 从 从 1. 写入 2. 通知 3. 读取 多副本冗余 一致性问题 • 怎么定义写成功 - 3副本成功, 影响可用性 • 可以读从节点 - 刚写入的读不到 - 不一致 • 只允许读主节点 - 扩展性受限 数据处理模块 数据接收模块