当前位置：网站首页>架构师成长：当谈到架构，究竟是谈什么

架构师成长：当谈到架构，究竟是谈什么

2022-07-20 23:41:00 【InfoQ】

每一位软件开发人员都有一个架构师的梦。

题记

上周六（7.16）有幸在深圳参加了 ArchSummit 全球架构师峰会，大会内容丰富，大咖云集，主题也有很多：包括但不限于前端、低代码、云原生、架构师成长、大数据等等。之前也参加过其它类型的技术大会， AS 给我的感觉，不论是内容形式和质量上都是独一档的。还有下午茶（忘记拍照了）与很多精美小礼品和活动抽奖，见文末。

本次大会

官网

，感兴趣的同学可以自行了解：

因为我只参加了叶绍志博士组织的

架构师成长

专题，点击

此处

。本文想讲讲我在听完这个专题的讲座后，对架构的一点点思考。

当谈到架构，究竟是谈什么

说到架构，可能很多人有不同的看法。有人会觉得架构师只是画框框线线的指挥家，另一些人会觉得架构师是一个技术过硬的实力派。架构无处不在，当谈到架构的时候，是在说什么？

叶博士给出了他自己的回答，架构的本质对应着软件研发周期的六个阶段，而这六个阶段从架构上也是不同的视角。这六个阶段分别是：

需求分析

问题定义

方案设计

研发实现

部署落地

持续运营

PS：更多详细内容将会通过整理演讲文稿的形式给出。

什么是软件架构

软件架构是指系统的基础结构。它是一般的概念设计，为软件的开发和维护提供信息，并定义它可以做什么和不能做什么。

软件架构是软件系统的基本底层结构。就像物理架构定义和限制如何有效地使用特定建筑一样，软件架构定义了软件是什么或可以是什么。虽然对用户通常是不可见的，但软件架构塑造了他们对特定软件的体验。

同样，软件架构对软件开发人员也有巨大的影响。当选择不当或执行不力时，软件架构可能会阻碍开发人员，将他们打包到一个难以适应或成本高昂的系统中。然而，如果做得好，软件架构允许灵活地扩展或适应以满足未来的需求。

如果说硬技能是架构师的安身之本，那么架构师除了从软件研发周期的六个阶段思考，还需要一定的软技能。

简单地说，软件架构就是一个系统的组织。此组织包括所有组件、它们如何相互交互、操作环境以及用于设计软件的原则。

为什么需要架构及其分类

因为系统复杂、组织复杂、业务复杂。

应用程序架构

对于我们软件开发者来说，最熟悉的应该是应用程序架构，特别是通常由单一技术编写的“应用程序”（比如Java网络应用程序、Windows桌面应用程序，等等）。应用程序架构的关注点是应用程序，通常包括将应用程序解构为类和组件，确保设计模式的正确应用，构建或使用框架，等等。本质上，应用程序架构谈论的是软件设计的低级别切面，通常只考虑单一的技术栈（比如Java、微软.NET等）。

结构单元主要以软件为基础，包括编程语言和结构、类库、框架、API等。它由类、组件、模块、函数、设计模式等加以描述。应用程序架构着重考虑软件和代码组织。

系统架构

我喜欢把系统架构看作是更大规模的应用程序架构。大多数软件系统实际上是由横跨不同层次和技术的多个应用程序组成。举个例子，你可能有这样一个软件系统，Java EE中间层消费Oracle数据库提供的数据，同时向.NET Silverlight客户端提供Web服务。每个部分都有自己的应用程序架构。

要让整个软件系统工作起来，就要思考如何组合这些单独的应用程序。换句话说，要有端到端软件系统在较高层次上的整体结构。另外，大多数软件系统都不是孤立的，因此系统架构还关注互操作性和与环境中其他系统的集成。

结构单元就是各种软硬件，从编程语言和软件框架到服务器和基础设施。跟应用程序架构相比，系统架构描述为从组件和服务到子系统等更高层次的抽象。系统架构的定义大多数都包括了软件和硬件。毕竟，一个成功的软件系统离不开硬件，即使是云上的虚拟硬件。

软件架构

应用程序和系统架构相对较容易理解，但人们对“软件架构”一词的理解不尽相同。我想把软件架构定义得尽可能简单，而不去受制于各种定义的复杂性和细微差别。对我而言，软件结构就是应用程序和系统架构的结合。

换句话说，从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构。从开发者的角度考虑软件开发，关注点多数会放在代码上。在这里，我们考虑的是有助于构架更好软件的东西，比如面向对象的原则、类、接口、控制反转、重构、自动化单元测试、代码整洁和其他不胜枚举的技术实践。如果你团队里的人都只考虑这些，那么谁来考虑其他事情？

横切关注点，比如登录和异常处理；

安全性，包括认证、授权和敏感数据保密；

性能、可伸缩性、可用性和其他质量属性；

审计及其他监管需求；

客观环境的约束；

互操作性、与其他软件系统的集成；

运营、支持和维护的需求；

结构和整个代码库解决问题、实现特性的方法的一致性；

评估正在构建的基础有助于交付按计划进行。

有时你需要退一步，远离代码和你的开发工具。这并不意味着低层次的细节不重要，因为可用的软件最终还是要靠交付可运行的代码。细节同样重要，但就大局而言，对软件的整体视角可以确保你的代码符合整体愿景而非背道而驰。

企业架构：战略而非代码

企业架构一般是指整个组织的中心工作，着眼于如何组织与利用人员、流程和技术来使企业有效和高效地工作。换句话说，它是关于企业如何分成组或部门，业务流程如何在上层运作，以及技术如何支撑这一切。这跟软件架构形成了强烈对比，因为企业架构没有必要关注技术细节。相反，企业架构可能看重的是如何在整个组织中最好地利用技术，而无需实际介入这些技术的工作原理。

有些开发者和软件架构师把企业架构看作职业发展的下一站，然而大多数人却并非如此。从事企业架构工作所需要的思维方式和软件架构大相径庭，对于技术及其在组织中的应用，视角很不一样。企业架构需要更高层次的抽象。这关乎广度而非深度，关乎战略而非代码。