Java架构师的升级之路

最新推荐文章于 2024-07-12 14:44:15 发布

2401_84046816

最新推荐文章于 2024-07-12 14:44:15 发布

阅读量225

点赞数 4

分类专栏：程序员文章标签： java 开发语言

本文链接：https://blog.csdn.net/2401_84046816/article/details/138901177

版权

程序员专栏收录该内容

464 篇文章 0 订阅

订阅专栏

问题四，D公司需要在linux上搭建一套和产线一样的测试环境，在平时的开发过程中，各业务组可以通过工具，在测试环境上部署或回退本项目的组件，这里，不仅要搭建测试环境，更要通过jenkins等工具给各业务组搭建一套能便捷部署系统的工具。

除了上述的问题之外，资深架构更像一个救火队员，比如在公司的业务体系里，任何一个团队报出的和架构相关的问题，比如调消息队列有延迟，调分库分表时报内存OOM异常了，或者因Dubbo底层而导致的延迟或OOM，资深架构得能亲自或带领手下解决具体的问题。

三、和高级开发相比，资深架构一定得精通的技能（或素质）

其实高级开发和资深架构在需要掌握的技能方面，并没太大的差别，具体而言，能帮助实现性能优化的分布式组件和数据库组件（或者叫中间件）也就这么多，linux下的操作命令也就这么些，一些系统管理的工具，比如Maven，Jenkins，ant等的用法也不难。但和高级开发相比，资深架构的差别在于如下几点。

①. 资深架构解决的问题种类和数量要比高级开发多很多，所谓神枪手得靠子弹喂出来，有些问题，比如针对Kafka消息中间件的问题，资深架构一看日志就知道该怎么改，或者一看log4j错误信息就知道和其它哪些类有冲突了，又如，在搭建线程池时遇到了OOM问题，资深架构估计也能通过简单地看日志，也能快速定位问题所在。也就是说，资深架构已经积累了很多处理问题的经验，遇到一般问题时，无需再通过比较耗时的debug看问题根源，往往在脑子里已经存储了大量可能会导致问题的原因，再通过查看关键日志即可定位到具体的代码点，然后就能很快地给出解决方案。

②. 在给出解决方案时，比如要上个分布式redis集群，或者上个消息中间件，对高级开发而言，往往会有很多试错的时间，比如上线后有某些功能点没调通，得通过Debug或查日志来逐一解决问题，或上线某个基于python的大数据分析系统后，虽然能满足基本的功能，但在某个场景（比如写日志线程并发量太多）里，可能会导致OOM异常。而对资深架构来说，往往之前已经做过同类事情，所以能避免很多坑（少了很多试错成本和时间），而且由于对底层代码比较熟悉，所以哪怕出现比较疑难的问题（比如不能稳定重现），资深架构能通过看日志很快定位到具体的底层类，（而高级开发一般对此就束手无策了）。相比之下，资深架构的中流砥柱效应就能体现出来。

③. 资深架构一般具有对各组件的差别非常了解，比如做分布式队列，该先用Kafka还是rabbitMQ，或者搭建数据库集群时，该用MySQL里的哪种引擎。这样，在选型时，由于知道了各种方案的优缺点，所以能知道哪类方案更适合本业务系统，或者说，通过重写哪类组件的底层代码，能很快地搭建起满足本系统的中间件组件。这点，高级开发未必能做到。

总结一下，资深架构得对关键组件的底层非常了解，并且精通针对某些组件（比如消息组件，分库组件）的实施和排查问题的能力，此外，资深架构的基本功也得非常扎实。

①. debug能力就不用说了，得能熟练地通过linux命令，从各类日志中发现并解决问题。

②. 无需了解所有组件的底层代码（这太难了，也做不到），但需要了解一些常用组件的关键底层实现（比如Spring IOC或常用中间件）方式，更得具备到组件内部jar里debug排查问题的能力。

③. 学习能力更不说了，和高级开发相比，资深架构更得了解哪类组件该学，而且，每个组件内部的知识太多，比如Kafka的知识就能写至少一本书，对于资深架构而言，首先需要用较短的时间了解该组件（比如kafka）的架构以及和其它分布式组件（比如Flume）的整合方式，而且还得具备过滤知识的能力，即知道哪些知识不用学。这样一旦有需求，就可以较快地搭建出系统原型骨架，随后再逐步完善功能效果。

四、对于程序员而言，如何高效地升级到架构或资深架构？

当我还处在一般开发和高级开发的中间水平时，我认为我能很快地升级到架构师的水平，所谓无知者无畏。当我迈出升级的步伐时，刚开始，我突然发现升级的难度很大，从而无处下手，因为平时我缺乏实践架构师技能的实战机会。现在，通过一些努力，我虽然没有自信说自己一定达到了架构师的水平，但大多数架构师能干的活，我勉强能做好。而且我平时也在不断揣摩身边技术架构的思考方式和解决问题的方法，所以在这方面我自认为给出的建议不会耽误大家。

首先是巩固自己基本功方面的建议。

①. 学再多的视频和材料，也不及动手实践一个案例。

比如，大家在学习消息队列时，一定得动手搭建个环境，最好用虚拟机模式分布式的场景，这时可能就有同学说了，环境太难搭建，怎么办？自己查资料，这种动手能力对架构师而言就属于基本功，如果这也做不好，那么也没希望升级到架构师了。

