你眼中的架构师是什么样的？

编者按：本文来自微信公众号“InfoQ”（ID：infoqchina），作者王福强；36氪经授权发布。

写在前面

人人都在说架构师， 但又好像每个人的理解都不一样，任人难辨。 今天扶墙老师正好借“大咖说”的宝地， 好为人师一把， 笑侃自身的架构师经历，跟大家分享一下自己对架构师的认知，不管你是在山底，山腰亦或山顶，都希望对志在攀爬“架构师之山”的同学有所帮助。

我的架构师之路

我职业生涯前期最典型的阶段是在英极软件（大连）， 这是一家在大连只要有人提起就会“骂娘”的公司， 因为现在互联网行业很普遍的 996， 其实我在英极的时候就早已习以为常了， 那时候是 2006 年。 很多人都埋怨累， 我听说有的人入职之后，第二天就离职的。

 我当时进英极完全是凭着一股倔强， 因为当时有个很多国人瞧不上的“小日本儿”，o， 不，是“老”日本儿， 一天只睡几个小时， 但给出的式样书详细到伪代码级别，而且基本没有错误， 当时的 CTO 老王跟着这个日本人对应“厮守”了好几年了，基本也是这种工作强度，我年纪轻轻的不能输啊...

在英极的工作中， 处理 Excel 报表是很典型的一个场景，大家都是按照日本人给出的 Excel 报表样式，用 POI 直接写代码画表格并填充数据，后来，我哪天脑子“抽筋”， 就换了种工作方式， 将日本人给的报表样式文件拿过来清理后，作为模板读到程序里，然后直接通过少量代码设置数值就可以了， 效率大幅提升，后面大家就都依葫芦画瓢照着来了， 这算是我做的最小粒度的架构设计了吧。（后面进一步使用 ireport，crystal report 之类的方案，那就更是后话了）

虽然那时候我的 Title 或者 Level 是 Java 程序员，但其实已经在行使架构师的职责了。

2009 年 6 月 23 日入职了阿里巴巴平台技术部， 先后参与并主导了 ROMA Web 框架， EROSA 和 EROMANGA 中间件的设计，开发和推广工作， 职称也从高级 Java 工程师，变成了技术专家和高级技术专家，但其实行使的也是架构师的职能：

• ROMA 是去架构一个 framework 粒度的程序框架，当然，很多思想是从 SpringMVC 打碎骨架重新拼接出来的；）

• Erosa 处理 MySQL 的 binlog 复制， 通过考虑复制链路上下游的系统和用户， 来架构一个通用的数据产品；

• Eromanga 是在 Erosa 的场景下结合最早期的 Kafka 思想架构的消息中间件，可以称为一个独立运行的完整的软件系统和产品；

这个阶段，我是处理框架和系统粒度的架构师。

如果说作为技术架构师在后面得到大家高度认可的话，那么， 在阿里巴巴平台技术部的日子不可磨灭， 戏谑点儿说，现在都是在吃那段时间的老本儿 ；） 没天没夜的啃英文 papers 和 ebooks， 而这些很多资料都是 2-3 年后才会在国内看到。

2012 年阿里集团内部整合， 我转岗到了天猫， 负责导购部门的整体架构工作。 从技术层面来说，导购系统大多是围绕着搜索和推荐系统进行构建； 但从整个导购部门职能来说，需要关注的就不单单是技术就可以的了。

除了连接投放平台， 运营平台等核心导购系统形成导购系统生态链，还要去了解流量，用户，商品，组织结构等不同层面的概念和资源， 虽然其中负责的 SEO 事情没有做起来（商业上的事儿，自己意会 ^_-），但却实实在在提升了自己在架构层面的认知， 你不再只单单关注技术， 你还要去关注商业， 组织结构，人等更大范围的知识域。

架构粒度不再是单一软件系统，而是多个软件系统 ; 架构的关注域也不再单单是技术，还有技术之外的事物。

2014 年加入挖财，因为在大连就一直是围绕着金融做系统，技术上也早有储备，算是回归舒适区吧。一进挖财就进了小黑屋， 从最早带人写代码， 跟项目进度，协调人员和资源， 到后期的团队组织和管理， 算是经历了从几十个人到 2016 年离职之前 700+ 人的成长阶段。 这个阶段的架构粒度有前期的框架， 系统，技术生态，也有后期的组织， 文化和团队管理。

虽然 2016 年离开挖财有很多原因，但 最核心的因素可能是认知和职能的不匹配， 所以， 选择开启了新的征程， 选择了创业。

我个人的整个架构师之路大体上是这个样子。

前阵子 51 信用卡的孙总希望我作为 CEO 来运营一家子公司，虽然 CEO 确实是我作为架构师的下一个目标， 但股权结构让我很难心理上“断奶”，所以，为了继续对自己狠一点， 我还是回绝了这个 offer， 但还是很感谢孙总的信任。

我眼中的架构师类型

很多同学一定疑惑了， 我们不是在谈架构师吗？ 怎么扯到 CEO 上了那？ 其实，架构师只是一种职能，职位或者 title 与职能并不冲突。

架构师其实有很多种类型， 最典型的要数支付宝的鲁肃。想当年他的一篇 ppt 将支付宝的整体架构演变阐述地深入浅出， 扶墙老师看了之后，简直就是膜拜有加。只可惜，当年可以跟随大咖的机会没抓住， 悔之晚矣， 而鲁肃也从当初的支付宝首席架构师变成了现在蚂蚁金付的 CTO， 架构师之路上继续前行...

为什么说架构师之路上继续前行那？ 因为 CTO 也是架构师。

