为什么很多程序员没有升级到架构师？
对我们程序员来说，发展的途径要么是走管理岗，从开发升级到项目经理甚至是部门经理；要么走技术升级路线。不过在技术路线方面，无法升级到架构师的程序员不在少数。一方面，在不少公司的高级开发岗位上，无法让程序员实践甚至接触到架构师的技能，另一方面，有不少程序员甚至不清楚架构师所需要掌握的技能和升级途径。所以从结果上来看，至少有5成的程序员止步于“高级开发”的程度，这是非常令人可惜的。
我这几年一直努力地从高级开发升级到架构师，目前虽然职位上没达到，但好歹多少也能干些架构师方面的活了。在本文里，将结合我自身和其它一些程序员的经历，分析不少程序员无法升级到架构师的普遍原因，由此向大家展示从高级开发升级到架构师的难点，并在此基础上给出相关的升级建议。
1. 很多程序员在日常工作里无法接触到架构师的技能
大多数的程序员能在工作中接触到高级开发的技术，所以从初级开发升级到高级开发，难度并不大，但架构师就不同了。
比如在外包公司里，程序员大多是做重复劳动，业务变了，但用到的技术还是增删改查。或者在一些规模比较小的公司，项目组出于成本和质量监控的考虑，也未必会让程序员从事架构方面的工作。哪怕在一些技术含量比较高的互联网公司，出于业务封装的角度，一些高并发高可用的实现往往被封装在方法里，程序员仅仅是通过调用方法实现功能，未必能在代码层面，显式地看到架构方面的技能。接触不到相关技能，单靠看视频看资料积累起来的技能，在面试过程中往往会不堪一击，从而无法应聘架构师的岗位，这反过来制约了程序员向架构师发展的脚步。
我有时候在面试高级开发的时候，会深入问些架构方面的问题，比如我问，你们系统里，模块间的通讯用的是什么组件 ，不少高级开发甚至是一头雾水，或者在他们眼里，更多的是调用方法实现功能。
2. 不少程序员往往会深挖单机版的技能
很多工作中得过且过的程序员，在实现的功能通过测试以后，或许就无所事事了，而且这类程序员不在少数，在小公司或外包公司里，这类程序员往往会更多，说实现的，他们的竞争力和从培训班里出来的程序员没什么两样，或许就更熟悉业务背景。
或者有些程序员虽然上进，但会深挖单机版的技术细节，比如我问String对象的== 和equals方法有什么差别，或者，JVM虚拟机调优有哪些实践要点，此类回答他们会回答非常到位。这固然要比纯粹会写代码的程序员要好，但此类技能顶了天只能算高级开发的技能。如果在升级时过度追求这方面的技能，无异于缘木求鱼。
3. 列举架构师平时要干的活，确实和高级开发有差距
上文是从客观和主观两个方面，讲述了架构师升级的难处，在讲述升级方法前，我们先来看下架构师究竟要干什么活，以此来明确努力的方向。
需要搭建高可用的框架，比如就拿最简单的搭建数据库服务来说，得考虑如果一台MySQL服务器宕了，如何保证业务切换到另外一台机器上。
需要考虑高并发的因素，从这个点展开，架构师至少需要会用nginx，mycat，netty，redis之类的工具，以及考虑搭建实现负载均衡的集群。
需要把设计好的架构部署上线，或者哪怕上线动作是由运维来做，但架构师至少要知道如何把nginx集群等组件部署上线的活，由此架构师需要了解必须的linux命令和脚本，以及了解jenkins之类的部署工具。
上述技能不是简单会用即可，如果在开发部署和运行过程中由问题，架构师得负责解决。这就要求架构师不能仅仅靠看视频知道如何搭建系统，更得具备针对netty等组件的debug能力，还得能通过看日志，知道集群的运作情况，如果集群出了问题，还得知道如何快速解决。
不能仅仅关注技术，更得结合业务，把诸如抢红包之类的需求通过架构实现，这就要求架构师得知道各种组件的优劣，以此能选型并设计方案。
从上述对架构师的需求来看，从高级开发升级到架构师很难，也在情理中了。
4. 从运维入手，熟悉架构师的入门技能
升级到架构师很难，但绝非不可能，对于高级开发而言，从运维入手，或许能熟悉架构师的技能。
比如先从ant脚本，jenkins脚本和linux shell脚本入手，能知道系统的部署方式，以及熟悉必备的linux调试技能。
通过观察nginx或dubbo或zookeeper配置文件，了解各组件的运作方式，并能通过这些了解高并发高可用系统里负载均衡和失效转移等配置方式。
可以观察线上相关的日志，了解系统部署的情况，以及从架构层面了解诸多组件间的关联。
在上述步骤里提到的脚本和日志，在平时工作中只要上点心，应该可以看到，或者我们可以和运维人员多交流请教，上述组件部署和配置的知识也不难知道。在这个过程中，暂时没涉及“修改配置”和“搭建组件”等技能，毕竟这属于熟悉阶段。
5. 多解决实际问题，了解组件的关键配置，并了解组件的底层代码
程序员在熟悉基本的部署和架构方面的技能以后， 就可以参与解决一些实际的问题了。在公司里，测试和上线阶段出现的问题不能算少，其中也会包含很多和架构相关的问题，比如kafka没配好，导致消息积压，或者dubbo超时时间配置过长，导致调用链路超时失效，或者再如redis超时时间过长，导致OOM异常。类似问题的种类五花八门，只有想不到的，没有不可能出现的。
刚开始，程序员可以跟在资深人员之后查问题，或者找到问题后，再手动复盘一下，学习架构师分析和解决问题的入手点，一来二去，一定能熟悉组件的配置，并了解组件的底层代码，更能熟悉配置各种框架组件的实施方案。
这个阶段依然属于“见习”，但至少能从实践角度，掌握架构师所需的技能。对比自己通过看视频，以闭门造车的方式积累架构师的技能，通过上述步骤得到的相关经验来源于实际，无疑值钱得多。
6. 必要时，得通过跳槽，争取架构师的实践机会
其实在小公司甚至是外包公司里，都有机会了解甚至实践上文提到的架构师相关技能。程序员通过上述步骤掌握架构师的相关技能后，如果再加以实践机会，就能很快成为名副其实的架构师。
这种实践机会在大公司里不难找，但在小公司里或许就不多了，不过也不要紧，这时如果再出去面试架构师的岗位，基本上就没什么难度了。我们来看下架构师的面试问题。
如何部署nginx（或其它组件），从而实现高可用？
Redis集群里，容灾一般是怎么做的？
Kafka消息队列里，如何实现消息重复？如何确保消息不被重复消费？
或者是问底层的问题，比如说下netty里的读写索引工作方式。
或者在目前阶段，大家未必能回答好上述问题，但一旦在运维层面了解过组件的搭建方式，或者通过排查实际问题了解过组件的运作和交互方式，再专研下相关底层代码，哪怕没太多的架构师实践经验，此类问题也不难回答。
或许一个没太多实践经验的架构师，在公司里日子会很难过，可以会让领导和组员感觉实践经验不足，但大多数架构师也都是通过实践一点点积累相关经验的，在这个阶段里，如果再肯多听多看多问题，升级到资深架构，就指日可待了。
# 7. 总结，升级到架构师后，会有更多的机会
其实对于我们做IT的人来说，升级到架构师未必是唯一的发展途径，但不是每个人都适合搞管理。如果走的是技术加成路线的话，从架构师到技术专家，或许是一条比较合适的发展途径。
对于高级开发而言，或许真有30岁或35岁现象，毕竟高级开发所需的技能很容易被毕业生或培训生掌握，年纪一大了就没竞争优势了，但正是因为升级到架构师不是那么容易，到35岁时，或许还有竞争的能力。
而且，一旦升级到架构师，退则可以找个小公司做技术负责人，以求小富即安，从而不会像高龄码农那样被淘汰；进则可以再到大厂里去磨练一番，然后再通过各种途径拓展影响力，那么真就可以说成为技术大牛了。反之，如果止步于高级开发，虽然也能通过跳槽提升工资，但格局始终无法像架构师那样开阔了。