架构师有多难_什么知道

系统架构设计师，难考吗系统架构师属于软考的高级，考试肯定是有有一定的难度的，但是如果自身基础好，通过考试自然是没问题；如果自身基础较为薄弱，参加培训通过系统的学习架构的知识体系，再做相关的试题，想要通过考试也是不难的。
成为架构师，职业规划这么难么？博主28岁了，海归研究生毕业，生活无忧。所以一直觉得什么架构师，项目经理， CTO ，赢取白富美都是时间的问题。直到突然有一天被领导叫到办公室，给我倒了1杯水，认真地跟我说你现在需要去找自己喜欢的工作。。。

我突然就失业了，离职之后走在大街上，想着自己到40岁的时候应该是个什么样子，突然心底一沉，我貌似想不到什么好的结局。

后来我痛定思痛，决定用28岁的努力来弥补之前缺少的东西，那我之后的面试过程中，与朋友的交流过程中，基本上都会聊职业规划，这是我写的关于架构师的职业规划和技术栈，也是一个28岁的程序员的自我救赎之路！

都说程序员35岁之后就找不到工作了，那么35岁的程序员找不到工作了，总得找个地方埋了吧？那他们埋在哪里呢？

博主一段时间坐在HR对面，经常听到她们说的一句话："35岁的程序员，不用来面试了" 。

那么程序员到35岁到底转行了多少？

程序员年龄分布图：

图中可以看到25岁的程序员是最多的，而35的程序员是25岁程序员的十分之一不到。如果程序员不是在10年前招生比现在少10倍的话，那么恐怕一半的程序在工作到35岁之前已经转行或者死掉了。

这是一个国内的调查

也是类似的结果，程序员在达到35之前就转行了。

如果在28岁的程序员，天天都很忙，不知道忙什么，到了他们35岁会在哪里？

这是程序员的转行报告

架构师故名思义，处于一个牛逼的状态，可以说在技术界一人之下，万人之下。位置如下图所示

那我们已经知道了程序员只知道加班和努力的话，那还是要在35岁给自己找个地方给埋了。所以仅仅努力是不够的，我们来看看应该怎么努力

程序员是个高强度职业，都说自己工作太多，根本没有时间学习。这里我贴一个左耳朵耗子的文章。

09 | 答疑解惑：渴望、热情和选择

这是一个我认同的架构师技术栈
前阿里P9:架构师是如何炼成的？大家好，我是程序员菜菜。[太阳]