作为一位不写代码的 CTO， 冯大辉其实是被冤枉的。CTO 负责的是整个技术部的架构， 包括但不限于团队的组织结构， 团队文化， 人员的选用育留，薪酬福利等等， 不一而足， 同时还要协调产品， 市场等不同部门的工作，所以， 写代码已经不是 CTO 的核心能力和评估标准了， 如何架构好技术部门并协调其它部门，从而很好的支撑公司的业务发展才是 CTO 作为技术部的总架构师的核心职责。 所以， 大辉兄，你受委屈了 ；）

话说回来， 有些 CTO 偶尔写写代码，那也是一种乐趣，比如我们平台技术部的老大 (当年阿里的 P11)，偶尔还写写 golang 那，但你不能把写不写代码当帽子扣给所有的 CTO 啊，对吧？

马云老板其实也是架构师， 他是阿里这个商业帝国的架构师， 现在估计所有人都不会怀疑他在商业和战略上的架构能力。

查理芒格是我的第二代偶像（啥？ 第一代是谁？ 李小龙呗！），也是一名架构师， 他通过驾驭不同领域和学科的知识来帮助巴菲特架构商业投资生态。查理芒格的典型概念主张叫 lollapalooza 效应，是说一旦你可以连接和融会贯通不同领域的知识， 就可以形成一种强大的悟的效应， 而这恰恰是架构师最应该向往的境界。

《硅谷》不知道有多少人看过？ 里面的 Peter Gregory 这个人物给我留下了很深的印象。当某公司两个创始人去找他融资的时候， Gregory 呆木木的坐着喃喃私语遐想了估计 n 个小时，最后直接下了一个交易单， 就为这两个融资者挣到了需要的融资。 Gregory 属于典型的深度思考者， 他能够在深度思考过程中将事件连接，并架构好一个交易链条，从而完成最终的商业目的。 跟亮哥运筹帷幄应该有异曲同工之妙吧！

再高一层级的架构师要数我们的邓小平邓老了， 国家层面改革开放的总设计师，也是总架构师， 牵动的资源粒度更大，还能在几十年的时间窗口内推动落地， 这架构师绝对牛！

可以看到， 架构师随着他能够处理的架构域不同而不同，架构师也有不同的类型和段位，如果你还在为架构师应不应该写代码而斗嘴，那你应该反思一下自己的架构认知了。

我认为架构师须有的核心能力

Connect Everything

我觉得架构师的核心能力是连接一切的能力，架构师的 Slogan 应该是“连接创造价值”。

现在网上或者书本里，更多是在推崇一万小时定律之类的理论， 你只要相信一万小时定律，你就可以成为某个领域的专家，你在职场就可以成为骨干平步青云，可是， 为什么很多 CEO 或者公司老板既不是专业人士，也没有勤勤恳恳打磨自己的技能，却是 CEO 或者公司老板？ 因为没有人会告诉你， 除了一万小时定律， 还有“连接创造价值”的架构师之路可以选择。

• 图计算里的图 Node 固然突出，但离开了 Edge， 还称得上什么图， 产生得了什么价值？

• 电话和移动设备固然重要，但离开了电话线和光纤的连接， 也只能当摆设；

• 人群聚集的社区和城市固然重要， 但离开了路的连接，那也只能鸡犬相闻，闭关锁国了；

专家也好，架构师也罢，都重要，但在大多数人不能确切的理解架构师的情况下，扶墙老师我不得不为架构师代言啦 ;o)

Eager To Learn

一万小时定律本质上其实是针对同类可重复的事物进行重复性打磨和深入， 但架构师要做的更多是面对未知和新生事物， 所以就需要架构师能够持续学习，才能胜任这个职能。

做架构师不比做专家轻松， 你要持续的学习不同领域的知识， 你要不停的跨界，你要持续的沟通和思考， 只有这样，你才能“搜集足够的素材”， 然后再根据当前场景和目标来进行架构和输出。

Be Open-Minded

我之前很多时候只是在奋声疾呼大家要 Open-Minded， Open-Minded， 但发现效果不好。后来我明白了， 一个人能不能 Open-Minded， 不在于这个人有没有这个意识， 而在于这个人有没有经历。很多时候， 光有意识是不够的， 必须自己去经历过，撞过南墙，然后才能逐步变得开放（Open-Minded）。

记得一次跟杭州氦氪科技的 CEO 聊天， 说道他们的 CTO 自从跟他一起出去跑客户跑市场之后就变得好沟通多了， 我们俩都不禁会心一笑。确实是这个样子， 不让每个人自己去撞撞南墙， 很多时候靠喊是没有用的。

我很喜欢《疯狂动物城》里的那首主题歌《Try Everything》， 受其启发并结合个人经历，自己总结了一句话，送给大家：

Connect the world, meet the people and try everything！

Leadership

单单只是勾画出一幅完美的架构蓝图还远远不够， 一名合格的架构师还要能够领导或者协调大家一起来将这幅架构蓝图落地， 能否落地，能落地多大的架构蓝图， 往往考验的就是一名架构师的领导能力。

在不是很复杂的架构域内， 架构师单凭谋事之心一般就可以成事了，但一旦牵扯复杂的架构域， 要谋事且成事，就需要架构师兼有谋人之心， 做到政教合一往往更是可以事半功倍。 不过， 总体上来说， 领导者不是管理者， 谋人谋事，最好是做到“心简单，脑子复杂”就可以了。如果你愿意追求更高段位，那对随之而来的痛苦和困难要有心理准备 ；）

人人都是架构师

我觉得架构师跟职位和位置等并没有必然的联系， 任何人在任何场景都可以是架构师， 无非架构的粒度和自我的架构认知不同而已。

我一直在强调一名合格的架构师， 但如果非要我划分更高一档的架构师的话，还有一档卓越的架构师， 而责任， 是走向卓越架构师的必经关卡。