回想我当年处于高级开发阶段，也算是个熟练工，每天干的都是体力活，说白了就是不断复制熟悉的工作模式。由于在工作中没法实践到高并发组件等架构师所必需的知识点，当时只也只能靠看资料来积累，靠面试来感受对公司架构师的实际要求，自己感觉也走了不少弯路。
每个公司做的活其实都有局限性，如果就停留在本公司熟练工的阶段，那么一定无法紧跟技术进步的步伐，长而久之就会落后了。
话说回来，不是每个熟练工都能经得起舒适区诱惑的，我就拿我经历过的舒适区和目前的挑战区状况对比一下。
上班前，在外企的时候，由于每天干的活都能应付，所以没丝毫压力，而且由于是弹性工作制，所以10点到算常态，一周总有1次10点半前到，上班路上，还能用悠闲的心情看风景。在目前互联网公司，上班前就得规划一天的工作，有时候想想今天要干的活技术上我不大熟，或者得催别的组要接口，所以经常有忐忑不安的感觉，一路上有时还得小跑，虽然也是弹性工作制，但总是9点前到，早到就能早开始做事情。
由奢入俭难，而且舒适区用的技术要比挑战区落后很多，而高级开发到架构师的升级任务未必是容易达成的，所以在舒适区的时候，只能平时多上进，要怎么上进？其实拿出当年高考四分之一的努力程度即可。
架构师的重要工作任务是解决分布式高并发的问题，所以升级可以从会用一些分布式框架开始。
比如nginx怎么配置，dubbo和zookeeper怎么整合，kafka消息中间件怎么配置，redis怎么配置，或者ETL该怎么配置。看了各种教程后，一定得自己找个环境配置一下，比如我通过nginx配置，确实能把请求发送到不同的服务器上，或者通过设置dubbo配置，确实能做到超时重发。
这个步骤的难点是，在自己的机器上未必能模拟出分布式环境，所以如果可以，就找公司测试环境实践，或者自己机器上装个虚拟机。如果实在没有办法，安装个环境，然后自己设置一遍配置，哪怕没法调试，自己设置一遍总比光看教程要好。
不少高级开发摸不到升级架构师的方法，其实很多技巧平时工作时就能接触到。可能这里一时无法列全升级到架构师所需要的基本功，但大家可以思考如下两方面的问题。
1当前系统的运维方面，为了让你的系统能平稳地运行平稳地升级版本，你需要掌握哪些技能？当系统在线上表现出有问题时，你该如何通过查日志等方面来排查问题点？
2再进一步，可以考虑系统高并发方面的问题。你的系统当前能应付多少并发量？当前系统的瓶颈在哪？任何系统都有瓶颈，比如SQL压力大，非常容易导致OOM异常。如何通过看日志等方式确认当前系统的瓶颈所在？
为了得到上述两个问题的答案，我们需要掌握各类技能，比如通过jenkins打包发布版本，通过linux日志查看问题，通过MAT查看OOM异常时的Dump文件，诸如此类，这就是升级到架构师所必须的基本功。
所以当我们在一个公司成为熟练工，达到“舒适区”以后，一定不能局限于自己所被分配的活。如果再达到高级开发的水平后，一定有机会接触架构配置调优等方面的活，这时候，有条件的最好能亲身参与，如果没条件，哪怕看配置看流程看代码也行。
初级开发会专注于“如何调用”和“如何才能保证没有语法和逻辑上的问题”，高级开发会根据当前需求选择一些合适的语法点，比如遇到高并发会选择“线程池”，遇到NIO类需求时则选用netty，而架构师则需要在使用各种组件时，进一步了解各种坑。
推而广之，除了netty之外，高级开发在“会用分布式组件”的基础上，更得从高可用（一台down了能自动切换）高并发（这不用说了）集群上下功夫，这只能一个个组件自己看了，网上这类资料不少，比如我前几天看到篇阿里架构师面试指南，里面针对各组件提了不少问题，大家可以逐一对比，根据问题查看底层实现细节。
对高级开发而言，组件可能就是一个个jar包，但对架构师而言绝不是这样，比如某个基于netty的系统一直出现OOM异常，那么架构师首先得熟悉nettyjar包里的底层代码，而且必要时，得debug进这些底层代码，或者通过dump文件发现现有系统在使用堆外内存时未释放内存的点。
看底层代码，说起来容易做起来很难，要看到什么程度？如何才能不拘泥于细节？我目前的体会是，第一看流程，从流程里看这个组件的关键模块和重要方法，第二还是结合阿里架构师面试题里的问题，比如提到dubbo底层通讯协议，那么就把对应的模块和对应的方法看一下。
记得我在入门架构师的开始阶段，总是很理想话，总是会画出一个解决高并发的框图，里面包含了各种组件，这不算错，但只是第一步。
在大多数场景里，架构师不是从零起点设计，而是需要结合现有系统的各种痛点改造系统。举个例子，当前数据库性能很慢，如果有钱的话，比较直接的办法是升级到oracle，但往往不现实，所以架构师可以搭建多个mysql实例，然后用mycat做分库分表。而且，从单库切换成分库分表时，得考虑到，万一切换失败，我该如何回退，由此可以设计出开关和汇总表等方案。
那么高级开发如何在这方面提升自己的能力呢？只能跟在架构师后面，仔细分析具体的设计方案。俗话说，熟读唐诗三百首,不会作诗也会吟，而各公司多少会有些线上的组件，大家可以通过看配置文件以及架构的工作流程，而且，在上线一个新架构方案时，可以多了解下避规风险和回退的方案。
2遇到架构方面的方案评审，尽可能多参加。组内如果有架构方面的活，尽量多做些，刚开始一定是不会，不会的时候千万别怕丢脸，多跟着熟悉架构的同事后面多问，多看看人家是怎么排查和调试架构方面的活，一来二去就熟悉了。
我也见到过一些同学，所在的公司用的技术比较传统，在整个公司里都没有机会用到分布式组件架构，那么没办法了，要么自己看资料自己练习（这其实效果并不好），要么自己找个机会跳到互联网公司。
说到底，升级的诀窍只能是多观察多揣摩多实践，而升级路上的艰辛，真的是如人饮水，冷暖自知。
本人尚属勤奋，所以虽然天赋一般，在升级的路上也是一波三折步步艰辛，但在坚持之下，自认为也算有些进步，所以尚敢写些心得供大家参考。
关于转载有如下的说明。
1本文可转载，无需告知，转载时请用链接的方式，给出原文出处，别简单地通过文本方式给出，同时写明原作者是hsm_computer。
2在转载时，请原文转载，如要在转载修改本文，请事先告知，谢绝在转载时通过修改本文达到有利于转载者的目的。