从老马那抠出点东西,由于是个视频,没有文档资料,遂观后做下总结,以便以后自己遇到优化的时候可以考虑考虑这些方面,下面我将总结的写出来,供大家分享,可能有不对的地方希望指出
一.SOA服务的粒度的把控:
建议:服务在设计时应该是自上而下或者在服务开发之前做相应的调整,尽量的保证服务粗粒度化,这样就能减少前端的调用次数,当然这跟减少页面的http请求的效果是一致的.另外现在通过UML序列图的方式也综合了自上而下的开发方式,为底层业务模型修改完善提供了更好的契机,那么在开发的时候也可以进一步去讨论需要公开的服务,补充上粒度比较细的那一部分.也就是说先把握大局从上到下,然后把握住细节从下而上.
二.接口的定义:
接口是否代表了业务,是否是合适的粒度,是否会有性能问题,别小看接口设计,一旦确定以后很难修改,接口的好坏决定成败.所以接口的设计很重要.接口设计的好坏也直接影响到了性能问题.
三.图片服务器跟web服务器分离
目前图片服务器跟web服务器在同一台及其上,图片的访问量非常大,而没有经过压缩和缩略图等处理,当然图片的处理我们后面细说.图片的请求占用资源比较多,而主web请求占用事件比较端,而在请求队列中等待的时间却很长,图片的请求严重影响了web的正常注册和找回密码等请求.建议:图片和web服务器分开,web站点加一些客户端缓存,以及服务端缓存等技术,将请求的处理提高一些并发性能,用apachebench测试我们的请求并发处理是4个/s,通过缓存相信能提高至少10倍.
四.关于图片处理:
建议:前端压缩和处理图片,后台取图片时根据前端需要生成对应的缩略图[第一次,后面直接返回]并返回,建议图片的名字中可以做些文章加入一些元数据等记录图片的存放位置,格式,时间,大小,类型等,后面扩展时可以直接通过图片名访问对应的key数据库,获取到具体路径[可以参考淘宝的图片文件系统:tfs],图片文件传输的时候可以做压缩,但要考虑到压缩解压缩需要的cpu资源,在IO(磁盘,带宽,传输能力)和CPU之间有一个平衡的考虑
五.关于分布式事务性能问题的探讨
由于在soa架构的系统中,服务级别的分布式事务由于占用事务锁的事件比较长,并发大的时候很容易导致死锁.建议:采用异步队列的方式解决必须有事务保证的数据操作.分布式事务的替代方式是采用队列,放到队列中的东西就认为是一定可以成功的,对于不使用队列的情况,如果调用失败了则记录日志,不会进行回滚.除非涉及到钱或者非常中的数据的地方才做分布式事务
六.关于缓存
建议:分布式缓存可以考虑使用Nosql db比如:MongoDB,此Nosql数据库并发性能非常好,而且可以简易的进行分布式部署,节点很容易进行扩展,另外当我们对数据库的操作和查询都是直接面对的数苦苦,而中间没有响应的一级二级缓存,导致压力还是直接给了数据库,性能的瓶颈最终在数据库端有所体现
七.关于数据库
数据库要求非常高,cpu和内存消耗都比较大,另外对IO的读写也要求比较高,当前数据库的分配应该还算可以了.后面我们设计EDMX或者设计业务时,尽量考虑后期能进行的垂直分库,水平分库等.另外就是数据库集群一定要利用起来,不管是发布,订阅,镜像等技术实现读数据库间数据同步,一定在平台级别解决读写分离
八.关于日志
异常时我们才需要日志,而正常的操作日志可以通过行为分析等组建进行记录,而并不需要记录浪费性能[文件太大,十分占用磁盘的IO和磁盘的空间],而关闭日志我们又捕捉不到异常,所以日志这个还是需要我们平台或者项目进行考虑一个解决方案.
总结
一切都是为了性能,稳定行,可维护性,尽量保证节点保持简单逻辑,尽量减少同一层节点之间依赖,并实现功能分解,使用异步进行整合,故障转移,失效保护.数据方面实现读写分离,数据库分离,功能划分,缓存,镜像.最终理想的可伸缩性架构是可以自由增加或替换服务器,无需去停机维护或做很大的调整.
总体就这么多,希望以后碰到类似问题可以拿出来做参考,打出来的过程自己也过了一遍,虽然有些点自己还hold不住,以后总会碰到,自己就会有个印象,可以来这寻找答案,如果大家又更多的观点,可留评论.