---
URL: "/zh-CN/blog/2024-10/why_sa.html"
LLMS_URL: "/zh-CN/blog/2024-10/why_sa.md"
lastUpdated: true
commentabled: true
recommended: true
title: "为什么需要架构师"
description: "为什么需要架构师"
date:

pageClass: "blog-page-class"
---

---
lastUpdated: true
commentabled: true
recommended: true
title: 为什么需要架构师
description: 为什么需要架构师
date: 2024-10-30 13:18:00
pageClass: blog-page-class
---

# 为什么需要架构师 #

在聊架构师这个角色之前，我们得先搞清楚一件事：行业里对这个职位的看法其实挺模糊的。回顾一下，过去在一些大公司，有那么一段时间，架构师被视作一个专职的角色。但现在，情况有所变化，这个称呼渐渐退回到了“工程师”、“专家”或“研究员”这类更加技术性的职位名称里。换句话说，那些曾经被冠以“架构师”头衔的人，现在可能更多的是以工程师或研究的身份出现。
但这并不意味着架构师这个角色就消失了。事实上，在我的个人工作经验中，遇到的所谓“架构师”五花八门。特别是在一些小团队中，项目经理可能也会自封为架构师。这里的“架构师”，更多的时候不是一个官方职位，而是根据项目需要，某人暂时扮演的一个角色。
如果你想了解架构师到底是什么，先得接受一个事实：在当前的技术领域，架构师这个角色还没有一个清晰且统一的定义。它更像是一个根据项目情况变化的角色，而不是一个固定的职业路径。这也就意味着，成为一个架构师，与其说是达到某个职位的高度，不如说是在特定情境下，扮演的一个必要角色。
1、架构师的定义
架构师：任何复杂结构的设计人员。
架构师这个概念是从建筑业借鉴过来的。实际上，如果我们将“Software Architect”直译成中文，它意味着“软件建筑师”。这不仅仅是一个简单的名字借用；在很多方面，软件架构师的角色确实与建筑师有着相似之处。为了深入理解这种联系，我曾经翻阅了不少关于建筑设计的书籍（比如，《建筑的永恒之道》是一本极好的参考资料），通过这些学习，我发现软件架构与建筑设计之间不仅有着历史上的联系，它们的发展轨迹在某些方面也可能朝着相同的方向前进。

一脉相承：无论是传统的建筑师还是现代的软件架构师，他们的核心职责都是为了构建一个宏大的设计蓝图，确保在需求方和实施团队之间架起一座沟通的桥梁。
**分道扬镳：**这种分歧主要是因为两个领域发展阶段的不同。建筑行业有数千年的实践历史和几百年的理论基础，已经发展成为一个高度模式化的领域。相比之下，软件架构作为一个领域的历史还不足二十年，仍然处于快速发展和变化之中。在这个阶段，软件架构师更多的是关注于技术的选择和实现方式，而不是设计的美感，这也是为什么软件架构师通常被看作是高级工程师，而不是设计师。
殊途同归：尽管如此，计算机科学的发展历程也证明了技术的持续抽象和模式化。从面向服务的架构（SOA）到物联网（IoT），再到“如果这个，那么那个”（IFTTT）的编程理念，我们已经开始看到软件领域向着建筑业已经达到的模块化水平迈进。随着技术的发展，软件架构师的工作越来越多地涉及到决定“要做什么”，而不仅仅是“怎么做”。这种变化预示着，未来软件架构师可能真正成为一个关注设计本身的职业，大学中甚至可能开设专门的“软件架构”专业。

