架构师成长：关于我在 ArchSummit 大会收获了什么

每一位软件开发人员都有一个架构师的梦。当谈到架构，究竟是谈什么？

0 题记

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

本次大会官网，感兴趣的同学可以自行了解，错过深圳站的同学可以去了解一下北京站 ：

因为我只参加了叶绍志博士组织的架构师成长专题，点击此处。本文想讲讲我在听完这个专题的讲座后，对架构的一点点思考。

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

有我的背影

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

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

1. 需求分析

2. 问题定义

3. 方案设计

4. 研发实现

5. 部署落地

6. 持续运营

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

2 架构及其分类

架构的本质是随着业务的增长而逐步演进的，并不能脱离业务而刻意设计。

2.1 应用程序架构

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

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

2.2 系统架构

系统架构看作是更大规模的应用程序架构。大多数软件系统实际上是由横跨不同层次和技术的多个应用程序组成。

举个例子，你可能有这样一个软件系统，Java EE 中间层消费 Oracle 数据库提供的数据，同时向 .NET Silverlight 客户端提供 Web 服务。每个部分都有自己的应用程序架构。

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

跟应用程序架构相比，系统架构描述为从组件和服务到子系统等更高层次的抽象。系统架构的定义大多数都包括了软件和硬件。毕竟，一个成功的软件系统离不开硬件，即使是云上的虚拟硬件。

2.3 软件架构

软件架构是指系统的基础结构。它是一般的概念设计，为软件的开发和维护提供信息，并定义它可以做什么和不能做什么。简单地说，软件架构就是一个系统的组织。此组织包括所有组件、它们如何相互交互、操作环境以及用于设计软件的原则。

软件结构就是应用程序和系统架构的结合。换句话说，从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构。

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

从开发者的角度考虑软件开发，关注点多数会放在代码上。

在这里，我们考虑的是有助于构架更好软件的东西，比如面向对象的原则、类、接口、控制反转、重构、自动化单元测试、代码整洁和其他不胜枚举的技术实践。

如果你团队里的人都只考虑这些，那么谁来考虑其他事情？比如：

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

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

• 审计及其他监管需求；

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

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

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

2.4 企业架构：战略而非代码

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

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

3 什么才是好的架构设计

第一，不脱离业务的刻意设计。

第二，从战略层面上：能够有效支撑业务的快速发展。

第三，从战术层面上：提高系统的高扩展性、高维护性、高伸缩性、高复用性。

4 成为架构师需要哪些技能

4.1 成为 T 型人才

架构说完了，说说成长。架构师一般都是技术深度优先，再横向扩展广度。也是就所谓的 T 型人才，如果没有在一个行业一个领域有一定的技术基础，我想他也很难成为这个项目的架构师、工程师。

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

作为一名架构师，需要跟部门各种人打交道，所以需要沟通和协调这种关系技能。还需要懂得共享目标、学会合作、甚至于向上管理。

4.2 如何成长

关于成长，最大的对手永远只有你自己，因此需要极致自律。让自己的路走宽的时候，也无需跟他人挤独木桥，自己可以卷自己热爱的事情，但从没想卷过他人，也不会推荐其他人像我一样去做。

又想到了高中时期最火的一句话：走自己的路，让他人去说吧。

职业中需要保持良好的能力和态度，这很关键，可以说人生的大部分时间都是在职场中度过。能力和态度决定了能不能走好走远。

如何提升自己在业界的影响力？扎根于一个领域，参与开源项目，热衷于分享自己的经验和学习成果，通过文章、书籍的形式进行传播等。 其中九叔有个观点说当他自己写不出东西的时候，他会认为他自己并没有得到成长，需要有一定的危机感了。

个人深有体会，自从参加社区的日更活动，或需要不停查看资料或看书，或解决了一个 Bug，方才有思路，最后总结自己的经验，写成一篇文章。

自己的读书也是，朋友说我是她朋友圈最爱看书的人了，但是自己近段时间不看非技术书后，也很少在朋友圈分享自己的关于读书的观点了。每天在业务代码中度过的日子又能与朋友分享什么呢？

所以，想要成长和进步，如果不大量获取和吸收，真的很难有观点输出。

毕竟，如果闭门造车，最后可能是贻笑大方。

PS:（这一部分内容也会将《荆棘与玫瑰：基础服务架构师的成长之路》的内容整理出一篇文章。）

5 总结：架构师成长——高阶 Coding 之路

优秀的软件架构设计是面向未来的思维。随着公司的发展，消费者期望的变化和新技术的发展，总会有新的需求出现，但良好的软件架构在设计上是灵活的。

成长，无非是自身最大的帮助。

最后，十分感谢 InfoQ 组织了这么好的一场大会，感谢写作社区让我有幸能拿到门票学习到大咖们的经验和知识。

希望有朝一日，自己也能成长那个站在大会讲台上的人，道阻且长，行则将至，行而不辍，未来可期。

自己的笔记

下午茶

大会部分礼品

希望下一次的 ArchSummit 仍有你我的身影。

参考链接：

• 架构师能力模型——打造六边形战士
  

• 荆棘与玫瑰：基础服务架构师的成长之路
  

• 程序员必读之软件架构

• 软件架构师的 12 项修炼