两年通信设备开发经验，四年互联网 • 五年C/C++使用经验，一年Golang 2 CONTENTS • 程序开发的需求 • Golang特性 • Go开发mysql中间件 • 整体方案 • 分表路由 • 故障切换 • 平滑扩容 • 系统运维 3 程序开发的需求 • 语言特性精炼，容易入门 • 开发效率高，代码逻辑清晰 • 运行性能强，节省机器资源 • 部署维护方便 • 生态圈完善 4 9 故障主备切换 • 故障情形 • 从节点挂掉：进行剔除下线处理 • 主节点挂掉，机器存活：通过binlog恢复数据，提升备为主 • 主节点挂掉，机器不存活：采用Relaylog恢复数据，提升备为主 • 部署模式 • 一主多从 • 双主多从 10 故障主备切换 • 一主多从模式 master slave slave slave slave 机房A 机房B Dead-Master 日志 Latest-Slave与Slave差异 日志 Master故障时试图通过Rsync拉取Binlog，最大程度保 证数据不丢失； Slave之间的数据差异通过中继日志恢复。 • 数据恢复工作原理 11 故障主备切换 • 双主多从模式 master slave slave slave slave 机房A 机房B master 12 在线平滑扩容 • 数据迁移形式 •

⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved • 直接配置主从同步 • 机房间⺴⽹网络差，⾮非常差（北京<->⾹香港，北京<->北美） • 会触发Redis全量同步（超过repl-backlog-size时） Redis跨机房同步 需要替代⽅方案 专业DSP解决⽅方案 © ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll ReservedAll Right Reserved • 取消Redis的主从同步 • 写主Redis时，同时写⼀一份到NSQ，异步写⼊入其他机房 • 使⽤用SoftLayer的⾹香港云主机作为中转（why?) Redis跨机房同步 专业DSP解决⽅方案 © ⼲⼴广州舜⻜飞信息科技有限公司 All Right ReservedAll Right Reserved • 内存占⽤用过⼤大时，可以切分为多个实例，减少单个实例 All Right ReservedAll Right Reserved • 性能不⽐比Redis差 • SSD优化 • 完备的分布式集群 • ⼆二级索引 • 开源，企业版⽀支持跨机房的集群 • 99%的请求1ms响应 • ⽀支持的数据结构类型偏简单 CookieMapping: Aerospike 专业DSP解决⽅方案 © ⼲⼴广州舜⻜飞信息科技有限公司 All

links links 目录 上一节: 国际化站点 下一节: 错误处理，故障排除和测试 225 11 错误处理，调试和测试 11 错误处理，调试和测试 我们经常会看到很多程序员大部分的"编程"时间都花费在检查bug和修复bug上。无论你是在编写修改代码还是重构系 统，几乎都是花费大量的时间在进行故障排除和测试，外界都觉得我们程序员是设计师，能够把一个系统从无做到 有，是一项很伟大 例如有些时候可能我们的误操作引起了数据的丢失，那么master/slave模式是无法找回丢失数据的，但是通过冷备份 可以部分恢复数据。 冷备份一般使用shell脚本来实现定时备份数据库，然后通过上面介绍rsync同步非本地机房的一台服务器。 下面这个是定时备份mysql的备份脚本，我们使用了mysqldump程序，这个命令可以把数据库导出到一个文件中。 #!/bin/bash # 以下配置信息请自己修改 mysql_user="USER" 考官方的文档配置，相当的简单。我们这里介绍冷备份 的方式：redis其实会定时的把内存里面的缓存数据保存到数据库文件里面，我们备份只要备份相应的文件就可以， 就是利用前面介绍的rsync备份到非本地机房就可以实现。 redis恢复 redis恢复 redis的恢复分为热备份恢复和冷备份恢复，热备份恢复的目的和方法同MySQL的恢复一样，只要修改应用的相应的数 据库连接即可。 但是有时候

svr：cache（redis） + db（mysql） – Route svr：cache + cache（standy） 架构—异地双活 • 要求 – 正常情况下： • 任何一个机房可推送到所有机房app – 异常情况下： • 本机房内推送可达 • 架构图如下 （核心解决路由共享问题） 架构—总结 • 异步通信接口 • 协议包业务态隔离 • 简单无状态 • 有状态的服务（涉及到存储）做到可降级

deploy:rollback app 简单 激情 速度快 聚焦 极致 可信赖 注意事项 1. 发布后的监控报警系统 2. 部署并行，串行 3. Github国内连接 4. 回滚 5. 多国机房的问题 简单 激情 速度快 聚焦 极致 可信赖 原有问题是如何被解决的 1. 迭代周期漫长 2. 质量缺乏保障 3. 系统可维护性差 4. 开发过程透明度差 简单 激情 速度快 聚焦 极致

