架构师的最佳成长路线

架构随笔录

想一两句话把什么是架构师讲清楚，是非常困难的一件事。因为架构师这个角色是致力于解决高度复杂抽象的问题，所以架构师的定义也是复杂抽象的。

但并不代表架构师的定义无法被解释清楚，我们需要多花点时间，从各个角度来解读架构师。

00

什么是架构师？

大白话的解释就是，软件产品的设计师。架构一词最早源于建筑学，软件工程的架构师与建筑工程的架构师有非常多的相通之处，都是负责“产品”的宏观层次设计。

百度百科给系统架构师的定义如下：

系统架构师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师，对常见应用场景能给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等。

系统架构师又要具备哪些能力呢？

作为系统架构师，必须成为所在开发团队的技术路线指导者；具有很强的系统思维的能力；需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，哪些是无效的。架构师应当是一个成熟的、丰富的、有经验的、有良好教育的、学习快捷、善沟通和决策能力强的人。丰富是指他必须具有业务领域方面的工作知识，知识来源于经验或者教育。他必须广泛了解各种技术并精通一种特定技术，至少了解计算机通用技术以便确定那种技术最优，或组织团队开展技术评估。优秀的架构师能考虑并评估所有可用来解决问题的总体技术方案。需要良好的书面和口头沟通技巧，一般通过可视化模型和小组讨论来沟通指导团队确保开发人员按照架构建造系统。

（1）技术能力

技术能力，不用置疑肯定是最重要的。技术能力弱的架构不是一个好架构。所以，你需要知道所有主流技术的基本原理、应用场景，及快速解决问题的能力。所以，架构师必须要有见识，所需知识面肯定是要不断拓展的。你需要清楚在什么样的场景用什么样的技术比较合适，并知道可能存在什么样的风险。来了需求，你脑袋是空的，不知道用什么技术这是最可怕的。

（2）架构能力

这个可以表现为抽象能力、整体规划能力、及设计能力。你需要照在业务的角度进行系统分解、技术选型、架构搭建，以及规范制定。架构出来了至少可以满足最近的发展，或者可以很方便对现有架构进行扩容。有人说架构不需要懂业务，我面试过的就有明确表示不做业务架构。当然有方面的架构师，如中间件架构师，运维基础设施架构师等。但一般的后端架构师都是需要了解业务，不理解业务你如果进行系统分解，服务划分，及根据不同业务作出不同的架构。技术都是为业务服务的，不站在业务的角度设计架构，那架构就是空谈。

（3）沟通能力

这个看起来不是最重要的，其实也非常重要。作为一个优秀的架构师，你需要清楚的知道客户的需求，需要不断和需求人员进行沟通，以达到客户真正的目的。不论是不是架构师，任何一个职场人，提高自己的沟通表达能力无疑是不可或缺的。有一句话怎么说的，领导就喜欢拍马屁的。做领导的大多不是技术特别牛的，但沟通能力肯定是很好的。

也就是说作为一名系统架构师，你除了具备必备的架构能力之外，你还要具备技术和沟通能力，因为架构师的最终目的就是为了解决业务和技术歧义的。

一般情况下，开发人员可以考一个系统架构师的职业认证，这样也能够增强你的架构硬技能。

01

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

在老板眼中，架构师是一名技术领导者，带领团队攻关疑难问题；在业务方眼中，架构师是一座业务与技术的桥梁，填平业务与技术的鸿沟；在研发团队眼中，架构师是一位导师与布道者，是大家学习的榜样；在项目组眼中，架构师是团队的灵魂支柱，再困难的问题，抽丝剥茧后，也能变成小问题；在外行人眼中，架构师是年薪百万的牛人，但为何如此，摸不清门道。在我的眼中架构师就是一个角色，可以说只要你的能力达到了，人人都是架构师。一般一个架构师起步是要从小的模块设计开始的，那个时候你就应该建立架构思维。

02

架构师的服务对象是谁？

服务对象总结起来包括三种：

第一类客户是需求人员（大多时候是产品经理，有时直接面向商家）。架构师需要不断和需求人员沟通，协助需求人员挖掘出客户的本质需求，保证需求质量。

第二类客户是研发人员。架构师需要将复杂的业务问题和目标，抽丝剥茧后，转换为技术设计语言（应用、模块、包、代码、API、数据库表等），指导研发人员顺利落地；出现技术争议时，在业务价值与技术实现间做好平衡。

三类客户是业务决策者，架构师需要为重大业务规划提供的技术演进方案与成本预估，帮助决策者做出正确决策。

03

架构师的日常工作

