I、EDITORIAL
私は私の友人の多くはマイクロサービスアーキテクチャを構築するために自分の会社で春クラウドフレームワークを使用していると信じて、結局、これは技術の非常に火災です。
春クラウドを利用して、従来のITシステムの利用者の少量のみが露出することができる場合は、問題を見ていません。
量がより多くのユーザー、毎秒ピーク、並行システムの数万のためのインターネット会社の要求である場合には、春のクラウド技術を使用して注意が必要ないくつかの問題があります。
第二に、シーンの導入、早期の問題
最初はの点では空のトーク理論、理論、ではない実際の例は、これは私の友人の一人は、実際のケースで起業家のインターネット企業が起こっています。
インターネットのようなビジネスを行う会社の友人は、アップシステムのマイクロサービスアーキテクチャを構築する春のクラウド技術スタックの使用上、小さな研究開発チームを設置しました。
それを行うには、通常は通常のQAテストはすべての主要な問題を見つけることができませんでしたいくつかの時間、最終的には、コアビジネスシステムのための残業の昼と夜は、私はかなり良いパフォーマンスを感じ、すべてが完璧です。
システムライン上のように、そして、ユーザは、小規模、登録ユーザー数千人の、ユーザーの日活の何十万もの少量を開始します。
毎日、データベース内のテーブルに新しいデータは、そう時間をかけて、データのサイズは、実際にゆっくりと、単一のテーブルの何百万人に育つとは思いませんでした。
それは、また非常に間違っていないようです。この時間は、ユーザーがいくつかのオペレーティングシステムは、ブラシアウトページカトン数秒を感じるだろうことを訴えていることです。
これはなぜそれで?
コアの理由は、数百万の大規模な単一のテーブルデータの数、です。
たくさんの関連付けられた個々のサービス、実行するSQLはより複雑で、マルチテーブル
そして、良いインデックス、またはインデックスのデザインが、いくつかの兄のフラストレーションは、SQLの行数百人を書いた設計ではない、SQLが複雑すぎる場合、SQLは、数秒を使い果たし確かに正常です。
我々はマイクロサービスフレームワークを少し理解していれば、それはたとえば装う+サービス起動フレームワークリボン組成のために、言ったタイムアウトを呼び出すためのインターフェースがあり、知っておくべき、タイムアウトインターフェース呼び出しを設定することができ、いくつかのパラメータがあります。
あなたは数秒のブラシが出てこないため、人々はタイムアウト例外を返しますインターフェースを呼び出す場合は、ユーザーがページを磨くません。
良いよりも第三に、若いトムはちょうど沸騰し、危害
一般的にこの種のものに遭遇し、糞の大きな塊そこに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等各种你能想到的技术手段,优化一下性能。
否则你要是胡乱设置超时时间是几秒,甚至几十秒,万一下游服务偶然出了点问题响应时间长了点呢?那你这个线程池里的线程立马全部卡死!
这两步解决之后,其实系统表现就正常了,核心服务B响应速度很快,而且超时时间也在1秒以内,不会出现hystrix线程池频繁卡死的情况了。
第三步
事儿还没完,你要真觉得两步就搞定了,那还是经验不足。
如果你要是超时时间设置成了1秒,如果就是因为偶然发生的网络抖动,导致接口某次调用就是在1.5秒呢?这个是经常发生的,因为网络的问题,接口调用偶然超时。
所以此时配合着超时时间,一般都会设置一个合理的重试,如下所示:
设置这段重试之后,Spring Cloud中的Feign + Ribbon的组合,在进行服务调用的时候,如果发现某台机器超时请求失败,会自动重试这台机器,如果还是不行会换另外一台机器重试。
这样由于偶尔的网络请求造成的超时,不也可以通过自动重试避免了?
第四步
其实事儿还没完,如果把重试参数配置了,结果你居然就放手了,那还是没对人家负责任啊!
你的系统架构中,只要涉及到了重试,那么必须上接口的幂等性保障机制。
否则的话,试想一下,你要是对一个接口重试了好几次,结果人家重复插入了多条数据,该怎么办呢?
其实幂等性保证本身并不复杂,根据业务来,常见的方案:
可以在数据库里建一个唯一索引,插入数据的时候如果唯一索引冲突了就不会插入重复数据
或者是通过redis里放一个唯一id值,然后每次要插入数据,都通过redis判断一下,那个值如果已经存在了,那么就不要插入重复数据了。
类似这样的方案还有一些。总之,要保证一个接口被多次调用的时候,不能插入重复的数据。
六、总结全文,回眸再看
有图有真相!老规矩,最后给大家上一张图,最终优化后的系统表现大概是长下面这样子的。
分享一份面试宝典《Java核心知识点整理.pdf》“,覆盖了JVM、锁、高并发、反射、Spring原理、微服务、Zookeeper、数据库、数据结构等等”,还有Java208道面试题(含答案)加入群(Java填坑之路)659655594 即可免费获取到!