为什么 90% 的“码农”做不了软件“架构师”?

用户头像
Java架构师迁哥
关注
发布于: 2020 年 09 月 29 日
为什么90%的“码农”做不了软件“架构师”?

写代码和做架构是两个不同的事情。



什么是架构师,架构师要做什么事情,为什么Java的领域里,会更注重架构师?



很早很早之前,我对于架构的概念一点都不理解,依稀记得,架构( architecture)这个词,来自于建筑领域。



这对于我这个没写过几行代码的人来说,瞬间就有了一种“不明觉厉”的崇拜感。



架构,感觉好厉害的样子,从名称上来说,好像是设计根骨,设计底层,设计最核心的东西的人。



架构师,一定很NB,我什么时候能成为架构师呢?



后来懂了一点点代码,去写增删改查,更是体会不出来架构的概念,不就是Sql语句吗?明明DBA更厉害啊,做各种的慢Sql优化,所有的Sql都要让DBA审核,DBA对于Mysql,或者是Oracle的各种性能调忧很厉害,而熟悉业务的开发人员又常常能写出几万行的SQL语句。



我看到这些头都要炸了好么?



什么是架构



所以,倒底什么是架构?整个系统只有一个WEB,Spring MVC+Spring+Hibernate搞定一切,开始做需求分析,实际上就是设计表结构而已,剩下的就是查查查,改改改,删删删。



直到某天,我知道一个词,缓存。



缓存这玩意儿,在很早之前学习各种基础课程的时候,了解过一些,一级缓存,二级缓存什么的,LRU我好像也懂一点点,但是,在系统里,缓存算是什么?



在公司里,那个架构师,画了一张图,告诉我们,这台机器上,放了一个Memcache,然而我们都不懂,他只解释了一句,这个Memcache是缓存。



我的第一个困惑就是,所有的请求都要再次转发到另一台机器上,把数据取出来,单个请求可能不算什么,每天有几十万次请求,这中间的损耗不大么,为什么不把Memcache放到本地机器上呢?



他没解释,只告诉我说,不大,Memcache就是要放在另一台机器。



在当时,我不清楚内网和外网的差别,也不清楚访问Memcache的请求倒底是需要多少MS,更不理解,把Memcache放在和业务层一台机器,或者是分开放的差别倒底是什么。



但这个问题一直困惑着我,简单来说,这其实算是一点点架构师要做的事情的萌芽,一个系统中,如果拆解出来了很多模块,倒底应该部署在哪些机器上?架构师会解决这些问题。



后来,到了搜狐之后,我突然间发现了我之前学到的东西,在搜狐的技术大神面前,直接被轰成渣。



负载均衡是什么?热备又是什么?



穿透DB是什么意思?怎么我取数据库里取一个值,数据库里没有,这种空数据的请求会把DB打跨?我还要把这些为Null的请求单独缓存起来?



本地缓存做为一级缓存,Memcache做二级缓存?



“对缓存来说,最关键的设计就在于失效策略是什么。”大神镇定的看着我。



我很惶恐,感觉能把失效策略设计出来,很不容易。



不同的应用场景,对于缓存的要求不一样,对实时性的要求也不一样。榜单这种一天更新一次的,每天晚上定时生成一次就好了。后台更新,但是要注意,一定要直接生成,直接切换,不能让前端用户访问的时候,再去生成。



对于名字这种东西,用户改完之后,必须立刻更新缓存,包括本地缓存和远程缓存。



这算不算架构中的一部分,根据不同的应用需要,去设计不同的策略,同时把这些场景规范化,成为一整个团队都要去遵循的标准?



我不知道,我只知道,能Hold住团队里所有人的那个人,技术一定非常NB,团队里的每一个人,都会质疑,如果你Hold不住全场,怎么能推行下去?



当时近30的技术团队里,每一个都是神一样的存在啊,谁能Hold住30多个神。



而且,原来不应该把所有的代码放到一个WEB里,原来分布式是这么回事儿,原来一个系统,是由多个子系统构成的,原来还要分层,原来封装和抽象是这么个意思。



WEB层是一层,通常可以通过LVS部署两台到三台,或者是更多的,Service一层用来处理业务逻辑,缓存层用来扛并发,一定要藏在Service里面,Controller调用Service的时候,并不需要知道,数据倒底从哪来的,每一个Service使用什么样的缓存策略,完全不需要Controller层知道,持久化,对,对于大型应用来讲,Mysql只能用做是持久化,Mysql的单条访问速度并不查,只是在并发能力太差,扛不住。但是,有可能数据量过亿啊?



