网站简易后台,浙江住房城乡建设厅网站,域名注册信息怎么查,广州建站方法Java生鲜电商平台-SpringCloud微服务架构高并发参数优化实战 一、写在前面 在Java生鲜电商平台平台中相信不少朋友都在自己公司使用Spring Cloud框架来构建微服务架构#xff0c;毕竟现在这是非常火的一门技术。 如果只是用户量很少的传统IT系统#xff0c;使用Spring Cloud可… Java生鲜电商平台-SpringCloud微服务架构高并发参数优化实战 一、写在前面 在Java生鲜电商平台平台中相信不少朋友都在自己公司使用Spring Cloud框架来构建微服务架构毕竟现在这是非常火的一门技术。 如果只是用户量很少的传统IT系统使用Spring Cloud可能还暴露不出什么问题。 如果是较多用户量高峰每秒高达上万并发请求的互联网公司的系统使用Spring Cloud技术就有一些问题需要注意了。 二、场景引入问题初现 朋友A的公司做互联网类的创业组建了一个小型研发团队上来就用了Spring Cloud技术栈来构建微服务架构的系统。 一段时间没日没夜的加班好不容易核心业务系统给做出来了平时正常QA测试没发现什么大毛病感觉性能还不错一切都很完美。 然后系统就这么上线了一开始用户规模很小注册用户量小几十万日活几千用户。 每天都有新的数据进入数据库的表中就这么日积月累的没想到数据规模居然慢慢吞吞增长到了单表几百万。 这个时候呢看起来也没太大的毛病就是有用户反映系统有些操作会感觉卡顿几秒钟会刷不出来页面。 这是为啥呢 核心原因是单表数据量大了一些达到了几百万。 有个别服务跑的SQL比较复杂一大堆的多表关联 并且还没有设计好索引或者是设计了索引但无奈一些小弟写了上百行的大SQLSQL实在太复杂了那么一个SQL跑出来好几秒肯定是正常的。 如果大家对微服务框架有点了解的话应该知道比如Feign Ribbon组成的服务调用框架是有接口调用超时这一说的有一些参数可以设置接口调用的超时时间。 如果你调用一个接口好几秒刷不出来人家就超时异常返回用户就刷不出来页面了。 三、扬汤止沸饮鸩止渴 一般碰到这种事情一大坨屎一样的SQL摆在那儿写SQL的人过一个月自己都看不懂了80%的工程师看着都不愿意去花时间重写和优化。 一是修改的人力成本太高二是谁敢负担这责任呢 系统跑的好好的就是慢了点而已结果你硬是乱改一通重构把系统核心业务流程搞挂了怎么办 所以那些兄弟第一反应是增加超时时间啊接口慢点可以但是别超时不响应啊 咱们让接口执行个几秒把结果返回用户不就可以刷出来页面了不用重构系统了啊轻松愉快 如何增加呢很简单看下面的参数就知道了 大家如果看过之前的文章应该知道Spring Cloud里一般会用hystrix的线程池来执行接口调用的请求。 所以设置超时一般设置两个地方feign和ribbon那块的超时还有hystrix那块的超时。其中后者那块的超时一般必须大于前者。 Spring Cloud玩儿的好的兄弟可千万别看着这些配置发笑因为我确实见过不少Spring Cloud玩儿的没那么溜的哥们真的就这么干了。 好了日子在继续。。。 优化了参数后看上去效果不错用户虽然觉得有的页面慢是慢点但是起码过几秒能刷出来。 这个时候日活几千的用户量压根儿没什么并发可言高峰期每秒最多一二十并发请求罢了。 四、问题爆发洪水猛兽 随着时间的推移公司业务高速发展…… 那位兄弟的公司在系统打磨成熟几万用户试点都ok之后老板立马拿到一轮几千万的融资。 公司上上下下意气风发啊紧接着就是组建运营团队地推团队全国大范围的推广。 总之就是三个字推推推 这一推不打紧研发人员在后台系统发现自己的用户量蹭蹭蹭的直线增长。 注册用户增长了几十倍突破了千万级别日活用户也翻了几十倍在活动之类的高峰期居然达到了上百万的日活用户量 幸福的烦恼。。。 为什么这么说因为用户量上来后悲剧的事情就发生了。 高峰期每秒的并发请求居然达到了近万的程度研发团队的兄弟们哪里敢怠慢在这个过程中先是紧张的各种扩容服务一台变两台两台变四台。 然后数据库主从架构挂上去读写分离是必须的否则单个数据库服务器哪能承载那么大的请求多搞几个从库扛一下大量的读请求这样基本就扛住了。 正准备坐下来喝口茶、松口气更加悲剧的事情就发生了。 在这个过程中那些兄弟经常会发现高峰期系统的某个功能页面突然就整个hang死了就是没法再响应任何请求所有用户刷新这个页面全部都是无法响应 这是为什么呢原因很简单啊一个服务A的实例里专门调用服务B的那个线程池里的线程总共可能就几十个。每个线程调用服务B都会卡住5秒钟。 那如果每秒钟过来几百个请求这个服务实例呢一下子那个线程池里的线程就全部hang死了没法再响应任何请求了。 大家来看看下面这张图再直观的感受一下这个无助的过程 这个时候咋办兄弟们只能祭出程序员最古老的法宝重启机器 遇到页面刷不出来只能重启机器相当于短暂的初始化了一下机器内的资源。 然后接着运行一段时间又卡死再次重启真是令人崩溃啊用户们的体验是极差的老板的心情是愤怒的 画外音 其实这个问题本身不大但如果对Spring Cloud没有高并发场景的真实经验确实可能会跟这帮兄弟一样搞出些莫名其妙的问题。 比如这个公司明明应该去优化服务接口性能结果硬是调大了超时时间。结果导致并发量高了对那个服务的调用直接hang死系统的核心页面刷不出来影响用户体验了这怪谁呢 五、追本溯源治标治本 没法子了那帮兄弟们只能找人求助。下面就是作者全程指导他们完成系统优化的过程。 第一步 关键点优化图中核心服务B的性能。互联网公司核心业务逻辑面向C端用户高并发的请求不要用上百行的大SQL多表关联那样单表几百万行数据量的话会导致一下执行好几秒。 其实最佳的方式就是对数据库就执行简单的单表查询和更新然后复杂的业务逻辑全部放在java系统中来执行比如一些关联或者是计算之类的工作。 这一步干完了之后那个核心服务B的响应速度就已经优化成几十毫秒了是不是很开心从几秒变成了几十毫秒 第二步 那个超时的时间也就是上面那段ribbon和hystrix的超时时间设置。 奉劝各位同学不要因为系统接口的性能过差而懒惰搞成几秒甚至几十秒的超时一般超时定义在1秒以内是比较通用以及合理的。 为什么这么说 因为一个接口理论的最佳响应速度应该在200ms以内或者慢点的接口就几百毫秒。 如果一个接口响应时间达到1秒建议考虑用缓存、索引、NoSQL等各种你能想到的技术手段优化一下性能。 否则你要是胡乱设置超时时间是几秒甚至几十秒万一下游服务偶然出了点问题响应时间长了点呢那你这个线程池里的线程立马全部卡死 具体hystrix的线程池以及超时时间的最佳生产实践请见下一篇文章《微服务架构如何保障双11狂欢下的99.99%高可用》 这两步解决之后其实系统表现就正常了核心服务B响应速度很快而且超时时间也在1秒以内不会出现hystrix线程池频繁卡死的情况了。 第三步 事儿还没完你要真觉得两步就搞定了那还是经验不足。 如果你要是超时时间设置成了1秒如果就是因为偶然发生的网络抖动导致接口某次调用就是在1.5秒呢这个是经常发生的因为网络的问题接口调用偶然超时。 所以此时配合着超时时间一般都会设置一个合理的重试如下所示 设置这段重试之后Spring Cloud中的Feign Ribbon的组合在进行服务调用的时候如果发现某台机器超时请求失败会自动重试这台机器如果还是不行会换另外一台机器重试。 这样由于偶尔的网络请求造成的超时不也可以通过自动重试避免了 第四步 其实事儿还没完如果把重试参数配置了结果你居然就放手了那还是没对人家负责任啊 你的系统架构中只要涉及到了重试那么必须上接口的幂等性保障机制。 否则的话试想一下你要是对一个接口重试了好几次结果人家重复插入了多条数据该怎么办呢 其实幂等性保证本身并不复杂根据业务来常见的方案 可以在数据库里建一个唯一索引插入数据的时候如果唯一索引冲突了就不会插入重复数据 或者是通过redis里放一个唯一id值然后每次要插入数据都通过redis判断一下那个值如果已经存在了那么就不要插入重复数据了。 类似这样的方案还有一些。总之要保证一个接口被多次调用的时候不能插入重复的数据。 转载于:https://www.cnblogs.com/jurendage/p/11406867.html
