程序员向架构师转型之路

课程简介

具备若干年开发经验的普通开发人员往往面临个人发展的瓶颈，即如何从普通开发人员转型成高层次的系统架构师和技术管理人员。想成为一名架构师，应当具备全面的知识体系，需要进行系统的学习和实践，很多开发人员有往架构师转型的强烈意愿，但苦于找不到好的方法和路径。

此达人课提供架构师所需的各方面技能和相应的学习方法，以及架构师所需掌握的系统工程方法论和软能力，旨在为广大开发人员提供一套精简但又全面的转型指南。

本课程一共包含 14 篇文章，从架构设计和架构师的基本概念出发，重点介绍架构设计的核心技能和知识体系。同时，本课程的目标之一也是为了帮助读者完成架构师岗位的就业，所以在课程最后也列举了一部分阿里巴巴、网易、蘑菇街等作者亲身经历的架构师面试题分析，供读者参考。

作者简介

郑天民，网名天涯兰，日本足利工业大学信息工程学硕士，10 年软件行业从业经验，在医疗、安防和电商行业都有所涉及，前后担任系统分析架构师、部门经理、技术总监等职务。目前就职于一家业界领先的移动医疗互联网公司，负责产品研发与技术团队管理工作。《系统架构设计：程序员向架构师转型之路》《向技术管理者转型 : 软件开发人员跨越行业、技术、管理的转型思维与实践》《微服务设计与架构》（预计 3 月份出版）作者，北风网《系统架构师》直播课程主讲。

课程内容

导读：直面架构师转型

为什么要向架构师转型？

无论对于传统行业还是互联网行业，开发具有功能强大且用户体验好的移动端应用已经成为众多软件从业人员的目标和要求。然而，分析和设计一个软件系统以及管理其研发过程并不是每一个软件行业从业人员都能做的事情，需要具备专业的知识领域、丰富的实践经验以及良好的个人综合能力，我们把具备以上能力的人才称之为软件架构师。

中国目前每年有几十万的软件开发人才缺口，其中对具备系统架构设计和实现能力的人才更是趋之若鹜。对于一名软件开发人员而言，成为一名合格乃至优秀的架构师是自身奋斗的一个方向。目前很多公司尤其是大型公司程序员并不缺，缺的是架构师。

同时，对于一名具备多年行业从业经验的开发人员，如果目前还处在普通的开发人员序列，还没有具备相应的意识形态和专业能力去从事系统架构设计和实现相关工作的话，势必导致技术与年龄不相匹配，也就会出现职场上经常谈论的所谓“ 30 岁危机”。所以，从这个角度讲，成为一名架构师事实上也是自身发展所不得不面临的一个瓶颈。如何打破这个瓶颈，如何从普通的程序员转型成为一名架构师，对于广大开发人员而言都可能是一个值得思考的问题。

当然，对于从事技术开发的人员而言，技术变化日行月异，一个人的能力很大程度上体现为一种学习能力。如何实现自我提升，如何看到目前还没有看到的技术层次，也是个人发展道路上不可回避的一个话题。

本课程的潜在受众

本课程面向立志于转型成为架构师的后端服务开发人员，读者不需要有很深的技术水平，也不限于特定的开发语言，但熟悉系统开发常见技术并掌握一定系统设计基本概念有助于更好的理解课程中的内容。通过本课程的系统学习，读者将在思想、方法论和综合素质等各个方面往一名合格的架构师方向发展，为后续的工作和学习铺平道路。

本课程的内容大纲

本课程从“向架构师转型”的角度出发，基于我自身在传统以及互联网行业多年的技术与管理工作经历展开论述，全面阐述如何从普通的开发人员成功转型成一名架构师的系统方法和模型。

本课程首先对架构设计的核心概念做基本分析。接着引出架构师角色，从架构师的活动、分类、技能和职责等角度对架构师的角色做了深度剖析，并对普通开发人员和架构师的区别进行了全面比较。为了成为一名架构师，需要明确架构师所需掌握的层次、维度和视图，这些层次、维度和视图是架构师手上的武器。

架构设计的技术体系非常广泛，本课程无法也无意对所有的技术和工具做全面介绍。本课程针对架构设计的知识体系进行了抽象，认为架构设计包含以下几个基本切入点。

• 领域建模：架构设计的第一步；
• RPC：一切架构的基础；
• 分布式：最核心的架构；
• 微服务：最热门的架构；
• 消息传递：可解耦的架构。

