ssdc-移动互联网技术挑战

移动互联网技术挑战

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@xiaomi.com  

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