优化滴滴点点

半夜里展转反侧，将系统优化的滴滴点点记录成案

 

1.服务粒度尽量的粗粒度化

为何这么说？若是开发过程当中 咱们直接设计EDMX模型，以后设计服务，这种自下而上的模式致使系统中不少的服务，服务力度的把控天然不是很好，好比说一个登录，客户端须要调用四或五个服务才能完成登陆操做，直接带来性能问题，还有可能带来重复性的开发,【建议:服务设计自上而下,契约优先原则，以业务逻辑进行划分，尽量的粗粒度化，这样减小服务调用次数，这与减小客户端Http请求效果是一致的，固然不可能完美的作到粒度的把控,须要在后续开发中补充粒度比较细的部分，或者讨论某些服务公开的必要性】

 

2.单台服务器状况下图片、文本等静态资源的优化

只有单台服务器的状况下，保证图片资源与Web服务在不一样的域名下，主要是为了减小在访问图片等静态资源时发送Cookie等没必要要的信息

再者对图片进行压缩或者缩略图的形式处理，减小带宽消耗

 

3.Web服务与图片服务器的分离

这里强调下为何有作服务器分离的必要:当主Web请求与图片请求在一台机器上时，图片请求占用资源多，web请求占用时间短，但web请求队列等待时间却很长,图片请求严重影响Web正常访问,【建议:图片与Web服务器分开，固然，图片服务器部署在轻量级的Web服务器(例如Nginx)更理想,同时添加客户端缓存、服务端缓存提升响应效率】

 

4.图片的处理

客户端上传图片时进行压缩处理，服务器针对图片作分布式的存储，不清楚的可 参见《视频/图片集群化存储》这里有实现的思路  请求图片时也能够压缩处理，可是消耗CPU，这里须要在带宽等资源与CPU资源之间寻找一个平衡点 (读者有兴趣能够了解淘宝开源文件系统:TFS 章文蒿博士主导)

 

 

5.关于分布式事务性能

分布式系统中最难处理的就是事务这一块了,soa架构系统中 服务级别的分布式事务因为占用事务锁时间比较长，大并发量时容易致使死锁【建议：根据事务的重要性作不一样的处理，服务不须要事务状况下使用异步方式处理。须要事务状况下使用队列替代分布式事务(队列是解决死锁的经常使用途径) 队列执行失败，只会记录日志，不会进行回滚操做。只有重要的事务(通常涉及敏感数据时)再作分布式事务】

 

 

6.缓存

分布式缓存除了Memcached,  Memceche使用案例《Memcache+Cookie替代Session解决方案(MVC版)》 也能够考虑使用MongoDB等非关系型数据库处理，由于NoSql数据库并发性能很是好，并且很容易的作到分布式部署，节点易扩展

 

7.数据库

硬件层面:由于数据库对CPU、内存、IO要求都比较高，通常都会作数据库的集群，基于同步机制作数据库的读写分离。主库去掉外键、去掉非必要索引，从库添加索引。

业务层面:在业务设计时，尽可能多考虑后期能进行垂直分库，水平分库等

 

代码层面:

    使用缓存减小查询次数,

    批量提交数据减小数据库交互次数

    只取用到列数据 避免select *

    SQL语句的优化

 

    

 

8日志

系统日志主要存在并发的问题，尤为WCF只有一个日志文件，这时咱们能够新建异常消息队列，系统运行时开启一个监听,监听异常消息队列，将消息队列中异常信息写入日志或者NoSql类型数据库，固然不止这一种解决方案

 

 

9关于硬件的分配

不一样服务器不一样配置要求

数据库服务器：内存、cpu、磁盘读写要求高

应用服务器：内存和CPU要求高

图片等静态资源服务器:磁盘、带宽要求比较高

Web主站点：带宽、cpu、内存要求高

当硬件不足状况下合理分配服务，避免资源争抢

 

总结的比较粗犷,也有一时未想起的方面，此文考虑后续更新