感觉更像是敏捷开发中的坑总结

详尽日志 #

不怕日志多，就怕有问题没有足够的线索提示去支撑排查

• 所有日志 向stdout:特别是早期开发阶段，这一块的日志要注重可读性，比如颜色高亮,日志可以分级别输出，后期可以把debug级别的日志过滤丢掉;使用循环日志避免占用全部磁盘空间
  
• 入库统计数据单独binlog文件,先写文件后入库(WAL)
  
• 上下文调用日志分文件输出,这些很可能要进行入库，直接json格式
  
  

数据量与性能评估 #

这些在需求评估的时候就要注重提前说明(当然如果有相关经验下才会意识到),在不同数据量的情况下,涉及到 数据结构、数据表设计到与功能性能的 关键点:

能用MongoDB 或者Elastic Seach最好直接用，不管是DDL 还是性能比关系型数据库MySQL,Postgress要方便灵活

• 比如在 报表 统计方面，查询方面,NoSQL型的数据结构算法更适用,就像OLAP比OLPT在统计查询方面更占优势; 如果涉及到多表关联查询，为了性能和业务功能，必要的冗余数据得融合起来
  
  

传输协议 (websocket与 http都是用tcp，但是一个可以自由回写，一个被动触发才机会回写 这在功能实现的效率上 表现的截然不同):

• 像长语音流转写文本,走实时流传输就会比一次性请求转写要高效(实时传完最后一个分段流,整体体的文本结果就出来了,而一句话转写从存储成一整段录音->传输录音->服务器转写整段录音的全部过程要双倍时间，但是从体验上却是 瞬时与大半天的 效率表现)，而短录音片段则用 一次性转写的http请求更简单方便