在这些知识体系的背后体现的是一种学习模型，从学习模型中我们应该认识到各种工具、框架背后的相同点，也即技术体系中存在的相通性。本课程同样也会阐述如何从各种纷繁复杂的工具和框架中梳理出背后的通用性原理并在日常工作中指导自己的学习路径。

架构设计同样体现为一种系统工程，系统架构设计和实现的背后同样需要考虑项目管理、配置管理、过程改进和交付管理等工程性问题，这些内容同样是架构师区别于普通开发人员的关键要素。

在很多公司或团队中，架构师还充当着技术管理者的角色，也就需要架构师具备较强的软能力，这种软能力体现在架构师与外部团队、内部团队、上级领导以及自身管理的各个方面，本课程也会对架构师应该具备的软能力模型做进一步阐述。

最后，本课程会给出我在经历过阿里、网易、滴滴、蘑菇街、贝贝网等国内大型互联网架构师岗位的面试之后对面试过程进行总结和思考的一些经验，并提供具有参考价值的架构师面试题分析和面试技巧，帮助读者能够在架构师面试过程中找对方向并顺利就业，完成程序员向架构师的成功转型。

本课程配套书籍

本课程与我所著的《系统架构设计--程序员向架构师转型之路》内容上高度一致，读者也可以把这本书作为向架构师转型的指导用书。

下篇导读

在下一篇中，我们将具体探讨程序员向架构师成功转型的具体模型，确保从思想上对转型过程和方法有充分认识。

第01课：程序员向架构师转型模型

从周围的两位同事说起

我本人在杭州，大家都知道杭州有家公司叫阿里巴巴，我也推荐过一些前同事和朋友去阿里巴巴面试，有些成功入职，有些虽然最终入职但过程比较艰难，而有些则一直没有找到机会。这里举两个例子与各位读者分享。

同事A：每一面都顺利通过，一次性走完所有流程，历时约 1 个半月入职阿里闲鱼。阿里闲鱼是阿里旗下一个二手商品的交易平台，1 个半月的面试时间在入职阿里的过程中已经算是比较快的流程，需要做到每一面都一次通过。这里简单介绍一下阿里的面试流程，正常情况下是 4 轮面试，有些部门在同一轮面试中会对候选人进行多次面试，如果一次不行还会安排不同的面试官再面一次。而每次面试都需要协调面试人员，所以整体流程通常都会比较长。

同事B：一共面试 11 个岗位，其中一面失败 5次，二面失败 6 次，三面失败 2 次。从今年上半年开始，历时半年仍未入职。目前已放弃，准备做一定积累之后再进行尝试。

事实上，这两位同事的年龄、工作履历以及技术能力相差无几，那为什么面试同一家公司结果会完全不同呢？通过对这两位同事的面试经历进行分析，我们能够得出一个结论，即知识体系的重要性。

再举一个同事的例子

同事C：10 年以上开发经验，工作能力和态度都没有问题，但一直都是从事偏向业务的开发工作，随着年龄的逐渐偏大，目前已经明显遇到了职业生涯发展瓶颈。

就我个人与同事 C 的对比，从薪资上目前是同事 C 的两倍，并且对系统架构和技术管理体系都非常了解，成功担任过大型企业中的系统分析架构师与技术总监职务，可以说在一定程度上已经突破了目前所面临的发展瓶颈。

针对同事 C 的案例而言，我们同样得出另外一个重要的结论，即转型思维的重要性。

我们将在后面的内容中花较大篇幅讨论如何建立知识体系结构，本篇的内容主要围绕转型思维展开，即程序员向架构师转型应该具备相应的转型模型。

成功转型的三段式模型

转型需要一个过程，任何过程一般都可以抽象成人、工具和流程的组合。但是对于转型过程而言，显然普适意义上的人、工具和流程并不能直接应用。如何找到更加有效的途径来完成从程序员到架构师的转变，本课程提出了针对转型的特定过程模型，即如下图所示的由思路、方法论和工程实践所构成的三段式模型。

转型的思路

