前言
每次开发新功能,服务端需要先出方案,常常因为考虑不够全面导致提测阶段被提各种bug,而且在提测阶段再修改方案已经来不及了。
要点
方案的全面性是最重要的,这需要我们通读prd
- 首先关注每一个功能模块是否在客户端退出重进或切换设备时仍然需要,如果需要,那就需要服务端来设计存储的数据结构
- 设计数据结构的时候需要考虑客户端一次性需要获取多少数据,以及尽可能避免一个接口内foreach调用rpc接口,以及一次性拿大批量数据,使用redis也需要避免使用大key,否则会造成主从复制异常,Redis服务阻塞无法响应请求。因此落盘前的数据尽量先把无效数据过滤掉
- 客户端的上报接口需要关注断网、下课、关摄像头等特殊情况
- 如果数据的下发需要经过复杂的计算(累计计时、频繁数据库IO),造成服务端有性能风险,可以考虑客户端分担一部分计算逻辑,来减少服务端的CPU和IO使用频率
- 尽量选择更稳定的方案,比如客户端的上报可以使用更稳定的tcp socket来替代http接口
- 还需要考虑对已有功能的兼容,以及对于下游的影响
总结
- 设计方案,最重要的是全面性,要逐行通读prd,避免遗漏功能设计
- 其次要考虑性能压力的平均分担,一旦在提测阶段发现方案设计引发的性能问题,很难通过fix来解决,只能改方案
- 稳定性也是一个重要因素,用户经常遇到失败重试非常影响体验
- 每个功能都需要考虑断网,失败重试,切换设备这些特殊场景
- 还需要考虑对已有功能和旧客户端的兼容,以及对于下游的影响