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

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

抽象设计；

非功能设计；

关键技术设计。

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

垂直维度

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

水平维度

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

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

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

架构师的另一个技术职责，是对非功能需求的分析。这也是“架构服务于功能，高于功能”的含义。这里的非功能性需求包括了软件系统的可靠性、扩展性、可测性、数据一致性、安全和性能等。考虑到成本和运行环境等限制，这些非功能性需求很多时候是不能同时满足的。这个时候就需要“权衡”，空间换时间的算法层面的权衡，性能和可测性、可靠性的权衡，一些权衡甚至上升到了学术层面，变成无完美架构的理论根基（如CAP理论）。

架构师的最后一个技术职责是关键技术设计。建筑师不只是做整体外观设计的，建筑师也需要考虑关键部分的细节设计——曾经在巴塞罗那圣家堂，我甚至看到高迪连教堂里一把椅子都留下了详细的设计图纸。同理，架构师也需要对可能影响到软件系统整体质量的关键部分，做更细节的详细设计。

2.2、架构的组织职责

架构师是企业的一员，作为“边界人”，承担着在不同角色、团队之间沟通协调的作用。

和业务、产品团队的协作

软件系统是解决现实世界的问题的，任何的软件系统都是业务相关的，当一个软件系统的商业模式确定之后，架构师就开始和业务、产品团队紧密合作，确定软件系统的业务架构和领域模型。业务和领域模型抽象的好坏，决定了软件产品是一次性的解决方案，还是可以持续支撑业务成长的真正的产品。

需要说明的是，业务、产品方和架构师是需求方和实施方的关系，所以，双方之间既是合作的关系，有时候也是谈判双方的关系，特别是对于外包型的软件产品而言，这个时候，架构师又承担着在业务方和技术团队之间找到诉求契合点的重任。

和技术团队的协作

研发阶段，有架构师参与的项目，往往牵涉多个不同方向，不同业务领域的研发团队。架构在其中的作用，是整体大图的传导，以及应用和团队研发边界的划分，对于影响到整体的非功能需求的关键技术点，架构师也要能亲力亲为完成设计。归根结底，架构师为软件系统的整体质量负责，也为研发团队的研发分工负责。

部署阶段，架构师需要和运维团队一起评估满足整体非功能需求的前提下，软件系统部署的硬件成本和部署拓扑结构。例如对于互联网应用，针对性能要求，是否需要CDN，带宽需求；针对可靠性，是否需要多机房部署；针对安全，是否部署相关的安全软件。最终的部署策略，仍然是基于成本和需求的一个权衡。

技术团队是架构师的大本营。根据不同公司的职能定位不同，有的架构师立足于技术团队，有的游离于技术团队。立足技术团队使架构师能更深入了解团队所负责的产品，因此能对业务做更合理的建模，也有利于架构师对关键技术方案做针对性设计，但是可能会限制了架构师拥有更加全局的视角。游离于技术团队的架构师能够从全局看待软件设计而不受制于屁股，因此更能从客观合理的角度规划整体设计，但是由于对技术团队没有管理职能，对于方案的落地只能依靠个人的技术号召力，而且，游离意味着疏远，如果架构师不能自觉地去跟进软件产品的实际落地，可能慢慢就会架空，变成PPT架构师。

简言之，架构师既不能完全负责某个技术团队，也不能完全游离在技术团队之外，这个，又是一个职能定位的权衡了。

同时，架构师和技术团队的协作，还有一个很重要的组织职能。如前述，架构师既决定了整体的架构选型，也决定了关键的技术方案的设计，而什么是需要架构师亲力亲为的关键技术方案，是架构师来确定的。因此，这就引申出架构师的另一个重要的组织职能——团队培养。如果架构师完成所有的技术方案设计，研发团队只管写代码，架构师会累死，研发团队也不会成长，这就要求架构师给予研发团队足够的成长空间和信任，并因此承担一定的风险和责任，这是这个角色必须承担的。

和其他角色的协作

除了产品和技术团队，架构师需要协作的还有项目经理，外部客户，甚至是公司财务……一句话，架构师作为技术方案的总负责人，对接所有对技术方案有关联关系的合作方。

如何沟通

协作就需要沟通，架构需要掌握多门沟通语言，而最好的语言是图表。对于产品来说，架构师沟通的工具是业务架构，用例和领域模型；对于研发团队来说，架构师沟通的工具是应用架构，组件和时序图；对于运维团队来说，沟通的语言又成了部署架构。图表的作用是维护共同的语言，同时也是让设计文档化以便于传承。

3、架构师的成长

上面讲了架构师的职责，职责既是能力的要求。可以看到，架构师既是一个全方位的技术专家，也是一个沟通协作的专家。因此，总结一下，架构师的成长，也是两条线：

技术上

架构师的首要工作是抽象建模，而首要的首要是要了解自己所处的业务领域，只有对业务足够了解，才能更好地抽象和建模，也更能沉淀通用的设计方法论。几年前，我曾经看过我司首席架构师的书单，其中有银行卡组织的介绍的，有零售银行的业务分析的，而那个时候，我司还只是金融业边上的支付公司而已。

另一方面，架构师需要在业务领域所涉及到的技术领域中，都要了解甚至精通，譬如对于互联网行业的架构师，小到语言、算法、数据库，大到网络协议，分布式系统，服务器，中间件，IDC等等都需要涉猎。一句话，架构师是技术团队的对外接口人，也应该是外部团队技术问题的终结者。广度之外也要深度，对于关键的技术模块的设计，架构师需要有技术的权威性。

组织和个人成长上

架构师要作为业务和技术的桥梁，因此需要精通业务和技术的语言，要锻炼沟通能力，不只是口头的沟通能力，也包括用标准化的图表表达设计思路的能力。

架构师需要一种“中庸之道”。不管是技术的选型，团队的协作、培养和分工，商业诉求和成本、产品需求和技术诉求的匹配，很多时候都是一种权衡。可以说，架构的工作主题就是权衡，这可能也是工程师成长为架构师最大的挑战。工程师经常是完美主义的，程序也总是精准精确的，但是架构师要习惯于不完美和一定条件下的不精确。

4、补充说明

上面写了这么多，其实针对的是大型的，有明确需求的，多团队参与的项目或者产品的架构师。现实世界中并不都是这样的项目，所以也并不都是这样的角色分工。例如，对于创业团队来说，活下来是最重要的，所以创业团队崇尚的是敏捷开发，快速构建，灵活试错，37signals的《Getting Real》是这种思想的最好诠释。这样的研发体系特别适用于不需要太复杂的底层设计，功能扁平化的，可以快速开发原型，小迭代不断扩展的应用，特别是web应用和APP。

另外，架构师也不是技术人员唯一的方向，甚至不是大多数技术人员的职业方向。在技术上，架构师是广度优先兼具深度，同时在技术之外附带了许多的业务性和组织职能，而很多的技术人员会更倾向于在技术的深度上不断挖掘，也不愿意投入太多的精力在业务和沟通上，这样的技术人员其实更适合的是技术专家的路线。技术专家研究的是纯粹的技术，这里面可能有算法、有编程语言、有运行容器（虚拟机、操作系统、应用服务器、中间件）、有通讯机制，这些都有足够的源源不断的问题等着技术人员去解决，而他们解决的问题，也成为软件技术不断向上抽象，不断模式化的基础，所以，技术专家的路线也是同样重要的。