当然，要实现这样的转变，我们这一代技术人员面临着巨大的挑战。我们需要像建筑行业的先驱那样，不断地规范化技术实践，形成设计模式，同时还需要建立一套既考虑架构美学又不忽视功能设计的统一标准。这是一条漫长而艰难的道路，但正如建筑领域所展现的那样，通过不懈努力，最终能够达到的成就是无限的。
2、架构师的职责
在软件行业的早期，"架构师"这个职位并不存在。那时候，大家都是程序员，也许会有一个领头的，称之为"主程序员"。但随着时间的推移，计算机技术飞速发展，软件开始渗透到生活的方方面面，不仅覆盖面广，而且复杂度大增。现在，拥有数百万甚至数千万行代码的软件系统已经变得司空见惯。随着软件日益复杂，开发者面临的挑战也与日俱增，因为人脑处理信息的能力终究是有限的。为了应对这些挑战，软件开发工具和方法也在不断进化，从汇编语言到高级编程语言，从基本的函数编程到复杂的框架，从面向过程到面向对象，从设计模式到架构模式，这一切都在展示着人类在软件工具开发上不断追求"封装"和"抽象"。
在这个抽象和封装的进程中，架构设计可谓达到了顶峰。作为架构师，不再需要过分纠结于编程语言、函数或设计模式等具体细节，而是要从一个更高的视角，全面考虑整个软件系统的设计，确保技术方案的合理性、需求的完整实现，以及与商业目标的契合度——这些构成了架构师的技术职责。
随着行业的不断发展，软件项目参与的角色和人员也变得越来越多样化，不仅仅局限于程序员和需求方，还扩展到了技术、产品、设计、商务、项目管理等多个团队。同时，技术团队内部的分工也越发细化，形成了前端、后端、测试、运维、技术支持等多个专业领域。在这种背景下，架构师成为了技术团队与产品、设计等非技术团队之间的桥梁，负责协调不同团队间的沟通，确保技术与业务的有效结合。作为技术团队的领导者，架构师需要勾画出整个项目的蓝图，明确各个环节的边界，引导各个专业领域的团队成员协同工作，共同完成软件系统的构建和发布——这就是架构师的组织职责。
2.1、架构师的技术职责
讨论软件架构师和建筑师的角色时，我们常常会发现两者之间存在着引人入胜的相似性和关键性的差异。这种比较不仅帮助我们理解软件架构师的角色，还揭示了软件开发过程中的独特挑战和机遇。
让我们来看看那两个在建筑领域根深蒂固，但在软件架构界至少目前不完全适用的基本理念：

职业路径的差异：在建筑领域，成为一名建筑设计师通常不需要经历建筑工人或工程师的角色。相反，软件架构师的成长路径几乎总是从软件工程师开始的，通过深入实践中积累经验和技术深度，逐渐演化成为能够担当架构设计重任的专家。这种差异反映了软件行业对于实际编码和项目经验的高度重视。
职责范围的差异：建筑学与工程学之间存在明确的分工——建筑师负责概念化设计，即决定要建造什么，而工程师解决实现问题，即如何建造。软件架构师则通常需要兼顾这两方面，他们不仅定义软件的功能和外观，还必须深入到技术实现的关键部分，确保设计的可行性和实用性。

这两个差异引出了软件架构师的三大技术职责，主要分为三大块：抽象设计、非功能设计以及关键技术设计。每一项都对成功的软件开发至关重要。
抽象设计的艺术：架构师的任务是在不同的抽象层次上自由地分析需求，每个层次或视角都为我们提供了一个独特的视图。这些视图不仅相互验证，而且共同组成了一个完整的设计蓝图。抽象设计可以从两个维度来看：

垂直维度：这里我们从顶层的企业架构到底层的系统架构，分别关注不同层面的需求和决策。比如，CTO更关心企业架构，因为它关系到公司整体的IT战略方向；产品经理和运维团队则更关注应用架构，涉及产品的业务流程和部署问题；而研发团队则深入到系统架构，专注于具体系统的设计和框架。
水平维度：针对特定业务，架构设计可以进一步细化为业务架构、数据架构、技术架构和应用架构。这些视角涵盖了从业务流程分析到技术选型的全方位设计。架构师和产品经理合作确定业务的核心领域模型；数据架构师设计数据模型；技术架构师选定技术栈；应用架构师规划应用的架构布局。