思路意指思考的条理脉络，通俗的解释就是心里的想法。转型需要想法，但往架构师转型的想法却受以下三个方面限制：意识形态（Mindset）、环境（Environment）和决心（Determination）。意识形态是转型的触动点，当我们想去做一件事情而这件事情需要付出很大努力时，通常是意识形态发生了变化，从习惯于根据详细设计文档编写代码并完成功能自测，到根据业务需求抽象出系统模型并转变成架构描述，意识的转变是工作内容转变的前提，意识形态很多时候决定了一个人发展的高度。但一个人所能达到的高度还很大程度受限于环境因素，好的环境和不好的环境对个人发展影响巨大，而我们往往无法改变环境，只能适应环境，所以是否具备一个良好的环境也是在转型之前需要进行梳理并作出判断，必要时也应该果断采取行动。思路的最后一点就是决心，当意识形态和环境因素都已经具备，决心变成是否能够转型的关键，毕竟想要成为一名合格甚至优秀的架构师可能要比想象的困难。

一般而言，从偏向微观的编码领域进入到需要宏观思维的架构设计领域，开发人员会发现这种角色转换要比预想的更具挑战性。实际上许多技术人员对架构师存在明显的误解，认为只要技术能力出众就能成为架构师，或者认为那些画画系统模型图的工作不是架构设计，甚至看不起那些关注业务模型的设计人员。尽管这样，每年还是有许多技术人员接受提拔而成为架构师，这些技术人员相信会找到并解决架构设计过程中存在的种种问题，正是这种信念促使大多数技术人员接受挑战并完成转型过程。然而，并不是所有的技术人员都能获得提拔的机会，对于目前尚未有明确的提升机会但又想往架构师转型的技术人员而言，我们认为思路恰恰是其首先需要考虑的问题。

转型的方法论

所谓方法就是做事的手段、方式、流程，而方法论即一组方法的集合，也就是一组用于确保成功的规则的集合。技术人员想要转型到架构师岗位，将要面临一大堆他们不熟悉的问题。对于技术人员，解决技术问题的能力是主要的衡量标准，技术人员自身所具备的方法论也更多的偏向技术体系本身。但对架构师而言，技术体系只是一个方面，更多的方法论需要进行理解和掌握。

对架构师而言，了解主流软件架构风格、模式和模型、通过整合各种架构体系形成自身的架构设计思想是一种方法论；能够对主流架构设计方法进行阐述、把握主流技术体系知识领域以及相应的原理是一种方法论；围绕软件开发生命周期的系统工程，理解软件工程、业务架构、敏捷方法、产品交付等概念是一种方法论；作为架构师明白面临的各种软技能需求以及相应的应对方法也是一种方法论。理论指导实践，只有具备相关的方法论，才能用于工程实践。

转型的工程实践

在软件开发领域，我们经常提倡使用各种最佳实践（Best Practice）。最佳实践是一个管理学概念，认为存在某种技术、方法、过程、活动或机制可以使生产或管理实践的结果达到最优，并减少出错的可能性。把软件开发的最佳方式和开发人员个人做得最好的事项一一总结出来，就是组织的最佳实践。最佳实践包含在技术和非技术领域，包含在对人和事物的处理过程，也包含在架构师所应具备的各项软、硬能力中。要想成为一名架构师，对架构师所应该从事的各项活动都应该需要且能够提炼出最佳工程实践作为具体工作展开的输入和模板。

架构师的学习模型

在讨论完架构师转型的基本模型之后，我们还需要给出架构师的学习模型，因为转型的过程本质上还是一个不断学习和进步的过程。对于正在向架构师转型的开发人员而言，处于初始阶段的同学有转型的想法和思路，但是在纷繁复杂的技术知识体系和各种层出不穷的工具框架面前就显的无从下手。而有些同学已经跨越了初级阶段，并按照自己的方法正在系统的梳理各种架构师所需的技能，但很多时候会发现效果不是很好，自身提升的速度比较慢。学习模型的作用就在于为这两类人提供一个简单的方法确保能够快速成长。

在本课程中，架构师的学习模型由以下两个阶段所构成。

• 第一阶段

第一阶段的主要工作是找一两个核心框架和技术体系进行深入分析并抽象出其中的技术理论。所谓理论指导实践，架构师一定要从纷繁复杂的技术知识体系和各种层出不穷的工具框架中抓住其背后的原理，然后做到用自己的语言对这些原理进行阐述。事实上，现在很多大型公司的架构师面试风格上就是偏向于考察面试者的原理分析能力和表达能力，这点我们在课程的最后一篇中会再结合架构师面试的技巧以及部分面试题做进一步展开。

• 第二阶段

