架构师多如过江之鲫，但你真的了解架构师这个工种吗？

当我第一次和InfoQ约写一个关于架构师的稿子时，我很是愣了几分钟，虽然我自已的职业生涯经历过几次不同的架构师岗位，也组建过架构师团队。但是，当我要将其落到纸面上时，却发现今天我所看到的在行业内的架构师实在是千差万别，甚至鱼龙混杂，在方向、技能、经验、学术、成就上的差异也犹如云泥之别，于是，今天我想和大家交流一下我对架构师的一些看法。

随便打开某招聘网站：系统架构师、搜索架构师、前端架构师、iOS/Android架构师、平台架构师、（大）数据架构师、JAVA/PHP/.NET架构师、高级架构师、资深架构师、BI架构师，这些是大家常见的，君不见还有后台架构师、MIS/ERP/OA系统架构师、金融系统架构师、搜索架构师、总线架构师、运维架构师，安全架构师......林林总总，不一而足。

仅仅是上面这些岗位名称，就能看到架构师岗位的差异之大，方向不同、技术栈不同、行业不同，即便同一个岗位，水平差距也是天壤之别，如果仅以架构师一个称谓来描述，显然是不合适的，所以我觉得今天在行业内这个称谓还有点”虚”。

首先我认为是因为程序员需要。 小的时候，记得当地的所有理发店，无论哪个理发师来剪头发，都是一个价格，虽然也是从1毛涨到了5块，但价格都是一样，但选择去哪家店或哪个理发师的权利在消费者身上。

长大工作之后，住地楼下有一家理发店，为了贪图方便，我经常去那里剪，清楚的记得其中一个名叫王子的小伙子在给我理发，第一次去剪的时候是20元，然后每隔几个月就会涨一次价，从最初的20元涨到38元、58元、68元、88元、98元，最后到了108元。

每次付款的时候，热情的小伙子都特别不好意思地对我说：“哥，我又升职了，价格涨了！”， 人还是那个人，理发水平对于男性而言大体也看不出多大差异，但头衔从理发师变成发型设计师、高级发型设计师、设计总监、高级设计总监、首席设计师、沙宣首席设计师，当价格一路涨到和天罡北斗一个级别的时候，我终于忍无可忍的换到离住地2公里多远的小闫理发店，10元搞定。 PS：想想当时真的是懒啊，可能跟当时头发的发量也有关系。

这样举例似乎有点贬低程序员的意思，但是大家不要忘了看上面价格的走势，涨到98元的时候我还坚持在那里剪头发，这说明我也已经是走在初级程序员、中级程序员、高级程序员、架构师/开发经理、总监的路上了。王子同学在那几年的时间，除了价格提升了，但技能方面似乎没有特别大的进步，但这不能说明那几年我的能力没有进步，确确实实是积累了一些经验，也有了点提升，自然薪水也涨了上去。

大部分职业都是需要有成长体系，才能让人有奋发向上的追求，而架构师就是程序员这个群体成长道路上往往会出现的一个重要节点， 他描述了一个程序员在某个领域、行业在知识、技能的广度或深度已经积累到一定程度，需要社会对这个群体有一个较清晰的定位和价值判定，是开发领域社会分工精细化的一个产物 ，所以我认为这个岗位的出现和程序员的成长有关，也是程序员的需要。

因为项目开发需要。 一个开发项目从立项到结束需要做许多事情，需求分析、梳理抽象、系统/模块划分、服务化、数据结构设计、前后端架构、技术架构、运维、监控等等，它涉及抽象、架构、设计、评估、攻关、调优、团队培训等等。

他需要有一个角色负责整体，很显然项目经理、产品经理、BA做不好这样的事情，往往需要由团队的主要负责人来做这样的事情，我猜即便在开发比较精细化分工的今天，大部分的创业公司找的应该就是这类人：他们具备CTO、VP、TD（简称CVT）中的某一个头衔，这些人大部分的时间其实都花在这些事情上面了。

但是随着业务的发展，CVT们就会发现自已变成了瓶颈，除了前面提的这些技术工作外，还要求CVT们要花费大量时间不停学习新知识，实践，总结，还需要和公司业务部门讨论需求，和外部机构对接，组建团队，项目管理等，于是就需要有分工，要有项目经理、HRBP、BA/SA、架构师等来支持其工作，需要有更专注、专业的人员来帮助，于是就出现了架构师这样的岗位。

所以，这样的需要和分工就决定了在每个领域、行业对知识、技能、经验的要求层次各有不同，都被统称为架构师，因此就会出现上述所讲的“虚”的感觉。很多时候大家在讨论架构师的时候会出现牛头不对马嘴，甚至出现上下左右互相鄙视的场景。

