编码高可用的一点思考

背景

最近，公司里许多项目因为各种原因(如工期问题、个人习惯问题、经验问题)，导致出现了一些线上性能问题，进而影响了服务可用性。在此分享一些个人编码中高可用的思考习惯

正文

先来提问一个问题，如果在程序中跑如下SQL(base on MySQL)，有问题吗？

select * from t_order where id = #{orderId};

hang住，别往下看，思考30s

---

答案是：或许有，或许没有

只给了一条SQL，其它上下文都缺失，无法判断是否会有问题。一些可能出问题的点：

1. projetion 是 *，无法知道实际有多少个字段，3-5个字段跟300-500个字段的表，对性能的影响，并非一个级别
2. 查询条件id列未必是主键，谁规定了名为id的列一定会设为primary key？如果id列上没有索引，那上述SQL查询就是一个全表扫描，性能可想而知
3. 表的数据量是多少？百万、千万级别的表，与十亿、百亿级别的表执行同一条SQL，即使有索引，性能也不一样
4. 其它诸多原因，比如使用的存储引擎，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 性能白皮书)

5. 预估出一年之内的QPS可能仍然不够，因为预估永远是预估，与实际情况相比可能相去甚远，产品可能在一夜之间成为爆款而导致流量爆增，也可能遭遇到恶意访问的攻击。因此，我可能会考虑给接口加上一道保险，做好熔断降级的保护措施，在流量洪峰降临的时候能留有足够的时间去应对，避免被轻易击垮

6. 接口开发完上线之前，如果有必要且条件允许，可以做一次压测，直观地查看效果，如果达到预期则上线，基准值可以做为下次服务扩容的参考；达不到预期则修改以完成目标，避免上线后被真实流量击垮，造成线上事故

7. 上线之后观察一段时间服务运行质量SLA，如接口QPS，响应耗时，服务的负载等，判断真实场景下的表现下是否达到了预期，并以此为经验不断加强自己对服务能力的评判

8. 监控告警不能少：上线一段时间内运行正常不代表后续的运行也是正常的，随着流量逐渐增大，原来的接口性能可能会逐渐跟不上，我们需要有手段来及时发现这种现象并及时地加以修正

一句话总结：时刻问自己，我即将上线的代码，如果在配置不变的情况下，流量翻了X倍，能扛住吗？质量会下降吗？数据准确性会降低吗？如果能清晰地知道答案，那就安心地上线。如果不能，还请三思。最可怕的是：从来没思考过这个事

最后

我希望，大家都是基于分析，而不是基于运气