关于架构师认知的一些摘要

架构

按所工作的不同软件层分，有网络架构，系统架构，数据架构，业务架构，应用架构，平台架构等。

按所解决的问题领域分，有电商架构，支付架构，搜索架构，安全架构，性能架构，游戏架构，多媒体架构等。

按其工作的深度来分，有集成架构，业务架构，模块架构，框架架构，中间件架构，软件架构，引擎架构，服务器架构，甚至编程语言架构等。

架构师

架构师必须在熟悉客户需要做什么的基础上，伏下身子带领各个开发团队攻克难题并优化系统组成间的关联。

认真细致、技术全面、善于沟通，技术上深度广度都没问题， 又喜欢这个工作，还会不时做底层实现，从业务和开发两个角度出发，搭出“架构”是为了开发效率，为了运行效率，为了开发质量，为了业务灵活和运行稳定，为了维护方便等等。这样的人，个人认为可以称为“架构师”。

架构师不是随便什么人可以做的，在一个企业团队里，架构师作为研发和管理骨干，具有特殊的地位和权利。

架构师需要具备的基本能力有： 持续学习的能力，不满于现状，坚持不断学习，努力提高自己的开发技术和管理沟通水平，拥有强烈进取心；英语水平能力，据说中国有 700 万码农，英文不好似乎是一个比较普遍的现象。英语，尤其读写不好，把合格的架构师候选人选砍掉一大半。

架构师，程序员， 产品经理的区别，大概就是建筑行业里建筑师，建筑工人，甲方业主的区别。产品经理说我要建这么这么一栋楼，架构师说好吧，我来帮你看看是做成砖木结构还是框架结构，房型怎么设计，水电气怎么布局，预算多少，然后程序员上阵，按照图纸把楼建起来。运营是大楼的物业管理，负责营运大楼。

软件开发越来越成为传统行业（即便在互联网企业），一个成熟的软件团队内部自然会分化出这些角色，各展所长。但非常不同的是，建筑工人很少能自发成长为建筑师，后者都是科班出身，因为建筑学科已经高度发达，需要掌握结构力学，美学等技术，现在软件行业还没有这么高的成熟度，程序员和架构师接受的都是一样的计算机教育，所以程序员可以自学升级到架构师，走一条不同的升级打怪路线。

在设计师的世界观里一切东西都需要设计。软件也需要精心设计，在优秀的程序员眼里，每一行代码都需要架构，都体现了架构。

为了解决问题，程序员自然需要架构，他们中的佼佼者被冠以架构师的名号，获得了一定的话语权，逐步成为一个职业分工。我想，这就是架构师的本来面目。成为架构师，需要经验和眼界。

老码农分为两种：游击队和板凳王。坐穿板凳有利于积累经验，而不利于开拓眼界。游遍四海有利于开拓眼界，而不利于积累经验。

码农要成为架构师的道路还是很漫长的，需要不断的攻克以下内容：

工程协作专题：磨刀不误砍材工，做为程序员也应该选择更为“锋利”的工具，进而提升开发效率和团队协助能力，让自己有更多思考的时间。

源码分析专题：编程人员技术提升最快的方式是阅读和理解优秀的代码，领悟大师级思想，让思想顿悟，目击不一样的风景，提高核心竞争力。

分布式专题：当 Web 系统从日访问5万逐渐增长到1亿时，Web 架构层面需要如何突破访问瓶颈，提高访问效率。

微服务专题：spring、springboot、docker。

性能优化专题：深入内核，直击现下火热中间件性能提升，拒绝理论讲解，让你看到提升的具体数据。

并发编程专题：直击当下火热互联网技术，深入理解多线程本质，剖析底层原理。

电商项目实战：大型分布式电商项目实战，结合当下火热互联网技术的综合运用，多种设计思路、解决方案、架构理念融为一体，全方位提升项目实战能力。

技术掌控力：成为架构师要掌握全面的技术栈，一切技术皆工具，包括开发语言、框架、各种中间件都是工具，要达到熟练使用，了解其原理和长短板，具备合适场景合理选型和灵活运用的能力。在学习方法上，首先需要把所有技术列出来，然后将自己现在所拥有的技术跟这个图表做一个匹配，标出里面哪些熟悉，哪些还有待提升，重点关注那些有待提升的部分。

