史海峰——前贝壳金服小微企业生态CTO，负责小微企业生态金融服务产品规划、技术团队管理、系统建设。曾负责饿了么技术创新部产品研发团队，完成多个创新性业务项目及技术产品。曾在当当负责总体架构规划、技术规范制定和技术预研推广，善于把握复杂业务需求，提出创新性解决方案，参与多个重点项目的方案设计。

— 1 —

架构师的定义

在互联网圈里架构师这个名号的火热程度堪比产品经理，在产品经理没火之前就已经风生水起。乔布斯是苹果的产品架构师，比尔盖茨是微软的首席架构师，马化腾也号称腾讯的首席架构师。

有些人会觉得架构师很神秘，不知道整天脑袋里在想什么。

那么架构师到底是什么样的人？

聚焦到IT技术领域，基本可以还原，架构师的本质就是更高级更资深的程序员，架构师的能力要求在程序员或者说工程师之上，是一脉相承，有延续性的。

有些大厂因为层级较多（当然也是有更顶尖的人才），高级工程师跳到小厂做个架构师游刃有余。

所以我们并不纠结于工程师进阶架构师的边界到底在哪里，实际上有的公司架构师是正式职位，有的只是项目的临时职务。

架构师是足够复杂、规模较大的系统才需要的角色，当系统架构不那么一目了然，才需要有人在更高的视角上去关注整体性的东西。

架构师是高阶职位，难以通过培训批量生产，严重依赖于个人的工作经验和成长，而且各方面都要求更高。

架构师的经验体现在什么地方呢？举一个例子：

比如一个复杂的分布式系统，时时刻刻处理业务请求，要设计一套机制，保证所有的业务都能处理完成，无论成功失败。

简单的开发思维会考虑，尽可能的捕获异常，给每一种错误类型编号，中途失败的流程要进行回退，相信设计能覆盖所有情况。

有经验的架构师则会清醒的认识到，这样的系统随着不断升级和持续运行，一定会出现各种各样的问题，不出问题是不可能的。

应用的潜在bug、业务逻辑漏洞、数据异常、网络抖动、硬件故障、人工误操作，甚至还有莫名其妙未能找到原因只能归结为灵异事件的问题，会层出不穷，等你解决。

我们需要做的是尽可能监控、捕获到异常情况，通过技术手段修复多数的问题，少数不常见的或者难以自动解决的问题最终还是要考虑通过人工方式处理。

我们的目标是解决问题，通过分析，调整架构，优化逻辑，旧的问题解决后，还会有新的问题。

只要系统运行，就需要维护，软件工程理论中系统上线后期维护都是一个重要的阶段，此时系统是动态的，业务是连续的。

用近几年很多人用过的比喻，开着飞机修飞机，开着火车修火车，在原有的系统上做修改，并不比从头做一个系统轻松。

就像是CAP理论下，多数的选择是最终一致性，即通过努力，无限趋近于问题最小化，时刻准备着迎接新问题，动态平衡才是系统运行的常态。

用七句话总结我对架构师的定义：

以工程思维全面理解业务需求

基于模型和基础模式抽象简化

提出恰当可行的整体解决方案
在限定资源范围完成明确目标

满足业务需求且保证系统质量

在可预见的周期内具备扩展性

并在系统生命周期内持续演进

以上只是描述了架构师本身，实际工作中还有许多干系人，包括了项目经理、业务需求提出方、产品经理、研发工程师、测试工程师、运维工程师、DBA及各部门各层级的管理者，在一些外部合作的项目中还包括其他公司的各类人员。

项目由相关干系人组成的团队完成，架构师必须与其中各类角色协作，以达成项目目标，因此要有很好的综合素养，对于相关干系人的职责必须有深入理解，熟悉项目操作流程，能够与各方做好沟通。

比如现在都推行敏捷开发，快速迭代，一般的需求，小的敏捷团队就可以实现，架构师可能不会参与，怎样保证设计开发的质量？

更远一点，怎么保证在诸多小团队各行其是的情况下，整体架构的合理性、先进性，甚至推进架构演化？

这其中会有很多流程外的沟通交流，架构，不是编码规范、设计原则、技术框架，更多的时候是通过各种沟通，尤其是非正式沟通，所达成的共识。

这个共识越清晰，沟通成本就越低，工作就越高效，产品质量就越有保证。

— 2 —

架构师的核心价值

如今是一个互联网+的时代，系统架构有哪些特征？对架构师有怎样的要求呢？