文章插图
相信每个程序员心中都有一个成为架构师的梦想，但梦想是美好的，道路是曲折的。
可能很多人觉得学习架构设计就像学习一门编程语言一样，先学习一下基本的语法，再研究一下细节和原理，然后实践一下就能够快速掌握。不过，真正实践之后，你会发现——架构设计的难度和复杂度要高很多。
前阿里架构师李运华（P9）在他的专栏里总结了几个架构设计相关的特性：
1. 架构设计的思维和程序设计的思维差异很大。
架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。很多程序员在转换为架构师后，很难一开始就意识到这个差异，还是按照写代码的方式去思考架构，会导致很多困惑。
2. 架构设计没有体系化的培训和训练机制。
3. 程序员对架构设计的理解存在很多误区。
例如：要成为架构师必须要有很强的技术天分；架构师必须有很强的创造力；架构设计必须要高大上才能体现架构师的能力；架构一定要具备高可用、高性能……这些似是而非的误区让很多技术人员望而生畏，还没尝试就已经放弃了。
在他的专栏《从0开始学架构》中，李运华还提到了架构设计的目的。从架构设计的历史背景，可以看到，整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。
简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。
这个结论虽然很简洁，但却是架构设计过程中需要时刻铭记在心的一条准则，为什么这样说呢？
首先，遵循这条准则能够让“新手”架构师心中有数，而不是一头雾水。
“这么多需求，从哪里开始下手进行架构设计呢？” 。“架构设计要考虑高性能、高可用、高扩展……
这么多高 XX ，全部设计完成估计要 1 个月，但老大只给了 1 周时间” 。
“业界 A 公司的架构是 X ， B 公司的方案是 Y ，两个差别比较大，该参考哪一个呢？” 。
以上类似问题，如果明确了“架构设计是为了解决软件复杂度”原则后，就很好回答。
“这么多需求，从哪里开始下手进行架构设计呢？”——通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
“架构设计要考虑高性能、高可用、高扩展……这么多高 XX ，全部设计完成估计要 1 个月，但老大只给了 1 周时间”——架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
“业界 A 公司的架构是 X ， B 公司的方案是 Y ，两个差别比较大，该参考哪一个呢？”——理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
其次，遵循这条准则能够让“老鸟”架构师有的放矢，而不是贪大求全。技术人员往往都希望自己能够做出最牛的东西，架构师也不例外，尤其是一些“老鸟”架构师，为了证明自己的技术牛，可能会陷入贪大求全的焦油坑而无法自拔。例如：“我们的系统一定要做到每秒 TPS 10 万” 。“淘宝的架构是这么做的，我们也要这么做” 。“Docker 现在很流行，我们的架构应该将 Docker 应用进来” 。
以上这些想法，如果拿“架构设计是为了解决软件复杂度”这个原则来衡量，就很容易判断。
得益于移动互联网技术的快速发展，李运华有很多的机会直接参与架构设计，这些架构背后的业务形形色色，包括社交、电商、游戏、中间件、内部运营系统；用到的技术栈差异也比较大，包括 PHP ， Java、C++ 等。
虽然每次架构设计对他来说都是一个新的挑战，但正好也提供了非常好的机会，让他亲身体验不同的架构设计。在这个过程中，他不断学习、思考、实践、总结、改进、交流，逐步形成了自己的一套架构设计方法论。有了这套方法论后，不管什么样的业务，不管什么样的技术，按照这套方法论都能够设计出优秀的架构。
从普通程序员到大厂架构师，它指明了方向，非常不错的学习资料啦！
架构师的技术升级之路
这篇文章更多的是从沟通角度分析架构师的升级之道。但我们知道，架构师更多是靠技术拿高薪。
在本文里，我将列些我见到的技术架构平时需要解决的问题，有技术的，也有沟通协调方面的，以这些实实在在的案例，来列举些技术架构需要具备的技能，以此来分析下高级开发如何更高效地升级到技术架构。好了，开场白结束，正文开始。
1 技术本身不产生价值，业务才会，论技术和业务的整合
一般会把架构分为技术架构和业务架构，这里我无意对比这两类的优劣，但我只想说，在公司里，是靠业务价值创造盈利点的，所以技术，比如消息队列，内存优化，以及分库分表数据库集群等，只有嵌入到业务里，才能通过提升业务的可扩展性或性能，从而产生价值。
上述似乎是废话，但恰恰是架构师工作的难点，大家可以想象一下，比如通过MyCat搭建个分库分表架构不难，甚至把分库分表组件通过负载均衡搭建成集群也不难，这些网上都有现成的案例。但如何要在当前的业务系统里实现分库分表，难度就不小了。具体来讲，因为业务系统里或许有冗余数据，而且有各类带join, group by等的查询语句，如何在分库分表系统里兼容这些历史问题，而且在上线新分库系统后迁移历史数据，又如，在产线切换到分库分表时，万一有问题如何回退，这些绝非是知道些Demo案例的高级开发能解决的问题。
所以在技术和业务方面，我自己的感受是（包括我见到的和听到的）：只有接触到业务了，才能用技术解决实际问题，才能更了解这个技术用起来的各类坑，像刚才提到的分库分表是这样，其它的诸如日志组件，消息队列组件都这样。通过下面部分给出的架构师平时要解决的实际问题的讲述，大家能更深刻地体会到这点。
2 资深架构师平时要解决的问题
如下的问题均是来源于实际，出于项目保密的原则，本人隐去了关键性的业务描述，但大家都能看懂，并能感受到架构师平时要解决问题的难度。
问题一， A公司有财务管理人事管理等10个左右的项目，它们在产线上，需要标准化管理，比如用同一个Maven仓库，不论功能业务如何，得用同一套配置管理服务，用同一套日志管理和分析组件，还得用同一套大数据组件来根据不同的业务维度来分析数据。
如果是重新搭建一套系统，这个难度也不小，更何况，对资深架构师的要求是，在历史项目的技术上做标准化管理，否则每个项目各管各的，维护成本大不算，不同项目间的库还很容易产生冲突。架构师要在保持业务稳定的前提下实现这点，大家可以考虑下难度。
问题二，随着B公司业务量的上升，数据库里的数据达到了T级，所以需要通过分库分表来实现优化。这本身不难，但如何在升级的过程中保持业务的稳定？不能说上个功能点，关键业务就挂了，而且，万一上线后出现问题，得提供应急的回退方案。
问题三， C公司是个创业型公司，刚开始的时候，通过SSM外加Oracle ，能满足大多数的业务需求，但随着业务量的提升，需要资深架构在短时间里实现针对高并发和大数据的方案，比如并发量高了，系统至少不能垮，而且针对每笔订单，处理可以稍作延迟，但不能丢数据。
问题四， D公司需要在linux上搭建一套和产线一样的测试环境，在平时的开发过程中，各业务组可以通过工具，在测试环境上部署或回退本项目的组件，这里，不仅要搭建测试环境，更要通过jenkins等工具给各业务组搭建一套能便捷部署系统的工具。
除了上述的问题之外，资深架构更像一个救火队员，比如在公司的业务体系里，任何一个团队报出的和架构相关的问题，比如调消息队列有延迟，调分库分表时报内存OOM异常了，或者因Dubbo底层而导致的延迟或OOM ，资深架构得能亲自或带领手下解决具体的问题。
3 和高级开发相比，资深架构一定得精通的技能（或素质）
其实高级开发和资深架构在需要掌握的技能方面，并没太大的差别，具体而言，能帮助实现性能优化的分布式组件和数据库组件（或者叫中间件）也就这么多， linux下的操作命令也就这么些，一些系统管理的工具，比如Maven ， Jenkins ， ant等的用法也不难。但和高级开发相比，资深架构的差别在于如下几点。
1 资深架构解决的问题种类和数量要比高级开发多很多，所谓神枪手得靠子弹喂出来，有些问题，比如针对Kafka消息中间件的问题，资深架构一看日志就知道该怎么改，或者一看log4j错误信息就知道和其它哪些类有冲突了，又如，在搭建线程池时遇到了OOM问题，资深架构估计也能通过简单地看日志，也能快速定位问题所在。
也就是说，资深架构已经积累了很多处理问题的经验，遇到一般问题时，无需再通过比较耗时的debug看问题根源，往往在脑子里已经存储了大量可能会导致问题的原因，再通过查看关键日志即可定位到具体的代码点，然后就能很快地给出解决方案。
2 在给出解决方案时，比如要上个分布式redis集群，或者上个消息中间件，对高级开发而言，往往会有很多试错的时间，比如上线后有某些功能点没调通，得通过Debug或查日志来逐一解决问题，或上线某个基于python的大数据分析系统后，虽然能满足基本的功能，但在某个场景（比如写日志线程并发量太多）里，可能会导致OOM异常。
而对资深架构来说，往往之前已经做过同类事情，所以能避免很多坑（少了很多试错成本和时间），而且由于对底层代码比较熟悉，所以哪怕出现比较疑难的问题（比如不能稳定重现），资深架构能通过看日志很快定位到具体的底层类，（而高级开发一般对此就束手无策了）。相比之下，资深架构的中流砥柱效应就能体现出来。
3 资深架构一般具有对各组件的差别非常了解，比如做分布式队列，该先用Kafka还是rabbitMQ ，或者搭建数据库集群时，该用MySQL里的哪种引擎。
这样，在选型时，由于知道了各种方案的优缺点，所以能知道哪类方案更适合本业务系统，或者说，通过重写哪类组件的底层代码，能很快地搭建起满足本系统的中间件组件。这点，高级开发未必能做到。
总结一下，资深架构得对关键组件的底层非常了解，并且精通针对某些组件（比如消息组件，分库组件）的实施和排查问题的能力，此外，资深架构的基本功也得非常扎实。
1 debug能力就不用说了，得能熟练地通过linux命令，从各类日志中发现并解决问题。
2 无需了解所有组件的底层代码（这太难了，也做不到），但需要了解一些常用组件的关键底层实现（比如Spring IOC或常用中间件）方式，更得具备到组件内部jar里debug排查问题的能力。
3 学习能力更不说了，和高级开发相比，资深架构更得了解哪类组件该学，而且，每个组件内部的知识太多，比如Kafka的知识就能写至少一本书，对于资深架构而言，首先需要用较短的时间了解该组件（比如kafka）的架构以及和其它分布式组件（比如Flume）的整合方式，而且还得具备过滤知识的能力，即知道哪些知识不用学。这样一旦有需求，就可以较快地搭建出系统原型骨架，随后再逐步完善功能效果。
4 对于程序员而言，如何高效地升级到架构或资深架构？
当我还处在一般开发和高级开发的中间水平时，我认为我能很快地升级到架构师的水平，所谓无知者无畏。当我迈出升级的步伐时，刚开始，我突然发现升级的难度很大，从而无处下手，因为平时我缺乏实践架构师技能的实战机会。现在，通过一些努力，我虽然没有自信说自己一定达到了架构师的水平，但大多数架构师能干的活，我勉强能做好。而且我平时也在不断揣摩身边技术架构的思考方式和解决问题的方法，所以在这方面我自认为给出的建议不会耽误大家。
首先是巩固自己基本功方面的建议。
1 学再多的视频和材料，也不及动手实践一个案例。
比如，大家在学习消息队列时，一定得动手搭建个环境，最好用虚拟机模式分布式的场景，这时可能就有同学说了，环境太难搭建，怎么办？自己查资料，这种动手能力对架构师而言就属于基本功，如果这也做不好，那么也没希望升级到架构师了。
类似这样，大家可列个学习列表，网上升级到架构师的系列视频很多，质量高的也不少，都是别人的经验之谈，但如果就看理论，或者看关键点，这连架构师的面试都通过不了，更何况做实际的架构师的活。
2 平时不能畏难，一定得多解决问题。
在平时工作中，一定会出很多问题，而且不少是出在核心代码和底层代码里，这时就一定得通过看日志等方式去排查问题。我知道，对很多想升级的高级开发而言，刚开始的时候一定很难，比如linux命令都不熟，或者效率很慢，别人都找出问题点了，自己才刚打开日志。其实大家都这样过来的，多查多练，最多三个月，动手能力一定能提升。
3 得锻炼自己在linux里（或在分布式环境里）部署系统部署组件的能力，尤其是部署集群的能力，在此基础上，通过各种工具能进行压力测试。
比如还是拿kafka来说，搭建好集群后，就可以用kafka自带的Performance来做压测。其实如果是自己练习，压测的结果没太大的意义，但这个流程走下来，一定能对搭建环境，使用工具和看日志等技巧就非常熟悉了。
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开发而言，动嘴要比动手写代码要难。下面也给出些提升“动嘴”能力的技巧。
1 首先得提升自己综合逻辑思维的能力，这点可以靠多写博客，甚至写书来提升。其实写的时候，就相当于把自己要讲的内容用文字整理了一遍，这样无形中也提升了自己综合表达能力。
2 在组内要多分享技术。其实刚开始分享时，一定不知道该说什么，甚至讲完后没人能懂（当然自己一定能懂），但多讲几次后，口头表达和与别人的交流能力也上去了。
3 在遇到和其它组交流时（比如联调或沟通接口），一定得抓住机会多开口，刚开始的时候，估计很难让别人能接受自己的观点，或者自己有理也未必能讲清楚，但经过多次协调后，就能让别人接受自己的观点，或者大家能达成彼此能接受的妥协方案。
对本文感兴趣的Java工程师的朋友们可以私信我【Java架构】进我的粉丝群领取一些架构资料电子书籍在群里也会有面试上的一些建议交流
最后一个小要求，可以帮我转发下！

