深层次优化的基础是对业务的理解

字数 2411阅读 662评论 1赞 1

今天是深圳慢生活的第三天了，昨天早上可以凭身份证和24小时核酸阴性出入小区，去商超购物，不过中午的时候政策变了，需要去管理处开证明，一个人一天只能出去一次。于是我就准备把今天的机会攒着，到傍晚的时候出去散散步，然后再去超市。没想到晚饭后想去开证明的时候被告知下午接到通知，恢复完全封闭了。早上政策放宽给人疫情得到控制，会一天天放松的遐想落空了。

疫情一旦在大城市出现，伴随而来的就是某某健康码平台的故障，实际上只有西安一码通被炒的纷纷扬扬，其他的因为政府公关能力比较高，都没有激起涟漪。这两天又有某城市市民云出故障，不过也很快平息了。按理说西安事件发生后，各地政府都比较重视这方面的应用优化，为什么遇到一些重大事件的时候还是会出问题呢？而互联网公司的系统为什么会在类似双十一这样数百倍业务高峰的情况下还能良好运行呢？

可能没有接触过电子政务系统的朋友对此更难理解，那么简单的一个一个应用系统，为什么会动不动就崩溃呢？实际上，每一个城市APP的崩溃大多数是在某个点上出现了瓶颈，最后该点阻塞了整个应用，导致了故障。比如接入网络的带宽和延时、负载均衡设备的带宽与转发效率、应用服务器的性能、应用编写的好坏、REDIS的均衡访问、bigkey、慢查询的数量、数据库服务器的性能、存储的IO延时等，都可能成为堵塞点。城市APP看似简单，不过是一个统一入口，再去调用不同系统的接口，实现十分复杂的综合业务功能。

刚刚开始的时候系统还比较清晰，比较简单，不过随着系统上线，不断的加入新的功能，APP内部的接口逻辑往往越来越复杂，而且每次功能的变更并没有统一的设计师，都是由新模块的开发者设计一个接口，然后添加到以前的主模块中。随着时间推移，这些接口会变得越来越重，越来越复杂，而且很多类似的代码在多个接口中存在重复，很可能么有被统一的重构。我们帮助优化过一个城市APP，一个登录操作居然有9个接口，每个接口的调用延时都不低，而且属于不同的应用系统，优化起来相当困难。在设计之初，架构师并没有意识到今后会有很大量的并发登录存在，因此也没有设计成异步的，并且也不支持动态/在线降级功能。按照我们刚刚入场时的测试看，当时的部署资源，顶多能够支撑200多人的并发登录。要实现2万并发登录，必须将现有硬件扩容100倍，这几乎是不可能完成的事情。

最后我们决定从这9个接口调用开始优化，只有把这9个接口调用的延时降低下来100倍，才能在现有硬件条件下达到提升100倍并发能力的目标。当初客户找我们做优化是看中了我们在数据库优化方面的能力，他们觉得oracle数据库上的瓶颈应该是导致APP并发量上不去的主要原因。为了充分了解系统的瓶颈在哪里，我们首先安排了几次压测。通过压测发现，数据库根本就没有任何压力。不过前端APPSERVER的所有线程池都满了，出现了阻塞。初步定位，问题出现在REDIS上。实际上，对于城市APP这种互联网特征较为明显的应用，如果说问题已经出现在数据库上了，那说明这个系统的架构已经完全不适合此类应用了，因为数据库是最难横向扩展的组件，也是横向扩展成本最高的组件。

定位问题在REDIS上之后，后面的工作就变成了纯粹的技术工作，存在BIGKEY，存在负载不均衡的KEY，存在慢查询，这些问题一一的找出来，然后解决掉就行了。这种问题分析，必须理解业务，否则就很难深入下去了。我们做优化的这个项目，登录卡在200并发，是因为有一个十分大的KEY，有几百KB，里面存储了APP的菜单的模板，每个登录的请求都会访问这个KEY,而这个KEY只有一个值，因此只存储在REDIS集群中的一个实例里，这个REDIS实例就成为访问最热的那个实例，而且因为REDIS的单线程架构，这个BIGKEY的单词访问效率也不高。弄明白登录中的这个逻辑后，我们就要求开发商做两个改造，第一个是将这个KEY做成多个副本，在每个REDIS实例中均匀分配对这个KEY的访问，其次是拆分这个BIGKEY，首次登录的时候只需要获取第一层菜单就可以了，没必要把一个完整的菜单都下载下去。因为高并发的防疫请求来的时候，往往只需要访问主页的快捷键，根本不需要访问其他菜单项。

实际上这种系统的优化，在技术上并不难，就是让所有的模块都能够横向扩展，不存在任何的无法扩展的点，那么如果真的要达到某种并发要求，那也就是钱的问题了。想省钱就在应用代码上多做优化，不想改应用，就多花点钱。

实际上我们的优化过程中也遇到过一些问题，有一次一个特殊任务导致并发量突增数十倍，某项功能突然出问题了。后来一分析，这个出问题的功能中的一台独立使用的F5是几年前的低端设备，当时的并发量把背板处理能力打满了。从这次故障也可以看出，任何一个细小的地方没有注意到，就可能毁了一个城市APP。

如果真的最后负载都压倒数据库上了，数据库顶不住了怎么办？实际上此类业务的特点决定了，数据库中存储的相对静态的并发访问最多的数据是完全可以放到可横向扩展的REDIS集群中的，数据库最大的负载来自于写入日志和审计数据等内容。这些数据库写入操作完全没必要设计成同步模式的，应用把这些数据写入ACTIVEMQ之类的中间件，然后由一个异步写盘的任务异步写入数据库就可以了。通过消息中间件来平滑业务高峰，那么再大的高峰，数据库也是可以轻松扛下了。

城市APP的业主是当地的政府或者事业单位，在行政上和互联网企业有着极大的不同，其决策的科学性、投资的规模与魄力都和物联网企业有着巨大的不同。很多问题的出现其实并不是技术因素占主导的，因此我们也不能简单的认为某某某的技术不行，才导致了问题的出现。不过城市APP的并发量和复杂程度、一致性要求远没有电商、12306等应用复杂，其优化难度还是不高的。只要真正理解了业务，根据业务特点使其具备横向扩展能力，并逐个接口提升效率，还是比较容易完成优化工作的。

国产数据库

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论1 条评论

GoldenDB产品经理中兴通讯
2022-05-10 10:08

实战总结，深入浅出，赞！

Ctrl+Enter 发表

匿名评论

深层次优化的基础是对业务的理解

添加新评论1 条评论

作者其他文章

相关文章

相关问题

相关资料