高可用系统在点评的实践与经验
大众点评
可用性理解
频率要低
时间要快
几点经验
基本是演进过程
思考笔记
http://blog.csdn.net/qq_15437667/article/details/50986972
高可用的图。
高可用是个结果。。
频率要低MTBF:
更多从设计上,(业务-》组织结构-》架构)
时间要快MTTR:
5分钟把问题解决
频率要低
业务场景+流量规模=方案演进节奏
设计节奏
化简为繁,化繁为简
一个系统,模块化,垂直服务化,平台服务化,化整为零。
幼儿时期
一坨
少年时期
提升研发效率&故障隔离
问题在于,分离之间会互相影响。
数据挂了,使用缓存,怎么办?还有数据一致性问题。
青年时期
数据跟服务走,不共享数据
订单领域的服务化。拆成几百个服务。瓶颈单点还是在数据库
MYSQL,频率是1-2w的速度。
成年时期
水平拆分
拆库拆表,拆成1000多个表,需要基础组件基础,否则运维成本很高。
常碰见几个例子,服务器网卡坏掉……;Cache和Cat服务器,容易坏,它们都在一个机柜里面。。。。;MQ等中间件也会引起问题
再涨10倍怎么办
系统继续拆分
基础通道做大
流量分块
其他问题
CDN/DNS,
联通,电信不稳
频率要低-易运营
- 系统可限制流量,很容易解决问题,1s的任务分给3s做
- 无状态,才容易扩容
- 降级能力,柔性可用
频率要低-易测试
跟运营一起评估,评估流量,评估性能
频率要低-重视发布
如果不能回滚,否则就不要发布
灰度发布、灰度运营
时间要快-持续关注运行时
跟监控速度有关,要熟悉系统以及下游的容量,影响时间、QPS不同时间流量变化
机器所在的网络,数据库结构
时间要快-有快速发现机制
- 告警移动化,这样能快速发现
- 监控的实时化,秒级很需要
- 监控可视化,这样才能快速定位
监控系统需要达到秒的级别
时间要快-有效的恢复机制
上策:系统,容错、自动恢复;中策:运维,回滚、重启、扩容、下服务器、切灾备;下册:研发。
希望系统能够自己解决问题
几点经验
- 珍惜每次真实的高峰流量,建立高峰流量模型(为下次准备);压测也没有这个准;普通流量跟高峰流量模型往往不一样
- 复盘,珍惜每次线上故障复盘,上一层看问题,下一层解决问题(1问题,2原因,3原因,4原因,5原因),要实际解决。梳理流程是没有用的
- 可用性不只是技术问题(考虑每个场景,从产品角度、业务角度思考)
- 可用性最大的敌人,单点、发布,发布如何控制?架构变化基本是去掉性能单点
- 一切现有架构都是错的(有序组织是错误的)