0、故事主角
呱呱乐 是一家互联网金融公司。主营现金贷、p2p理财、消费分期业务。
公司现有技术人员800名，系统极其庞杂，每日稳定处理25w左右的订单量，有抢购活动时，系统的QPS(Query Per Second)峰值达到了3w。
系统虽然庞杂，但在技术老大C哥的带领下，服务的可靠性高达99.99%，技术方面的成绩闻名业内。
这不，C哥受邀参加2022年全球互联网大会了。
我是技术主编王小五，让我们一起来采访下C哥吧，你们有什么想问的，也可以关注我的专栏留言吆~
1、呱呱乐系统初期
小五：C哥好，很多网友对呱呱乐公司的系统演进感兴趣，您能给我们讲一讲吗？
C哥得意的笑了笑：好的，那我简单介绍下吧。
呱呱乐初期其实是一个名不见经传的小公司，只有6名技术，主要做消费分期业务，系统是基于LNMP搭建的基础架构，框架使用的是ThinkPhp。
刚开始流量比较小，业务也比较基础，主要提供用户登录注册、订单、账单、支付、风控、消息发送等功能。
功能刚开始都比较简单，所以这样的架构能够满足需求，所有的功能都在一个Git工程里开发。
这些功能抽象出来，可以用一张图表示：
小五：是的，初创型公司基本都是这样的技术架构，简单而实用，满足快速迭代、功能为主的需求。
C哥：但是，随着访问量的增多、业务越来越复杂，这样的架构就有点力不从心了...
2、宕机一小时
小五：哦？怎么个力不从心法？ 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哥，感谢您的分享，明天再来采访您~
注：文中公司、人物均为虚构，只为故事更加精彩~
小记：服务治理还在学习阶段，经验有限，不对的地方请多多指教。
后续：服务治理理论篇(二)、实践篇会相继出炉~
