背景
最近,公司里许多项目因为各种原因(如工期问题、个人习惯问题、经验问题),导致出现了一些线上性能问题,进而影响了服务可用性。在此分享一些个人编码中高可用的思考习惯
正文
先来提问一个问题,如果在程序中跑如下SQL(base on MySQL),有问题吗?
select * from t_order where id = #{orderId};
hang住,别往下看,思考30s
答案是:或许有,或许没有
只给了一条SQL,其它上下文都缺失,无法判断是否会有问题。一些可能出问题的点:
- projetion 是 *,无法知道实际有多少个字段,35个字段跟300500个字段的表,对性能的影响,并非一个级别
- 查询条件id列未必是主键,谁规定了名为id的列一定会设为primary key?如果id列上没有索引,那上述SQL查询就是一个全表扫描,性能可想而知
- 表的数据量是多少?百万、千万级别的表,与十亿、百亿级别的表执行同一条SQL,即使有索引,性能也不一样
- 其它诸多原因,比如使用的存储引擎,DB的配置等等等
提出上述问题是想引出一个观点:某项技术、某段代码本身没有问题,如果有问题,那可能是使用者将它用错了地方,或是懒惰,或是疏忽,或是缺乏对其掌控度
接着,再来思考一个问题,我有一个方法如下:
public Order getOrder(Long orderId) {
// select * from t_order where id = #{orderId};
return orderMapper.selectByPrimaryKey(orderId);
}
orderMapper调用的是第一个问题中的SQL
假设DB是一台8C16G的MySQL,使用的是InnoDB引擎,订单表的id列是主键,且表的列数大概20列,表数据量是2000万左右
很显然,该方法是一个"查询订单"的接口。如果我把上述方法暴露出去供人使用,请问,有问题吗?
hang住,别往下看,思考30s
答案是:或许有,或许没有
很简单的一个方法,显然功能性是OK的,即是说:如果使用方想要一个查询订单的接口,上述方法功能性上是OK的,满足需求
对于缺乏编程经验的同学而言,写到这里应该就结束了 —— 需求满足了
假如该同学提供的接口应对的业务场景是管理后台的运营查询,确实也应该结束了,上述代码已经能够满足绝大部分场景了,做的太多反而画蛇添足,且浪费资源。比如添加缓存 —— 对于管理后台而言,性能要求不那么高,数据的准确性才是首要考虑的目标,假如引入缓存,还要额外考虑缓存一致性问题;如若引入的是分布式缓存,甚至还要考虑缓存产品可用性的问题:多一个外部依赖,就多一份故障的可能性
所以,如果某个同学提供的方法只实现了业务逻辑本身,它未必有问题
但是这个"没问题",是基于运气(实现代码之前不知道业务使用场景,上线后发现恰巧是运营查询使用,因此没有崩溃),还是基于懒惰(可能知道它有潜在问题,但是懒的改),还是基于工期(可能会存在潜在问题,但业务至上,先上一版再优化),还是基于分析(分析之后知道一定不会有问题,故意不做额外的处理,保持代码的简洁性)?
我希望,大家都是基于分析
但是,换一个场景,假设是提供C端查询的场景,那非功能性方面的要求:如性能、可用性、可靠性,就很有考虑的必要性了
但凡涉及到用户级别的接口,我都会小心翼翼地进行考量跟分析,以确保接系统设计跟接口实现能够满足功能性要求的同时,能够在可用性、可靠性、性能等方面满足接下来半年或一年以内的业务增长
回到C端查询订单需求本身,如果拿到这个需求,在实现上我可能会做如下思考:
-
使用这个接口的地方是什么场景?
是订单详情页、订单列表页或者是其它?—— 知己知彼,百战不殆,如果将来性能不够可以视不同的场景,做对应的业务优化;如果接口出了问题,也能评估影响面,做相应的紧急修复方案等
-
目前的用户量是多大?日活、月活是多少?使用该接口的场景,是否有可参考的QPS?
例如,给首页提供新的接口,可以参考首页其它接口的QPS。—— 关注这些的目的,一是为了评估新接口QPS的base line,如果低于这个阈值,上线即崩溃;二是为了接下来的技术方案做准备,10 QPS 跟 10K QPS 的要求必然不一样
-
知道了目前的QPS还不够,还需要预估接下来半年、一年内的业务增长,会让QPS提升多少?30%?50%?那么实际落地的时候,就要按照业务增长的要求去实现,不低于目前值,也不去做过度设计 —— 过度设计是一种资源浪费
-
接下来,就要根据相应的性能要求去做方案设计
例如,目前是初创阶段,当前10 QPS,预估接下来一年撑死了QPS 20。那么,上面的代码仍然是没有问题的,可以支撑业务需求。—— 需要有这一步的分析跟思考,而不是凭运气
但是假如目前是1000 QPS,接下来一年QPS会达到3000,那上面的代码就有问题了。对于题设条件中的MySQL,一个根据主键进行查询的语句,撑住3000 QPS是一件很轻松的事情,但是还要考虑到库里并不只有这么一个查询,别的查询也跑在这库上面,资源之间会发生竞争,如果大家的SQL都裸跑到MySQL,很容易把库给打崩。因此,就要考虑采用别的手段比如加缓存等
此处额外注意两点:
- 有时候一次接口调用,会涉及多次DB查询,这时候对于DB的QPS还要往上增加
- 对一些基础中间件的能力有一个基本认知:例如一台单机Redis最大QPS 10W+,超过这个能力的业务就要提前考虑集群化方案;例如MySQL 8C16G能轻松撑住3000 QPS,但1C2G就撑不了(可参考:阿里云MySQL 5.7 性能白皮书)
-
预估出一年之内的QPS可能仍然不够,因为预估永远是预估,与实际情况相比可能相去甚远,产品可能在一夜之间成为爆款而导致流量爆增,也可能遭遇到恶意访问的攻击。因此,我可能会考虑给接口加上一道保险,做好熔断降级的保护措施,在流量洪峰降临的时候能留有足够的时间去应对,避免被轻易击垮
-
接口开发完上线之前,如果有必要且条件允许,可以做一次压测,直观地查看效果,如果达到预期则上线,基准值可以做为下次服务扩容的参考;达不到预期则修改以完成目标,避免上线后被真实流量击垮,造成线上事故
-
上线之后观察一段时间服务运行质量SLA,如接口QPS,响应耗时,服务的负载等,判断真实场景下的表现下是否达到了预期,并以此为经验不断加强自己对服务能力的评判
-
监控告警不能少:上线一段时间内运行正常不代表后续的运行也是正常的,随着流量逐渐增大,原来的接口性能可能会逐渐跟不上,我们需要有手段来及时发现这种现象并及时地加以修正
一句话总结:时刻问自己,我即将上线的代码,如果在配置不变的情况下,流量翻了X倍,能扛住吗?质量会下降吗?数据准确性会降低吗?如果能清晰地知道答案,那就安心地上线。如果不能,还请三思。最可怕的是:从来没思考过这个事
最后
我希望,大家都是基于分析,而不是基于运气