90%的程序员,都没用过多线程和锁,怎么成为架构师?


作者:小傅哥
博客:https://bugstack.cn
Github:https://github.com/fuzhengwei/CodeGuide/wiki

沉淀、分享、成长,让自己和他人都能有所收获!

一、前言

你只面向工作学习吗?

如果说编程只是单纯的承接产品需求开发系统功能,那么基本可以把程序开发简单理解成按照需求PRD,定义属性创建方法调用展示,这三个步骤。

尤其是在一些大公司中,会有易用的、完善的、标准的架构体系和运维服务,例如:RPC、MQ、Redis集群、分布式任务、配置中心、分库分表组件、网关等搭配出来的系统架构。也因此让程序员做到只关心业务功能开发

让程序员只关心业务开发,有成熟的系统架构、有标准的开发流程、有通用的功能设计,对于团队效能提升来说是非常好的事。但一部分程序员正因为有这样的好事,让日复一日的岁月做着同样的事,最后成为工具人。

如果是框架和中间件的存在,是了让程序员只关心业务开发。那为什么你面试的时候会被问到核心组件的设计和原理呢? 在这个年代,别放弃学习是你几乎唯一的生存途径。

二、多线程和锁没用过?

面试必问的多线程,甚至可能问的还挺深入,比如:AQS、CAS、CLH、MCS、锁升级、对象头等等。但在实际的业务开发中,你用到了吗?可能这也是大部分同学说,面试造火箭的地方!

互联网应用中有些业务场景开发,确实很少能用到多线程,也几乎不需要你去加锁。即使你能用到多线程的地方也可以用其他更好的方式处理,就像你需要多个线程把数据落库,那么就可以使用异步MQ的方式,把压力分散到各个应用实例上去。而这一开发方式的演变,是因为现在的应用开发和部署都是基于分布式的思想,所以也就很少会有非得用线程来压榨单实例CPU。

在基于RPC+MQ+数据库路由+网关,以及各类配合的组件下,构建出的分布式应用,在某些时候是改变了我们的开发模式的。可能原来我们需要大量使用多线程在单个实例下的开发思路,在使用分布式架构后,就需要转变这一思想,所以随时而来的使用多线程和锁的场景也会减少。

图 14-1 分布式简化的应用部署

图 14-1 分布式简化的应用部署

,也不是就没有多线程和锁的业务场景,就比如我们的核心组件中,数据库连接池、分布式任务中,都会涉及到多线程和锁的使用。也有一些类似商品秒杀的场景,同样需要使用到锁。

那么,使用多线程为了更大限度的利用资源提升效率,加锁是为了在同一个资源有竞争的情况保证业务流程的正确性。就像:数据库连接池为了合理分配数据库资源、商品秒杀是为了库存的竞争。

可是,在没有需要竞争和分配资源的情况下,一般并不会在分布式场景下使用到多线程。假如我们做一个用户资源单次计数的操作,那么原来的应用是单实例还是可以加锁累加计数的。但现在是分布式应用部署,也就是你可能这一时刻是A实例提供你的需求,当你再次刷新页面后可能访问到的就是B实例。这时候在想做一些实例上的累加,就没那么方便了。

这也就是在分布式应用框架的应用中,让你能用到多线程和锁的地方并不多的原因。但如果你有需要去了解一些中间件或者核心组件的设计时,就需要了解相关的核心知识。

很多纸上谈兵的技术,也就是你造轮子、造火箭、成为架构师的根基! 如果你还想奔着这条路能走的更远,就需要继续学习。

三、你的成长阶段目标?

图 14-2 你的成长阶段

就编程开发这条道路而言,每一个成长阶段的目标都会有它随着带来的难以攻克的

  • 上学阶段,对突如其来的奇怪知识,想把它在自己电脑运行起来,就很难。
  • 工作1~3年,以前掌握的都是毛皮,接下来需要有深度的学习,而深入后都将与数学硬碰硬。
  • 工作3~5年,看以前理论性的知识也没那么难,但怎么实际要解决一些复杂项目,还是专心脑干。
  • 工作5~7年,薪资与职位都会成为这个阶段非常难以突破的瓶颈,积累不足、沉淀不够,现状不满!
  • 工作7~10年,以前觉得什么都难学,现在可能让你有空闲时间都难。并不一定年龄到了,本事就到了。

随着年龄的增长,每一阶段都有难以跨越的难。而那些看上去突破了瓶颈,达到了你想要的高度的人。其实每一个阶段,他们都跑在前面。

