架构师是什么？

作者简介：

蔡学镛，台湾台南县人，程序员，1999年获得台湾清华大学计算机硕士学位。曾为创新工场首席布道师。

现在多数人对于架构师的理解，总认定他们是高并发高可用的系统设计专家，但我认为这样的认识过于片面。例如，嵌入式系统的设计也可能需要架构师，但嵌入式系统没有高并发需求。

简单来说，架构师就是设计架构的专家。但这个解释可能会犯众怒，因为只是把问题放到「架构」这两个字上头，根本没有正面回答问题。所以我接下来必须解释什么是架构。什么是架构？这又是一个难以回答的问题。我们将范围缩小到软件架构，会好解释一些。简单来说：

软件架构就是「关键」代码的组织与交互方式。

这里说的代码，更多指的是运行时期的代码，而非开发时期的源代码。但开发阶段的代码设计当然会影响到运行时的代码，所以设计架构时也不能完全忽略源代码的设计。

根据这样的推理，架构简直又无所不包了。这时候请把眼光放在「关键」两个字上。关键代码包含两个方面：

1. 核心代码设计

2. 影响开发、运维、以及未来可扩展的代码设计

核心代码负责处理此系统最关键的任务，肩负著此系统成败的重责大任，所以架构师最好能深入到详细设计。

至于其他部分如果会影响开发、运维、和未来扩展，架构师也必须参与设计。设计粒度可以稍微粗一点，在模块的粒度即可，不需要深入到详细设计。

除非是纯技术型的项目（例如设计一套分布式缓存系统），否则核心代码的设计与未来可扩展的代码设计应该都会涉及到行业知识。这就回答了一个常见的问题：架构师是否需要深入到行业知识？这是根据「项目性质」而定。

但架构师的岗位设计，最好能兼顾到个人兴趣。一个好的架构师，往往有很强的自我驱动力，逼著他去干他没兴趣的活，通常不会有好下场。让他去做他有兴趣的事，他拼了命也会把事情做到极致。很多技术能力好的架构师，非常不愿意碰领域（行业）设计。他们自我定位这么清晰，也未尝不是好事。就别逼他们去做领域设计了。

因此，架构师最好分为技术型的架构师，与领域型的架构师。技术型的架构师就只搞专心技术，领域型的架构师必须技术和行业领域兼顾（但更侧重领域）。有些领域型的架构师没有提炼出快速上手新领域的方法，只能固定在一个领域。有些领域型的架构师则可以跨不同领域。

除了技术型与行业领域型这两类型的架构师之外，还有运维类型的架构师和数据架构师。运维类型的架构师侧重在基础设施（ Infrastructure ）的软硬件与网络，更没有行业领域属性。数据架构师则必须领域知识与数据库技术兼顾。

架构师一词相当泛滥，大家莫衷一是，希望这篇文章能起到解释的作用，让大家理解我们的工作范畴。