在很多程序员的脑子里，都会有这么一条打怪升级的路：以前我也相信这条路，现在想想，可能是因为我看到的江湖太小了在我初出茅庐的时候。慢慢的，江湖久了，眼界开阔了，才发现自己的想法太简单了。“架构师”的第一个定义十多年前，初入江湖的我，初入深圳一家拥有上千研发人员的大型软件公司。面试我的人据说是公司的架构师。那时候，我真的是对这位建筑师充满了敬佩，以致到现在我还依稀记得他的容貌和声音。当时的后端主流技术是Struts+Spring+Hibernate，也就是当时业界常说的SSH；前端主流技术是HTML+jQuery+nativeJS。那时候还没有管理jar包依赖的maven，也没有开箱即用的SpringBoot。如果要将以上技术集成供开发者应用到新的项目中，往往需要几天甚至几周的时间。这是建筑师的责任。因此，我给架构师第一个定义：架构师是将各种框架集成到一个项目中，提供通用代码，支持开发人员完成业务功能开发，并提供必要的技术支持的人。后来，我回到了西安。此时，凭借自己的不断努力，我已经很好地掌握了上述技术。在西安的一家小型软件公司，我也做过架构师，同时给自己定下了一个工作原则：不参与业务功能的开发，而是为程序员提供通用的能力和技术支持。在接下来的几年里，我一直坚守着自己对架构的定义，原则性的业务知识，钻研各种酷炫的技术，为开发者提供支持，作为团队面对困难时的最后一道防线。“架构师”的第二个定义现在，我已经入江12年，在架构师的岗位上大概有8年了。本来以为“架构师就是巅峰”，中间一时迷了方向。经过与人的不断交流和多次面试经历，似乎每个人对“建筑师”这个词都有不同的理解。有一次，我参加一个架构师培训营，培训资料中有一张图片给我留下了深刻的印象。虽然我已经找不到原图了，但表达的想法如下图所示：Thelecturerwillarchitect比喻是交响乐中的指挥。在他的描述中，架构师的视角应该高于其他人。重点不在于个别具体问题，而应从全局的角度去考虑和规划，然后指挥他人。把计划付诸实施。建筑师如果深究细节，只会因抬头看路而迷失方向，就像“不识庐山真面目，只因身处此山”。于是，我对“架构师”有了第二个定义：架构师是一个看问题的角度比别人高，以更高的角度统领全局，不拘泥于技术细节的人。但这样的定义也让我在之后的面试中不断被面试官挑战。在大多数面试中，面试官对架构师的要求仍然是某项技术的深度，而不是整体的技术广度。“架构师”的第三种定义在近几年的工作经历中，我接触到了另外一类架构师，他们常被称为“解决方案架构师”、“行业架构师”、“交付架构师”、“售前架构师”architect”等等。刚开始从事这类工作时，我重新审视了之前给architects的两个定义，似乎此时的工作内容与那两个定义完全不同。经过将近2多年的解决方案架构师职位经历，发现这种架构师其实是作为客户的顾问存在的，工作内容几乎已经脱离了编码，而是赋予了一定的技术和产品体系，提供个人咨询服务之前，在客户购买期间和之后，帮助客户规划技术方向，产品组合，提供切实可行的解决方案等。此时，我脑海中诞生了“架构师”的第三个定义：架构师是站在战略层面，为企业信息化提供整体解决方案、路线规划和合规监管的人。人们。后来我以“架构师金证”通过了TOGAF，也为我打开了“企业架构”的大门，也让我更加坚信了我对架构师的第三个定义。“建筑师”不是这样定义的。虽然我脑子里有三种架构师的定义，但它们非但没有让我对架构师的理解更加清晰，反而让我更加困惑。尤其是在面试架构师这个职位的时候，明明自己很强，但是总感觉自己和面试官的对话不在同一个频道。这也让我一度怀疑自己的能力，开始否定自己。经过深入思考和阅读相关资料，我发现问题的根源在于对“架构师”一词的误用。MartinFowler（微服务架构的提出者之一）在他的一篇关于架构师的文章中说：不管架构是什么，都包含重要的东西，而架构师就是关注这些重要东西的人。在我看来，“架构师”这个词被滥用正是因为这个职位专注于重要的事情。所以在行业招聘的时候，只要涉及到重要的事情，都会被称为“架构师”。架构师的分类其实架构师有很多种，每一种架构师都有自己的成长路径——这与打怪升级不同。首先，我把“关注自己想要什么的人”分为三类，如下图：常见的技术专家包括：数据库架构师、缓存架构师、框架架构师、工作流架构师、大数据架构师、等这些架构师关注的是相应领域的技术细节，常见的产品和行业专家包括：售前架构师、解决方案架构师、交付架构师、某些行业架构师等，这些架构师关注的重点不是研发和技术，而是在某个产品系统或者某个行业的通用需求中，对于上图中的“架构师”，还可以进一步拆分，如下图所示：研发架构师：a负责IT项目或产品，负责IT系统的技术规划、研发、运维，常见职位包括：系统架构师、软件架构师、技术架构师等业务架构师：常见于各行各业life行业，负责规划所在公司的业务逻辑。常见职位包括：领域专家、业务架构师、首席设计师等。企业架构师：各行各业常见，负责公司内外IT系统的规划和建设。在非IT公司，主要负责公司内部IT建设，为业务部门提供信息化支持；在软件或互联网IT公司，只能负责公司内部系统，或者同时负责内部系统和外部系统。架构师这里说的工作方式主要分为两类：集中式和连接式。(1)中心化架构师。集中架构师的角色出现在团队中。当出现其他团队成员无法处理的问题时，集中式架构师将成为团队的最后一道防线。中心化架构师的优势在于：作为决策的唯一制定者，可以高效统一团队内部思维，保证团队内部的一致性。作为团队中经验和技术的专家，会给其他成员带来安全感。集中式的缺点是：作为唯一的决策者，集中式的架构师可以高效地统一思维，但在实际工作中，架构师往往不是最接近问题的人，架构师的误判也比较常见。由于中心化架构师是唯一的决策者，其他成员只能跟随，所以很可能做出错误的决策。中心化架构师强大的个人能力给其他成员带来安全感的同时，也会让其他成员对中心化架构师产生依赖，导致其他成员的积极性和主动性降低。架构师自身的工作强度也会相应增加。(2)连接的架构师就像胶水，他们更善于与他人合作。这样的架构师个人技术能力可能不突出，但他们有丰富的经验和沟通能力，通过与不同职能团队的深度合作，协助团队解决问题，并在必要时为团队提供相应的资源和授权。此外，连接架构师将成为技术人员和非技术人员之间的桥梁，连接业务部门和技术部门。在我工作的早期，我是非常支持中心化模式的，因为我觉得这种沟通成本最低，效率最高，但是现在，它的缺点不容忽视，系统越大，缺点越明显。所以我现在的推荐方式是以连接型为主，集中型为辅。总结结合本人在软件研发行业12年的工作经验，笔者对不同阶段的架构师职位提出了三个定义。在与各种人群讨论架构师的过程中，我得出的结论是，“架构师”这个词在业界被广泛“滥用”。在对建筑师的定位进行深入思考后，提出了建筑师的分类体系。笔者认为，被误用的“架构师”一词其实表达了包括技术专家、架构师、产品和行业专家在内的不同方向，并继续将架构师的方向分类为：研发架构师、业务架构师和企业架构师三种。简而言之，架构师专注于重要的事情，他们的视角应该更高，以避免陷入细节；系统越大，就需要越多的互联架构师，当团队犹豫不决时，就需要集中的架构师来快速做出决策。
