标签：优化 同步 mem 维护 不能 刷新 性能 注释 本地
顺序不代表重要性，请根据场景自行斟酌！
1、高可用：破除单点故障、保证服务无状态或者状态一致，任何节点挂掉不应该影响整个服务，服务启动后可以被自动发现。使用LVS或Nginx负载均衡，需要支持水平扩容。
2、模块化：任何系统都不应该太复杂，不应该承担太多责任，按照低耦合高内聚的原则，需要将系统抽象为多个模块，分而治之。
3、依赖链：根据依赖倒置原则，高层模块不该依赖低层模块，模块之间的依赖链尽量清晰有序，避免循环依赖。依赖密切的两个模块可以考虑合并，或者共用一个中介者对外提供服务。
4、监控：通过监控内存，CPU，硬盘，网络，错误率，响应时间，TPS，节点状态等等，可以实时了解服务状况，通过历史数据可以知道服务状况的变化，特别是每次发版，可以知道版本造成的性能影响。
5、多级缓存：根据不同的使用场景，可以选择本地缓存或者集中缓存，可以选择同步刷新或者异步刷新，可以选择redis或者memcached，需要提前考虑好数据量大小，以及考虑日后扩容。
6、数据存储：数据层比服务层更需要设计，这是一条非常重要的经验。如果你的数据结构开始设计不合理，将来数据结构的改变会花费你数倍的代价，老的数据格式向新的数据格式迁移会让你痛不欲生。数据是否需要备份（恢复时要避免数据冲突）。读取频繁是否应该使用镜像（但镜像与主节点具有一定延迟）。写入频繁是否可使用队列（需要考虑消息不被重复处理，以及失败后续机制）。是否使用nosql（需要考虑nosql带来的限制）。
7、分库分表：如果因为表多而导致数据库压力大，可以考虑垂直切分，将不同模块的表放到不同的数据库中，需要分析表之间的耦合关系，尽可能避免分布式事务。如果是因为单表数据量太多，可以考虑水平切分，水平切分的关键在于找出根元素，例如社交网站的user就是根元素，以根元素为基准将其关联的表进行水平拆分，可以减少跨库join查询。另外、对于各种聚合函数只能通过各库统计后再合并，分库分表代价不小。
8、服务开关：可对各模块增加开关，或者服务降级，当模块出现问题可以不影响全局服务，这也便于日常维护。
9、模块通信：一个好用的RPC框架非常关键，由于系统被模块化，每个模块可能是个很小的微服务，系统之间通信将会变得非常频繁，这时就需要高性能低延迟省流量的RPC框架，框架对系统的影响很大。
10、集群管理：对于任何散乱的分布式系统，必须需要有调度中心，决不能放任混乱。中心主要负责配置管理，服务注册，监控部署等，但是，要尽量减少部署场景，部署时要优雅停机，不要丢失正在处理的数据。
11、动静或轻重分离：有利于根据不同的场景选择不同的网络模型，不同的GC收集算法，不同的服务类型等等，针对特定场景进行优化。
12、流量控制：防止攻击，防止刷量，尽量将请求提前返回，减少对服务器的穿透减少服务器资源浪费，过滤掉无用请求和恶意请求。
13、对外接口：尽量要标准，尽量要封装，尽量要有一层代码用来解耦，以防第三方变动带来的不变。
14、异常和日志：异常尽量统一处理，减少代码因异常导致的复杂度。日志打印尽量规范，方便整体分析。分布式服务要对请求跟踪，便于排查问题和分析。
15、编码细节：接口文档，数据库文档，代码注释等等，重要性就不说了。合理控制线程数，合理使用IO，减少多线程对于资源的竞争，合理使用数据结构hashmap、treemap、bitmap等，合理使用fork-join等，都是很好的。
最后：对扩展开放，对修改关闭，任何设计不需要一次性做的很到位，但是一定要具有长远的目光，尽可能预留将来的扩展，正所谓：人无远虑必有近忧。
标签：优化 同步 mem 维护 不能 刷新 性能 注释 本地
原文地址：http://www.cnblogs.com/m13321169565/p/6322760.html