过亿怎么办?是用分库,还是分表?读写分离要不要做?一台服务挂一台数据库,哪些数据库应该放在一个实例里,哪些应该单独拆出去?每台服务器的配置是什么?



我大概知道一点点,架构师要做哪些事情,他就是要把这些大的骨架定好,然后我们去填充里面的内容。如果骨架定歪了,其余团队必然跟着歪。



这时候有了一系列的问题,第一个,Controller和Service之间,Service和Service之间,应该通过什么调用?



RMI,这是惟一的选择。用thrift,或者是ProtocolBuffer,或者是Rest实现的RPC?



这是架构师要考虑的事情,如果是用RMI,我们是要自己实现,还是要找找是否有好用的开源的框架,在其他的系统里被证明了是有用的?



大神们花了两周的时间,对当时流行的开源框架过了一遍,最终选定了Tuscany,到现在我都觉得设计精美,完暴Dubbo的东西,真的是一点都不想切到Dubbo上去,毕竟“曾经沧海难为水,除却巫山不是云”。



直到最近几年微服务兴起的时候,我还是同样的目瞪口呆,这跟2009年搜狐当时做白社会的架构比起来,优势倒底在哪里?差别好像没有那么大啊,而且Tuscany实现的更完美,只是使用的时候要有更强的约束,因为Tuscany太强大了~强大到有一点点重,必须要做简化,而且,Tuscany的开发团队不怎么维护了,白社会当时做的东西,还是大神花了两周的业余时间写了一个Scallop,增加了Tuscany的负载均衡的功能。



但是,倒底用什么,不用什么呢?除了Tuscany,还讨论过要不要用Hadoop,要不要用ActiveMQ,要不要用Erlang。



每一个技术框架的选择,都经过讨论,验证,测试,最终在全团队里推行。



架构师需要的能力



这是否也是架构师的职责?这个架构师太厉害了,他需要从前到后都要懂,他需要制定关键的技术细节,他需要给出最佳实践,他需要了解业界所有流行的解决方案,他需要去猜测Facebook怎么解决问题的,Twitter怎么解决问题的,Google怎么解决问题的,这些解决方案可不可以拿过来,也同样适用于我们自己的场景。



他需要精通分布式,Nginx或者是F5,微服务,缓存,持久化,消息队列,他需要熟悉所有这些技术细节里的最常用的解决方案,不能有遗漏,也不可以过度设计,他决定的不是他一个人喜欢的风格,他决定的就是整个团队,在项目死亡之前都必须遵循的规范,现在的团队成员,和未来的团队成员,都必须遵循的体系,而且,如果在未来,这些架构体系有不合理的地方,那就麻烦大了。



这样的架构师,还要肩负着一个重大的使命,修复开源软件的Bug。



在很早之前,我一直误以为开源软件是很厉害的很NB的东西,我一直以为这是完美的,很久很久之后,才明白,所谓的完美,都是用血和泪塑造而来的。



不经过各种各样的验证,环境,使用的测试,很难达到一个上线标准的稳定,即便是上线了,也有可能会出现之前完全预料不到的问题。



可是,如果你选择了这个框架,出了问题,谁去解决?



架构师,他要开源码,理解这些开源框架的思路,然后去找有可能产生问题的地方,再去修复他。



我一直都觉得,能看懂别人写的代码的人,都是神。



某段时间我去看一个heritrix,看的我神清气爽,各种层出不穷的继承,各种抽象类,连着三天我欲仙欲死,更加坚定了我死也不要,也不允许其他人在项目里使用继承的决心。



但是Heritrix从外表看起来特别牛,他的抓取策略也很NB,用的分布式抓取的解决方案非常轻巧。可是我我实在是不想再去读一次了,在当时不读不行,资料太少。



那么,一个架构师,要对这些源码都了解么?又或者是,他必须具备,需要他去读源码,他就必须读源码,而且去优化的能力?这大概比提前懂源码,更神奇。



因为是有时间要求的啊,简单来讲,他需要在一个有效的时间内,去弄懂所有的底层的东西,说句实在话,当有同事嘲笑我都没有完整的看过TCP/IP协议详解的时候,我真的是无话可说的。



对于特别底层的东西,我确实了解的不够多,可是架构师们不一样。



有了这些,就可以称之为架构师了么?



架构师需要懂业务么?是不是就可以每天看技术,写底层框架(比如我们原来在搜狐用到的DAL,数据访问层,用起来简直是神器的东西)。



