越来越多的App在移动网络下开始发力，介绍在实际工作中遇到的各种技术挑战，包括的范围有开发、架构、运维、流程各方面的问题和解决办法。

1. 移动互联网技术挑战
54chen@ssdc
h+p://54chen.com
2013.11

2. 2010年
移动互联网
更奇特的网络环境，更高的响应要求
似曾相识的开发、架构、运维、流程

3. 开发

4. 网络问题
• DNS
• 不同运营商之间
• 不同地域之间

5. DNS
•
•
•
•
问题：解析不准、不解析
保底IP、域名
反查协议
数据修正

6. 跨地域、跨IDC
•
•
•
•
问题：慢、不通
调度系统
udp
摸索修正

7. 调度系统

8. 其他
•
•
•
•
2Gwap、3Gwap
慢、连不上
建立反馈渠道
依旧对未来充满信心

9. 数据同步问题
• Server-­‐db：业务更新最终更新点。
• Client-­‐db：业务更新最初更新点。
• 更新失败，数据不同步。

10. • 类似微信的sync协议
• 每个请求带读写水位
• Client-db只作缓存
• 省流平衡点
A
• Bug防备省流
B

11. 开发
• 奇异的网络环境
• 特殊的数据同步
• 敏感的流量限制

12. 架构

13. 防反扑流量
• 雪崩
• 主要来自客户端重试
• 严重时超过15倍流量

14. 防反扑流量办法
• 设计远高正常吞吐量系统
• 客户端放弃重试
• 防洪水闸门

15. 防反扑流量办法
•
•
•
•
防洪水闸门：
快速结束超时
快速拒绝
逐渐随机准入
• 例子：小米抢购

16. Good
enough模式
• 防止过于复杂的服务交错调用(例：评论并
发通知)
• 产品确定核心
• 柔性服务

17. 新旧版本兼容
• A/B
test
困难度：*****
• 灰度升级系统（ Android好一点，ios比较
困难。 ）

18. 即便如此，每次更新也需要开发人员各自考虑兼容问题
例如：群里添加等级功能

19. 架构
• 流量反扑更厉害
• 点到即止省麻烦
• 灰度升级很必要

20. 运维

21. percentile
• XX服务慢
• XXX刚刚不能用
• XXXX打不开
• 衡量内外服务质量
• 内置基础代码中
• 任意项目可度量
• 99.9%的请求在300ms内

22. SRE
• 开发工程师的操作失误
• 不了解运维的全局网络规划
• 写了一天代码，梦中被叫醒重启机器

23. SRE
• Site Reliability Engineering（站点可靠性工
程师）
• 响应、技术、视野 > 开发工程师的专业职位
• 以稳定为己任

24. devops
• 善于归纳总结
• 人肉化->脚本化->web化->平台化->规模化
• 有一部分研发与一部分运维必须在devops
紧密合作

25. 运维
• 衡量指标科学化
• 线上稳定专人化
• 平台建设合作化

26. 流程

27. post-mortem
• 故障快速反思
• 周知
• 不在同一个坑栽两次

28. Post-­‐mortem要素
•
•
•
•
事件经过：时间、人物、经过、结果
技术细节：剖析
传达：确保周知
千万别发成了事故报告

29. 服务器发布
• 严格的询问反思，确保各环节通过
• 保持快速发布节奏
• Post-­‐mortem时不断修正各环节

30. 服务器发布要素
• 功能描述
• 集成测试是否通过
• 单元测试是否通过 • 压力测试是否通过
• Codereview是否通过• 是否有协议变动

31. 流程
• 故障剖析对人不对事
• 发布流程对事不对人

32. 移动互联网
更奇特的网络环境，更高的响应要求
似曾相识的开发、架构、运维、流程
我们需要更多高手
54chen@xiaomi.com

33. 谢谢！
微博@54chen
http://54chen.com czhttp@gmail.com