为什么有人说大部分码农做不了软件架构师？从事软件开发多年，在编程行业真正的架构师比例少的可怜，就目前国内软件开发环境而言，真正意义的架构师还不是很多，因为大部分的代码框架几乎从开源代码社区里面拿出来，然后定制成自己公司产品需要的，其中研究框架的时间比较长的，并且能够深度定制的程序员就算是高手了，因为很多开源的代码更新速度非常快速，能跟上开源社区的代码更新速度的企业已经是实力非常强的公司了，国内企业现在真正意义上的从头开始设计一个框架然后推向市场相对比较少。
经过十几年的发展，国内编程人才的平均水平已经上来了，虽然在顶级程序员由于在编程底蕴以及生态系统这块有差距，但基层的程序员水平已经上来了，国内很多互联网公司做的产品有些已经不弱于欧美等企业，这些都是国内程序员水平提升的结果，而且现在由于培训行业在国内普及，入门级别的程序员在国内数量巨大，所以很多人喊着国内程序员行业已经饱和了，已经不适合再去从事程序员的工作了。
事实上国内软件行业内需依然足够多，特别是现在的三四线城市都陆续出现了软件公司，而且规模和数量都在提升，国内企业对中高级程序员的需求量还是非常巨大，五六年大小公司对于这类的人才招聘一直没有停止过，而且薪资水平还维持在非常高的水准，了解这个行业现状对于规划自己的职业生涯还是有着非常大的好处。
架构师这种职位可遇不可求，基本上国内架构师都是自己本公司内的优秀的软件工程师，成为了优秀的程序员并且在公司内部深得公司的信任愿意给这种突破的机会，抓住了后边的就会给与架构师的待遇，不是每个程序员天生就是做架构师的料，关键还在于平时的积累，有了机会抓住了，要成为架构师先要自己成为一个优秀的程序员，优秀的程序员需要具备什么样子的因素，现在就根据自己技术生涯的一些经历分享给大家。
基本功扎实。很多程序员在入门之前由于在学校里面比较重视基础，还能看看基础，在成为了程序员之后就开始放松了对这方面的要求，所以导致很多程序员见到有笔试的公司，直接就选择了放弃走人，不能讲这类的程序员水平不行，但起码不是优秀程序员的范畴，优秀的程序员是经得住基本功考验的，是不怕这些所谓的笔试题目的。
算法扎实。很多程序员做了很长时间还不觉得算法挺重要，算法贯穿整个技术生涯，如果没有意识到这点说明意识层面还没理解到，证明需要弥补的东西还是非常多，有些程序员可能是学习了一门编程语言就匆匆去找工作了，运气还不错还找到工作了，没有很好的规划技术生涯路线，一个标准的程序员需要的一门基础的编程语言，熟悉数据结构，并且穿插着学习算法，这三样也是优秀程序员的标配，学习技术不是由着自己性子去做事，需要有规划，这其中不能少了算法的因子。
锤炼编程思想。很多程序员觉得能够写代码，时间长了经验到位了慢慢就能熬成资深技术专家了，程序员不是靠着熬日子过的，需要不断的提炼编程思想，举个简单的例子，做网络编程如果懂得了一门编程语言的编程经验，相信切换到别的语言只需要很短时间内就能搞定，而且积累总结类似的场景以后遇到这种场景都能灵活应对，还能同步迁移到类似的场景，不能只是为了做而作，仅仅就是为了完成任务，那么提升的空间有限，不能因为工作承担的东西就这么点，而不去补充其余的东西，善于总结也是优秀程序员需要具备的一种意识。
成为架构师没有所谓的模板，而且有些人一辈子也没有这种机会，但想要达到这种境界就需要先让自己成为一个优秀的程序员，这样子遇到有理想的企业抓住机会就上去了，一旦进入这个级别后面的编程生涯就会有根本的变化了，关键在于平时一点一滴的积累，让自己长期处于一种高效的学习状态，有太多的程序员经历了几年的适应期就提前让自己进入了舒适期，结果随着年龄的增长技能没有相应的跟上导致年龄大了竞争力下降，出现了老了被企业淘汰的悲剧，什么样子的态度决定什么样子的人生，也就决定了什么样子的结局，希望能帮到你。
作为一名IT行业的从业者，同时也是一名计算机专业的研究生导师，我来回答一下这个问题。
首先，目前IT行业内大量的程序员确实无法成长为架构师，主要原因集中在三点，其一是自身的知识结构不足以支撑向架构师方向发展；其二是岗位工作任务受限；其三是行业迭代速度太快，学习压力较大。
早期的架构师主要集中在后端领域，针对于不同的开发领域，对于架构师的要求也不尽相同。总的来说，架构师的任务主要集中在三个方面，其一是整体技术框架设计；其二是技术选型；其三是解决难点问题。所以对于程序员来说，如果想成长为架构师，需要做好以下几个方面的知识储备：
第一：丰富的开发经验。开发经验通常是软件架构师的基本要求，通常软件架构师都是从初级程序员、主力程序员、研发级程序员等岗位一步一步成长起来的，每一个阶段都会积累一定的开发经验，这些经验对于架构师的方案设计会起到重要的作用。对于大量的程序员来说，从主力程序员向研发级程序员发展会存在较大的困难，主要原因就是基础知识结构的问题，不少程序员通过读研的方式完成这一步升级。
第二：丰富的知识结构。架构师的知识结构不仅仅局限在技术层面，还需要掌握大量的行业知识，不同行业领域往往有不同的特点，要能够根据这些特点来完成具体的方案设计。
第三：紧跟技术发展趋势。架构师一定要紧跟技术发展趋势，同时能够对于未来的发展方向有较强的认知能力，这对于架构师的方案设计会起到重要的作用。对于技术趋势的认知能力，是判断一名架构师能力的重要因素。