当然，说到这里，很多架构师可能会嗤之以鼻，没有负责过一个开源项目、做过分布式框架、经历过上亿级并发的系统架构师，怎么能称之为架构师呢，我想说的是基本上你是对的，但如果你还有3分钟休息时间，不妨再往下看看。

承上所述，如果限定在一个特定场景，比如亿级以上并发的分布式服务系统中从事架构的岗位，称之为架构师，那么大家可能就会觉得比较容易接受了。

但是我更愿意将参与构架系统的开发人员，称之为领域专家，它里面其实有许多技术栈不是一个人就能够完成，比如在硬件、数据存储、网络层、操作系统、服务框架、安全、算法、大数据等都有相应领域专家参与完成，并不只是在最上层搭框架画蓝图才是架构师，每个领域都需要有专业的人员负责架构、研究、开发。

这些领域还能再细分，对特定领域的存储系统、特定的网络协议、特定领域的业务场景等有较深研究，这并不是说一个领域专家对其它方面就不熟悉了，而是说他在某些领域特别有研究，远远超出行业平均水平，踩过许多个坑，有足够经验，同时在技术领域的知识广度上比较好，那么这样的开发人员常常会被定义成架构师，但我还是更愿意称其为领域专家。

这也是计算机和互联网发展到今天，必然会出现的一种情况，回顾整个IT行业发展轨迹，许多岗位都是这么出现的，如Web前端架构师、产品经理就是典型例子。

仅仅把领域专家限定在技术层面，对于许多开发人员来说大致比较容易接受，但如果把它扩展到业务领域（有些时候称应用架构师？），就很有争议了，甚至我见过有一部分架构师是一直鄙视并唾弃这种所谓业务架构师：业务架构有什么好谈？只有技术做不好的人，才会谈业务架构！我们还是来谈谈拜占庭将军、区块链、机器学习、大数据…

我不完全反对这种观点，首先这种情况的出现，是因为很多开发人员觉得业务架构不如技术架构有深度，如果让一个分布式领域的专家来谈谈分布式服务框架的治理、RPC协议、长短连接、路由设计、容错、流控、灰度、降级、一致性、可靠性之类的内容，他可能会滔滔不绝讲上几个小时，闻者如痴似醉。

但如果你让一个电信领域的技术专家来谈业务架构，我相信许多开发人员会昏昏欲睡，一个是有行业特性因素，再一个就是没有一个可量化标准来评判好坏，于是就导致这样的局面。

但是在非开发人员的群体眼里，业务架构又是如此重要，重要到他们根本不关心你的技术架构是什么样，除了系统不要出故障、不能太慢之外，他们关心的是需要有什么样的系统/模块/服务来更有效率支撑业务？系统/模块/服务流程是否顺畅？能否适应业务的快速变化？新的活动/规则出现是否尽量少开发，甚至不用开发？

诸如此类，大部分都是需要有业务领域的专家或者架构师来完成，但在实际工作中我见到过不少比较精通某些技术领域的架构师，比如网络、数据库、分布式服务框架、安全、算法甚至工作流引擎等。

但开发人员中具备较高视野，能够快速梳理、分解、抽象业务需求，并真正能实践落地的却是极为稀少 ，而这个领域也是行业内一直被忽视的，因为没有评判标准，不像技术框架那样可以被量化（可支持多少QPS、多少吞吐量、并发处理多少订单等），大部分时候技术都是被业务在拖着走。于是，技术永远是瓶颈！

当然上面我是举了一种比较极端情况，更多时候架构师们都同意架构必须了解业务，但开发人员内心真正把这个事情放在重要地位的其实并不多，工程技术是愿意花时间学习，并进行实践，就能快速进步的，但业务抽象却需要多年一线经验积累和总结，需要时间沉淀。

给一个开发人员时间让他研究一个流行的新技术或是重写一个已经不太适合当前业务的技术框架，他肯定如饿了几天的饥汉见到一块大肥肉，摩拳擦掌，跃跃欲试，十八般武艺全上了；

但如果你让他完成某个业务需求的抽象分解、流程梳理，并实现开发，我相信他也能做，但愿意花很大精力，认真去做的、并且做好的其实不多，因为结果不好评估，成就感不强，所以大部分时候做这样的事情会感觉比较痛苦。对比一下两种场景的做事心态，结果不言而喻。

所以，我认为大部分时候架构师用领域专家来描述可能更为准确一些，当然，这不仅限于精通技术领域的专业人士。