其实这篇文章和一号专车重构那篇是在同一周末一起写的，这篇文章写在前面，写着写着就想把当时一号重构经历的那些开发过程，写出来和这篇文章相互印证，但结果是重构的文章先发了出来。这几天也有不少非研发领域的朋友在问一些关于研发或是架构的事情，让我挺惊奇，所以除了工程人员之外，这篇文章也给各个奔跑在创业路上的业务及管理人们一些参考。而我做为一个长期在一线的程序员，在技术领域并没有什么建树，如果整天不写代码，而是琢磨着写文章到处吹水，本身是一些颇为可耻的事情，写稿子这个事情到此为止，下不为例吧！

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

什么是架构师？

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

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

为什么是架构师？

每次付款的时候，热情的小伙子都特别不好意思地对我说：“哥，我又升职了，价格涨了！”， 人还是那个人，理发水平对于男性而言大体也看不出多大差异，但头衔从理发师变成发型设计师、高级发型设计师、设计总监、高级设计总监、首席设计师、沙宣首席设计师，当价格一路涨到和天罡北斗一个级别的时候，我终于忍无可忍的换到离住地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语言、最基本的文件系统或者数据库可以解决大部分的系统问题。但为什么每年会有许多新的语言、框架、数据库、协议、原则、模式等出现，只有保持好奇心，多问为什么，为什么会有这样的东西出现？它解决什么问题？怎么解决？它的缺点是什么？它带来什么新的问题？追根溯源，深入理解，方能有所吸收和成长。

基本素质好，心态也对，剩下的就是扎扎实实的大量实践，在工程领域没有什么比大量实战更能提高开发人员的水平了，哪怕心态再好，再聪明，如果缺乏多年大量一线的实战经验，还是如空中楼阁，谈起理论技术头头是道，但落地上就容易出问题。许多刚工作几年，本身素质也非常好的程序员就栽在这上面，因为确实素质不错，所以很快就转到了管理岗位，朝夕论道，也逐渐远离代码，走到一定阶段，还是容易被人诟病，实在是很可惜。空杯、好奇、实践，这样的心态应该是成为一个优秀工程人员所要具备的了。

技术的架构

业务的架构

组织的架构

后序