升级架构师之路的踩坑系列一
备注：本文源于互联网，文中的“我”指原文作者，非站长本人。《升级架构师之路的踩坑系列》收集了诸多IT开发人员的升级之路，希望给大家一些启发。
先说明一下，文中说的是技术架构，而不是业务架构，另外，这个架构是指目前比较热门的高并发大数据的架构。论能力，我还达不到架构师的水平，所以我目前还在不断努力。下文将回顾了我在架构师方面的学习途径和学习方式，也总结下我在这方面踩过的坑，从而让大家别再重犯。
1 初始迷茫阶段：只知道架构师很挣钱，但不知道该学什么
我自认为还算比较上进，所以，在 Java 高级开发的岗位上也是不断学习，当时再往上升，有项目经理和架构师等选择，一方面，我听说架构师很挣钱，另一方面，我也想再深入了解些技术，所以就想往这方面转。当时我是很迷茫的，甚至不知道该学什么，以及该怎么学。那个时候，我就开始用面试来探路了，投了不少公司的架构师职位，记得当年面试真的是答非所问。
面试官的问题 1：你用过什么架构？他的本意可能是问分布式架构，比如 Dubbo 等。我只能回答出，我用过 Spring MVC，其它就不知道。
面试官的问题 2：在项目里，怎么应对高并发流量？我的回答是，靠多线程，以及 Servlet3.0 的并发功能。
面试官的问题 3：你们在数据库层面，如果应对海量的操作？我的回答是，用 SQL 调优技术，根据执行计划，看 Oracle 执行的瓶颈。
上面这些问题可能面试官想了解集群等方面的知识，但我只能从单机版的方面回答。总之，当时的回答很多是答非所问，幸好当时的面试是用来试错。
回想起当时的场景，虽然到处到网上搜诸如 “Java 架构师的技能 “等关键字，也看了不少资料，面试回来也赶紧补课，但总体上，甚至无法建立起学习规划，所以当时的学习效率并不高。
2 牛角尖误区阶段：过于偏重代码层面的解决方案
因为当时在高级开发阶段，自己动手搭建过 spring mvc 等框架的实现方式，很多问题都是自己写模块来解决的，所以就认为很多架构级别的事情，更多的得靠自己写代码来解决，而架构师应当更多关注系统的结构。
比如，当时我在学习负载均衡，总想着自己写一个模块，通过 NIO 或队列的形式，自己把请求转发到合适的服务器上，又如，在安全容错方面，总想着自己写一个异常处理的模块，来解决超时的请求。
这种做法本身没错，因为资深级别的架构师确实是自己通过代码写诸如负载均衡等的实现方案，但在刚开始的升级阶段，更多的得靠现有的组件来解决实际问题。
这就好比一个画家在成名后，能自己创作出各种艺术精品，但在学习阶段，更多是通过临摹大师的作品来体会大师们的创作思路。所以，在学习阶段，架构师不能指望一步登天，总是先通过了解现有组件的代码和实现方式，来慢慢积累经验。
3 牛角尖误区阶段：陷入各组件的细节中
在经过一些大神的帮助后，我也知道了一些架构级别的组件，比如消息级别的组件 Kafka，以及 ZooKeeper 等，这时，当我看到这些组件神奇的功效后，就忍不住去看底层实现，当我沉浸于底层实现的精妙时，就不知不觉地陷入到它们的细节中。这时，我确实能向别人吹嘘某种组件的底层实现细节，让别人也感觉我很厉害，但仅此而起。当我了解到一个个组件的实现细节后，也发现自己确实也长了不少知识，但对实际工作的帮助并不大。
现在回想下，当时应当是先了解面上的知识点，比如我要搭建一个分布式高并发的系统，我应当了解这个系统应当包括哪些功能模块（比如反向代理，数据库集群，消息中间件等），在这基础上，然后在每个方面再选用合适的组件。否则的话，光了解零件的构造，不了解机器的工作机制和流程，还是无法成为架构师。
4 放眼看世界阶段：学了一大堆组件，也了解了很多方向，但要把组件组装到一起，不容易
在陷入学习细节的学习误区后，我发现无法有效地把了解到的组件整合到一起，比如怎么把反向代理 nginx 和消息中间件整合到一起，这样就无法让多个组件起到 1 加 1 大于 2 的作用了。这时，我就结合了具体的业务功能，看了不少代码，或者是别人的解决方案，终于知道各组件之间是怎么整合的。而且，在此基础上，也开始自己动手组装一些组件。在刚开始的阶段，自己搭建的这些系统只能是实现功能，效果和外观上只能是呵呵了。但我感觉很欣慰，至少能动手实践了，能通过对比自己和大神之间的成果来了解进步方向了。
5 进入自我反思阶段：后来发现架构师更得考虑可重用和可维护性
经过不断徘徊和摸索，现在发现，架构师的能力其实是体现在日常工作中的，在一个项目里，并不是架构师搭建好系统架构体系后就什么都不干了，架构师在项目开发过程中，更能帮助组员搭建出可用性高和可维护性强的应用系统，后者其实更能体现出架构师的能力。
比如某个收银系统得支持预付卡，银行卡，微信，支付宝还有积分等的支付方式，而且支付的渠道还得分银联和网联以及门店等，如何搭建一个能支持上述渠道和上述支付方式的系统？可能一般的程序员就会就事论事，用最简单最快速的方式，针对每种方式建一个类，做多在方法级别抽象出来，估计这样只能实现方法级别的重用。但发现这样远远不够，因为没有一成不变的代码，上述代码在经过多次需求变更以及多次功能改动后，就会变得一团糟，基本上就很难维护了。甚至会发现修改代码的时间会比写新代码的时间要长很多。架构师在处理这类问题时，不会光想着当前如何实现功能，更会主动地考虑，当功能变更时，如何更高效地修改？如果当有类似功能来时，如何最大限度地利用现有的模块？其实答案我们都知道，即面向对象思想以及基于设计模式的解决方案。这里我的体会是，当我们陷入修改泥潭时，或者不得不做重复劳动时，这时再回顾面向对象和设计模式，再尝试着用其中的一些方法（无非是继承，抽象类，接口，内聚，组合等方式）改善代码结构时，从中我们能得到意想不到的收获，我的一些对设计的感悟就这样来的。
我们不可能每天都会面对架构层面的设计，但写代码是每天必不可少的工作，我们如果每天能及时回想下，我今天写的代码，如果遇到功能改动时，会不会修改起来很困难？如果可维护性差，那么该怎么改进？然后再进一步考虑下，我面临的问题场景能否和设计模式中的一种或多种匹配上？如果能的话，该怎么用设计模式的思路来改进？多想下这类问题，我们就会有收获，虽然我目前还谈不上是架构师，但至少我就通过这种方式提升了不少能力。上述是我的一些体会和总结，大家可以留言，谈谈自己在升级架构师的一些体会。