架构师并不是一个很好玩的升级路线。
相对于架构师的开发工作。研发工作更有趣，更容易得到社会的承认，不论是图形学，还是人工智能，区块链，甚至黑客（网络安全），凭借你的智慧和努力，可以在短时间内取得成就，并达到一个很漂亮的高度。研发方面是拼年轻，智商和体力的工作，有众多的天才少年取得漂亮的成果，每年有大量新的技术突破和文献等着大家研究。你做的每一件事情，都能表现出漂亮的成果，全局光照，计算机视觉。或者很容易赚到很多的钱，自动驾驶或者区块链ico ，就算做游戏外挂，其收入也大得超乎你的想象。

而架构师不是，架构师拼的只有经验，正确的方法和项目数量。《C++程序设计新思维》里面有一句话：“只有天才的程序员没有天才的构架师。” 在构架师的世界里不存在天才，只存在重构。一定要有正确的方法（敏捷开发），然后就是无数个项目和时间的铺垫。然而对一个架构师应该明确，我们的职责是内部质量而不是外部质量，我们要把软件做的强壮且易易扩展。但你会发现，对于外行麻瓜来说，这根本不吸引人，麻瓜老板经常说一句话：你功能做不出来我们公司就破产了，别他妈的再花时间重构了。

至于为什么架构师很少
内部原因是：架构师太无趣了，相对于图形学光照算法，你却强调测试驱动重构持续集成。研发工程师会得到大量的外部激励，所有人都去赞扬他们的成果。而构架师需要从自身产生激励的能量，比如对代码的洁癖，重构在不改变功能的情况下不断优化代码质量，一个分层，一个正确的依赖关系，甚至一个精简美丽的命名，都需要由衷地感到兴奋和刺激。否则很难熬下来。