数据缓冲，提⾼可⽤性 ，缓冲服务故障 使⽤案例 ⼴告点击数统计 Web Service MySQL cluster User Click User Click User Click Stateless Stat Service Stateless 2. 数据⼴播 MQ stream computing 使⽤需求 • 数据缓冲，提⾼可⽤性 ，缓冲服务故障 • 数据⼴播，分发给多个服务 MQ stream computing Web Service stream computing stream computing 使⽤需求 • 数据缓冲，提⾼可⽤性 ，缓冲服务故障 • 数据⼴播，分发给多个服务 • 负载均衡，提⾼消费者的扩展性 使⽤案例 ⼴告点击数统计 Web Service MySQL cluster 4. 正确消费确认 MQ stream stream computing Web Service stream computing stream computing Msg 使⽤需求 • 数据缓冲，提⾼可⽤性 ，缓冲服务故障 • 数据⼴播，分发给多个服务 • 负载均衡，提⾼消费者的扩展性 • 消费反馈，确保消息不丢失 使⽤案例 ⼴告点击数统计 Web Service MySQL cluster User

宏观： • 为什么公司的系统总是在同⼀个环节出故障，有没有成熟的⼯具和流程能够避免这 些故障？ • 为什么让⼤家升级⼀个 sdk 这么难？ 微观： • 为什么这⾥不加锁也是安全的？ • 怎么样减少 valiation 的⼯作量？ ⾃身 • 要做⼀个有好奇⼼的⼈ • 与有好奇⼼的⼯程师多交流 举例 公司内和队列相关的业务总是出故障，⽐如： • 公司⾥的团队使⽤的 kafka sdk 上游的业务团队会调整发出来的业务消息，经常导致下游发 ⽣故障 举例 公司内和队列相关的业务总是出故障，⽐如： • 公司⾥的团队使⽤的 kafka sdk 有问题，总会碰到断连不重 连的情况 • 上游发出来的订单状态机顺序因为⽹络问题会发⽣乱序，影 响我的计算流程 • 上游的业务团队会调整发出来的业务消息，经常导致下游发 ⽣故障 Deprecation 章节 Dependa bot

资源状态 李晨曦 GitHub: hexilee PingCAP R&D PingCAP 研发工程师，CNCF 开源项目 Chaos Mesh® 核心贡献者， 主要负责工程效率提升和 HTTP 故障注入功能的设计实现。并推动 GraphQL 在 Chaos Mesh 项目中的实践落地。 目录 1. Chaos Mesh 介绍 2. 问题与解决方案 3. 设计思路与实现 4. 后续的工作 com/chaos-mesh Chaos Mesh 是什么 我们的目标 ● 建立一个完全闭环的云原生混沌工程平台 ● 让混沌工程变得更易用 问题与解决方案 集群中的状态 Chaos Mesh 本身的运行和注入的故障会 给各组件以及目标 Pod 带来各种状态。 cluster status Components Controller Daemon Dashboard Dns Server Pods Status Processes ipset iptables Pid Command Fds 集群中的状态 在实际混沌实验过程中，可能会出现注入的错误不符合预期，甚至完全没有效果的情况。能否高效 地获取各种状态则决定了故障诊断的效率。 集群状态大致可以分为两类，主要分类依据是能否通过 kubernetes API 直接查询。 k8s 可直接查询的状态 Kubernetes 和 Chaos Mesh 组件运行的状态均可直接通过

高性能 • 支持水平扩展 • 无单点故障 Go语言特性 • 静态的、编译的 • 自动内存回收 • 命令式编程 • 函数可以作为值 • 面向并发 • 内置RPC支持 推送服务器要求的应对 • 高并发 – goroutine • 可靠性 – 使用Redis暂存消息 • 高性能 – 静态编译语言 • 支持水平扩展 – 使用RPC组成集群 • 无单点故障 – 使用Redis实现数据共享

单体和微服务怎么选？ 单体的优点 • 开发简单 • 测试简单 • 部署简单 • 扩展简单 单体的缺点 • 难以理解和功能扩展 • ⼩改动也得全量更新 • ⼩问题容易触发⼤故障 • 能够⽀撑的业务规模有限 微服务的优点 • 边界清晰的业务拆分 • 易开发、易理解、易维护 • 技术栈可相对独⽴ • 持续集成、持续部署更容易 • 按需对服务进⾏治理 fork请求，proxy验证 • 定期复盘过程，总结可复制套路 • 汇报成果，让领导看到收益 数据拆分 • 数据不能乱，规则先确定 • 定义数据边界，避免数据冗余 • 数据库互相隔离，避免故障传递 • No join, no pain! ⽤户 商品 订单 物流 接⼝聚类收敛 • 按功能聚类接⼝ • 避免微服务过微 • 避免调⽤链路过深 正确性验证 • 循序渐进可回滚