架构师是干什么的

一、先说下大家对架构师认识的误区

1、架构师不是不食人间烟火，不是只在一个人的隔间里设计架构，而是需要和产品方，需求方，程序员等各路人马打交道。

2、架构师偏重于技术，这个不假，但绝不能是技术完美主义者，因为任何产品或网站的架构都充满着妥协。

3、高级程序员和架构师的界限并不明显，不是哪天高级程序员学好了什么课程，掌握了一门技术就自动升级到架构了，有些要求不高的项目里，甚至由高级开发来充当架构的角色。

4、架构师并不是门门都精通，而是得知道某个需求要点可以有哪些实现方案，然后会根据当前的预算，人员等情况合适地选择适合当前项目组的。

5、对架构师而言，不是什么都是得自己设计，比如实现负载均衡时，不可能让架构师用java实现一套解决方案，而是至少选用哪种组件，比如nginx，能在项目中把这套组件搭建起来。

6、架构师设计出来的，是产品，未必是艺术品。架构师设计出来的产品可能仅仅能满足流量等的需求，可能只能远观，近看可能就一团糟了。但公司恰恰是要结果的，而且产品开发的周期会很紧，所以最终上线的架构也就只能是应付当前的需求。

二、高级开发升级到架构师的必要条件

在很多场景里，高级开发只有具备了如下的条件，才有资格升级到架构师，这里我是拿java架构举例。

1、Java Core以及Java web的基本技能，比如集合，多线程，SSM框架就不说了，这个是必须要掌握的。

2、至少能会在linux上看日志，如果可以，最好具备在linux上部署和运行程序的能力。

3、具备一定的调优能力，比如需要能通过看日志，进行JVM内存调优，或者通过看执行计划等方式，进行SQL调优。

4、得了解设计模式，可以不用精通，但至少得知道，在哪种场景里，可以通过哪种模式来优化结构。

5、这个是关键的一条，考虑问题时，得摆脱“单机版”的局限，在知识储备里，得包含负载均衡，消息队列，数据库集群等基于分布式的知识点。

6、和人打交道时，至少没障碍，至少得能清晰地表达出自己的意思。

三、高级开发不会自动升级到架构，除非认真准备过

在大多数公司里，会有高级开发升级到架构师的案例，我也见过不少高级开发通过跳槽，成为架构师的案例。但机会只给有准备的人。

如果高级开发一直关注手头上的事情，工作之余也不学习，那可能就无法完成升级了，而且这个升级的步骤要比初级开发升高级的要难得多，为什么呢？

公司一般都是需要具备有过实践经验的架构，而高级开发一般是通过跳槽来完成升级的，但如果你当前是高级开发，估计很难有实践架构的机会，所以很难通过架构师的面试，没有架构师的实践机会，那么如何升级呢？这似乎是个死循环。

下面说下我见过的完成升级的捷径：

1、如果你所在的公司是互联网公司，那么高级开发多少会接触些分布式高并发架构的知识，那么高级开发在平时可以多观察多积累，等到组内架构师离职了，一般就有机会了。

2、有些公司还是用传统的技术，比如还是用单机版的SSM，甚至用JDBC+java的开发模式，在这类公司里，升级似乎有些难，但不是不可以。在这里公司里干活的高级开发，平时一定得多看相关书籍，看的时候围绕一个主题：如果让我设计一个能满足双十一流量的架构，我该怎么做？再具体下，如果让我设计一个高并发流量的秒杀系统，我又该怎么做？其实很多架构面试题就围绕这两方面。

经过学习，至少高级开发能有架构师的技能了，至于这类高级开发如何在简历中写架构方面的经验，别问我，我不能说，或者是，大家可能都知道，但我不可说。

四、架构师必备的技能（再说升级的方式）

1、围绕着刚才说的，实现一套能满足高并发的系统，那么得了解负载均衡，限流，模块间的消息队列，缓存，热备冗余，数据库集群等知识。

