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