Bug地狱 #1 突然宕机，企业级应用到底怎么了
背景
目前就职的企业经营是一家服务小微门店Saas企业，以进销存管理和客户营销为主体提供订阅服务。项目正式上线可以说是从13年，基础架构是Web和后端使用C# .net，数据库使用SQL Server。这时公司业务正好遇到中国Saas的顶峰，业务不断增长，但是系统宕机的问题一直出现，甚至周末节假日在户外也要oncall，拿出电脑解决问题。
第一次重构 前后端分离
首先是将钱后端一体的代码机构换成前后端分离结构。技术栈仍然是.net。中间前端的技术栈在人员的流转中尝试使用react进行重构，但是最终没有成功。但是部分的页面使用vue进行了重写，使用iframe进行嵌入，没有进行根治的前端重构。通过后端的分离和前端的重写，系统的稳定性得到了提升，但是仍然有很多的隐患，直到今天，这些问题暴露的出来，出现了了更换架构也无法解决的问题，这个后面再讲。
第二次重构 转换技术栈，使用Java 微服务来了 好像好了起来
在我21年除选择入职这家公司，其中最重要的就是我想要进入一家使用微服务的公司，公司的服务器大约有70台，约30个服务。
在18年左右，公司进行了第二次重构，转为使用java技术栈，主要原因是架构师的选择与市场的供需关系，市场上找不到那么多能够直接上手企业应用的工程师。这次重构的方式是，通过.net后端转发请求到java微服务，逐步将后端的功能使用java实现。前端没有进行彻底重构，基于底层.net，通过iframe嵌套vue的方式进行业务扩展。后端的技术栈使用Spring Cloud，注册中心使用Consul，各种中间件使用spring data相关的组件，部分数据库迁移到Pgsql。
通过这次重构，所有的后端业务基本上都转变为使用java实现，系统的稳定性得到的提升，没有了时时待命的情况，偶尔出现重大问题基本上都是发生数据库的问题。
第三次重构 重构前端 正式使用vue
到了22年，通过转为java的后端，系统稳定了，但是前端的用户体验和开发效率都很低，而且随着业务的不断扩展，重构必然要进行，不然开发的节奏始终会被限制。前端使用qiankun 微前端进行重构，按照业务模块区分子项目。后端部分也重写部分接口，将前后端的职责进行明确区分，同业务下接口的数据结构保持统一，降低未来的代码维护成本。
此时公司还扩展了小程序商城的业务能力，希望通过疫情的影响，帮助更多的小微门店进行线上业务的拓展。小程序商城的技术栈使用uniapp。
危机出现
在第二次重构时，公司的业务已经开始呈现缓慢增长，但是系统压力和数据库的压力不断积累。人员减少（业务增速导致始终成本大于利润，再加上疫情对线下门店的影响）。业务不断扩展代码里惊为天人的循环内远程方法调用，数据库没有建立必要的索引，这些问题导致了系统卡顿。最先建立的数据库，包含了300多张数据表，其中不乏上亿数据的表。少量的人员，既要维护原有的代码，又要兼顾业务扩展。数据量的上升，导致数据库瓶颈，主库压力过大，导致服务雪崩，一旦遇到大量的并发请求，服务就会宕机。
系统仿佛脆弱不堪，就像破了很多洞的巨轮。不管是工作日还是周末，总是会通过客服人员反馈系统无法使用。
是时候要根治这个问题了，要被迫开始建立监控系统，寻找能够监控系统的中间件，将本应该就具有完善的监控系统的服务，变得完整起来。
补充一句，基本没有代码单元测试，直接将新写的代码上线，通过check账号来进行测试。XD
未完待续，建立监控系统，寻找优化点。后面会讲到如何建立Promuetheus监控系统，如何通过中间件监控sql，如何查看线上某个具体接口的性能情况。