查看原文
其他

关于编码高可用的一点思考。

ZX why技术 2022-09-23

你好呀,我是歪歪。

我在之前的文章曾经表达过一个观点:有的时候我们都是在基于运气编程。

“一般来说,没啥问题。”

“幸运的话,不会出问题的。”

“我觉得应该没这么倒霉吧,概率太小了。”

“这个触发 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 倍,能扛住吗?质量会下降吗?数据准确性会降低吗?如果能清晰地知道答案,那就安心地上线。如果不能,还请三思。

最可怕的是:从来没思考过这个事

最后,我希望,大家都是基于分析编程,而不是基于运气编程。

荒腔走板

发个牢骚啊。这个五一调休真的是调的让人特别的无语。

昨天上了一天班,让我产生了一种既是周一,又是周五的神奇错觉的。

我记得我小时候五一假期是有七天的,当时电视里面还有一个《五一七天乐》的节目,是一档搞笑类的节目。

那个时候,娱乐项目很缺乏,我就守着电视看这个节目,每天乐的像个傻子似的。

不知道怎么回事,也不记得从哪年开始七天变成了五天。本质上是五一法定假期从三天变成了一天。

放一天你就放一天,我也二话不说,正常上班正常休息就行了。

结果放一天你也要硬生生的调成五天,真是又那啥又那啥的。

调休就很伤的,让人觉得莫名的累。

别说什么拉动内需,促进消费什么的。就当下的这个情况,你还敢去哪儿消费,保住绿码才是王道。

算了算了,吐槽就吐槽,过了就过了。

等真的到了五一的时候,我又会在家里待着,乐的像个傻子似的。

我也是,真是又那啥又那啥的,牌坊什么玩意的。

五一,我都想好了,躺平。

我希望大家和我一起躺平。答应我,谁也不许卷谁。


·················END·················

推荐👍 :手机害人!

推荐👍 :初看一脸懵逼,看懂直接跪下!

推荐👍 :一不小心节约了 591 台机器!

推荐👍 :当Synchronized遇到这玩意儿,有个大坑,要注意!

推荐👍 :2021,我这一年。

你好呀,我是歪歪。一个主要敲代码,经常怼文章,偶尔拍视频的成都人。

我没进过一线大厂,没创过业,也没写过书,更不是技术专家,所以也没有什么亮眼的title。

当年以超过二本线 13 分的“优异”成绩顺利进入某二本院校计算机专业,误打误撞,进入了程序员的行列,开始了运气爆棚的程序员之路。

说起程序员之路还是有点意思,可以看看。点击蓝字,查看我的程序员之路

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存