1. 充分校验入参
有一句话叫 "All input is evil",即一切的输入都可能是恶意的。 因此,经验丰富的工程师会对接口的入参进行严格的校验,从最基础的非空、长度校验,到复杂的业务逻辑校验都不应忽略。例如,在典型的电商下单场景中,我们需要校验用户状态是否正常、商品是否上架、库存是否充足、优惠券是否可用等。请记住,入参校验是防止低级错误的第一道防线,养成这个习惯至关重要。
2. 完整记录日志
我们总希望自己写的代码在本地、测试、甚至生产环境下都能完美执行。但现实中,业务异常情况常常发生,即使我们拥有像ELK、Skywalking这样的日志收集和链路追踪工具,日志记录的全面性和合理性仍直接影响我们排查问题的效率。日志的覆盖面应该包括关键路径、异常处理等。你今天省下的日志记录时间,将来很可能会在排查问题时花费更多。
3. RPC 调用需考虑网络问题
RPC 调用不同于本地调用,因为网络不稳定性带来了许多不确定因素。你需要思考以下问题:
- 请求未能到达服务提供者怎么办?
- 请求到达但未返回结果时如何处理?
- 超时和重试策略如何设置?
根据不同业务场景(如读请求、写请求,高并发与非高并发),处理策略应该有所不同,不能一概而论。
4. 批量处理替代单次处理
在需要多次执行 RPC 或数据库操作时,如果每次都在循环中调用单次接口,而不采用批量处理,将大大降低性能,尤其是在大量数据场景下。 此外,在循环体中添加日志记录时也要注意,避免生成大量日志,消耗磁盘资源。
5. 复杂 SQL 需先执行计划
那种海量数据下多表关联查询的SQL语句,一次执行把整个数据库搞挂并不是完全的小概率事件。因此,如果你写完一个这样的SQL语句,一定要记得怀有敬畏之心地先执行一下,看看效果。记住,不要在测试环境的数据库中执行,因为有的公司的测试库和生产库的数据量是天差地别,数据分布形态也不一样,执行结果可能没有参考性。记得要去生产库的从库去执行,因为主库一旦出现问题,影响范围太大。从库也不要直接去执行,执行之前还是要explain一下,看看执行计划的。如果执行计划中出现了大表的type=all,那也就别再执行SQL了,把从库打挂了影响也不小,先想办法优化吧。
6. 扩展或新增,不直接修改
维护中台服务时,如果对业务全貌还不熟悉,不要轻易修改业务主流程,特别是在多个业务线共用同一服务的情况下。采用扩展或新增的方式,可以减少对已有功能的影响,避免牵一发而动全身的风险。
7. 重构而非重写
重构的目标是优化现有代码的结构,而非推翻重写。相比于重新编写整个系统,合理的重构可以提升代码的可维护性,避免造成大规模的业务中断。
牢记:重构是为了提高代码质量,而非推倒重来。
8. 非必要,不引入
在满足业务需求的前提下,技术方案越简单越好。例如:
- 如果 MySQL 足以承受业务请求压力,就不需要引入 Redis 或 ES。
- 如果同步调用能够满足业务需求,就不要盲目使用异步 MQ。
- 如果简单coding即可高效迭代的需求,那就绝对不引入设计模式;
过度引入新技术不仅增加了系统复杂性,也提高了维护成本。一个出色的工程师,他的特质是喜欢迎接挑战,但一个营收惊人的关键系统,对它最好的方式是杜绝挑战。
9. 保证数据一致性
当业务系统采用多数据源时(如 MySQL 主从模式或 MySQL + Redis 组合),需明确哪个是主数据源,发生数据不一致时以主数据源为准。此外,需设计策略确保多数据源最终一致性,以免系统埋下隐患。
10. 避免过度前瞻性设计
有些工程师在项目初期就着眼于未来的高并发或大规模扩展,过早地拆分微服务、进行数据库分库分表。这种过度设计会增加开发和调试难度,尤其是在业务前景不明朗的情况下,可能导致资源浪费。 我们要根据实际业务情况设计系统,保持简单而实用,避免不必要的复杂性。