1、图片服务器跟Web服务器分离

目前图片服务器跟Web服务器在同一台机器上，图片的访问量非常大，而且没有经过压缩和缩略图等处理，当然图片的处理也有很多的技术后面细细说。图片的请求占用资源比较多，而主Web请求占用时间比较短，而在请求队列中等待的时间却很长，图片的请求严重影响了Web的正常注册和找回密码等请求。
建议：图片和web服务器分开，Web站点加一些客户端缓存，以及服务端缓存等技术，将请求的处理提高一些并发性能，用ApacheBench测试我们的请求并发处理是4个/s，通过缓存相信能提高至少10倍。

2、关于图片处理：

当前的随记中的图片没有做任何的处理，建议在客户端做压缩和处理，上传一张处理后的图片，一般图片也就是40k就可以了，而查看图片文件夹内部很多图片>300K，一次下载太浪费带宽了，客户端现在做了前端的缓存，稍微减少了部分图片的请求。
建议：前端压缩和处理图片，后台取图片时根据前端需要生成对应的缩略图【第一次，后面就直接返回】并返回，建议图片的名字中可以做些文章加入一些元数据等记录图片所放位置、格式、时间、大小、类型等，后面扩展时可以直接通过图片名访问对应的 Key数据库，获取到具体的路径【可以参考淘宝的图片文件系统：Taobao File System 简称：TFS】，图片文件传输的时候可以做压缩，但要考虑到压缩解压缩需要CPU资源，在IO（磁盘，带宽，传输能力）和CPU之间有一个平衡的考虑。

3、关于分布式事务性能问题的探讨

由于在SOA架构的系统中，服务级别的分布式事务由于占用事务锁的时间比较长，并发大的时候很容易导致死锁。某些具体模块还得使用事务保证数据的完整性。
建议：采用异步队列的方式解决必须由事务保证的数据操作。分布式事务的替代方式是采用队列，放到队列中的东西就认为是一定可以成功的，对于不使用队列的情况，如果调用失败了则记录日志，不会进行回滚。除非涉及到钱或者非常重要的数据的地方才做分布式事务。

4、关于缓存：

目前分布式缓存其实是一个单一的节点，而且只有分布式缓存挂掉，所有用户掉线，整个应用服务都得重启，所有它是不可靠的，当然可以进行扩展。
建议：分布式缓存可以考虑使用NoSql DB比如：MongoDB，此NoSql数据库并发性能非常好，而且可以简易的进行分布式部署，节点很容易进行扩展，另外当前我们的所有的对数据库的操作和查询都是直接面对的数据库，而中间没有相应的一级二级缓存，导致压力还是都直接给了数据库，性能的瓶颈最终会在数据库端有所体现。

5、关于数据库：

数据库要求非常高，CPU和内存消耗都比较大，另外对IO的读写也要求比较高，当前数据库的分配应该还算可以了。后面我们再设计业务或者Edmx时，尽量多考虑后期能进行垂直分库、水平分库等。
另外就是数据库集群一定要利用起来，不管是发布、订阅、镜像等技术实现读数据库间数据同步，一定在平台级别解决读写分离。

6、关于日志：

异常时我们才需要日志，而正常操作日志可以通过行为分析等组件进行记录，而并不需要记录浪费性能【文件太大，十分占用磁盘的IO和磁盘空间】，而关闭日志，异常等信息我们又捕捉不到，所以日志这个还是需要我们平台或者项目进行考虑一个解决方案。

7、关于硬件：

数据库服务器：内存、CPU、磁盘读写速度都要好
应用服务器：内存和CPU大点
图片、下载服务器：磁盘、带宽要求比较高
Web主站点：带宽、CPU、内存要求高

8、总节

一切都是为了性能、稳定性、可维护性，尽量保证节点保持简单的逻辑，尽量减少同一层次节点之间的依赖，并实现功能分解、使用异步进行整合、故障转移、失效保护。数据方面实现读写分离、数据库分隔、功能划分、缓存、镜像。最终理想的可伸缩性架构是可以自由增加或替换服务器，无需去停机维护或做很大的调整。

参考书籍：

《高性能网站建设指南》
《Web性能权威指南》