第一，技术开源化

开源已经成为互联网技术的主流，多数公司使用开源技术，自行选型维护，出了问题自己解决，而且技术更新很快，需要能够高效学习快速上手。

开源的技术流，与大众创业、万众创新一样，充分发挥创造力，各种风险和坑也都由使用者来买单。

第二，产品敏捷化

业务调整快，小步快跑，快速试错，必然弱化长期规划，创业公司可以先上MVP，已经上规模的公司怎么保持活力？
可以将新的业务做成独立的模块，解耦，降低依赖，更重要的是时刻关注架构的灵活性，有备无患。

第三，服务全网化

面向全网用户，随时提供服务，系统规模大，停止服务就会损失收入，要求尽可能无缝升级。

业务不可控性较大，业务量可能很大波动，一旦业务爆发，要有快速的弹性部署方案。

第四，系统复杂化

难免有很多的临时方案，以及有用没用的功能堆积，会使系统的可维护性，架构合理性越来越差。

系统的交互越来越多，关联性强，需要工具结合系统机制进行管理，否则就会失控。

第五，人力高效化

根据摩尔定律，基础设施成本日趋廉价，而人工成本则持续走高，这是两个必然方向。

那么就需要提供更好的技术平台，好钢用在刀刃上，技术人员的能力要求越来越高，高效做有意义的事，简单重复的东西让机器去做。

在互联网+的时代背景下，架构师的核心价值是什么？

借用李智慧老师《大型网站技术架构 核心原理与案例分析》中的说法：

软件架构师的最大价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自于架构师对业务场景的理解、对人性的把握、甚至对世界的认知。

在技术团队中，架构师是技术的领导者，没有人辅导，手把手教更是不可能，必须对最终设计和实现负责。

多数情况下，架构是一种妥协，一种平衡的产物，掌握这个平衡度的，就是架构师。

我们都知道，理想的架构是什么样的，但又必须抱残守缺，面对现实，提出可行方案。

因此，架构师是胸怀理想的现实主义者，高度在理想，落地在现实，绝对是有挑战，有难度。

— 3 —

架构师的核心能力

对于架构师的核心能力定义，《软件架构师的12项修炼》中有一张图，可作参考。

周爱民老师也曾经在《程序员》上发表过《做人、做事，做架构师——架构师能力模型解析》。

就我的个人总结，架构师的核心能力包括六个方面：

做一个合格的架构师，需要各方面能力都比较强，不能有明显的短板。

其中技术能力和业务能力属于硬指标，可以通过学习和工作，跨过行业门槛获得。

这里主要分析下后四种，可称为通用技能，对于团队协作的技术职位都是需要的。

前三种是内功，用汽车比喻的话，自我驱动能力相当于发动机，高效学习能力则是方向盘和变速箱，良好心态就是悬挂和制动系统。

沟通协作则是外功，最终的外在体现，内功与外功两者之间就如同内因和外因，起决定作用的是内部因素。

1.自我驱动能力

这是一种特质，简单说就是有上进心，不甘于混日子，闲不住，爱钻研，始终有目标性的追求，有很强的自控力。

这种动力来自于兴趣，比如对技术的热爱，就是喜欢。

每个人都有自己的兴趣点，可能不是IT技术，找对自己的方向很重要。

而且喜欢不一定就能做好，有时候努力够了，成就要看天分，发现对自己不合适，干活没劲头，不如及早调整。

具备这样能力的人一般都很明显，做事努力，用心，进步很快，相信大家在工作和学习过程中都遇到过。

举一个加班的例子吧，搞IT的加班很常见，甚至可能许多人并不是真心愿意加班，但一定有很多人有这样的经历。

就是碰到一个技术问题，哪怕工期上没有那么紧迫，也要盯着它，甚至不吃饭，不喝水，绞尽脑汁要整明白，死磕到底，搞定为止。

自我驱动力表现在了这种高度专注的精神，遇到问题斗志昂扬的冲劲，解决问题的成就感之上。

前阵子网上流传一篇励志帖子《我前妻的故事（一个初中肄业生的奋斗）》，其中的前妻就是自我驱动力非常强悍的典型代表。

2.高效学习能力

IT技术需要不断学习，持续更新，真正的学习，是要靠自己的，要把学习养成习惯。

架构师很多时候要快速切入一个不熟悉的领域，必须要有高效的学习能力。

有些人会抓住一切机会学习，比如我的同事张亮同学，等待面试的时候还拿着一本技术的书在看。