架构师思维能力：我们常说道与术的问题，架构思维就是架构师的“道”。在这里给大家简单列举几条：

相关信息

第一点：知行合一，做之前，先考虑意义

就是说在做某件事之前，你一定要知道自己的目的是什么。你的目的和你做的事情两者要合一。这是一个层面。 第二个层面是清楚地知道你手里的资源允许你干什么事。比如说 Spring Cloud，我很想去用，但是我的团队 hold 不住，你强行把这个东西推下去之后，事情做的并不成功。结果还是需要你承担责任。

第二点：原生优于定制，约定大于配置

也就是如果你没有特殊需求的话，官方的东西最好，保持原样，除非他不满足你的要求，你再去定制他。因为你改了之后，一旦发生问题，你很难摸清楚错误发生在什么地方。而如果官方的出现问题，整个社区都在给你撑着，你就能够及时地把这东西补上去。

第三点：什么都是，最后会沦落到什么都不是

这是很多人早期搞架构的时候犯的一个错误。当时我老想着做一套完整的系统，无论你想做什么样的业务，拿来之后稍微一修改什么都能支撑，后来发现根本不是我想的那样，它几乎什么都不能支持。就像造汽车，偏舒适还是运动，两者兼顾的没有。

控制技术欲，不要瞎折腾，你自己或者你们公司内部有没有技术欲特别强，总喜欢玩新的技术，看到新技术就想用到自己的系统中的。这不是一个好的架构师的行为。做架构的前提是稳，这是底线，试错一定不要在生产环境中。

第四点：留下扩展，但不要想到100年后

当代人做当代人的事情，不要考虑那么久远。当代留下的坑，只能留给后代补。

第五点：没有最好的，只有最合适的

跟第3条比较像，但第3条是广度上，这一条是深度上，垂直领域不要总想做到最完美。

第六点：够用就好，玩的越花，风险越大