没有不懂业务的架构师,所有的架构,都依赖于业务。所有的架构师,也必须要去写业务代码,不把自己设计的东西,用在真正的项目里,恐怕他们自己都不会知道,这种架构设计的合理性在哪里。



在某团购公司上市之前,他们的CTO拿出来了他们的架构图给我看,在给我看之前,所有的技术术语都一样,但是当我认真看了架构图之后,我的困惑。。。。



为什么Memcache要放在Controller层被调用? 不应该是放到Service层吗?



怎么会出现你说的,一个Serivce负责维护的数据,也有可能被另外的Service去更改的情况?每一个Service对数据的操作,必须是独立的啊,除了这个Service,其他的任何服务都决不允许直接更改DB啊。



而且,怎么Service拆分了,DB不拆分呢?这样的话,压力大的DB会把全站拖跨的啊。



那张架构图我看到之后,感觉自己的认知被突破了,原来可以这么做,原来同样的,类似的技术选型,可以做出来如此艰难的东西?



就在我以为这其实就差不多是架构师的全部的时候。



在最近一段时间,我突然间发现了一个问题。



为什么有的人代码写的这么烂,很多写死的代码,一点儿灵活性都没有,更没有规范,完全就是堆压。



为什么有的人根本不知道怎么去抽象,并不清楚怎么样积累成公共组件,为什么他们改一个问题,通常会引出更多的问题?



为什么他们的代码里的实现方案,让人看完之后恨的牙痒痒,想改又完全不能改,毕竟,正常工作的代码才是好代码?



很大程度上是因为,很多程序员,不懂的代码的扩展性,不会面向未来编程。



怎么叫做面向未来编程?



一个好的工程师,在听到需求的时候,可以根据自己的业务能力,判断出来这些需求中,哪些是有可能变化的,哪些是不太可能变化的。



针对这些变化的内容,在编写的过程中,不会写死,而反复确认不可能会变化的需求,会写的简单一些,防止过度设计引起的复杂度。



简单说,当他拿到需求时,并不单纯是考虑这个需求怎么实现,还会考虑,自己设计的架构体系,扩展性在哪里,在他的眼里,看到的需求会被分解,折分,然后自己的技术方案,会挨个分解,分配。



在完成设计之后,他会很清楚的知道 ,自己设计的系统里,哪些变化是支持的,随便你改,我只需要改动一个很简单的内容,哪些是你绝对不能改的,你要改,我就必须花很大的代价,特别是在已经有线上数据的时候。



而且会拿着自己的架构体系跟PM沟通,讲清楚。



什么样的变化是支持的?短信通道是有可能变化的,而调用短信通道的地方可能会有点多,所以我必须把短信通道抽象,并封装在一个公共接口,如果需要更换短信通道,我可能只需要更改一个配置文件就好了。



那么什么样的变化是不支持的?我不需要不停机就更换短信通道的功能,除非你在后台系统中提前配置好,或者是有明确的需要,我做出这么一个东西出来。往往在前期,不会用到。



为什么?



在创业初期,短信通道往往用于用户注册,一旦出问题,就是生死问题,必须要有一个备份,运营商一怒封掉你的通道,很常见。



而重启一次服务,在创业前期,往往没有那么严重。



所以,这些技能,是不是也应该归纳到架构师的职责里去?



架构师从开始就要考虑选型,从语言开始,从业务开始,要对这个领域里的开源框架熟悉,了解,要能解决疑难问题,要懂安全,要会备份,要学会面向未来编程,还需要什么?



还需要DevOPS.



在持续集成的年代,在服务器规模越来越大,在云服务器的年代,在异地存储,冗灾,在全球化越来越快的年代。



运维的重要性已经到了一个很核心的程度了。弹性伸缩,自动扩容,灰度发布等等等概念,要求,都在冲击着架构师这个概念的定义。



如果说之前的架构师,更多的是在系统开发前,现在越来越偏于系统上线后。



还包括数据分析,日志分析,等等等等,对了,还没有提到Nosql DB,实时搜索,知识库,算法这一系列的东西。



每一个领域都在细分,每一个概念都在深化。



简单说,架构师确实和语言无关,但是又绝对和语言有关系。



你可以说,架构师就是在做选型,但是只会做选型,肯定做不出架构师。



Java更需要架构师,因为他本身就是各种开源框架,不对这些框架了解的清清楚楚,你很难做出一个好的选择,而一旦架构被固定,实际业务人员的开发,又会变的简单很多。



说到了现在,我有没有讲清楚架构师是什么?



而你,还想要做架构师吗。