外部原因是：浮躁的社会容不下一个架构师成长的时间和空间。一个框架师需要大量的项目经验，超级长的编码时间。坚持正确的方法和一个融洽配合的团队。国外的架构师都是大胡子，而国内程序员到30岁，老婆就催着要去做管理岗位了。和研发工作拼智商不同，架构师就拼的是经验，没大胡子没五六十岁很难成为xx之父这个级别。

行业原因是：架构师容不下架构师。架构是艺术不是科学，没有一个统一的标准，每个成型的架构师心里都有一套属于自己的程序结构和原则，你可以看到十个图形学程序员基于一个算法合作，但你很难看到两个架构师做一个项目不打架的。架构师需要有自己的团队来验证自己的观点和共同进步，但就如同食肉动物永远是食草动物的十分之一，行业也没那么多团队给架构师来糟蹋。

经历过很多项目洗礼，并有自己的想法和能力的架构师，必然是稀有动物。

但看起来无聊的架构师有什么用呢？
他是辅助英雄，给整个团队加各种属性光环：降低代码中的混乱（熵），让团队中初级的程序员做出高级的代码，提高单位时间效率避免加班，让团队更容易进入未知领域，大幅度降低企业成本。

我现在做的混合现实领域，这是一个新的领域，有一个优秀的架构师可以在没有前人经验的情况下开疆辟土，并且可以带起来整个团队的开发质量，降低成本给客户更多的获利空间。
这个问题不知道提出来的缘由是啥，其实问题不是很合适，不过还是一分为二的来回答一下，如下：
架构师不是谁都能做到的，我想说如下几点：首先，应具备的素质应该是快速的学习能力，需要从平常的任何工作活动中，快速学习，包括从自己的本质工作完成，以及与他人的交流中，而后者又尤其重要，从别人那儿学来，而快速形成自己的理解并超越对方，而这，从自然规律角度上来讲，这只有少数人能做到；
其次，需要具有全局的视野，能平衡整系统各子系统之间的解耦与耦合，这个需要积累，需要在各子系统内有实际项目的、比较成功的设计编码的问题处理能力，而尤其是问题处理能力又尤为重要，这也不是段时间能达到。
第三，在这个行当内，能静下心来踏踏实实，保持饥渴的学习，保持积极正向的心态，不断的越挫越勇，始终往设计架构方面努力，在当下整个行业浮躁的环境下，很对都想通过不断的跳槽来达到涨薪的目的，这又会淘汰一大部分人。
最后，即便具备了素质，你能否当上架构师，取决于客观因素了。因为一个架构师，决定了他所在领域的发展规划，以及当前的问题现状的改进，这个位置至关重要，不是那个人，上一层组织关系是不会让你做这个位置的，上层组织还会考察你除了技术能力以外的，诸如与人沟通，管理你的上下级，包括你的上级的上一级到连三级的关系，关系到你的直接老板的，这些其实就很难说了。
呵呵，当然了，还有其他很多了，靠这个问题是说不清道不全的。
真正的软件架构师对各方面的职业素养都要求比较高。架构师的工作，不是平时工作的简单堆叠，除了专业技能要过硬外，还要思维活，想东西细致全面，需要自己去主动去接纳工作以外的大量知识。此外，在性格方面也有一定要求，一个软件架构师往往还需要具备善于沟通的品质。