在第二阶段，架构师需要广泛了解其它框架和技术体系，看能否把在第一阶段中自己抽象出来的技术理论用来剖析这些框架，如果不能，找各种资料继续第一阶段。

从上面的两个阶段我们可以看出学习模型是一个循环模型，就我自身经历而言，一般人都需要经历过 3~5 个循环之后才能对架构设计这一领域有比较深入的理解。对于初始阶段，可以找类似 Mybatis、Spring 等相对比较独立的核心框架入手，然后逐步过渡到向 Dubbo、Zookeeper 等综合型框架。而对于那些已经完成初始阶段的同学而言，需要在不同的循环中针对不同的知识体系做相应的规划，可以针对分布式、微服务等主题进行专门的学习和训练。

架构师转型的思维和挑战

根据以上分析，从最高的高度看待架构师转型，可以总结出如下图所示的转型等式，前面提到的转型模型和学习模型都是为了构建适合自身的知识体系和转型方法。虽然这个等式非常简单，但架构师转型面临巨大的挑战，挑战来自于架构师的工作特性以及康威定律。

康威定律（Conway‘s Law）指出设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。从传统的单块架构到目前非常流行的微服务架构实际就是这一定律的一种体现。现在很多开发团队本质上都是分布式的，单块架构的开发、测试、部署协调沟通成本巨大，严重影响效率且容易产生冲突。将单块架构解耦成微服务，每个团队开发、测试和发布自己负责的微服务，互不干扰，系统效率得到提升。可见，组织和系统架构之间有一个映射关系：一方面，如果组织结构和文化结构不支持，通常无法成功建立有效的系统架构；反过来，如果系统设计或者架构不支持，那么你就无法成功建立一个高效的组织。

康威定律给我们的指导是设计系统架构之前，先看清组织结构和组织文化，再根据具体情况设计并调整系统架构。要做到这一点，架构师应该具备较高的综合能力。下表体现了普通研发工程师与架构师工作性质的对比，从对比中我们可以看到，架构师的工作不能只关注与技术，而更重要是站在团队和组织的角度看问题。

对比维度	程序员	架构师
技术	技术实现	技术创新
管理	自我管理	小组管理
指导	经验传承	组员培育
沟通协调	团队活动	全方位
策略规划	技术支持	技术策略
绩效重点	前瞻性技术	全组绩效

但是我们知道软件研发人员也具有自己的思想和方法论，一方面作为技术人员自然崇尚技术能力，架构师应该具备较强的技术创新能力才能让下面的开发人员信服；另一方面，架构师需要把握团队架构，在组织文化下和外部团队进行有效协作，需要具备人员和过程的管理能力，能够使内部、外部的团队成员目标一致，实现架构师的自身价值。显然，要做到以上两个方面是困难的。

面对架构师转型所需要克服的各项挑战以及康威定律给我们带来的启示，结合转型成功所需要的三段式模型和学习模型，我们得出了如下的转型思维导图。该图上半部分代表包含思路、方法论和工程实践的三段式模型，下半部分代表转型主题，即知识体系、软技能和就业指导三个部分。其中知识体系是本课程的主体内容，但本课程也会对架构师所需的各项软技能做简要介绍，并通过面试技巧和面试题分析对架构师的就业活动给出一定的参考性建议。三段式模型指导着转型主题的落实，即对每一个转型主题，思路、方法论和工程实践都是我们进行转型的基本切入点；反过来，转型主题又推动着三段式模型的进一步成熟和改进。该转型思维导图构成了本课程的基本行文框架，本课程后续内容基本按照该图进行展开。

下篇导读

本篇给出了向架构师转型的基本模型，总领整个课程内容。在下一篇中，我们将具体探讨架构师角色，明确架构师的职责、类型和所需的技能。

第02课：深入剖析架构师角色

什么是系统架构设计：关于架构演进理论

在过去软件开发过程发展的很长一段时间内，软件架构表现为一种集中式的单块（Monolithic）式，即先对系统进行分层，然后通过单个进程进行部署和维护，典型的分层体系包括界面交互层、业务逻辑层和数据访问层。直至今日，这种单块模式在部分系统构建过程中仍然是最基本的架构模式。

随着业务功能的不断发展以及性能、数据存储等系统瓶颈问题的出现，单块模块逐渐不适合系统的维护和扩展，分布式架构应运而生。通过把系统业务进行服务化，以及完善服务治理功能，系统架构就可以如同搭建积木一样构建成高度可集成、高内聚松耦合的业务系统，如下图中系统主体由 Frontend-Service 和 Core-Service 两层服务化构成，为 Web 层提供网关和核心业务服务。