在同等的时间里，怎样能最高效的吞吐量，获得更多的有价值的信息量，并沉淀为自己的能力，就需要正确的方法。

每个人都有自己的特点，需要找到适合自己的学习方法，方法得当，事半功倍。

那么学习的过程，也是一个不断发现自我，形成模式，目标导向，反复强化，不断调整的过程。

比如曾经有位振坤同学，每天下班回家，还要英文原版的书，在家钻研技术到后半夜，形成了习惯，成效自然显著，后来去了百度。

《从学渣到学霸-我的100天阅读简史》，可作为学习的借鉴。

3.保持良好心态

N年前，曾经流行一句话，心态决定一切。

TVB有句经典台词说得好，做人呢，最重要的就是开心。

积极正面的阳光心态，是把事情做好的基础，因为工作中难免有意外和波折，不会一帆风顺，好心态能够为你保驾护航。

好心态一般什么样呢？谦虚平和、宽容、有韧性，活在当下，内心强大。不是说你是架构师就高人一等，要凭实力说话。

这其中还包括责任心，决定了心态的方向。

比如我就认为，敬业是职业化的体现，那么无论是否处在已经即将离职的状态，都应该做好自己的职责，做一天和尚撞一天钟。

4.善于沟通协作

架构师处在团队中，且属于技术核心角色，必须做许多沟通配合的工作，而且要做好，做到位。

这其中有几方面需要强调，首先是团队精神，架构师不能个人英雄主义，团队的存在就是因为能做到比个人更好，团队的成功才是最终的目标。

团队成员各有千秋，合作愉快的基础是理解万岁，消除沟通障碍，架构师在这方面有更大的责任和义务。

技术人员相对简单直接，也容易认可技术上的原则，以诚相待能够最大程度上降低沟通的成本，事情说清楚就好。

而成就他人是一个技术领导者必备的素质，相信互惠互利，我为人人，人人为我，甚至要把更多的机会给别人，吃独食的人难以服众。

— 4 —

架构师成长四要素

架构师进入新的团队，要成长，要成事儿，时间线如上所述，如果换一个视角来看这个过程，有四个要素：学习、适应、合作、驱动。这四个要素也是层层递进的关系。

第一，学习，了解业务现状，了解行业，要有行业视野，知道行业历史和发展方向；

第二，适应，融入团队，团队氛围什么样？有哪些工作流程？组织是一个什么架构？管理风格什么样？怎么做决策？

第三，合作，跟团队形成合力，产出成果，不断的沉淀一些东西出来，积累信任。

第四，驱动，需要多分享、做一些铺垫和引导，提高影响力，获得认同，形成共识，一起达成目标。

怎样学习？

我去当当是做电商系统架构，之前没做过，作为消费者，只有一些很浅薄的认识。怎么办？主流的电商网站都打开对比看区别是什么，有点像产品经理做竞品分析。做架构更要深入理解业务，不只是看功能、流程的差别，要去理解内部机制和外部市场的异同。当时多数电商网站都差不太多，暖色系主题，刺激消费欲望，只有当当是绿的，还有不走本地化路线的亚马逊。后来当当也改成了红色主题，还把“网”去掉了。为了体验和感受电商，我在各大电商都下了不少单，最多的肯定是当当，买了不少书，有些至今未开封。

还有一个途径是看行业的书或者视频，当时电商的书很少，不像现在一搜一大堆，基本上能找到的书我都看了，还好也不多，不用挑。《电商风云》是纪录片，吴晓波策划，中央2套拍的，一共7集，挺好看。新进入一个行业，要从各个维度去找权威的人、权威的书或者权威的媒体，最好是成体系的。看书不能只看书的内容，得知道作者是谁，有什么背景，要用系统化的思维去吸收理解。左边的图是一个文件目录列表，是参加各种技术大会收集到的PPT材料。我们在当当文件服务器上建了个共享文件夹，大家都往上传。这些资料能开阔视野，如果关注一个专题，比如风控，可以直接搜，看看都有谁讲过，是哪个公司的。有些大会的视频回放会放到网上，看过PPT觉得好，还可以找找有没有视频，因为说的更详细。当然要是认识其他公司的相关负责人，直接去交流效果更好。

怎样适应？

一般正规的公司都有内部通讯录，能够看到组织架构，扫一眼就能有一个感性的认识。再进一步可以看这些部门都是干什么的由谁负责？自己在哪个部门，上级的上级是谁，有哪些平行部门？甚至可以看到同事职级，做到心中有数。