总而言之就是要技术好、思维活、会交际。大多数程序员做不到架构师的位置主要是因为自身能力达不到，其次是一个公司里面架构师占比本来就想小。

一般程序员在公司负责的工作主要是维护日常的需求，在原有的架构上进行修改，所以很少会接触到架构层面的东西。长期缺少接触相关的知识及业务的机会，久而久之离架构师的标准也会越来越远。
年轻的程序员在知识储备上无法达到成为架构师的标准。
现代的高可用架构一般为：RDS、Cache、MQ、后端服务、监控服务。而随便拿其中一个点，都有着非常多的技术点知识点需要掌握。

比如在多系统交互中，如何保证MQ中的消息能被对方系统消费，如何设计高可用的服务负载均衡，这些都是需要很多经验才可以解决，但是一般的程序员又不容易接触到架构设计。
而年纪大点的程序员要么是后期缺少折腾的的动力，要么在职业发展途径走到不同的分岔路口，最终走上架构师这个树枝上的寥寥无几。

小富即安的心理。很多程序员满足于现状，缺少坚持不断学习不断提高的动力，每个月拿着万把块钱的工资，心安理得，懒得去折腾。

一个公司架构师在广大码农里面占比还不到10% ，能成为架构师的一般都在公司里担任研发和管理的角色，想象一下公司团队的人员金字塔你就知道竞争力有多大了。
平常，开发的团队一般都是10多人组成。几个团队间一般会存在一个技术面最广、技术经验较充足的人，叫做架构师或者说是TL 。而架构师的存在，一般在众多的码农中占的比例少之又少，可能连码农总人数的10% 都达不到。软件架构师也存在初中高级。
码农都会写代码，对计算机编程语言都有自身的理解。但是很多时候，程序员或者说是码农只是机械的完成自身的编码工作。为了完成任务，成长有限。
看到这里，很多人都会说：编码时间长了，经验积累的足够，自身也就逐渐成为了资深技术专家。想法其实不能说是不正确，在一个人见多识广后，自然自身的内涵也就足够的丰富。从码农的角度出发。除了架构师，很少有35岁以上的人士会在互联网做程序开发。而一个人想要通过机械性质的编码积累经验。需要多少年成长才能见多识广呢？是否会有码农坚持到那一时刻呢？一个值得商榷的问题
码农是一份年轻人为主的职业。平均从业者的年龄都是20多岁。慢慢熬、慢慢积累在码农中也不能说错。但是很多人在软件开发领域积累一定的经验后就会转型不做开发。