比如有人玩这种 ++i++；finally(return）；if(赋值) ，面试玩玩也就算了，代码这么写存粹是没事找事。

第七点：大巧不工，简约最美

就是要把代码写的很简约，很优雅。

解决问题的能力，具备日常场景下的解决方案积累，举几个例子：

相关信息

单点登录

分布式事务及数据一致性

秒杀并发场景

复杂工作流

超高并发、吞吐量

团队协调力、管理能力，作为架构师，你不再像普通开发一样，局限在自己所负责的模块里，你的思维和设计要落地，你需要跟软件开发里的各个角色打交道，必须具备团队层面推进事情进展的能力（尤其架构团队的 leader）

最后，扩展自己的人脉。 人脉很重要，随着职位的提升，段位的提升，需要一定的背书。在这里顺带分享一下个人经历，我在自己毕业的前两年还未意识到这点，到3-5年的时候就开始打造技术领域里的朋友圈，认识了很多大佬，互相交流互相学习快速提升。

以上就是架构师要具备的能力，其中技术掌控力是底子，这个可以通过有效的学习手段来得到快速提升。

提示

微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。微软的这个分类是按照架构师专注的领域不同而划分的。

所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。

CTO

CTO 刚进公司的时候，也是写代码的，现在管着一个部门，职责是看公司3-5年的方向。据他说，他自认为能力还不够，Top1的CTO，职责是看公司5-10年的方向。

他的工作时间，70%时间在研究业界的各种技术方向，考虑未来的趋势，结合公司优势，思考公司的战略投入方向；剩下30%工作时间是向CEO汇报，帮CEO向董事会汇报，敲定以及调整公司投入方向和投入资源规模。

他是不可能有时间写代码的，整个部门近百人，都没有时间写代码。公司内和他并行的且有研发队伍的公司副总裁有5个，这些副总裁下面研发人员多则几千，少则几百，也都有一个cto（咱们用小写代替）。这些研发队伍是写代码的，但是cto也没有时间写代码。这几位cto负责落地公司战略，结合产品实际情况进行调整，确定子系统的技术方向，技术架构，也有责任反馈需求和意见，要求公司调整战略。

有几位cto我都很熟，他们其实最怀念的是写代码的时候，心不累，领导说啥就是啥，只管干活就行。现在不一样，一旦技术方向选择错误，不能给公司创造价值，或者成本过高不挣钱，那几百几千的研发人员收入将大幅度下降，这个责任背不起的，心累。大量程序员，总是瞧不起主管/架构师/cto。说实话，等你到那位置，再说瞧不起的话吧。反正我的头发是从做主管开始迅速白的。

架构师主要职责

架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。

• 确认需求

  在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。

  架构师要懂得用户需求，理解用户真正想要什么，这使得架构师必须要和分析人员不断沟通，反复确认需求规格说明书，以此来保证他精准清楚用户需求。项目经理刘先生在受访时说：架构师会与很多人沟通，例如开发人员，例如我们项目经理，有时甚至是用户本身。架构设计的目的很明确，目的是什么呢？挖掘用户需求。

• 系统分解

  在架构师认可需求规格说明书后，架构师已明确用户需求是什么，这时候便看架构师的分解能力了。依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。软件架构师的功力基本体现于此，这是一项相对复杂的工作。

  通过100offer入职的全栈技术架构师周先生从纵向分解和横向分解和我们说明了系统分解是什么：一般分为纵向分解和横向分解，纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件。横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。

• 技术选型

  在系统分解后，架构师会最终形成软件整体架构，接下来，架构师的职责是技术选型。Web Server 运行在 Windows 上还是 Linux 上？前端到底用瘦客户端还是富客户端呢？数据库是用 MySQL 还是 MSSQL 又或是 Oracle 呢？需要不需要采用 MVC 或者 Spring 等轻量级的框架？架构师张先生在接受采访时说，在了解用户需求后，分解完系统后，技术选型是非常重要的环节，提出各个方向，我再进行评估。不过，很多人都以为架构师是有决定权的，其实不是，架构师没有拍版的权力，决定由项目经理来做。 架构师在技术选型阶段会提供参考信息给项目经理，项目经理再从预算、进度、人力、资源等各方面情况来权衡，最终确认。

• 制定技术规格说明

  如前文调查显示，架构师在项目开发过程中是灵魂人物，架构师在项目开发过程中，是技术权威。并且要具备协调组织能力和懂得人员分工。在制定技术规格说明阶段，架构师要协调起所有的开发人员，架构师通常会用技术规格说明书与开发人员保持沟通，它可以是 UML 视图、Word 文档，Visio 文件等各种表现形式。让开发人员能从各个视角去观测、理解他们负责的模块或者子系统，确保开发人员能够按照架构意图实现各项功能。

架构师主要能力

周星驰有个片子《喜剧之王》，剧中的尹天仇整天揣着本《演员的自我修养》，一个好演员不仅需要天赋，也需要一定的理论指导，无师自通的人毕竟是少数。架构师的成长过程也是这样。从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程。经验积累是一个方面，素质培养是另一个方面，两者相辅相成，所以我觉得有必要把架构师的所要具备的素质罗列一下，作为程序员努力的方向。

在了解架构师的职责后，再来看看架构师该具备什么能力才能成为一家公司中的灵魂人物。

37% 的受访人认为架构师的设计能力最重要，技术实力重要度排在第二占了 24%，沟通能力则排在第三，占比 14%，管理能力在大多数架构师眼中并不是最重要的，仅占了 7%。此次，我们详细分析排在前三的能力。

• 设计能力：擅长整合分析架构是过程，并非结果。架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统，以及简洁描述，这是分析整合的能力。一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位以及产品业务，再整合利用现有的技术领域，找出最佳方案，实现产品概念。

• 技术实力：实现产品规划架构师首先要将代码写的清晰易懂，要能够实现功能，做到没有 Bug，这要求架构师必须具备至少熟练掌握一门语言。这是最重要的，每一名出色的架构师，必定是一位优秀程序员。架构师并不是纯粹的管理岗位，对那些爱写各式文档、画流程图、脱离代码、只说不做、高高在上的架构师，程序员们通常会称他们为—— PPT 架构师。不懂编程的架构师的职业生涯必定是短暂的，无论如何都不可本末倒置，要想实现自己的职业规划，不能荒废自己本身的技能，技术是架构师赖以生存的最基本能力。所以，不推荐不热爱编程的人去做架构师，对于团队工作和个人发展来说，都会带来糟糕的后果。

• 沟通能力：能够横向沟通架构师必须参与项目开发全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，在这一系列过程中，架构师会与各部门沟通交流。一个产品会有多部门合作，架构师在其中的沟通极为重要，直接影响产品进度与质量。架构师不仅要与开发人员沟通，也要和项目经理、分析人员甚至用户沟通，来实现产品的各种可能性。所以，对于架构师来讲，不仅有技术方面的要求，还有能够横向沟通的要求。

  为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师具有较强的沟通能力。沟通能力是人类最普遍性的素质要求，技术人员好像容易忽略，想成为架构师就不能忽略。千万不要抱着这样的观念：怀才跟怀孕似的，时间久了总会被人发现的。还是天桥上卖大力丸的哥们说得对：光说不练假把式，光练不说傻把式。看看你周围的头头脑脑们，哪一个不是此中高手，我们千万不要鄙视，认为这是阿谀奉承、投机钻营，凡事都要看到积极的一面，“沟通”的确是一种能力。我认为自己是一个略内向的人，因为我是农村出来的孩子，普通话都说不好，以前或多或少带有点自卑感，幻想着是金子总会发光，所以在职业生涯中吃了不少亏。现在，我深深懂得了沟通的重要性，我会很主动地跟同事们，跟老大们不定时地沟通，感觉工作起来顺畅多了。

  这一条我认为最为重要，所以排在首位。我甚至认为下面几条都可以忽略，唯一这一条得牢记，而且要常常提醒自己。

• 领导能力：架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。架构师如何来保证这种执行力？这就需要架构师具有领导能力。架构师的领导能力的取得跟项目经理不太一样。项目经理主要负责解决行政管理，这种能力与技术关系不大，他有人权和财权，再扯上一张“领导”的虎皮，采用“胡萝卜加大棒”的方式，基本上可以保证执行力。架构师在项目里面可能更多地使用非正式的领导力，也就是我们常说的影响力，里面包括个人魅力、技术能力、知识传递等等。

• 抽象思维和分析能力：架构师必须具备抽象思维和分析的能力，这是你进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局，这也是架构师大局观的形成基础。你如何具备这种能力呢？一是来自于经验，二是来自于学习。架构师不仅要具备在问题领域上的经验，也需要具备在软件工程领域内的经验。也就是说，架构师必须能够准确得理解需求，然后用软件工程的思想，把需求转化和分解成可用计算机语言实现的程序。经验的积累是需要一个时间过程的，这个过程谁也帮不了你，是需要你去经历的。但是，如果你有意识地去培养，不断吸取前人的经验的话，还是可以缩短这个周期的。这也是我写作此系列的始动力之一。

• 技术深度和广度：架构师最好精通1-2个技术，具备这种技术能力可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。架构师的技术知识广度也很重要，需要了解尽可能多的技术，所谓见多识广，只有这样，才可能综合各种技术，选择更加适合项目的解决方案。有的人说，架构师技术广度的要求高于技术深度的要求，这是很有道理的。

总而言之，一句话：架构师是项目团队中的技术权威。

架构师的误区

• 架构师就是项目经理：架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作，具备管理职能。一般小型项目中，常见项目经理兼架构师。

• 架构师负责需求分析：架构师不是需求分析员。需求分析人员的工作是收集需求和分析需求，并与最终用户、产品经理保持联系。架构师只对最终的需求审核和确认，提出需求不清和不完整的部分，他会跟需求分析员时刻保持联系。架构师是技术专家，不是业务专家。

• 架构师从来不写代码：这是一个尚存争论的问题。目前有两种观点。观点1：架构师不写代码，写代码纯体力活，架构师写代码大材小用。架构师把 UML 的各种视图交给开发人员，如果有不明确的地方，可以与架构师随时沟通。观点2：架构师本来自于程序员，只是比程序员站的层面更高，比程序员唯一多的是经验和知识，所以架构师也免不了写代码。

  我个人觉得这两种说法是与架构师的出身和所处的环境有关。架构师首先是一个技术角色，所以一定是来自于技术人员这个群体，比如系统架构师，多是来自于运维人员，可能本身代码写得并不多，或者说写不出来很漂亮的代码。软件架构师多是来自于程序员，有着程序员的血统和情怀，所以在项目开发过程中，可能会写一些核心代码。我们的理想是架构师不用写代码，但事实上有时候过于理想。架构师写不写代码，可能取决于公司的规模、文化、开发人员的素质等现实情况。另外，架构师也不是跟程序员界限分得那么清楚，按照能力也有高中低之分，写不写代码不是区分两者的根本标准。