服务化架构为系统提供了扩展性和伸缩性，然而随着系统用户体量的增加以及分布式系统固有的网络通信机制，性能问题在业务关键链路逐渐成为系统运行的瓶颈。解决性能问题的切入点有很多，一方面可以从硬件设备和软件服务器入手，但对系统架构而言，更多的场合需要我们分析系统实现方案，并使用以缓存为代表的架构设计手段重构业务关键链路，下图即为在 Frontend-Service 和 Core-Service 两层服务中分别添加分布式缓存之后所得到的系统部署图。

缓存能够提升性能，但不能解耦系统。当系统中分布式服务数量和种类日渐增多，而这些服务又分别属于不同业务层次时，如何合理的管理这些服务之间的调用关系，进一步确保系统的健壮性和扩展性成为系统架构设计的又一大难题。分布式服务的自身特征决定了其在时间、空间和技术上都具有一定程度的系统耦合性，在使用分布式服务时需要谨慎处理服务调用的时序、所使用的服务定义以及技术平台的差异性等问题，这些问题为如何开展快速架构重构和扩展、如何进行高效分布式团队协作带来了挑战。以各种消息传递组件为代表的中间件系统为降低系统耦合性、屏蔽技术平台差异性带来了新的思路。当不同的服务需要进行交互、但又不需要直接进行服务的定位、调用和管理时，消息中间件能显著降低系统的耦合程度，下图中在 Frontend-Service 和 Other-Service 中添加了消息传递中间件，确保两个服务在并不需要意识到对方存在的前提下进行数据的有效传输。

试想这样一种场景，我们的系统需要跟外部的多个系统进行集成以形成关键业务链路闭环管理，而这些外部系统分别部署在其他供应商或客户环境，并且每个系统都可能基于完全不同的技术平台和体系构建，随着业务发展需求，这些外部需求还需要实现动态的注册和注销。对系统架构设计而言，一方面我们需要整合这些外部系统提供的服务进行数据的获取和操作，另一方面，我们又不希望我们系统对它们产生强依赖。消息中间件在这种场景下已经失去系统解耦的价值，因为外部系统不在控制范围之内，我们对其内部实现原理一无所知。如何在异构系统、分布式服务和基于租户的基本架构需求下实现有效的系统集成，企业服务总线（Enterprise Service Bus，ESB）提供了相应的解决方案。通过在核心业务服务中引入 ESB 以及对应的路由、过滤、转换、端点等系统集成模式，即可屏蔽由于技术差异性导致的各种系统集成问题，并动态管理 ESB 上的第三方服务。如下图中，ESB 为内部的 Core-Service 整合外部的 Thirdparty-Service1 和 Thirdparty-Service2 提供了集成平台。

随着大数据时代到来，许多业务系统也面临着对庞大业务数据进行管理和利用的难题。近年来，以 Hadoop 生态圈为代表的大数据处理平台，以及以 Lucene 为内核的多种垂直化搜索引擎系统为业务发展提供了高效的批量数据处理和数据搜索功能。在系统架构设计维度，我们也可以引入如 Spring Batch、Spring Data 等轻量级的批处理和数据访问框架，以便与基于 Spring 的核心系统构建框架进行无缝整合，见下图。

上述的系统架构演进过程在现有的互联网应用中具有一定的代表性，很多 App 后台就是从一个简单的单块系统开始，当面临系统架构设计问题时，通过引入各种技术体系逐步完善架构，直至具备庞大体量的大型集群系统。在这个系统架构演进过程中，我们再来回答“什么是系统架构设计“这个问题时，我们可以认为系统架构设计就是在系统开发演化过程中，解决一系列问题的方法论和工程实践。关于方法论与工程实践的含义我们已经在上一篇中做了讨论。

关于架构师的几个常见的话题

在明确了架构设计的基本概念之后，我们将要进一步讨论架构师角色。围绕架构师角色存在如下几个常见的话题。

• 架构设计到底是一种技术活还是业务活？
• 架构师到底要做哪些工作？
• 架构师到底是不是一个技术管理岗？
• 架构师有哪些类型？
• 架构师应该具备哪些技能和职责？