反正,我说自己是架构师的时候,我的内心是羞耻的,我知道 ,我远远没达到架构师的能力。






架构师成长路线



然后,我曾整理过一个中级工程师的发展路线。



一 :科班基础



1.计算机组成原理 



2.计算机操作系统 



3.计算机网络



4.数据结构 



5.数据库



6.算法



推荐阅读这份大牛整理的《程序员必知的硬核知识大全》





二 :语言相关



1.JDk



1.1 JDK



1.2 线程



1.3 Set



1.4 Hash



1.5 GC



1.6 ClassLoader



1.7 lambda



推荐阅读这份《Java JDK学习笔记》





三 :Spring



1.IOC



2.Spring



3.Spring MVC



4.Spring Boot



5.Shrio



初学Spring建议看视频,推荐这套《Spring源码100集》





四 :数据库



1.Mysql 基础



2.DB设计



3.DB调优



4.Mysql 底层架构



5.idcenter



6.常用工具



7.索引



推荐阅读两本书籍



  1. 第一本是MySQL经典著作《高性能MySQL(第3版)》;

  2. 第二本一位大牛的笔记《MySQL性能调优与架构设计》;







五 :架构



1.设计模式



2.缓存



3.分布式



4.Key-Value



5.消息队列



6.定时任务



7.微服务



8.RPC



9.高并发



10.性能优化



设计模式建议去实战,通过实战去理解,可以看下面这一套视频:





六: 项目规范



1.接口定义



2.日志规范



3.编码规范



4.最佳实践



推荐阅读《阿里巴巴开发手册》





七 :运维



1.Linux常用命令



2.JVM常用工具



3.Nginx



4.Resin



5.LVS



6.Iptables



7.Jenkins



8.Ansible



9.容器:dock



10.监控



11.CICD



运维这一块本人并没有过深的去研究,只对这一份Linux手册爱不释手,此本笔记共1051页,不管是入门学习,还是当个工具书都是个不错的选择





八 :常用算法



1.一致性哈希



2.gossip



3.paxos



4.Spotsig



5.https



6.MD5



7.auth2



8. Bloom Filte



9.编辑距离



10.TrieTree



11.rete



推荐阅读这本《算法乐趣》本书包含了大量的算法真题与思路解析,对于学习算法很有帮助;



九 :源码解析



1.Spring



2.Redis



3.memcache



4.Mybatis



5.Log4j



6.Maven



7.Git



推荐同上



十: 开发流程



1.敏捷开发



十一 :场景解决方案



1.金融



2.支付



3.电商



4.直播



5.教育



6.O2O



7.分销



8.会员



9.活动



10.秒杀



Git网站上面有很多已经开源的优秀项目,在筛选了近百个项目之后推荐下面这六个优质商城项目;





十二: 思维方式



1.自顶而下



2.分层模式



3.抽象



4.落地



5.推测



6.验证



7.组件



8.定制



9.生成






最后再说一下,为什么很多程序员做不了架构师。



1 是刚开始就么有奔着这个目标去,好比是动作变形,反而不好纠正了。



2 是思维没能提升一个台阶,只局限于具体的编码,没有考虑过选型,复用,扩展。



3 是身边没有架构师的引导和培养,环境问题是一个很大的问题。



虽然我个人也经常自嘲,十年之后要去成为外卖专员,但实际上依靠自身的努力,是能够减少三十五岁之后的焦虑的,毕竟好的架构师并不多。



架构师,是我们大部分技术人的职业目标,一名好的架构师来源于机遇(公司)、个人努力(吃得苦、肯钻研)、天分(真的热爱)的三者协作的结果,实践+机遇+努力才能助你成为优秀的架构师。



如果你也想成为一名好的架构师,那或许以上这份学习路线与资料你需要阅读阅读,希望能够对你的职业发展有所帮助。



也希望大家能够通过本文提升自己的技术深度和广度,好适应未来社会的发展,不断地走出一条属于自己的人生道路!

写在最后

上述资料都已经整理完毕了,需要的朋友可以关注公众号【Java斗帝】获取

看完三件事❤️

如果你觉得这篇内容对你还蛮有帮助,我想邀请你帮我三个小忙:

  1. 点赞,转发,有你们的 『点赞和评论』,才是我创造的动力。

  2. 关注公众号 『 Java斗帝 』,不定期分享原创知识。

  3. 同时可以期待后续文章ing🚀



用户头像

还未添加个人签名 2020.09.07 加入

还未添加个人简介

评论

发布
暂无评论
为什么90%的“码农”做不了软件“架构师”?