所以说，长久时间的码农很少。而在短暂的码农开发软件的工作中，脱颖而出，成长起来的人更少。
些许拙见，供您参考。
从事互联网开发多年，欢迎大家骚扰
小团队一般 10 人左右，其中常常是技术最牛的人做架构师（或TL）。所以，架构师在广大码农中的占比大概平均不到 10% 。而架构师也可以分为初级、中级、高级三档，江湖上真正高水平的软件架构师就更少了。
所以，大部分（超过九成的）码农干上许多年，还是做不了架构师，这是什么原因造成的呢？
1：码农分为真的能写代码的，以及自认为能写代码的。
2：真的能写代码的码农又分为自认为写的不错的，以及真的还不错的。
3：真的能写不错代码的码农又分为会钻研会不断优化的，以及安于现状的。
4：会钻研的码农又分为喜欢广度了解新技术蜻蜓点水的，以及深入钻研用到知识的。
了解广度的码农又有少部分愿意深入某些技术，喜欢深入研究的又往往缺乏广度知识。
6：为业务而技术的深度广度都了解的码农，又需要有良好的沟通能力。
7：而沟通好的，又有一部分当PM去了。
8：然后剩下的，又有一部分慢慢脱离实际开发（不再做任何实现）或者开始依靠拿各种中间件搭积木来作为“架构”手段。
9：除去这些，剩下对业务有一定了解，对技术广度上有多种涉猎，深度上对部分技术研究彻底，还有很重要的一点，考虑问题足够细致全面。
10：细致全面善于沟通，技术上深度广度都没问题，又喜欢这个工作，还会不时做底层实现，从业务和开发两个角度出发，搭出“架构”来是为了开发效率，为了运行效率，为了开发质量，为了业务灵活和运行稳定，为了维护方便等等这样的人，个人认为可以称为“架构师” 。
而真能满足这种需求的，别说题主的10%的比例， 1%能不能达到我也持怀疑态度。其实现在的“架构师”大多数都停留在8这个层次，甚至很多在5这个层次就当上title上的架构师了。
总之，成为架构师，不仅仅是工作上的简单积累，更需要主动接纳工作外的大量知识，同时，对性格上对于非技术能力上也有一定的要求，不仅如此连思维方式都很重要，外加职业发展中又有很多岔路，最后走到架构师这根树枝上的就寥寥可数了。
如果你想要往架构师的方向发展的话，那或许你可以看一下我分享给你的这份进阶路线图，主要针对2到5年及以上工作经验的Java开发人员，里面的技术包涵了Java高并发、分布式、微服务、源码分析、高性能等技术，这些也是目前互联网企业比较常用的技术，那么来详细看看。（图片可以保存）
一：常见模式与工具
学习Java技术体系，设计模式，流行的框架与组件
常见的设计模式，编码必备
Spring5 ，做应用必不可少的最新框架
MyBatis ，玩数据库必不可少的组件
二：工程化与工具
工欲善其事必先利其器，不管是小白，还是资深开发，玩Java技术体系，选择好的工具，提升开发效率和团队协作效率，是必不可少的：
Maven ，项目管理
Jenkins ，持续集成
Sonar ，代码质量管理
Git ，版本管理
三：分布式架构
高并发，高可用，海量数据，没有分布式的架构知识肯定是玩不转的：
分布式架构原理
分布式架构策略
分布式中间件
分布式架构实战
四：微服务架构
业务越来越复杂，服务分层，微服务架构是架构升级的必由之路， Java技术体系，和微服务相关的技术有哪些呢？
微服务框架
Spring Cloud
Docker与虚拟化
微服务架构
五：性能优化
任何脱离细节的ppt架构师都是耍流氓，向上能运筹帷幄，向下能解决一线性能问题， Java技术体系，需要了解：
性能指标体系
JVM调优
Web调优
DB调优
如何一起学习，有没有免费资料？有需要的滴滴滴哦
【架构师有多难】软件架构师？似乎是个明确的职位或者岗位了。然而，他在软件产品开发过程中，充当什么角色？起什么作用？确众说纷纭，缺乏共识。成为一名架构师，码农根本没有明确的努力目标。这是问题的关键，架构师，是上级领导、老板对某些软件开发人员的“认同” ，是某种管理理念的体现，不是软件产品生产活动中某个具体的岗位、角色。