架构师，老兵哥刚参加工作那些年业界还没有这个职位，那时候跟技术相关的岗位就是开发工程师、测试工程师和系统工程师，后来随着软件规模不断增长而产生的，尤其是在互联网浪潮下用户数和访问量都是海量化的。在各种机缘巧合下，老兵哥结合个人喜好选择了走架构师路径，从懵懵懂懂边做边学，到现在总算摸出了些门道，回顾这个过程还是有很多经验可以分享的，接下来我准备把这些内容梳理后分享出来，给需要的小伙伴参考。今天我们先来看看什么是软件架构？它对软件研发来说有什么独特的价值？
- 1. 教科书式定义
软件体系结构，又称软件架构，目前业界尚无统一的定义，常见定义如下：
在一定的设计原则基础上，从不同角度对组成系统的各个部分进行搭配和安排，由形成系统的多个结构组成了架构。它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性，指其他组件对该组件所做的假设。软件架构，还包括符合系统完整性、经济约束条件、审美需求和样式，它并不仅注重对内部的考虑，而且还在用户环境和中对系统进行整体考虑，即同时注重对外部的考虑。软件架构，输出系统整体结构与组件的抽象描述，一系列关联的抽象模式，一个系统的草图，用于指导大型软件系统构建的各个方面设计。
一般而言，软件架构是一个软件系统从整体到部分的最高层次的划分。通常，一个系统是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息，主要包括：
- 架构组件（Architecture Component）：组成系统的核心元素。
- 联结器（Connector）：描述组件之间通讯的路径、机制和预期结果。
- 任务流（Task-flow）：描述系统如何使用这些组件和联结器完成某一项需求。
软件架构，是构建系统时所做出的最高层次的决定，之后很难被更改，这个决定不单单是技术维度的，还包括商业维度的。在建造一个系统之前，许多重要决定需要事先作出，而一旦系统开始详细设计甚至进行建造，那这些决定就很难被更改，甚至无法被更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
- 2. 大神们怎么说
上述教科书式的定义是非常专业、抽象和完整的，但对于缺乏架构工作经验的人来说，这类风格的定义是难以理解吸收的，读还是可以读懂，但是无感。接下来，我们先听一听行业内的大神是怎么定义软件架构的。Mary Shaw、David Garlan，经典书籍《软件体系结构》的作者，曾给出相对简化的定义：
软件体系结构 = { 构件（Component），连接件（Connector），约束（Constrain）}。
软件体系结构，以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理。在软件设计过程中，它是超越算法和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议，同步机制，数据存储，给设计元素分配特定功能，设计元素的组织、规模和性能，在各设计方案之间进行选择等。
- 3. 接地气的阐述
最近这些年，老兵哥我经常要给应届生同事培训应用架构，起初我就采用教科书上的定义，再附上大神的阐述，心想新同事们应该能够理解。但后来有机会给非计算机专业的学员介绍架构师相关工作职责时，我才发现人家无法理解这么专业抽象的答案，毕竟人家没有专业背景，也未曾做过相关工作。虽然上述定义都很好，但如果学员们无法体会理解并使用它的话，再正确也毫无意义。基于这层考虑，我开始采用学员们有亲身体验的案例来做类比。
计算机软件，是构成虚拟世界的基本元素。它的历史开始于二十世纪五十年代，非常短暂，而构成物理世界的建筑从石器时代就开始出现了，人类在几千年的建筑实践中积累了丰富的经验和教训。如果将软件比作虚拟世界的建筑，而软件架构就是建筑的主体框架。建造土坯房不需要复杂的框架，就是在地基上不断垒土，同样小型软件也不需要太过复杂的架构，面向过程、面向对象等就能满足需要了。但建造高楼大厦、小区楼盘等现代建筑就离不开复杂的框架，否则就建造不出来，即使建造出来了，但会存在坍塌的危险，大规模软件也依赖复杂的架构，否则无法化解其复杂度，无法持续更新升级、运维等。从这个角度看，架构师就相当于建筑设计师，这是需要创新创造的工作。
像构件、连接件和约束等软件架构概念，它们在建筑这个领域也能够找到对应，例如：建筑中的构件就是砖块、水泥立柱、预制板等，连接件就是连通每个楼层的楼道、楼梯和电梯等，而约束就是根据所在地域位置的自然和社会条件来确定建筑设计内容，可见我们人类建造虚拟世界的经验主要源自改造物理世界的过程。
- 4. 高大上的阐述
程序员是最喜欢自黑的一群人，我们常常用“码农”、“搬砖”来标榜自己，上面这种接地气的架构定义特别适合自黑的我们，从“搬砖”、“砌墙”的建筑工人转型升级至设计师，这应该也算比较自然、优化的选择。对程序员新人来说，上述阐述是比较形象易懂的，但是如果面向其他行业领域的人去解释，有没有更加高大上的阐述呢？老兵哥我经常要到外面做些职业发展类的培训授课，不管是学员还是合作伙伴都是非技术人员，为了让他们也能够理解我的本职工作职责，我经常用组织架构来类比软件架构。我们知道，组织架构是人力资源管理的重要工具，对于初创小企业来说，组织架构应该是简单实用的，但对于中大规模的企业来说，组织架构必须能够解决上规模员工的管理。
首先，人力资源能够为组织架构选择招聘合适的人才，并能够识别每个人才的优劣势，然后将其安排到可以发挥其特长的岗位，最后让其在具体的业务项目当中创造价值，这是不是有点像古代战场上的选人用人、调兵遣将？那么软件架构跟组织架构是类似的，不同是组织架构是用于人的，而软件架构是用于软件系统的。架构师要了解熟悉各种主流的技术栈、中间件产品等，知道它们身上的优劣势，并在系统设计中引用它们来解决特定问题，让每个构件都能够发挥出最大的效用，最后通过优势互补、紧密协作来化解业务的各种挑战。这种阐述是否更高大上？俗话说学而优则仕，如果我们能够把架构工作做好做到极致，那么等以后你晋升至管理层，这套方法论也是通用的。
看山是山，看山不是山，看山还是山，好像这也是我们学习技术的三重境界，穿越这三重境界离不开对软件架构这个领域做深入专业的学习和实践，这也是老兵哥正在努力做的。今天暂时先分享到这里，接下来我们还要继续剖析软件架构，看看架构是怎样演进变化的，都经过了哪几代迭代，每种类型的架构都有什么优缺点。
如果你觉得有价值，麻烦动动手指点下文 「 推荐 」按钮，让更多小伙伴可以看到，我也会更加有动力坚持分享。另外，老兵哥我后续还会分享职业规划、应聘面试、技能提升、影响力打造等经验，关注「 IT老兵哥 」，赋能程序人生！
- 软技能-热门文章：（首发公众号）
- “花式”裁员套路深，你知道吗？
- 遭遇裁员，如何渡过心理危机？
- 如何在寒冬中找到好工作？
- 2C 还是 2B，跟找工作有什么关系？
- 大公司 vs 小公司，你会选哪个？
- 记住这一点，不怕找不到好工作！
- 跳槽，跳还是不跳，该怎么跳？
- 程序员“求包养”攻略揭秘
- 很努力了，为什么我还在原地踏步？
- 从程序员到架构师，有捷径吗？
- 硬技能-热门文章：