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