多参与、多观察、多发声。右边这列是我参与的一些项目，里面是相关文档，参与项目多了对整个系统和相关团队会有更全面的认识。刚加入还是个新人的时候，一定要多了解，不懂就问。好记性不如烂笔头，中间这个图是我在当当4年多用过的笔记本。有些同学习惯用电脑管理日程、记笔记，都电子化，也没问题。还要及时总结，比如我在2013年跟架构师赵振林，画了一个当当的系统架构总图，把100多个系统都串了起来，填补了这方面的空白。

这张图是一个总结，当时我在当当已经一年5个月了。有了这张图，当当的系统不再是一朵云，再把所有系统的负责人拉出个列表，我就是对于系统架构和团队最了解的人。2013年到2014年，我认识当当所有的技术经理，几乎认识所有的技术核心骨干，即便跟一些同事打交道不多，至少也是点头之交，知道他是做什么的。

怎样合作？

合作本身比较软性，分几方面讲。首先得有热心肠，多帮忙，不求名利，重在掺和，如果没关系的事都不搭理，形不成合力，就算热脸贴冷屁股，也要表明态度。搞技术大家比较追求完美，实际上资源和时间有限，或者大家理念不同，就得妥协，妥协的进步也是进步，就算没有进步，促进了相互了解也有价值。得摆正心态，不以专家自居。谁也不是全能选手，不必因为自己是架构师就必须永远正确，要平等交流，对于很多系统的细节，直接负责人一定是最了解的。在非正式场合，大家可以一起吐槽，一起吹水，关系会更融洽。大家一起工作，最终是要出成果，用成果积累信任，有了信任才能更好合作，出更多成果。

这张图是什么？是我参与项目之后，留下的遗憾或者发现的问题，在后续的项目合作中，可以提出来，大家有针对性的一起解决，这样也更有成果。

怎样驱动？

架构师作为公司里的一个角色，有自己的职责，成果体现了价值。该做的事情要勇于承担，争取资源和主导权。有时边界的确不清楚，但如果觉得一件事该做，就要有所考虑。多分享，不一定非得是自己的心得体会，也可以是参加了外面的技术大会，或者学了一个课程，都可以公开分享。一方面混个脸熟，另一方面让更多的人了解自己认同的东西，可称为布道。可以作为讲师参加新员工培训，给新员工介绍公司的架构和自己的理念、原则，第一印象很重要！为他人的成就喝彩，为整体的进步鼓掌。不一定非得自己做才值得夸耀，大家都是同事，是一体的，大家好才是真的好。想推动一些事情，得去影响关键节点，一般来讲，就是组织结构里的关键负责人。理解他遇到的问题是什么？他的想法是什么？这个事情有几种方案？最好提前有所交流，能达成一些共识，真正做决策的时候就容易得多。有了成果要走出去参加行业分享，是骡子是马拉出来遛遛，既能展现公司水平，还能树立个人品牌，提升在公司内部的影响力。

架构师技术领导力的成长过程，不管是做事能力还是认知方面，都遵循了点线面体的规律，曾鸣、梁宁、罗振宇都提到过这个概念，右军老师也专门写过公众号文章。这是正常的成长过程，如果倒着来的话会很痛苦。如果降维用关注圈、影响圈、控制圈平面层次来看，成长就是三个圈越来越大的过程。

— 5 —

架构师的四门功课

架构设计是一门艺术，架构师作为架构设计的实践者，要掌握四门功课，不是说学逗唱，而是：多打酱油，能和稀泥，肯背黑锅，敢拉仇恨。

1.多打酱油

互联网公司普遍存在人员流动性强，缺乏文档的情况，而架构设计偏偏需要全方位考虑问题。

我就曾经遇到过这样的事情，一大帮人开了俩小时的会，终于讨论出一个都能够接受的可行方案，结果第二天有个没能参会的人回了个邮件，说他们有问题趟不过去，原来的方案得推翻重来。

技术最重要的一点就是复用，不重复造轮子，如果有的功能或者组件别人做过，拿过来用是最方便的。

所以架构师必须消息灵通，覆盖全面，知己知彼，收集问题，尽可能了解全局。

多打酱油什么意思，无论是否由你主导，主要的项目都要保持关注，多参与，多积累才有发言权。

这个过程中要不装不拿，不懂多问，谁也不是全才，不必急于表达自己和做出判断，谋定后动。