但就单纯的技术成长而言,其实理论知识并不难,只要你学就还能会,只是付出的时间成本不同罢了。但过了理论知识这一关后,接下来要面对的是创造能力,也就是为什么你感觉自己会了那么多技术内容,但是实际开发时却总感觉写不出好代码的阶段。

会了核心技术但又写不出好代码,就很像是:会汉字但写不出诗词歌赋懂色彩但绘不出山河大川能蹦跳但舞不出摇曳生姿

所以,多实战一些项目代码,多看一些设计模式,会让你更好的理解代码该怎么用,也就能提升突破当前的阶段屏障。推荐小傅哥的《重学Java设计模式》,公众号:bugstack虫洞栈,回复:设计模式,下载。

四、怎么成长为架构师?

图 14-3 架构师知识体系

讲到架构师,其实真的挺难因为报名一个课程学习完就能成为架构师。架构师的成长更多的取决你们的研发组是否需要一个架构师,也同时需要你在这个岗位起到应有的作用。

如果你还不是架构师,但想成为架构师。那么还取决于你的老板是否愿意把你培养成架构师,以及你自己的多方面能力是否具备。另外,并不一定高级开发就低于架构师。高级开发有时候比架构师做的事更专一、更核心。

那么除了图 14-3 对于架构师的能力概况,有哪些具体的事项呢?

  1. 定得了规范、设计了架构。
  2. 有一定的技术深入和广度,改的了bug、处理得了事故。
  3. 带了了小组推进项目落地,也能协同其他组配合。
  4. 了解运营和业务规划,提前介入产品开发阶段。
  5. 懂得了业务和运营,了解数据指标和各项ROI。
  6. 架构更多的是经验和经历的结合,而不是一个单项内容的单一渠道。
  7. 不是没有架构师就没有架构,有时候是一个公司或者小组承接的项目并没有那么大,使用成型架构模式即可。
  8. 但如果有非常复杂的场景设计,都是十几个系统的分组安排开发,提供服务,支持几万秒杀,几十万日活,在扩展到上百万DAU,就需要有架构师来把控。
  9. 再比如:从下单、到交易、到支付、到结算、到活动、到玩法、怎么支持。这个体量的复杂度才需要有架构权衡。
  10. 没有绝对的对和绝对的错,只是什么时候更适合罢了。多学一些,别给自己设定边界,才更好突围!

做好架构,远看是部门效率,近看是解决烂代码!很多时候的急,可能让整个工程烂掉。烂的越来越多,最终也会影响业务发展。那么这些烂代码都怎么来的呢?

  1. bug很多时候是接手了的烂代码或者别人的思路没有继续继承。
  2. 业务需求简单开始就写的没有扩展性,后面也不断的堆积。
  3. 没有很好的结构和命名、也从不格式化。
  4. 预期不到将来业务走向,设计不出合理的扩展性系统。
  5. 炫技大于整体规划和设计,一个新技能的引入,但缺少相应的匹配。
  6. 没有设计,功能都是流程式,需要啥就写ifelse。
  7. 总想一把梭,没关系的,心里有抱怨,部门有急功近利,不给你长时间的铺垫,没有有人带,写不出好东西。
  8. 组内缺少相应的流程规范和评审,设计评审、代码评审,也没与标杆项目可以参考。
  9. 懂几个jdk源码从不是写好代码的根本只是基本功。就像老木匠用斧子,新木匠用电锯,但做出来的东西,有的就好,有的就不好。
  10. 没有永远好的代码,如果像代码更好,就需要一直维护,一直改造。
  11. 没有业务对应的体量,不谈QPS、TPS、TP99、TP999,服务健康度,很多空谈都是耍流氓。

,来自于很多方面,而且这并不是你报名个课程就能学到的。业务、产品、研发,三方共同努力才能更好的减少烂的出现,而这些也是每一个研发都应该努力的方向,也几乎是你要成为架构师的必经之路。

五、总结

  • 写了这么多主要是想帮助那些和我一样在这条路上持续拼搏的同好,可能大家都会在这些阶段迷茫过:上学时技术怎么学、求职时简历怎么写、工作时个人怎么成长等等。所以很多时候更多的仍然是自己的克制和自己的选择!
  • 2020年这已经是12月,有疫情的开始、也有口罩带的一年、有人股票发财、也有人还不起房贷、有人急躁没目标、也有人学了不少知识。总归如何,时间很快!
  • 你用剑、我用刀、都有目标、都很风烧! 继续加油!

六、系列推荐

你可能感兴趣的:(java,后端,程序员,架构师成长之路,git)