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

你好呀，我是歪歪。

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

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

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

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

“这个触发 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 的配置等等等

提出上述问题是想引出一个观点：某项技术、某段代码本身没有问题，如果有问题，那可能是使用者将它用错了地方，或是懒惰，或是疏忽，或是缺乏对其掌控度

接着，再来思考一个问题，我有一个方法如下：

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

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

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

荒腔走板

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

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

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

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

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

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

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

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

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

算了算了，吐槽就吐槽，过了就过了。

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

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

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

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