架构师的自我修养(转)

架构师的定义

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

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

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

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

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

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

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

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

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

比如一个复杂的分布式系统，时时刻刻处理业务请求，要设计一套机制，保证所有的业务都能处理完成，无论成功失败。
简单的开发思维会考虑，尽可能的捕获异常，给每一种错误类型编号，中途失败的流程要进行回退，相信设计能否覆盖所有情况。
有经验的架构师则会清醒的认识到，这样的系统随着不断升级和持续运行，一定会出现各种各样的问题，不出问题是不可能的。
应用的潜在bug、业务逻辑漏洞、数据异常、网络抖动、硬件故障、人工误操作，甚至还有莫名其妙未能找到原因只能归结为灵异事件的问题，会层出不穷，等你解决。
我们需要做的是尽可能监控、捕获到异常情况，通过技术手段修复多数的问题，少数不常见的或者难以自动解决的问题最终还是要考虑通过人工方式处理。
我们的目标是解决问题，通过分析，调整架构，优化逻辑，旧的问题解决后，还会有新的问题。
只要系统运行，就需要维护，软件工程理论中系统上线后期维护都是一个重要的阶段，此时系统是动态的，业务是连续的。
用近几年很多人用过的比喻，开着飞机修飞机，开着火车修火车，在原有的系统上做修改，并不比从头做一个系统轻松。
就像是CAP理论下，多数的选择是最终一致性，即通过努力，无限趋近于问题最小化，时刻准备着迎接新问题，动态平衡才是系统运行的常态。

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

以工程思维全面理解业务需求
基于模型和基础模式抽象简化
提出恰当可行的整体解决方案
在限定资源范围完成明确目标
满足业务需求且保证系统质量
在可预见的周期内具备扩展性
并在系统生命周期内持续演进

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

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

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

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

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

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

架构师的核心价值

如今是一个互联网+的时代，系统架构有哪些特征？对架构师有怎样的要求呢？
第一，技术开源化
开源已经成为互联网技术的主流，多数公司使用开源技术，自行选型维护，出了问题自己解决，而且技术更新很快，需要能够高效学习快速上手。

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

第二，产品敏捷化
业务调整快，小步快跑，快速试错，必然弱化长期规划，创业公司可以先上MVP，已经上规模的公司怎么保持活力？

可以将新的业务做成独立的模块，解耦，降低依赖，更重要的是时刻关注架构的灵活性，有备无患。

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

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

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

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

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

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

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

借用李智慧老师《大型网站技术架构 核心原理与案例分析》中的说法：
软件架构师的最大价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自于架构师对业务场景的理解、对人性的把握、甚至对世界的认知。

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

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

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

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

架构师的核心能力

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

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

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

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

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

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

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

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

1.自我驱动能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.保持良好心态
N年前，曾经流行一句话，心态决定一切。

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

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

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

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

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

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

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

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

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

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

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

1.多打酱油

互联网公司普遍存在人员流动性强，缺乏文档的情况，而架构设计偏偏需要全方位考虑问题。我就曾经遇到过这样的事情，一大帮人开了俩小时的会，终于讨论出一个都能够接受的可行方案，结果第二天有个没能参会的人回了个邮件，说他们有问题趟不过去，原来的方案得推翻重来。技术最重要的一点就是复用，不重复造轮子，如果有的功能或者组件别人做过，拿过来用是最方便的。

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

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

这个过程中要不装不拿，不懂多问，谁也不是全才，不必急于表达自己和做出判断，谋定后动。打酱油不仅获取信息，还要输出信息，哪怕事不关己，可以建议，但不能指手画脚，获取沟通的最大收益，形成技术部门共识。

一般来说，男同学都是单线程思维模式，要达到最好的效果，打酱油的时候也要专注精神不分二心。当然也有奇人能够做到并发处理，比如我的前同事老王，时间分片高频切换事务处理输入输出，堪称一台人形电脑。

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

2.能和稀泥

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

那么就需要在这个过程中综合考量，化解争论，对事不对人，规避面子问题，努力充分沟通，达成共识。充分了解各方意见，设身处地理解本质问题，提出多种方案，客观的列出优缺点，以供决策。

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

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

3.肯背黑锅

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

举个例子，曾经有一个紧急的需求，交给了一个同事，快上线的时候撂挑子说干不完，领导找到我，问能不能干。这种情况，时间紧任务重，要是接了没干出来，黑锅就落在自己身上，但需求总要有人做，领导的信任更不能辜负，任务接下来干好了，后面就不必说了。

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

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

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

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

4.敢拉仇恨

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

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

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

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

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

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

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

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

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

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