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



什么是架构师，架构师要做什么事情，为什么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🚀