服务治理·理论篇(一)

2,235 阅读5分钟

0、故事主角

呱呱乐 是一家互联网金融公司。主营现金贷、p2p理财、消费分期业务。

公司现有技术人员800名,系统极其庞杂,每日稳定处理25w左右的订单量,有抢购活动时,系统的QPS(Query Per Second)峰值达到了3w。

系统虽然庞杂,但在技术老大C哥的带领下,服务的可靠性高达99.99%,技术方面的成绩闻名业内。

这不,C哥受邀参加2022年全球互联网大会了。

我是技术主编王小五,让我们一起来采访下C哥吧,你们有什么想问的,也可以关注我的专栏留言吆~

1、呱呱乐系统初期

小五:C哥好,很多网友对呱呱乐公司的系统演进感兴趣,您能给我们讲一讲吗?

C哥得意的笑了笑:好的,那我简单介绍下吧。

呱呱乐初期其实是一个名不见经传的小公司,只有6名技术,主要做消费分期业务,系统是基于LNMP搭建的基础架构,框架使用的是ThinkPhp。

刚开始流量比较小,业务也比较基础,主要提供用户登录注册、订单、账单、支付、风控、消息发送等功能。

功能刚开始都比较简单,所以这样的架构能够满足需求,所有的功能都在一个Git工程里开发。

这些功能抽象出来,可以用一张图表示:

image_1c4op458s17dnc3a1t7f1r3g1gfg9.png-23.4kB


小五:是的,初创型公司基本都是这样的技术架构,简单而实用,满足快速迭代、功能为主的需求。

C哥:但是,随着访问量的增多、业务越来越复杂,这样的架构就有点力不从心了...


2、宕机一小时

image_1c4ou6cv0l5an211ht71392rfnm.png-208.3kB


小五:哦?怎么个力不从心法? C哥微笑一下:宕机的时候,你就知道了,哈哈。


小五:哈哈,那C哥给我们讲讲吧,大家都很想听。

C哥:当我们业务开展到了6个月左右的时候,注册用户比较多了。 一天下午,大量用户反馈我们的app打不开了,同时我们也发现了这个问题。

于是我们从Nginx开始排查,发现流量正常,没有被DDOS攻击,Nginx配置也正常,没有任何问题。

接下来,我们又排查了PHP,PHP进程也一切正常,没有出现内存泄漏等问题。

剩下的,就排查Mysql了,一看不要紧,原来真是 Mysql 在搞鬼,CPU使用率近乎100%...

于是,我们赶紧暂停了Mysql服务。

通过查询慢Sql日志发现,原来是张二胖写的一条SQL导致了风控日志表进行了全表扫描,而风控日志表中的数据高达800万条...


小五:哈哈,这样的场景似曾相识,好多公司应该都经历过。 C哥:是啊,好多攻城狮都对数据库进行直接操作,而他们写出的SQL的质量又不能保证。


小五:那你们最终怎么解决的呢? C哥:首先我们对服务进行了降级,先保证核心功能可用。而后,我们又对该数据表加索引,对SQL进行优化,最终解决了这个问题。


C哥:从发现问题到解决问题,大约用了一个小时的时间,这一小时内,所有服务都不能用了,真是惊心动魄的一小时。从这时起,我就想有什么办法能够规避这类问题。 小五:是啊,这次可能是张二胖写出了全表扫描的SQL,下次可能是张三胖写出全表扫描的SQL,这样都会导致服务不可用,功能之间的耦合性太高了。


3、业务的继续开展


小五:C哥,除了消费分期业务外,咱们公司后来又开展了现金贷、理财业务。这些业务的加入,对于系统有什么影响呢?

C哥:哎,说起来都是泪啊。因为消费分期、现金贷、理财等业务,很多东西都是相同的,比如用户功能、订单功能、账单功能,前期为了业务的快速发展,我们直接从消费分期拷贝了两套代码出来,分别用来处理现金贷、理财的业务。


小五:的确是,这样能最快的支撑业务的运转。

C哥:但这样给自己埋了很大的坑,以后还得慢慢的去填~


C哥:业务中存在很多Copy-Paste的代码,比如用户表改动了一个字段,三个系统都需要去改。又比如加了Redis缓存,三个系统也都需要改动。实在是太繁琐了,如果忘记改动,还有可能造成服务挂掉,那时候真实天天改bug啊。

小五:心疼你们1秒钟。。。


4、没完没了的加班


C哥:随着业务的发展,系统越来越复杂,技术人员的体会也越来越“痛”,天天改不完的bug,夜以继日的加班...... 小五:现在的系统没有这问题了吧,C哥?

C哥:好在我们进行了微服务的改造,这种问题才得以解决。 小五:微服务?最近很火的概念,C哥给我们分享一下吧!

C哥:今天时间也不早了,要不明天再跟大家细讲吧。 小五:好的C哥,感谢您的分享,明天再来采访您~


注:文中公司、人物均为虚构,只为故事更加精彩~

小记:服务治理还在学习阶段,经验有限,不对的地方请多多指教。

后续:服务治理理论篇(二)、实践篇会相继出炉~


image_1c5582vev1mql1lrpbm3198i1pkop.png-127.1kB