在本篇后续内容中，我们将对以上问题做一一解答。当然，如同前面给出的关于架构设计方面的定义，不同的公司、不同的行业和不同的时期对这些问题也是见仁见智，我们只是基于最普遍的场景给出适合我们自身的答案。

架构设计到底是一种技术活还是业务活？

在很多技术人员的眼中，架构设计可能就只是一种技术性的工作，很多公司在招聘架构师的时候也过多的关注了候选人的技术能力。事实上，在大型软件系统中，架构设计被认为是从问题领域到解决方案的一种桥梁（见下图），从图中我们可以看到架构设计活动与代表问题域的需求分析活动和代表解决域的软件开发活动都有直接的交集，连接着两个软件开发的核心领域。

架构师是架构设计的执行者，架构设计的桥梁作用给架构师带来了挑战，意味着架构师需要同时具备处理两个核心领域的能力，即架构师需要能够从问题领域出发推导出满足业务需求的架构体系，同时又能够从实现方法入手设计出能够满足业务架构需求的技术架构体系，最终实现业务架构和技术架构的统一。

架构师到底要做哪些工作？

架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常，这个角色需要完成以下几项活动。

• 识别干系人并让他们参与进来

干系人是业务需求的源头，识别正确的干系人能够确保业务需求的正确性，让干系人参与能够确保业务需求的实时性和有效控制需求变更。

• 理解和记录系统功能和非功能相关的关注点

通过需求分析，架构师梳理并抽象系统的各项功能性和非功能性需求，并对这些需求进行系统建模。

• 创建并拥有应对这些关注点的架构定义

对功能性和非功能性需求，从扩展性（Extensibility）、性能（Performance）、可用性（Availability）、安全性（Security）、伸缩性（Scalability）等架构设计的基本维度出发定义架构，关于这些维度的讨论是下一篇的主要内容。

• 在把架构实现为具体系统的过程中起主要作用

推动架构设计活动按照项目和产品计划有序进行，参与需求、设计评审等各种技术评审过程，并管理系统设计和开发团队的日常工作。

就一个完整的系统开发生命周期而言，架构设计活动有其时效性。下图体现了传统瀑布（Waterfall）模型下的系统开发生命周期与架构师参与情况，从图中可以看出在由需求分析和系统建模所构成的系统初始阶段和由服务集成和产品接受所构成的最后交付阶段，架构师会较多的参与到系统建设过程中去，具体参与程度取决于系统本身的特征以及生命周期模型。对于类似 Scrum 的敏捷开发模型，如果把一个个迭代看成是小型的 Water-Scrum-Fall 模型的话，架构师参与程度实际上也与上图所示的结果相类似，即重点参与迭代计划阶段和迭代演示回顾阶段。

架构师到底是不是一个技术管理岗？

很多时候，我们也把架构师归为是一种技术管理者角色。技术管理者的工作包括设计行业与解决方案、推进业务结构与产品化、架构设计和技术创新、开展软件项目管理和研发过程体系建设等。视环境的不同，架构师也会在这些工作中发挥一定的推动作用。

但就一个完整的产品开发生命周期而言，技术管理活动也具有其时效性，这种时效性相较于系统架构设计和实现等技术专业类活动而言还具有较大的灵活性。我们可以理解为系统开发生命周期是整个完整软件产品生命周期的一部分，如下图所示。在系统开发工作开展之前，技术管理者需要进行行业分析、技术解决方案的设计以及产品开发策略的规划，同时针对行业特点也可能会从事部分的技术预测工作。而在系统开发工作结束之后，随着产品和运营工作的开展，技术管理者也要深入其中从组织战略的角度出发对技术提出进一步的规划方案和创新措施。

架构师有哪些类型？

基于以上关于架构师的工作内容、参与程度和系统工程的分析，可以看到架构师根据其作用、职责和对系统关注层次的不同，可以分成很多类型。狭义上的架构师往往偏重于技术架构设计，但从广义上讲，业界对架构师的划分有一定的体系。首先，根据所发挥的核心作用，可以把架构师划分成设计型、救火型、布道型、极客型等类型。相较于传统意义上的设计型架构师，这些类型的架构师更加偏重于执行某一项特定的架构工作，并不一定会完整参与系统开发生命周期，更加不一定会从系统工程的角度去看问题。其次，产品型、基础设施型和应用型等架构师是从其所处的业务和职责出发进行分类的结果。产品型架构师偏重于进行业务架构设计，往往在系统开发前期会重点参与；基础设施型架构师偏重于进行技术基础框架设计，一般采用独立于系统开发生命周期的特有开发模式；常见的系统架构师指的是应用型架构师，正如前文所述，负责将问题领域进行建模并转变成解决方案。再次，根据关注层次的不同，架构师也可分为几种不同的类型，包括但不限于功能、非功能、团队组织和管理、产品运营等方面。