打酱油不仅获取信息，还要输出信息，哪怕事不关己，可以建议，但不能指手画脚，获取沟通的最大收益，形成技术部门共识。

一般来说，男同学都是单线程思维模式，要达到最好的效果，打酱油的时候也要专注精神不分二心。

当然也有奇人能够做到并发处理，比如我的前同事老王，时间分片高频切换事务处理输入输出，堪称一台人形电脑。

当当技术部原来有一个开会的潜规则就很好，除了产品经理和项目经理，其他人开会都不带电脑，只拿笔记本。

2.能和稀泥

架构的核心在于平衡，实用导向，最终要提出解决方案。

那么就需要在这个过程中综合考量，化解争论，对事不对人，规避面子问题，努力充分沟通，达成共识。

充分了解各方意见，设身处地理解本质问题，提出多种方案，客观的列出优缺点，以供决策。

但有时也有化解不了的矛盾，无论是基于技术理念、设计思路、自身定位还是意气之争，有时搁置也是一种可选项，比如邓小平对钓鱼岛、台湾问题的处理方式。

之前有一个项目，我们提出的方案某个系统开发负责人不认可，期望用另一种实现方式，那我们就把两种方案都拉出来对比，每个系统的改动难度、问题都说清楚，最终对方还是接受了原来的方案。因为综合考虑，这才是最优解。

3.肯背黑锅

能力越大，责任越大，想做事就要有勇气担责任，担风险，逃避责任是难有成就的。

举个例子，曾经有一个紧急的需求，交给了一个同事，快上线的时候撂挑子说干不完，领导找到我，问能不能干。

这种情况，时间紧任务重，要是接了没干出来，黑锅就落在自己身上，但需求总要有人做，领导的信任更不能辜负，任务接下来干好了，后面就不必说了。

架构师作为主导，要清醒的意识到，需求和状况总是变化的，总有考虑不周的，总有难办的有挑战的，总有不确定的各种风险，需要坚持推进达成目标。

如果推进不成或者发现之前的判断甚至决策失误，适时调整，不必钻牛角尖，也要坦然承担失败的责任，这也是一种宝贵的经验。

作为一个技术团队，可能出现问题并非直接责任人是架构师，不必非要划清界限，团队的失败，也是每个人的失败。

最后要清楚，谋事在人，成事在天，事在人为，但要的确可为，明知不可为而为之，不是明智之举。

4.敢拉仇恨

架构师要面对很多挑战，技术人员都很有想法，都认为自己伟大光荣正确，不会因为你是架构师就乖乖地听话，要以理服人。

一个设计方案的出炉，可能需要像诸葛亮一般舌战群儒，说服很多人。

我遇到过这种情况，明明是好事儿，做起来也不难，就是有人不接受，不愿意做。

那就需要坚持主张，胸怀坦荡，没有私心，正直诚实，打开天窗说亮话。

即便大家很熟，也不能抹不开面子，不讲原则。

要注意一点，虽然真理经常是掌握在少数人手里，但要让多数人接受，不能被接受的真理也是没有价值的，可能就不是真理。

所以架构师可以力排众议，但不能成为千夫所指。

比如我们经常遇到时间紧迫要做临时方案，不考虑扩展性，如果同类的业务模式重复出现，再做临时方案虽然大家都轻车熟路，却不是一个好的选择。

因为有再一再二，就会有再三再四，只要把握住这一点，尽早进行架构改造，实现后就能快速响应后续的同类需求，这也体现了架构师的价值。

当你做的正确的事情多了，才会与团队磨合，获得大家的信任，而不是怨念，逐步树立自己的权威，从此可以跟小伙伴们一起愉快地玩耍了。

如果你对以上内容意犹未尽，欢迎来到7月3-4日深圳举办的K+全球软件研发行业创新峰会，史海峰将作为“恰如其分的架构设计”专题出品人，牵手去哪网架构师王鹏；阿里巴巴技术专家、阿里云SLS任务调度系统负责人潘伟龙，为大家带来《去哪儿网分布式链路追踪系统实践》、《亿级异构任务调度框架设计与实践》等精彩议题。

感兴趣的同学请点击下方阅读原文了解峰会详情，现在报名参会，还可享受早鸟优惠价哦！

另外，史海峰老师和峰会演讲嘉宾钱勇老师还受邀作客由K+峰会独家冠名的线上直播节目K+Talk，感兴趣的小伙伴赶快扫码预约免费观看吧，直播间还有重磅福利等你来拿！