保存成功
订阅成功
保存失败,请重试
提交成功

性能调优,你转型架构师途中的拦路虎

¥10会员免费看
IT老兵哥

2003 ~ 2008 年,这五年老兵哥我在通信行业做实习生和开发岗,主要用 C / C++ / MFC 开发嵌入式 / 服务器 / 桌面等应用程序,期间做过大量代码重构优化,但很少涉及性能调优,要么我负责的局部无需考虑并发访问和海量数据,要么网管平台仅供客户内部人员使用,不存在并发访问和海量数据。2008 年底,老兵哥我跳槽到了移动互联网做技术经理,随后五年主要用 Java / C++ 开发 Web / 服务器等互联网应用。

当时,架构师这个岗位在业界还是很罕见的,不懂预估并发用户、业务数据等规模,自然就预见不到后续并发访问和海量数据会带来巨大的性能挑战。我们赶着工期把功能需求实现、业务流程跑通,然后就上线了,但移动互联网爆发的那些年业务增长非常快,系统上线不久就遇到性能问题了,其现象就是原来耗时很短的操作现在动不动就超时,或者界面刷不出来数据等等,巨大的压力跟着客户投诉一起摆到了我面前。

性能调优任务不像普通开发任务,它需要背负业务、时间和难度等多种压力。罗马不是一天建成的,导致性能问题的原因错综复杂,当时老兵哥我也不知道从何处下手,找不到解决问题的切入点。好性能不是调优出来的,更多是设计出来的。只有经历过性能调优,才能体会这句话的真谛。性能调优,其实就是对承载业务的现网系统做重构优化,就像是边开车边换轮胎,它所需要的技能跟代码重构完全不在一个层级上。

现在老兵哥我知道,性能是系统性问题,性能调优离不开架构视角。不识庐山真面目,只缘身在此山中。当你陷在具体的、局部的问题当中,你是无法找到解决问题的思路的。你必须从实现细节跳脱出来,从更加宏观全局的视角来梳理业务流程,就像另一篇 Chat《图解 Spring Cloud:HTTP 请求的处理流程与机制》的剖析过程类似,然后以业务流程为线索分析每个环节存在的性能瓶颈原因,这样你就不再困惑了。

当每个环节潜在问题梳理出来之后,根据资源、时间等外部限制,按照帕累托二八原则,你可以决定优先解决哪些问题,从而有条不紊地化解性能压力了。随着在性能调优上的经验不断丰富,你就越来越有信心掌控更大规模的系统了。更值得高兴的是,当你费老牛劲把这些自己挖的巨坑填上后,你就记得下次不要再给自己挖坑了,也就懂得怎样设计一个高性能的互联网系统了,这不就是从开发跃迁至架构的契机吗?

性能调优,是从开发岗跃迁至架构岗的拦路虎。升级思维的过程是痛苦的,尤其是在背负压力下的被动升级,跳出原先的舒适区,进入更大的舒适区,这样才能站上新平面。记得当时老兵哥我还有不少负面情绪,回顾过往才懂得要感谢当时的领导给我这份压力,逼迫我高强度学习并突破了旧的思维,机会和挑战是并存的。现在老兵哥我把这些调优经验和架构视角梳理出来供转型升级的你参考,希望帮你少走些弯路:

  • 性能优化的 X Y Z 三维度视角
  • 从 X 维度优化业务的交互设计,包括业务规则、交互设计等
  • 从 Y 维度优化系统的处理流程,包括 Web 容器、Spring、ORM、数据库等
  • 从 Z 维度优化系统的技术堆栈,包括操作系统 OS、Java 虚拟机 JVM 等
  • 数据访问层性能调优案例详解,包括 SQL、 Hibernate、JProfiler 等
  • 性能优化当中蕴藏的架构思维

适合读者:计划转型升级的开发、测试、运维等

124 人已订阅
会员免费看
¥10 原价订阅
微信扫描登录
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!
入群与作者交流×
扫码后回复关键字 入群
Chat·作者交流群
入群码
该二维码永久有效
严选标准
知道了
Chat 状态详情
开始预订
预订结果公布19.10.29

预订达标,作者开始写作

审核未达标,本场 Chat 终止

作者文章审核结果公布19.11.27

审核达标,文章发布

审核未达标,本场 Chat 终止

Chat 完结
×
已购列表