这样的划分使得每个角色都能在其专业领域内发挥最大的作用，同时确保整体设计的协调一致。架构设计的目的是为了确保技术解决方案能够精准地匹配业务需求，正如不同类型的桥梁设计师面对的挑战各不相同，软件架构的设计也需要根据业务领域的特性来定制。每个业务领域的独特性要求架构设计必须具有灵活性和创新性，以实现最佳的业务支持。
非功能需求的分析：架构的真正价值体现在对非功能性需求的满足上。这不仅仅是关于软件能做什么，更重要的是它如何做得好。我们谈到的非功能性需求包括软件系统的可靠性、扩展性、可测性、数据一致性、安全性和性能等方面。在真实世界的约束条件下，如成本、运行环境的限制，往往难以同时满足所有这些需求。
这就要求架构师进行精细的权衡。例如，在算法设计中可能需要在时间和空间之间做出选择，或者在系统性能和可靠性之间找到平衡点。有时，这种权衡甚至触及到学术领域，例如CAP理论就是关于在一致性、可用性和分区容错性之间做权衡的经典案例。架构师的工作就是在这些多维度的需求中找到最优解，确保系统在满足核心需求的同时，保持良好的性能和可用性。
关键技术设计：架构师的角色并不仅限于宏观设计。正如建筑师不仅关心建筑的整体外观，还会深入到细节设计一样，软件架构师也需要关注那些对系统整体质量有重大影响的关键技术细节。拿高迪的巴塞罗那圣家堂为例，连一把椅子的设计都不放过，每个细节都被赋予了深思熟虑的考虑。
在软件架构中，这意味着对系统中的关键组件进行详尽的设计，不仅是功能实现，更包括如何实现这些功能的具体技术选型、性能优化、安全策略等。架构师需要深入到系统的内部，确保每一个关键点都经得起考验，无论是在系统扩展、数据处理还是安全性方面。通过这样的细节关注，架构师确保软件不仅在今天有效，也能面对未来的挑战。
2.2、架构师的组织职责
架构师，作为企业中的一个核心角色，担当着“边界人”的重要职责。他们不仅是技术决策的制定者，也是不同角色和团队之间沟通协调的桥梁。
架构师与业务、产品团队的合作
在现实世界里，每个软件系统背后都有一个问题需要解决。简单地说，这就是软件存在的理由。但问题的解决并不只是随便写写代码就行，而是需要深入理解业务本身。这就是为什么，当一个软件的商业模式明确后，架构师要和业务、产品团队紧密地工作在一起。他们的目标是什么呢？是确定软件系统应该如何支撑业务，也就是说，他们需要设计出一个既能解决当前问题，又能支持未来业务发展的架构和领域模型。
这里的“架构”和“领域模型”其实就是把复杂的业务逻辑分解成一个个更容易理解和实施的部分。这种分解的好坏，直接影响到软件是否只能解决眼前的问题，还是能成为一个真正能随着业务成长的产品。
但要注意，业务和产品团队与架构师之间的关系并不总是那么简单。他们既是合作伙伴，又可能是谈判桌上的对手，尤其是在外包项目中。这时，架构师的角色不仅仅是技术决策者，更是需要在业务需求和技术实现之间找到平衡点的关键人物。简而言之，架构师的任务是确保软件既能满足当前的业务需求，又能灵活适应未来的发展。
架构师与技术团队的合作
在与技术团队的合作中，架构师的角色不仅仅是技术的引领者，更是团队合作的枢纽和策略制定者。直接切入重点，我们看到架构师在研发阶段的作用不仅限于构建技术框架和确定开发边界，还包括对项目中关键的非功能性需求——比如系统的性能、可靠性和安全性——进行精准的设计和实现。这意味着架构师不仅需要具备宏观的视野，将不同的研发团队和业务领域有序地编织在一起，还需要深入到技术细节中，亲自确保这些非功能需求能够得到满足。
在部署阶段，架构师与运维团队的合作变得尤为关键。他们需要共同评估如何在确保系统满足所有预定非功能需求的同时，实现成本和性能的最优平衡。这涉及到复杂的决策过程，如选择合适的硬件资源、决定是否采用CDN以提高性能、如何确保系统的高可靠性以及部署安全策略等。架构师在这一过程中扮演的是策略家和协调者的角色，旨在设计出一个既经济又高效的部署方案。
站在技术团队的角度，架构师的定位呈现出一种动态平衡。一方面，深耕于技术团队让架构师能够更深入地理解产品和业务需求，从而做出更加精准的技术设计和决策。另一方面，保持适当的独立和客观视角使得架构师能够从更宏观的层面审视和规划软件架构，避免过分陷入具体技术细节而失去整体的协调和控制。架构师需要在深入与独立之间找到合适的定位，确保既不脱离技术团队的实际，又能保持必要的全局视角。
除了技术设计和决策，架构师还承担着重要的组织职能——团队培养。架构师通过制定关键技术方案，不仅展示了技术领导力，还为团队成员提供了学习和成长的机会。这要求架构师既要有足够的技术洞察力亲自解决核心问题，又要给予团队足够的空间和信任，让他们在实践中学习和成长，即使这意味着需要承担一定的风险和责任。架构师的这一角色不仅是技术领导者，更是教练和导师，引导团队不断前进，提升技术实力。
综上所述，架构师与技术团队的协作是一场精心设计的平衡游戏，需要架构师在保证技术先进性和系统稳定性的同时，促进团队的协作与成长。架构师必须在技术的深度与广度、团队内部与外部的定位、以及领导与培养之间精准把握，以确保既能实现高效的技术创新，又能维护和促进团队的整体协作和发展。
和其他角色的协作
想象一下，一个架构师不仅仅是坐在电脑前写代码的技术人员，他其实更像是一个大指挥官。他的任务是什么呢？是确保软件项目从开始到结束都能顺利进行。这听起来简单，实际上却涉及到很多方面。
架构师需要和谁合作？首先是产品和技术团队，这个不用说，毕竟软件是由他们一起打造的。但这还不够，架构师还要和项目经理合作，确保项目按时按质完成。还有外部客户，他们是软件的最终用户，架构师需要理解他们的需求。甚至连公司财务部门也逃不过架构师的合作名单，毕竟软件项目的预算和成本也是非常关键的部分。
架构师的角色远不止是技术实施那么简单，他必须与所有相关方保持沟通和协调，从技术方案的角度出发，确保每个人的需求都得到满足。这就是架构师作为技术方案总负责人的真正含义：他是连接所有点的线，确保这些点能够形成一个完整的、成功的项目。
如何沟通
沟通是团队合作的基石，而对于架构师来说，沟通的艺术不仅仅是说话和写字那么简单。他们需要的是一种更高效、更直观的沟通方式——图表。为什么呢？因为图表能够跨越语言和专业的界限，让复杂的概念变得易于理解。
对不同的团队，架构师使用不同的图表作为沟通工具。比如，和产品团队沟通时，架构师会用业务架构图、用例图和领域模型图来说明软件要解决的业务问题和如何解决。这些图表帮助产品团队理解软件的业务价值和功能范围。
当转向研发团队，架构师则切换到应用架构图、组件图和时序图。这些工具帮助研发人员把握软件的内部结构和各部分如何协同工作。
对于运维团队，架构师又会用部署架构图来说明软件如何在实际环境中部署和运行。这样运维团队就能更好地理解和准备所需的资源和配置。
图表的力量在于它们提供了一个共同的语言，让所有人都能理解软件的设计和运作原理，无论他们的专业背景如何。同时，图表还能将设计文档化，便于传承和未来参考，确保软件的长期成功。简而言之，架构师通过使用图表作为沟通的桥梁，不仅促进了团队之间的理解和合作，也为软件的成功奠定了基础。
3、架构师的成长
在探讨架构师的角色时，我们首先要明确一点：架构师的职责直接定义了他们必须具备的能力。这意味着，作为架构师，不仅需要掌握广泛的技术知识，成为一个全面的技术专家，同时还要精通沟通与协作技巧。这样的定位要求架构师在技术领域有深入的理解和广泛的视野，能够看到技术如何服务于业务目标；另一方面，他们还需要具备出色的人际交往能力，能够有效地与团队成员、利益相关者进行沟通和协作，确保技术解决方案的顺利实施。简而言之，架构师的角色是技术与沟通能力的完美结合体，他们在将复杂概念分解成易于理解的部分方面发挥着关键作用，确保所有人都能跟上项目的进展。
所以，如果我们要总结架构师成长的路径，其实可以看作是两个主要方向：
3.1、技术层面
作为架构师，你的主战场是抽象建模，但战斗前的准备不能少，那就是深入了解你的业务领域。只有当你对业务有深刻的理解时，你才能高效地进行抽象和建模，并能够提炼出通用的设计方法。回想起几年前，我看到我们公司首席架构师的书单时，明白了这一点。尽管我们那时仅是金融领域边缘的一家支付公司，他的书单上却涵盖了银行卡组织介绍、零售银行业务分析等领域。
另外，架构师不仅需要理解业务，还得对涉及的技术领域有广泛甚至深入的知识。对于互联网行业的架构师而言，这包括从编程语言、算法、数据库，到网络协议、分布式系统、服务器、中间件、IDC等各个层面。简而言之，架构师既是技术团队的门面，也是解决外部技术问题的关键人。除了技术的广度，深度同样重要，架构师对关键技术模块的设计应具备权威性见解。这样的角色定位，要求架构师既是全面的技术探索者，也是业务领域的深度分析师。
3.2、组织和个人成长层面
架构师站在技术与业务的十字路口，不仅需要精通各自的语言，更要在沟通中架起桥梁。这意味着，架构师的能力远不止于技术深度，还包括能够以口头和书面（特别是通过标准化图表）的形式，清晰、准确地传达设计思路和决策逻辑。这样的沟通技巧对于确保团队成员、利益相关者和客户之间的顺畅交流至关重要。
架构师的工作本质上是一场不断的权衡和平衡艺术，涉及技术选型、团队合作方式、人才培养、任务分配，以及如何在商业需求与成本控制、产品需求与技术能力之间找到最佳匹配点。这种持续的权衡过程不仅展现了架构师的策略思维，也是他们价值的体现。与工程师的角色相比，架构师更需要适应并接受不完美的解决方案和在给定条件下的近似精确，这往往是因为现实世界的复杂性和资源的限制。
从工程师到架构师的转变，意味着从追求代码的完美到追求系统设计和决策的优化平衡。这个过程中，架构师需要发展出对业务敏感性，深入理解业务背后的逻辑和需求，并以此为基础设计出既符合技术发展又服务于业务目标的架构方案。同时，架构师还要在技术前沿不断学习和探索，确保所采用的技术方案既前瞻性又实用，能够支撑业务的长期发展。