[补充实习笔记] JAVA服务端开发设计的一些指导原则

一,性能相关:
1,避免在循环内部new一个对象。
2,所有与IO相关的操作,都需要考虑性能问题,一般采取的措施是连接池,缓存,减少调用次数,合并请求。
3,每个业务都要分析整个请求链路,找到瓶颈,通过压测的方式确认问题及验证解决方案。
4,根据业务情况,使用异步化和最终一致性。
5,CPU,内存,网络IO,磁盘IO这些瓶颈,需要知道在合适的场景牺牲什么换取什么。通俗的讲是空间换时间,还是时间换空间。
不同业务场景下,要做合理的取舍。例如多线程并发查询后merge。这个就是利用CPU,内存换取速度。
6,善于借助集团内成熟通用的平台来解决性能问题。如TAIR分布式缓存,METAQ,NOTIFY消息队列,HSF,OPENSEARCH等等。
要知道什么场景适合用什么,每个产品的最佳实践是什么要清楚。
7,学会通过业务视角解决技术问题。例如:如果没有分库分表,支付宝的大量交易数据的并发性,可能永远无法解决。
适当的时候,需要根据用户ID去分库分表,分散数据库IO瓶颈。避免只从技术角度考虑问题,陷入死胡同。
8,使用新技术新协议时,一定要分析出最佳使用场景,不能盲目相信。搞懂原理,才能通过最佳实践发挥性能优势。
二,监控相关:
1,监控分为系统监控,应用监控,业务监控。
系统监控一般监控网络IO情况,磁盘IO,空间,CPU,内存等等。
应用监控一般监控JVM的内存,GC情况,日志中的异常情况,SQL,SPRING方法等的耗时情况。
业务监控一般监控一些业务指标,如PV,UV,交易的变化趋势等等具有业务含义的数据。
2,系统监控,应用监控统一接入alimonitor。业务监控暂时接入XFLUSH,这块还在研究。
3,做好容量规划,避免无法支持业务增长。监控好容量。
4,对于调用链路非常深的系统,做好链路监控,及时发现瓶颈。
三,安全相关:
1,不要为了维护方便,在代码里留后门。之前review代码发现有这些问题,上次阿里内外上有一个帖子也反馈了这个问题。
2,涉及到用户密码等,一定要散列哈希算法加密存储。
3,关键用户敏感数据(如:信用卡数据)不能存日志文件中,避免主机漏洞被拖拽。很多互联网公司就发生了这样的事情。
4,要考虑完整业务链路的安全,不仅仅是某一端的安全问题。
5,充分利用集团安全团队的产品及规范,避免产品出现安全漏洞,代码安全这块加强和安全同学一起REVIEW。
6,要注意开发环境和生产环境信息做隔离,避免因在开发环境中泄露导致生产环境安全问题。
7,不在外网分享带有业务规则及需要保密信息的内部文档。
四,规范相关:
1,幂等性:所有对外暴露的接口,需要做到幂等性。
2,隔离性:对同一个数据源的操作,建议由一个服务向外暴露,避免多个不同系统操作同一个数据源,特别是避免修改操作。
3,开源使用:使用第三方开源jar包时,一定要谨慎。搞懂原理,避免不成熟导致缺陷。
对开源的第三方包,一定要有源码。
4,线程安全:要时刻关注线程安全问题。每个业务都要考虑代码是否是线程安全的。
5,关于编程模型,不做强制要求,但是有一个原则就是,这块技术是主流的,外部容易招聘到相关人才,
技术体系是完善的,容易学习和发展定制。
6,关键代码及业务逻辑,一定要有注释。
7,每个系统的设计及需求,接口等,一定要有文档。方便沟通交流以及团队的传承交接。
8,不用存储过程去实现复杂的业务逻辑,原则见第2点。
9,JAVA的日志记录,格式要统一,存储路径和位置,以及磁盘满了之后日志转移的机制要完善。
10,设计REVIEW:系统设计一定要组织REVIEW,避免设计的不合理导致后续扩展性不好。
review的角度,考虑业务的扩展性及发展方向是一个重点。
11,重点业务的单元测试和接口测试用例一定要有且全面。
12,统一使用PE提供的运行环境和容器,特殊定制化容器场景一定要充分测试。
五,异常处理相关:
1,要区分好业务异常还是系统异常。为每种异常定义好处理方式。
2,避免抛出大量异常不处理。
3,异常为了方便系统间传输,一般需要约定errorCode。例如场景:可以根据错误编码,将异常翻译成多国语言。
4,跨进程调用,不要将整个异常堆栈传递过去。
六,设计模式相关:
1,模块之间避免循环依赖。
2,尽量使用接口解耦应用。
3,代码中使用分层设计的思想。
4,高内聚低耦合。