其实对高级开发而言，学习本身不是难点，关键是不知道该学什么，以及每个要点该学到什么程度？这里，如果你要面试成功，那么每个知识点知道个大概即可。

2、具体到学习路线，目前我知道的有阿里路线，我也见过有人把spring cloud各组件了解透，然后完成升级的案例。

3、对我而言，我升级时是看《亿级流量网站架构核心技术》这本书，其中涵盖的知识面比较全，然后我再根据其中给出的知识体系逐一再深入，比方说，我看了其中有提到用hystrix做限流，我就再看其它资料，深入了解下这个组件的配置等详细用法。总之，先看面，再深入点，随后再根据各组件，组装一个能应付高并发的系统。

4、实践很重要，而且在实践中别怕犯错误，但犯了错得及时总结。

可以这样说，架构师开始几个设计的项目，一定是惨不忍睹的，一定会不停地重构。所以，在架构师的实习阶段，加班是常有的，甚至可能会不断被领导说，设计出来的产品也有可能被抱怨。

这时一定得坚持，然后不断反思下，同时在设计架构时，一定能接触到各类相关的知识，这样架构师就慢慢成长了。

5、这个是比较容易忽视的一点，架构师一定得会沟通，这往往也是升级的瓶颈。

架构师得和产品沟通，以得到本系统的需求，同时得和需求方协调，在有限的时间里一定做不到面面俱到，一定得有所放弃，这个得事先谈好。然后再设计，拼接组件，然后得和开发或开发经理沟通，别让开发误解自己设计架构时的本意。

我目前不是架构，还在升级的路上，根据我接触到的架构师的升级经验，以及我本身的升级体会，在这里来总结下架构师的技术升级要点：用两个字来描述：集群，用三个字：分布式，再用多点的文字：把海量的流量和数据合理分摊到数量合适的机器上。

想明白这点，后面就能知道该学哪些了，比如流量分摊时得负载均衡，存储海量数据时得靠数据库集群，或分库分表，为了防止单点失效，得设计冗余系统，系统间通讯时得用消息中间件，不能让每次请求都走后台，所以可以搭建缓存，单个缓存容易失效，所以可以搭建分布式缓存，为了监控性能，所以得上一些监控措施，比如监控JVM，监控数据等的，为了等看日志，所以得上一些日志组件。等等。

上述知识点掌握后，再组装起来，比如搭建一个秒杀系统以检验自己的学习成果。

五、架构师平时干什么？

1、开会，开需求会，开设计评审会等。大概会占到平时工作的30%到50%。

2、如果不是资深架构或技术总监，那么未必会设计一套全新的架构，往往是在现有基础上改进，比如做扩容，分库分表，上新的日志监控系统。这方面，架构师往往会做个案例，比如在一台linux上搭个日志系统，把步骤写清楚，让开发依样画葫芦。对于资深架构而言，可能得重头开始设计，或者作出调整技术组件等的决定，这一般也先在部分系统或部分机器上做试验。

3、解决技术问题。这些问题未必是架构级别的，但只要是高级开发解决不了的问题，架构一般都得上，谁让架构是大牛呢？如果是架构组件方的问题，比如配置或部署方面的问题，架构师更得上。

4、但最重要的是学习，比如想，当前流量是2000每秒，到了5000时我该怎么办？然后再找些机器搭些组件来实验一下。

六、架构师更多的是和人打交道

和技术打交道容易，和人打交道难，因为一百个人会有一百个想法。

所以说，除了技术之外，架构师还得具备如下的能力：

1、能通过交流展示自己的想法。

2、在各方利益不一致时得会协调妥协，其实这也得靠各方沟通。

3、管理团队的能力。

4、充分倾听别人想法的能力。

所以说，很多公司的架构师绝不是“两耳不闻窗外事”，当然这类架构师也有，但这类绝对是大神级别的。