设计指导原则

标签：style   使用   strong   文件   数据   问题   

设计指导原则

一. 性能相关：

1. 避免在循环内部new一些没有必要每次都new的对象。
2. 所有与IO相关的操作，都需要考虑性能问题，一般采取的措施是连接池，缓存，减少调用次数，合并请求。
3. 每个业务都要分析整个请求链路，找到瓶颈，通过压测的方式确认问题及验证解决方案。
4. 根据业务情况，使用异步化和最终一致性。
5. CPU，内存，网络IO，磁盘IO这些瓶颈，需要知道在合适的场景牺牲什么换取什么。通俗的讲是空间换时间，还是时间换空间。不同业务场景下，要做合理的取舍。例如多线程并发查询后merge。这个就是利用CPU，内存换取速度。
6. 善于借鉴业界成熟通用的解决方案来解决问题。要知道什么场景适合用什么，每个产品的最佳实践是什么要清楚。
7. 学会通过业务视角解决技术问题。例如：如果没有分库分表，支付宝的大量交易数据的并发性，可能永远无法解决。适当的时候，需要根据用户ID去分库分表，分散数据库IO瓶颈。避免只从技术角度考虑问题，陷入死胡同。
8. 使用新技术新协议时，一定要分析出最佳使用场景，不能盲目相信。搞懂原理，才能通过最佳实践发挥性能优势。

二. 监控相关：

1. 监控分为系统监控，应用监控，业务监控。系统监控一般监控网络IO情况，磁盘IO，空间，CPU，内存等等。应用监控一般监控JVM的内存，GC情况，日志中的异常情况，SQL，SPRING方法等的耗时情况。业务监控一般监控一些业务指标，如PV,UV,交易的变化趋势等等具有业务含义的数据。
2. 做好容量规划，避免无法支持业务增长，监控好容量。
3. 对于调用链路非常深的系统，做好链路监控，及时发现瓶颈。

三. 安全相关：

1. 不要为了维护方便，在代码里留后门；之前review代码发现有这些问题。
2. 涉及到用户密码等，一定要散列哈希算法加密存储。
3. 关键用户敏感数据（如:信用卡数据）不能存日志文件中，避免主机漏洞被拖拽。很多互联网公司就发生了这样的事情。
4. 要考虑完整业务链路的安全，不仅仅是某一端的安全问题。
5. 充分利用公司已有的安全团队的产品及规范，避免产品出现安全漏洞，代码安全这块加强和安全同学一起REVIEW。
6. 要注意开发环境和生产环境信息做隔离，避免因在开发环境中泄露导致生产环境安全问题。
7. 不在外网分享带有业务规则及需要保密信息的内部文档。

四. 规范相关：

1. 幂等性：所有对外暴露的接口，需要做到幂等性。
2. 隔离性：对同一个数据源的操作，建议由一个服务向外暴露，避免多个不同系统操作同一个数据源，特别是避免修改操作。
3. 对开源的第三方包，一定要有源码。
4. 线程安全：要时刻关注线程安全问题。每个业务都要考虑代码是否是线程安全的。
5. 关于编程模型，不做强制要求；但是有一个原则就是，这块技术是主流的，外部容易招聘到相关人才，技术体系是完善的，容易学习和发展定制。
6. 关键代码及业务逻辑，一定要有注释。
7. 每个系统的设计及需求，接口等，一定要有文档。方便沟通交流以及团队的传承交接。
8. 不用存储过程去实现复杂的业务逻辑，原则见第2点。
9. 日志记录，格式要统一，存储路径和位置，以及磁盘满了之后日志转移的机制要完善。
10. 系统设计一定要组织Review，避免设计的不合理导致后续扩展性不好。Review的角度，考虑业务的扩展性及发展方向是一个重点。
11. 重点业务的单元测试和接口测试用例一定要有且全面，要养成用单元测试和接口测试来保证业务逻辑正确性的习惯，且还能大大提高后期系统维护的成本；
12. 统一使用PE提供的运行环境和容器，特殊定制化容器场景一定要充分测试。

五. 异常处理相关：

1. 要区分好业务异常还是系统异常。为每种异常定义好处理方式。
2. 避免抛出大量异常不处理。
3. 异常为了方便系统间传输，一般需要约定errorCode。例如场景：可以根据错误编码，将异常翻译成多国语言。
4. 跨进程调用，不要将整个异常堆栈传递过去。

六. 设计模式相关：

1. 模块之间避免循环依赖
2. 尽量使用接口解耦应用
3. 代码中使用分层设计的思想
4. 高内聚低耦合

设计指导原则,布布扣,bubuko.com

设计指导原则

标签：style   使用   strong   文件   数据   问题   

原文地址：http://www.cnblogs.com/netfocus/p/3831901.html