类似这样，大家可列个学习列表，网上升级到架构师的系列视频很多，质量高的也不少，都是别人的经验之谈，但如果就看理论，或者看关键点，这连架构师的面试都通过不了，更何况做实际的架构师的活。

②. 平时不能畏难，一定得多解决问题。

在平时工作中，一定会出很多问题，而且不少是出在核心代码和底层代码里，这时就一定得通过看日志等方式去排查问题。我知道，对很多想升级的高级开发而言，刚开始的时候一定很难，比如linux命令都不熟，或者效率很慢，别人都找出问题点了，自己才刚打开日志。其实大家都这样过来的，多查多练，最多三个月，动手能力一定能提升。

③. 得锻炼自己在linux里（或在分布式环境里）部署系统部署组件的能力，尤其是部署集群的能力，在此基础上，通过各种工具能进行压力测试。

比如还是拿kafka来说，搭建好集群后，就可以用kafka自带的Performance来做压测。其实如果是自己练习，压测的结果没太大的意义，但这个流程走下来，一定能对搭建环境，使用工具和看日志等技巧就非常熟悉了。

④. 尽量培养自己的调优意识。说这个话很虚，具体而言，自己得能通过各种数据库日志（比如各sql的运行时间）来找出长sql，并在此基础上通过执行计划来优化，又如，可以通过dump文件和GC日志来看虚拟机的内存使用曲线，看内存主要耗在哪些方面，如果是自己代码没写好那还好办，如果是耗在（中间件的）底层jar包里的代码里，那也得知道解决方案。

以上只是架构师所需要的基础技能，其实如果能真正做到上述4点的话，大家离开架构师的水准也不远了，在此基础上，大家还得继续锻炼整合的能力。

从纵向来讲，需要进一步深化搭建集群的技能，比如能从底层代码的角度，了解集群的组成方式，这样的话，就能很清晰地了解到集群的扩展方式和性能调优点。

从横向来讲，需要进一步了解多种组件的整合方式，比如系统如何同日志组件整合，大数据分析工具如何同日志组件整合等。

剩下的就是不断积累经验技能了。

五、在升级路上，如何避免一些坑

我在平时还有机会接触一些大神，这些其实都是大神们的经验之谈。下面分享下在升级过程中应当避免哪些坑。

①. 就像大家以前准备政治考试时，先准备大点，在保证大点不拉下的基础上，再详细复习每个大点里的细节。比如，可以先了解Spring Cloud里有哪些组件，比如Ribbon可以用来负载均衡，Hystrix可以用来容错等，先把Spring Cloud里诸多组件先了解个大概，能用它们搭建成一个微服务体系后，再深入了解其中每个组件的细节，比如Spring Cloud Stream里Kafka配置细节。但我经过和多位架构师沟通，他们在升级时，多少都在这方面走过弯路，我自己有时候也会不知不觉陷入技术细节之中，而忘记我学这个技术的初衷。这里给大家的建议是，在明确学习目标后（比如要学Spring Cloud），刚开始别先自己闭门造车地为自己制定学习目标，可以先借鉴现有的视频讲解等的学习路线。制定学习计划时，以两到三天为单位，给自己定好一个短期目标，等到Spring Cloud组件全都了解后，再通过运行通若干个案例来深入了解组件的细节，这样就能控制住自己的学习步骤。

②. 千万别理论和实际脱节。这似乎是废话，但我见过很多高级开发，平时就看视频和书，也不运行代码，结果进步的速度很慢。如果没机会实践架构技能怎么办？看自己组里有没有架构的活。如果也没有怎么办？（别嫌我啰嗦）回家自己准备环境，按视频里的搭建架构环境。必要时，你甚至可以通过跳槽来换得一个架构师的实践机会。

③. 架构师可以是技术控，但绝不能是完美主义，毕竟解决方案得和实际业务切合，并得考虑解决问题的成本。而且，架构师不能过于拘泥于细节，不能什么都事必躬亲，很多时候，得给出方向，或者把问题拆分成开发能理解的子问题，然后让手下人去干。这似乎和技术没有关系，这就要求架构师更具备和人打交道的能力了，这点将在本文的第6部分详细说明。

六、指导技术难于自己实现功能，再论资深架构的协调（或者说扯皮）能力的炼成

不少开发者，尤其是资深开发者，或许都有这样的体会，对于一些功能，我宁可自己做，而不是把它们拆分成若干个子功能再安排手下人去做。或者我宁可去攻克一些技术的难题，也不愿意去和人扯皮，从而去制定架构里组件的选型方案。

可以这样说，架构师30%的价值来自他拥有的专业技能，30%的价值来自他分析和解决问题的能力，而40%的价值（甚至更高）来自于指导和协调能力。除去最后40%的价值，架构师其实和高级开发没什么差别。比如通过下面的例子，我们能看到架构师为什么还得具备指导和协调的能力。

案例1：当架构师被要求改善本公司系统（比如是个应用网站）的调用性能时，他就得和多个组打交道，往往是，有些组未必肯支持（毕竟现有系统用得不错谁都不愿改），或者具体的改善点需要一些组来落实，这就相当于增加该组的工作量了。