iYou外网优化总结教训经验：

ou外网优化总结教训经验：

经过前期iYou服务外网平台搭建和优化，我做了一些思考和总结，并学习了很多其他公司或者平台搭建的一些思想，现总结如下，希望能在后面的iYou、IWe或者其他项目开发时，有所借鉴。

1、SOA服务的粒度的把控：
由于之前iYou开发都是由开发人员直接设计Edmx模型，然后设计服务，这种是自下而上的方式，后面开发了很多的服务，粒度的把控也不是很好，最终导致很多重复性开发以及不适于前端的调用，而导致了大量工作的返工。
建议：服务在设计时应该是自上而下或者在服务开发之前做相应的调整。尽量的保证服务粗粒度化，这样就能减少前端的调用次数，当然这跟减少页面的Http请求的效果是一致的。另外现在通过UML序列图的方式也综合了自上而下的开发方式，为底层的业务模型修改完善提供了更好的契机。那么在开发的时候也可以进一步去讨论需要公开的服务，补充上粒度比较细的那一部分。也就是说先把握大局从上到下，然后抓住细节从下到上。
2、接口的定义：
接口是否代表了业务、是否是合适的粒度、是否会有性能问题，别小看接口设计，一旦确定以后很难修改，接口的好坏决定成败。所以接口的设计很重要。接口设计的好坏也直接影响到了性能问题，
3、图片服务器跟Web服务器分离
目前图片服务器跟Web服务器在同一台机器上，图片的访问量非常大，而且没有经过压缩和缩略图等处理，当然图片的处理也有很多的技术后面细细说。图片的请求占用资源比较多，而主Web请求占用时间比较短，而在请求队列中等待的时间却很长，图片的请求严重影响了Web的正常注册和找回密码等请求。
建议：图片和web服务器分开，Web站点加一些客户端缓存，以及服务端缓存等技术，将请求的处理提高一些并发性能，用ApacheBench测试我们的请求并发处理是4个/s，通过缓存相信能提高至少10倍。
4、关于图片处理：
当前的随记中的图片没有做任何的处理，建议在客户端做压缩和处理，上传一张处理后的图片，一般图片也就是40k就可以了，而查看图片文件夹内部很多图片>300K，一次下载太浪费带宽了，客户端现在做了前端的缓存，稍微减少了部分图片的请求。
建议：前端压缩和处理图片，后台取图片时根据前端需要生成对应的缩略图【第一次，后面就直接返回】并返回，建议图片的名字中可以做些文章加入一些元数据等记录图片所放位置、格式、时间、大小、类型等，后面扩展时可以直接通过图片名访问对应的 Key数据库，获取到具体的路径【可以参考淘宝的图片文件系统：Taobao File System 简称：TFS】 ，图片文件传输的时候可以做压缩，但要考虑到压缩解压缩需要CPU资源，在IO（磁盘，带宽，传输能力）和CPU之间有一个平衡的考虑。
5、关于分布式事务性能问题的探讨
由于在soa架构的系统中，服务级别的分布式事务由于占用事务锁的时间比较长，并发大的时候很容易导致死锁。这是iYou前期开发遇到的血的教训，而后面做iWe时，肯定 某些具体模块还得使用事务保证数据的完整性。
建议：采用异步队列的方式解决必须由事务保证的数据操作。分布式事务的替代方式是采用队列，放到队列中的东西就认为是一定可以成功的，对于不使用队列的情况，如果调用失败了则记录日志，不会进行回滚。除非涉及到钱或者非常重要的数据的地方才做分布式事务。
6、关于缓存：
目前分布式缓存其实是一个单一的节点，而且只有分布式缓存挂掉，所有用户掉线，整个应用服务都得重启，所有它是不可靠的，当然可以进行扩展。
建议：分布式缓存可以考虑使用NoSql DB比如：MongoDB，此NoSql数据库并发性能非常好，而且可以简易的进行分布式部署，节点很容易进行扩展，另外当前我们的所有的对数据库的操作和查询都是直接面对的数据库，而中间没有相应的一级二级缓存，导致压力还是都直接给了数据库，性能的瓶颈最终会在数据库端有所体现。
7、关于数据库：
数据库要求非常高，CPU和内存消耗都比较大，另外对IO的读写也要求比较高，当前数据库的分配应该还算可以了。后面我们再设计业务或者Edmx时，尽量多考虑后期能进行垂直分库、水平分库等。
另外就是数据库集群一定要利用起来，不管是发布、订阅、镜像等技术实现读数据库间数据同步，一定在平台级别解决读写分离。
8、关于www.iuoooo.com 站点
此站点职责很清新就是用户注册、密码找回、客户端下载导向等。当然目前业务很简单，如果是到了IWE我们做Web的多模块集成的时候，多注意一下，因为web服务器考虑以后可能做负载均衡。做负载均衡就要考虑Web站点能按功能分割，只有分割了才能有伸缩性。
再有就是站点的缓存：客户端缓存和服务端缓存都没做，性能较差，建议使用：ApacheBench有针对性并发测试压一下，也可以用loadrunner或者VS的压力测试工具。
9、关于日志：
异常时我们才需要日志，而正常操作日志可以通过行为分析等组件进行记录，而并不需要记录浪费性能【文件太大，十分占用磁盘的IO和磁盘空间】，而关闭日志，异常等信息我们又捕捉不到，所以日志这个还是需要我们平台或者项目进行考虑一个解决方案。
10、关于硬件：
数据库服务器：内存、CPU、磁盘读写速度 都要好
应用服务器：内存和CPU大点
图片、iYou升级下载服务器：磁盘、带宽要求比较高
Web主站点：带宽、CPU、内存要求高
11、总节
一切都是为了性能、稳定性、可维护性，尽量保证节点保持简单的逻辑，尽量减少同一层次节点之间的依赖，并实现功能分解、使用异步进行整合、故障转移、失效保护。 数据方面实现读写分离、数据库分隔、功能划分、缓存、镜像。最终理想的可伸缩性架构是可以自由增加或替换服务器，无需去停机维护或做很大的调整。