• 应用设计型架构师

本课程所阐述的架构师角色从作用上讲限于应用设计型架构师，从职责上讲偏重于应用开发，并关注于功能、非功能、团队组织和管理等层次。这是行业内最常见的架构师类型，也是需求量最大的架构师类型。应用设计型架构师需要同时考虑业务架构和技术架构，从而实现业务架构和技术架构的统一。

• 大数据架构师

现在是大数据时代，在大数据领域也存在大数据架构师这一细分岗位。大数据架构也只是一种架构，通用架构风格和架构模式、通用架构设计原则和维度同样适用。而且大数据架构肯定也是一种分布式架构，从技术体系上讲也存在很多通用的应用场景，例如 RPC 在Hadoop、Yarn、Storm 中的应用；高可用架构在 Hadoop、Yarn、HDFS 中的应用；Zookeeper 在 Hadoop、Kafka 中的应用；消息传递机制在 Spark、Storm 中的应用；加密、授权、认证等安全性机制在大数据体系中的应用等。以上关于 RPC、高可用架构、Zookeeper、消息传递机制等技术体系在本课程中都会讲到。我们在第 10 篇中也会提到技术体系的相通性，所以大数据架构师也是架构师的一种表现形式，在掌握架构设计原理和核心技术的同时需要掌握大数据生态相关工具和框架，并具备架构师应有的综合能力。

架构师的技能和职责

作为一名合格的架构师，完备的技术领域知识是必备的技能，但针对应用设计型架构师，所需的技能不仅仅限于了解和掌握技术体系，也需要从业务领域和软技能两个层面进行技能拓展。

• 技术领域知识

架构设计相关的技术领域知识包括在上文中架构演进理论中提到过的分布式系统、缓存、消息中间件、企业服务总线、搜索引擎和批量数据处理等各种目前业务主流的技术体系，也包括软件架构体系结构中所蕴含的架构风格、架构模式和架构模型思想。

• 业务领域知识

在应用程序开发过程中，业务架构驱动技术架构现象非常普遍。提升业务领域知识和提升技术领域知识一样，都对架构设计有直接的影响。从这个角度讲，架构师应该具备跨领域的技能。

• 软技能

无论是传统型软件还是互联网应用，当前的开发模式已不再崇尚靠能力出众的个人来决定系统的产出，而是要靠团队。架构设计同样面临着项目计划同步、第三方服务集成、外部团队协作等团队性活动需求，很多场景下架构师需要与内部团队、外部团队统一协作才能设计出适合业务发展方向的系统架构。从这个角度讲，架构师应该具备跨团队的技能。

如果一名架构师具备以上能力，就可以从事架构设计工作。对于具体的工作内容，任何一名团队成员都应明确其职责并赋予相应的权力，架构师自然也不例外。架构师作为技术负责人，从问题领域出发进行抽象和建模并提供系统解决方案。同时，需要与过程管理人员进行合作，制定计划、分配资源、组建团队。最后，通过自身影响力和协作能力，保证项目按既定计划和成本完成。定义并记录系统的架构、构建和部署系统的策略、确保架构满足系统的质量属性、促进系统级别决定的产出、确保这些决定与干系人的期望一致、对架构方面的各项指标做平衡性的判断并确保达成一致意见等都是架构师的一些职责示例。

下篇导读

本篇深入剖析了架构师这一特定角色，并给出了架构师的工作职责、分类以及技能要求。在下一篇中，我们再来看一下架构设计相关的核心问题并讨论架构设计的层次、维度和视图。

第03课：架构设计的核心问题

第04课：领域建模——架构设计的第一步（上）

第05课：领域建模——架构设计的第一步（下）

第06课：RPC——一切架构的基础

第07课：分布式服务架构——最核心的架构

第08课：微服务——最热门的架构

第09课：消息传递——可解耦的架构

第10课：论技术体系的相通性

第11课：架构设计中的系统工程

第12课：架构师的软能力模型

第13课：架构师面试题分析

阅读全文: http://gitbook.cn/gitchat/column/5a56effae286423809d47f2d