关于编码高可用的一点思考。
你好呀,我是歪歪。
我在之前的文章曾经表达过一个观点:有的时候我们都是在基于运气编程。
“一般来说,没啥问题。”
“幸运的话,不会出问题的。”
“我觉得应该没这么倒霉吧,概率太小了。”
“这个触发 bug 的场景太复杂了,应该不会有人会遇到”
大家在日常工作的时候应该也说过类似上面这样的话,但是这样真的好吗?
这个时候就不得不拿出这个经典的表情包了:
给大家分享一篇雄哥的文章,我看了之后很帮助,希望也能带给你一点思考。
原文链接:https://www.jianshu.com/p/e7ed8494b2ee
作者:ZX_周雄
正文
最近,公司里许多项目因为各种原因(如工期问题、个人习惯问题、经验问题),导致出现了一些线上性能问题,进而影响了服务可用性。在此分享一些个人编码中高可用的思考习惯。
先来提问一个问题,如果在程序中跑如下SQL(base on MySQL),有问题吗?
select * from t_order where id = #{orderId};
hang 住,别往下看,思考 30s。
答案是:或许有,或许没有
只给了一条SQL,其它上下文都缺失,无法判断是否会有问题。一些可能出问题的点:
projetion 是 *,无法知道实际有多少个字段,3-5 个字段跟 300-500 个字段的表,对性能的影响,并非一个级别 查询条件 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 端查询订单需求本身,如果拿到这个需求,在实现上我可能会做如下思考:
1.使用这个接口的地方是什么场景?
是订单详情页、订单列表页或者是其它?
知己知彼,百战不殆,如果将来性能不够可以视不同的场景,做对应的业务优化;如果接口出了问题,也能评估影响面,做相应的紧急修复方案等
2.目前的用户量是多大?日活、月活是多少?使用该接口的场景,是否有可参考的QPS?
例如,给首页提供新的接口,可以参考首页其它接口的 QPS。
关注这些的目的,一是为了评估新接口 QPS 的 base line,如果低于这个阈值,上线即崩溃。
二是为了接下来的技术方案做准备,10 QPS 跟 10K QPS 的要求必然不一样
3.知道了目前的 QPS 还不够,还需要预估接下来半年、一年内的业务增长,会让 QPS 提升多少?30%?50%?
那么实际落地的时候,就要按照业务增长的要求去实现,不低于目前值,也不去做过度设计 —— 过度设计是一种资源浪费。
4.接下来,就要根据相应的性能要求去做方案设计
例如,目前是初创阶段,当前 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 性能白皮书
https://help.aliyun.com/document_detail/109378.html
5.预估出一年之内的 QPS 可能仍然不够。
因为预估永远是预估,与实际情况相比可能相去甚远,产品可能在一夜之间成为爆款而导致流量爆增,也可能遭遇到恶意访问的攻击。
因此,我可能会考虑给接口加上一道保险,做好熔断降级的保护措施,在流量洪峰降临的时候能留有足够的时间去应对,避免被轻易击垮。
6.接口开发完上线之前,如果有必要且条件允许,可以做一次压测,直观地查看效果。
如果达到预期则上线,基准值可以做为下次服务扩容的参考;达不到预期则修改以完成目标,避免上线后被真实流量击垮,造成线上事故。
7.上线之后观察一段时间服务运行质量 SLA
如接口 QPS,响应耗时,服务的负载等,判断真实场景下的表现下是否达到了预期,并以此为经验不断加强自己对服务能力的评判
8.监控告警不能少
上线一段时间内运行正常不代表后续的运行也是正常的,随着流量逐渐增大,原来的接口性能可能会逐渐跟不上,我们需要有手段来及时发现这种现象并及时地加以修正
一句话总结:时刻问自己,我即将上线的代码,如果在配置不变的情况下,流量翻了 X 倍,能扛住吗?质量会下降吗?数据准确性会降低吗?如果能清晰地知道答案,那就安心地上线。如果不能,还请三思。
最可怕的是:从来没思考过这个事
最后,我希望,大家都是基于分析编程,而不是基于运气编程。
荒腔走板
发个牢骚啊。这个五一调休真的是调的让人特别的无语。
昨天上了一天班,让我产生了一种既是周一,又是周五的神奇错觉的。
我记得我小时候五一假期是有七天的,当时电视里面还有一个《五一七天乐》的节目,是一档搞笑类的节目。
那个时候,娱乐项目很缺乏,我就守着电视看这个节目,每天乐的像个傻子似的。
不知道怎么回事,也不记得从哪年开始七天变成了五天。本质上是五一法定假期从三天变成了一天。
放一天你就放一天,我也二话不说,正常上班正常休息就行了。
结果放一天你也要硬生生的调成五天,真是又那啥又那啥的。
调休就很伤的,让人觉得莫名的累。
别说什么拉动内需,促进消费什么的。就当下的这个情况,你还敢去哪儿消费,保住绿码才是王道。
算了算了,吐槽就吐槽,过了就过了。
等真的到了五一的时候,我又会在家里待着,乐的像个傻子似的。
我也是,真是又那啥又那啥的,牌坊什么玩意的。
五一,我都想好了,躺平。
我希望大家和我一起躺平。答应我,谁也不许卷谁。
推荐👍 :当Synchronized遇到这玩意儿,有个大坑,要注意!
你好呀,我是歪歪。一个主要敲代码,经常怼文章,偶尔拍视频的成都人。
我没进过一线大厂,没创过业,也没写过书,更不是技术专家,所以也没有什么亮眼的title。
当年以超过二本线 13 分的“优异”成绩顺利进入某二本院校计算机专业,误打误撞,进入了程序员的行列,开始了运气爆棚的程序员之路。
说起程序员之路还是有点意思,可以看看。点击蓝字,查看我的程序员之路