架构师的日常工作主要包括如下内容：

（1）领导重大项目，攻关疑难问题，确定项目的架构方案和技术选型

一般架构师一定要参与重大项目，为什么这样说呢？重大项目的业务模型足够复杂，这样也需要架构来降低复杂度，以及制定架构方案和技术选型。

（2）制定研发标准和规范：编码标准，工具规范，评审流程，测试方法等

规范真的很重要，很多人都很讨厌去做规范方面的工作，其实作为一个架构师老鸟，告诉大家架构师大量的工作是制定技术和业务规范，并拿着这些规范和开发人员，还有管理人员去沟通。

（3）将架构方案和决策文档化，和团队沟通，并推行自己的架构主张

架构师光会做技术方案是没有用的，一定要去推技术方案，这样才能体现自己的价值，有能够进一步的确定自己的领导力。

（4）把高层的业务目标变成可落地的技术规划和解决方案

一般情况下，高层的技术规划和解决方案是高屋建瓴的，往往就几行话或者一个大而全的鸟瞰图，那么作为架构师就需要配合技术总监或者CTO将这些规划中的业务和技术愿景给剥离出来，并转换为开发人员和一线技术Leader能够懂的语言，这样大家就都能够听的懂，当然在转换的过程中最好不要有太大的歧义。

（5）检查、评审他人的技术方案

架构师参与重大项目的设计和落地的同时，还需要评审别的开发人员的技术方案，这样非常重要，一方面可以快速的去熟悉业务产品，另一方面也可以及时止损，防止一些坏的设计方案落地，从而影响开发交付的质量。

（6）和其他架构师、利益相关者沟通协作

一个大部门或者公司不止一个架构师，这个时候架构师之间一定要多开会，多沟通，这样就可以将自己团队中碰到的业务或者技术问题给抛出去，从而获取最佳的技术解决方案，尤其是项目需要跨团队沟通时，架构师之间的沟通就尤其重要。

如果公司就你一个架构师，那该怎么办呢？那你沟通的对象就会变成技术总监和CTO了。

（7）为团队澄清复杂问题、指导研发人员、解决技术冲突等

这点事架构师必须要具备的能力，也就是说架构师的主要职责就是要去指导开发团队去做事情。

尤其是需要解决复杂问题，并用最简单的方式去解决最复杂的问题，一定要想办法去解决开发人员开发项目过程中的技术和业务歧义。

04

架构师的总类

业界对架构师并没有统一的分类标准，推荐这两种分类方式：

• 从宏观到微观的角度划分；
• 按软件工程阶段划分。

从宏观到微观的角度去划分

（1）企业架构师

决定整个公司的技术路线和技术发展方向，有些公司也会称为首席架构师，实际上这个角色已经无限接近于CTO了。

（2）系统架构师

负责整体系统的架构设计，着眼全局，不太注重某个应用本身的架构，而是各服务、各系统间的协作上，更加关注如何综合运用已有的产品和技术，来实现客户期望的业务模式。系统架构师要求通晓业务、软硬件技术等多项知识，对知识的全面性要求很高。

（3）应用架构师

负责某个应用的技术架构，主要偏业务型应用，关注理解业务，梳理模型，设计模式、接口、数据交互等方面，同时也需要关注服务器负载、可靠性、伸缩性、扩展性、数据库切分、缓存应用等方面的基础架构设计。

按软件工程阶段划分

（1）解决方案架构师

专注于解决方案的规划和设计，所谓“解决方案”，就是把产品、技术、基础设施、理论方法，通过不断的组合和创新，满足客户的特定业务目标和需求。

（2）业务架构师

从企业战略、组织结构、业务流程、业务能力等维度入手，关注某一个行业或业务领域的分析，产出业务模型，最终指导系统模型设计。也可以叫业务领域专家、行业专家、业务咨询师、资深顾问。

（3）应用架构师

负责某个应用的技术架构，主要偏业务型应用，关注理解业务，梳理模型，设计模式、接口、数据交互等方面，同时也需要关注服务器负载、可靠性、伸缩性、扩展性、数据库切分、缓存应用等方面的基础架构设计。

（4）特定技术架构师

专精某项技术的资深专家，从事中间件架构、大数据架构、安全架构、存储架构、网络架构、前端架构等技术规划和架构设计工作。

04

架构师成长的阶梯

架构师成长阶梯主要包括5个阶段：高级工程师、应用架构师、系统架构师、企业架构师（首席架构师）和CTO。

05

架构师核心能力模型

架构师核心能力模型，这里以就阿里P序列职级为例，大家可以对比一下能力，以及自己的一些差距。