SSDC_高可用系统在点评的实践与经验

高可用系统在点评的实践与经验

大众点评

可用性理解

频率要低

时间要快

几点经验

基本是演进过程

思考笔记
http://blog.csdn.net/qq_15437667/article/details/50986972

高可用的图。

高可用是个结果。。

频率要低MTBF：
更多从设计上，（业务-》组织结构-》架构）

时间要快MTTR：
5分钟把问题解决

频率要低

业务场景+流量规模=方案演进节奏

设计节奏

化简为繁，化繁为简

一个系统，模块化，垂直服务化，平台服务化，化整为零。

幼儿时期

一坨

少年时期

提升研发效率&故障隔离

问题在于，分离之间会互相影响。

数据挂了，使用缓存，怎么办？还有数据一致性问题。

青年时期

数据跟服务走，不共享数据

订单领域的服务化。拆成几百个服务。瓶颈单点还是在数据库

MYSQL，频率是1-2w的速度。

成年时期

水平拆分

拆库拆表，拆成1000多个表，需要基础组件基础，否则运维成本很高。

常碰见几个例子，服务器网卡坏掉……；Cache和Cat服务器，容易坏，它们都在一个机柜里面。。。。；MQ等中间件也会引起问题

再涨10倍怎么办

系统继续拆分

基础通道做大

流量分块

其他问题

CDN/DNS，

联通，电信不稳

频率要低-易运营

1. 系统可限制流量，很容易解决问题，1s的任务分给3s做
2. 无状态，才容易扩容
3. 降级能力，柔性可用

频率要低-易测试

跟运营一起评估，评估流量，评估性能

频率要低-重视发布

如果不能回滚，否则就不要发布

灰度发布、灰度运营

时间要快-持续关注运行时

跟监控速度有关，要熟悉系统以及下游的容量，影响时间、QPS不同时间流量变化

机器所在的网络，数据库结构

时间要快-有快速发现机制

• 告警移动化，这样能快速发现
• 监控的实时化，秒级很需要
• 监控可视化，这样才能快速定位

监控系统需要达到秒的级别

时间要快-有效的恢复机制

上策：系统，容错、自动恢复；中策：运维，回滚、重启、扩容、下服务器、切灾备；下册：研发。

希望系统能够自己解决问题

几点经验

1. 珍惜每次真实的高峰流量，建立高峰流量模型（为下次准备）；压测也没有这个准；普通流量跟高峰流量模型往往不一样
2. 复盘，珍惜每次线上故障复盘，上一层看问题，下一层解决问题（1问题,2原因，3原因，4原因，5原因），要实际解决。梳理流程是没有用的
3. 可用性不只是技术问题（考虑每个场景，从产品角度、业务角度思考）
4. 可用性最大的敌人，单点、发布，发布如何控制？架构变化基本是去掉性能单点
5. 一切现有架构都是错的（有序组织是错误的）