uu直播快3平台_UU快3直播官方

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

时间:2020-01-31 00:31:55 出处:uu直播快3平台_UU快3直播官方

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

1、SOA服务的粒度的把控:

可能完后 iYou开发都是由开发人员直接设计Edmx模型,或者设计服务,有些是自下而上的方式 ,后面 开发了统统有的服务,粒度的把控也都是很好,最终导致 统统有重复性开发以及不适于前端的调用,而导致 了絮状工作的返工。

建议:服务在设计时应该是自上而下可能在服务开发完后 做相应的调整。尽量的保证服务粗粒度化,原来就能减少前端的调用次数,当然这跟减少页面的Http请求的效果是一致的。另外现在通过UML序列图的方式 也综合了自上而下的开发方式 ,为底层的业务模型修改完善提供了更好的契机。越来越在开发的完后 也可不都还可不可以 进一步去讨论都还可不可以 公开的服务,补充上粒度比较细的那一次责。也我希望说先把握大局从上到下,或者抓住细节从下到上。

2、接口的定义:

接口是算不算代表了业务、是算不算不算离米 的粒度、是算不算会有性能问题报告 报告 ,别小看接口设计,一旦选者完后 先要修改,接口的好坏决定成败。统统有接口的设计不得劲要。接口设计的好坏也直接影响到了性能问题报告 报告 ,

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

目前图片服务器跟Web服务器在同一台机器上,图片的访问量非常大,或者越来越经过压缩和缩略图等防止,当然图片的防止都是统统有的技术后面 细细说。图片的请求占用资源比较多,而主Web请求占用时间比较短,而在请求队列中等待的图片 的时间却很长,图片的请求严重影响了Web的正常注册和找回密码等请求。

建议:图片和web服务器分开,Web站点加有些客户端缓存,以及服务端缓存等技术,将请求的防止提高有些并发性能,用ApacheBench测试亲戚亲戚朋友的请求并发防止是有有有另另一个多/s,通过缓存相信能提高离米 10倍。

4、关于图片防止:

当前的随记中的图片越来越做任何的防止,建议在客户端做压缩和防止,上传一张防止后的图片,一般图片也我希望40k就可不都还可不可以 了,而查看图片文件夹內部统统有图片>1000K,一次下载太浪费下行速率 了,客户端现在做了前端的缓存,稍微减少了次责图片的请求。

建议:前端压缩和防止图片,后台取图片时根据前端都还可不可以 生成对应的缩略图【第一次,后面 就直接返回】并返回,建议图片的名字中可不都还可不可以 做些文章加入有些元数据等记录图片所放位置、格式、时间、大小、类型等,后面 扩展时可不都还可不可以 直接通过图片名访问对应的 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、总节

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

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

热门

热门标签