架构师的技术升级之路( 三 )


4 尽量培养自己的调优意识 。说这个话很虚,具体而言,自己得能通过各种数据库日志(比如各sql的运行时间)来找出长sql,并在此基础上通过执行计划来优化,又如,可以通过dump文件和GC日志来看虚拟机的内存使用曲线,看内存主要耗在哪些方面,如果是自己代码没写好那还好办,如果是耗在(中间件的)底层jar包里的代码里,那也得知道解决方案 。
以上只是架构师所需要的基础技能, 其实如果能真正做到上述4点的话,大家离开架构师的水准也不远了,在此基础上,大家还得继续锻炼整合的能力 。
从纵向来讲,需要进一步深化搭建集群的技能,比如能从底层代码的角度,了解集群的组成方式,这样的话,就能很清晰地了解到集群的扩展方式和性能调优点 。
从横向来讲,需要进一步了解多种组件的整合方式,比如系统如何同日志组件整合,大数据分析工具如何同日志组件整合等 。
剩下的就是不断积累经验技能了 。
5 在升级路上,如何避免一些坑
我在平时还有机会接触一些大神,这些其实都是大神们的经验之谈 。下面分享下在升级过程中应当避免哪些坑 。
1 就像大家以前准备政治考试时,先准备大点,在保证大点不拉下的基础上,再详细复习每个大点里的细节 。比如,可以先了解Spring Cloud里有哪些组件,比如Ribbon可以用来负载均衡,Hystrix可以用来容错等,先把Spring Cloud里诸多组件先了解个大概,能用它们搭建成一个微服务体系后,再深入了解其中每个组件的细节,比如Spring Cloud Stream里Kafka配置细节 。
但我经过和多位架构师沟通,他们在升级时,多少都在这方面走过弯路,我自己有时候也会不知不觉陷入技术细节之中,而忘记我学这个技术的初衷 。这里给大家的建议是,在明确学习目标后(比如要学Spring Cloud),刚开始别先自己闭门造车地为自己制定学习目标,可以先借鉴现有的视频讲解等的学习路线 。制定学习计划时,以两到三天为单位,给自己定好一个短期目标,等到Spring Cloud组件全都了解后,再通过运行通若干个案例来深入了解组件的细节,这样就能控制住自己的学习步骤 。
2 千万别理论和实际脱节 。这似乎是废话,但我见过很多高级开发,平时就看视频和书,也不运行代码,结果进步的速度很慢 。
【架构师的技术升级之路】如果没机会实践架构技能怎么办?看自己组里有没有架构的活 。如果也没有怎么办?(别嫌我啰嗦)回家自己准备环境,按视频里的搭建架构环境 。必要时,你甚至可以通过跳槽来换得一个架构师的实践机会 。
3 架构师可以是技术控,但绝不能是完美主义,毕竟解决方案得和实际业务切合,并得考虑解决问题的成本 。而且,架构师不能过于拘泥于细节,不能什么都事必躬亲,很多时候,得给出方向,或者把问题拆分成开发能理解的子问题,然后让手下人去干 。这似乎和技术没有关系,这就要求架构师更具备和人打交道的能力了,这点将在本文的第6部分详细说明 。
6 指导技术难于自己实现功能,再论资深架构的协调(或者说扯皮)能力的炼成
不少开发者,尤其是资深开发者,或许都有这样的体会,对于一些功能,我宁可自己做,而不是把它们拆分成若干个子功能再安排手下人去做 。或者我宁可去攻克一些技术的难题,也不愿意去和人扯皮,从而去制定架构里组件的选型方案 。

架构师的技术升级之路

文章插图
 
可以这样说,架构师30%的价值来自他拥有的专业技能,30%的价值来自他分析和解决问题的能力,而40%的价值(甚至更高)来自于指导和协调能力 。除去最后40%的价值,架构师其实和高级开发没什么差别 。比如通过下面的例子,我们能看到架构师为什么还得具备指导和协调的能力 。
案例1:当架构师被要求改善本公司系统(比如是个应用网站)的调用性能时,他就得和多个组打交道,往往是,有些组未必肯支持(毕竟现有系统用得不错谁都不愿改),或者具体的改善点需要一些组来落实,这就相当于增加该组的工作量了 。
案例2:当架构师搭建好一套分布式缓存系统后,就得培训其它组的开发人员,让他们合理使用这套系统 。
案例3:又如架构师帮一个组解决了一个典型的OOM问题后,得把解决这个问题的思路向其他组推广,以便节省解决同类问题的时间 。
从上述案例中,我们一定能感受到在沟通,协调方面架构师需要掌握的技能水准 。这方面说难不难,多练就行,但对IT开发而言,动嘴要比动手写代码要难 。下面也给出些提升“动嘴”能力的技巧 。


推荐阅读