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

在今天的互联网圈，可能随便遇到一个人递给你一张名片，title就是某某架构师。架构师多如过江之鲫，也正是眼下业内一个有趣的现象。对于架构师，你有什么看法？

当我第一次和InfoQ约写一个关于架构师的稿子时，我很是愣了几分钟，虽然我自已的职业生涯经历过几次不同的架构师岗位，也组建过架构师团队。但是，当我要将其落到纸面上时，却发现今天我所看到的在行业内的架构师实在是千差万别，甚至鱼龙混杂，在方向、技能、经验、学术、成就上的差异也犹如云泥之别，于是，今天我想和大家交流一下我对架构师的一些看法。
老司机简介
陈美珍（Frank），12年的软件研发以及技术管理经验。擅长互联网的高并发、高可用的分布式系统架构设计，组建并带领团队完成项目的订单从零到数百万量级的突破。对大中型复杂系统的需求分析、抽象、架构设计、拆分、服务化设计及整合也比较擅长，有多年证券、电信等传统业务系统实战经验。

什么是架构师？

随便打开某招聘网站：系统架构师、搜索架构师、前端架构师、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、多少吞吐量、并发处理多少订单等），大部分时候技术都是被业务在拖着走。于是，技术永远是瓶颈！

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

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

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

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

架构师的能力

当然，无论是架构师或是领域专家，我认为大体上它定位的是一个开发人员在某个领域、行业在知识、技能的广度或深度已经积累到一定程度，那么这样的人一般都是什么样的人呢？

基础：逻辑、抽象、想象

优秀的逻辑思维能力是成为架构师的基本要求之一，这对于大部分开发人员而言一般问题都不大，都是从小受过这方面的大量训练，又选择了程序员这个职业，总体都是不错的。

但出色的抽象能力，却决定许多开发人员未来的上升空间，无论他是从事技术或是业务领域的系统架构，都是需要非常出色的抽象能力，能够把不同的事物从不同维度分析，抽象成合适的模型，并能真正在实践中落地，这是一个非常重要能力。

除此之外，我认为还需要一点想象力，也可以认为是对业务的发展有一些前瞻性，这个能力更加不好评估，且尺度的把握也比较难，但以个人的经验来看，这是一个非常重要能力，否则技术被业务拖着跑的情况会更加严重，开发永远是瓶颈，越往上走对其要求就越高。

这三个能力，我认为是一个优秀的开发人员要成长为架构师、CVT都要具备的基本素质，剩下的就是要有好的心态和大量实战了。

心态：空杯、好奇、实践

IT行业是我认知里产生新名词最多的行业之一，一个简单的AJAX技术都能被行业媒体热炒两三年（当然也因为它才真正衍生出今天的前后端分离的开发模式），每年都有许多新名词，新技术，新的开源框架出现，一种开源框架可以在一夜之间全行业都使用。

这即说明行业的浮躁，但也说明行业更新变化之快，只要你不跟上学习，往往就会被拖下很远一段距离，当然很多原理和方法都是通用的，但有许多很好的实践在每个阶段都不断在行业内传播，也许已经是人所皆知的东西，但是只要你不跟上就很容易被抛弃。

举个自身特别挫的例子，让大家来鄙视一下：2007年开始大概有三年多的时间，我负责一个移动应用部门的产品及研发工作，大部分时间都在忙着项目的事情（当时的手机大部分还是功能机的时代）， 当有一天我和行业内朋友交流客户端集群方案时，连一致性HASH这种半小时就能搞懂的HASH算法，我居然完全没听过，被鄙视是活在古代，知识结构陈旧。很显然我已经被拉下很远了，回家一查居然是1997年就出来的论文，只是一开始在P2P领域应用比较多，传播较少。

所以，我想说的是在工程领域，一个优秀的开发人员，不能抱残守缺，只有谦逊的，保持空杯的心态，不断的向别人学习，才能前进。无论今天你身处什么位置，一定有许多知识片段是你所不了解的，只有在某些特定的领域可能你是专家， 理论上用C语言、最基本的文件系统或者数据库可以解决大部分的系统问题。

但为什么每年会有许多新的语言、框架、数据库、协议、原则、模式等出现，只有保持好奇心，多问为什么，为什么会有这样的东西出现？它解决什么问题？怎么解决？它的缺点是什么？它带来什么新的问题？追根溯源，深入理解，方能有所吸收和成长。

基本素质好，心态也对，剩下的就是扎扎实实的大量实践，在工程领域没有什么比大量实战更能提高开发人员的水平了，哪怕心态再好，再聪明，如果缺乏多年大量一线的实战经验，还是如空中楼阁，谈起理论技术头头是道，但落地上就容易出问题。

许多刚工作几年，本身素质也非常好的程序员就栽在这上面，因为确实素质不错，所以很快就转到了管理岗位，朝夕论道，也逐渐远离代码，走到一定阶段，还是容易被人诟病，实在是很可惜。空杯、好奇、实践，这样的心态应该是成为一个优秀工程人员所要具备的了。

技术的架构

技术的架构领域比较多，无论是较宏观的整体系统架构，还是再细分到某个领域，比如硬件、分布式服务框架、存储、监控平台、甚至算法、引擎等，各类分享的文章也比较多。

架构师不是科学家，更多工作只是在工程领域的实践经验的积累和总结，一个优秀的开发人员，有好的素质，好的心态，再碰到一些好的项目，积累了大量的实战经验，就有机会成为一名不错的架构师。

业务的架构

对业务进行架构虽然比较难以准确描述，因为它没有标准评判，边界并不足够清晰。但要成为这类型的专家，丰富的系统实战经验必不可少，踩过许多坑，经历许多不同的业务场景，让架构人员拥有足够广的视野，许多事物具备共通性，往往是可以相互借鉴和参考，也便于分析梳理业务需求，抽象业务场景，框定系统/模块/服务的边界。除此之外，还要有深厚的技术广度和深度，脱离技术讨论业务架构，就是纸上谈兵，落不了地。

组织的架构

最后聊一下关于技术的组织架构，这并不是讨论架构师岗位的范畴，但架构师和CVT之间就是一线之隔，随时可以转身，所以顺便提一下了。许多时候，CVT往往都是架构师转过来，因为带起技术团队比较轻松，和开发人员讨论问题时不会被翻白眼：）。

但随着业务发展，除了交流能力、协调等能力之外，组织的架构能力尤其重要，组织的划分会决定整个团队的效率，如什么时候组建架构师团队？架构师跟项目还是独立成部？不同职能是否垂直管理还是按功能团队组织？是否需要成立技术支持部门来应对干扰和收集问题？是否需要PMO？业务高速发展，大量进人时，组织架构上怎么快速消化？

跟技术架构一样，没有标准范式，只有根据不同业务场景而变，在不同公司、行业、特别是不同的发展阶段，对组织方式的要求也不一样，有些甚至是反模式的，但是如果有效，也是需要阶段性执行。

后序

以上内容仅出笔者个人的经历体会而成，偏颇极大，如果您不认同部分或全部看法，权当是笑话。所有涉及内容的争议，笔者不回复、不辩论！