支付宝架构师：从工程师到架构师的成长之路

0、前言

架构师是一个没有被严格定义的角色。

在写这篇文章以前，我特地把这几年看过的关于架构和架构师的 书从新翻了一遍，结果发现它们的定义或多或少有一些不同，而通过了这几年，一些以前赞成的观点，如今的我也不敢苟同了。另外一方面，业界对于架构师这个岗 位，其实也没有统一的角色定位。在阿里巴巴，前几年是有专职的“架构师”职位的，如今已经回归到“工程师”、“专家”、“研究员”这样的纯技术职位。而我 面试过的人中，也有各类各样的“架构师”，不少小团队里，项目经理就常常自认为架构师。大概架构师目前还不至于称为一个职业，更多的是在项目中的一个角 色，而其角色定位也是模糊的，所以，这个文章里，我主要仍是从本身的理解出发，阐述一下这个角色的定位和我的发展的建议。
一、架构师的定义

架构师：任何复杂结构的设计人员。

架构师的名字来自于建筑业，Software Architect直译应该叫“软件建筑师”。从不少方面讲，软件架构师的工做跟建筑师很像，为了寻根问祖，曾经我也看了很多建筑设计的书（推荐一本《建筑的永恒之道》），最后我发现，二者一脉相承，现阶段分道扬镳，将来也许异曲同工。

一脉相承——不论是建筑师仍是软件架构师，都是为了“大图”而存在，作好顶层设计，充当需求方和实施者的桥梁，是其最重要的两个职责。

分道扬镳——二者的发展 阶段不一样所致。建筑业实践绵延数千年，理论根基有数百年，真正成为一门学科也有一百多年，而软件架构真正出现不过二十年。建筑业已经在足够高的层面上模式 化，建筑师可以真正去“设计”，也就是决定“作什么”。而软件行业还在高速发展中，各个层面的技术还在百花齐放。技术的选择意味着权衡，所以软件架构师更 多还在关注“怎么作”——这也是建筑师能够称设计师，而软件架构师只能算高阶工程师的缘由，设计师更关注美感，而美感在软件架构师的考虑优先级里，排不上 第一。

异曲同工——计算机发展 的几十年，也是技术不断往上抽象和模式化的几十年。SOA、IoT、IFTTT等技术理念已经接近于建筑行业的模块化级别，各类“智慧城市”、“生态城 市”已经在架构层面上考虑“作什么”。假以时日，架构师也许能成为一个真正的纯“设计”的职业，到时候大学里也能够开设“软件架构”的专业了，那一句“建 筑设计师在成为建筑设计师以前，是不会成为建筑工人或工程师的“也能在软件行业成为现实。

固然，这只是可能的将来，这须要咱们这些前辈技术人员，可以和建筑行业的前辈同样，把技术规范化，设计模式化，还要有一套关于架构美学和功能设计的完整统一的约束，任重而道远。
二、架构的职责

在软件技术发展的前几十年，是没有架构师这个称谓的。全部的 人都是程序员，可能有个带头的人，叫主程序员。随着计算机技术的发展，软件覆盖的领域愈来愈大，软件自己也愈来愈复杂，如今，动辄几百万行、几千万行代码 的软件系统已经很是广泛。软件的复杂化，对于开发人员的脑力负担也不断增大，而人脑所能处理的信息量是有限的，因而，软件开发工具、开发方法也在不断发 展，从汇编语言到高级语言，从函数到框架，从面向过程到面向对象，从设计模式到架构模式……

整体而言，人类在软件开发工具的各个维度上都在作着“封装” 和“抽象”，架构设计是这种抽象和封装的最高层次。从架构的维度上，已经不须要考虑语言、函数、设计模式这一类的抽象，而是站在总体软件系统的高度上，考 虑系统设计的技术合理性，需求实现的完整性，商业诉求的匹配度（主要是成本和效率）——这是架构的技术职责。

另外一方面，随着行业的发展，软件项目的参与角色和人员也越来 越多，从起初只有程序员和需求方，发展到技术、产品、设计、商务、项目管理多团队，技术团队内部的分工也愈来愈细化，前端、后端、测试、运维、售前售后技 术、集成技术等应运而生。架构师是技术团队面向产品设计等团队的接口人，承担着弥合技术与非技术团队之间知识和语言体系差别的职责，同时做为技术团队的带 头人，要负责勾勒蓝图，明确边界，让不一样技能的团队通力协做，最终完成软件系统的总体建设和发布——这是架构的组织职责。
2.一、架构的技术职责

首先，架构师常常被类比于建筑师，可是有两个建筑领域的基础理念，在软件架构领域是不成立的（至少现阶段不成立）：

建筑设计师在成为建筑设计师以前，是不会成为建筑工人或工程师的。——现阶段的软件架构师，必定是从软件工程师成长起来的。

建筑学和工程学之间的区别表如今“作什么”和“怎么作”：建筑师决定作什么，工程师想出怎么作。——现阶段的软件架构师，除了决定作什么，也要决定关键部分怎么作。

架构的技术职责分为三大块：

    抽象设计；
    非功能设计；
    关键技术设计。

首先是抽象设计。架构师须要能自由地在不一样的抽象层次和视角上分析需求，不一样的架构层次/视角提供了不一样的视图，这些视图互相验证，又能构成总体的设计大图。架构的抽象层次分红两个维度：

    垂直维度

从上到下，分红企业架构、解决方案架构、应用架构、系统架构 等，这个分层的逻辑，是提供不一样颗粒度的业务建模。CTO关注企业架构，它提现了一个企业总体的IT技术建设的战略选择，典型的就是集中式和SOA、大型 机和云计算的选择等；产品经理和运维关注应用架构，这里映射了产品的业务流程和应用的总体部署依赖；外部客户关注解决方案架构，它定义了如何经过产品的整 合和协同，解决特定客户的特定的技术方案需求；研发工程师关注系统架构，这里定义了单个系统的领域建模和系统框架。

    水平维度

具体到对某一个业务的架构设计，又能够区分出业务架构、数据 架构、技术架构、应用架构几个不一样的视角。业务架构是对业务领域和业务流程的分析抽象，须要提炼出业务的核心领域模型，业务的可变和不变部分，这是架构师 和产品经理协同完成的；数据架构基于业务架构提炼的核心领域模型作数据模型和存储模型的设计；技术架构基于业务的性能，可用性，安全等非功能性指标，肯定 语言、框架、中间件、部署等技术选型；应用架构基于业务抽象设计应用系统的层次结构、系统边界等。

在这些架构划分中，企业架构匹配商业模式，业务架构匹配业务模式，其余几个架构的划分，更多的是从技术的不一样视角来看，他们提供了从不一样的抽象层次，不一样的切面对于功能需求的分析和建模。

同时须要说明的是，架构的抽象是匹配于业务的，就像桥梁设计师不能直接转作摩天大楼设计，架构抽象也是区分领域的，每个业务领域都有本身的独特性，所以在架构上也是千人千面的，好的架构设计也是对于业务抽象得最好的设计。

架构师的另外一个技术职责，是对非功能需求的分析。这 也是“架构服务于功能，高于功能”的含义。这里的非功能性需求包括了软件系统的可靠性、扩展性、可测性、数据一致性、安全和性能等。考虑到成本和运行环境 等限制，这些非功能性需求不少时候是不能同时知足的。这个时候就须要“权衡”