优化滴滴点点
半夜里辗转反侧，将系统优化的滴滴点点记录成案
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、内存要求高
当硬件不足情况下合理分配服务，避免资源争抢
总结的比较粗犷,也有一时未想起的方面，此文考虑后续更新