ssdc-移动互联网技术挑战
TRANSCRIPT
移动互联网技术挑战
54chen@ssdc h+p://54chen.com
2013.11
2010年
移动互联网
更奇特的网络环境，更高的响应要求
似曾相识的开发、架构、运维、流程
开发
网络问题
• DNS • 不同运营商之间 • 不同地域之间
DNS
• 问题：解析不准、不解析
• 保底IP、域名
• 反查协议
• 数据修正
跨地域、跨IDC
• 问题：慢、不通
• 调度系统
• udp • 摸索修正
调度系统
• 2Gwap、3Gwap • 慢、连不上
• 建立反馈渠道
• 依旧对未来充满信心
其他
数据同步问题
• Server-‐db：业务更新最终更新点。
• Client-‐db：业务更新最初更新点。
• 更新失败，数据不同步。
• 类似微信的sync协议
• 每个请求带读写水位
• Client-db只作缓存
• 省流平衡点
• Bug防备省流
A
B
开发
• 奇异的网络环境
• 特殊的数据同步
• 敏感的流量限制
架构
防反扑流量
• 雪崩
• 主要来自客户端重试
• 严重时超过15倍流量
防反扑流量办法
• 设计远高正常吞吐量系统
• 客户端放弃重试
• 防洪水闸门
防反扑流量办法
• 防洪水闸门：
• 快速结束超时
• 快速拒绝
• 逐渐随机准入
• 例子：小米抢购
Good enough模式
• 防止过于复杂的服务交错调用(例：评论并发通知)
• 产品确定核心
• 柔性服务
新旧版本兼容
• A/B test 困难度：*****
• 灰度升级系统（ Android好一点，ios比较困难。 ）
即便如此，每次更新也需要开发人员各自考虑兼容问题
例如：群里添加等级功能
架构
• 流量反扑更厉害
• 点到即止省麻烦
• 灰度升级很必要
运维
percentile
• XX服务慢
• XXX刚刚不能用
• XXXX打不开
• 衡量内外服务质量
• 内置基础代码中
• 任意项目可度量
• 99.9%的请求在300ms内
SRE
• 开发工程师的操作失误
• 不了解运维的全局网络规划
• 写了一天代码，梦中被叫醒重启机器
SRE
• Site Reliability Engineering（站点可靠性工程师）
• 响应、技术、视野 > 开发工程师的专业职位
• 以稳定为己任
devops
• 善于归纳总结
• 人肉化->脚本化->web化->平台化->规模化
• 有一部分研发与一部分运维必须在devops紧密合作
运维
• 衡量指标科学化 • 线上稳定专人化
• 平台建设合作化
流程
post-mortem
• 故障快速反思
• 周知
• 不在同一个坑栽两次
Post-‐mortem要素
• 事件经过：时间、人物、经过、结果
• 技术细节：剖析
• 传达：确保周知
• 千万别发成了事故报告
服务器发布
• 严格的询问反思，确保各环节通过• 保持快速发布节奏• Post-‐mortem时不断修正各环节
服务器发布要素
• 功能描述
• 单元测试是否通过
• Codereview是否通过
• 集成测试是否通过
• 压力测试是否通过
• 是否有协议变动
流程
• 故障剖析对人不对事
• 发布流程对事不对人
谢谢！微博@54chen http://54chen.com [email protected]