服务治理·理论篇(一)

0、故事主角

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

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

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

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

我是技术主编王小五，让咱们一块儿来采访下C哥吧，大家有什么想问的，也能够关注个人专栏留言吆~

一、呱呱乐系统初期

小五：C哥好，不少网友对呱呱乐公司的系统演进感兴趣，您能给咱们讲一讲吗？

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

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

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

功能刚开始都比较简单，因此这样的架构可以知足需求，全部的功能都在一个Git工程里开发。

这些功能抽象出来，能够用一张图表示：

---

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

C哥：可是，随着访问量的增多、业务愈来愈复杂，这样的架构就有点力不从心了...

---

二、宕机一小时

---

小五：哦？怎么个力不从心法？ 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，这样都会致使服务不可用，功能之间的耦合性过高了。

---

三、业务的继续开展

---

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

C哥：哎，提及来都是泪啊。由于消费分期、现金贷、理财等业务，不少东西都是相同的，好比用户功能、订单功能、帐单功能，前期为了业务的快速发展，咱们直接从消费分期拷贝了两套代码出来，分别用来处理现金贷、理财的业务。

---

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

C哥：但这样给本身埋了很大的坑，之后还得慢慢的去填~

---

C哥：业务中存在不少Copy-Paste的代码，好比用户表改动了一个字段，三个系统都须要去改。又好比加了Redis缓存，三个系统也都须要改动。实在是太繁琐了，若是忘记改动，还有可能形成服务挂掉，那时候真实每天改bug啊。

小五：心疼大家1秒钟。。。

---

四、没完没了的加班

---

C哥：随着业务的发展，系统愈来愈复杂，技术人员的体会也愈来愈“痛”，每天改不完的bug，夜以继日的加班...... 小五：如今的系统没有这问题了吧，C哥？

C哥：好在咱们进行了微服务的改造，这种问题才得以解决。 小五：微服务？最近很火的概念，C哥给咱们分享一下吧！

C哥：今天时间也不早了，要不明天再跟你们细讲吧。 小五：好的C哥，感谢您的分享，明天再来采访您~

---

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

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

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

---