对于IT技术人员来说，架构算是出现频率较高的词汇了。我们在讨论问题时画的条条框框也可以算作架构。只是平时并没有去深究什么是架构，怎么做架构。本书第一章就简单介绍了架构的方方面面。
-
架构的定义
- 架构是对构成系统的子系统或组件及它们之间的关系的描述，包括系统运行的环境及指导系统设计和演进的原则。
- 架构与设计的关系
- 这里说的设计指的是软件设计。软件设计主要关注的是子系统或组件代码实现层面的事情。架构关注的是构建系统骨架的问题，涉及功能，组织，业务，技术，质量属性等方面。
- 我们比较熟悉的设计模式，主要是关于如何组织代码以提升可扩展性、可维护性。
- 个人理解：
- 首先软件架构是对系统的一种高层次的描述。这个层次到了子系统或者组件。架构并不是对系统的事无巨细的描述。低层次的，诸如代码层次的设计和决策，架构可以不关注。
- 对构成系统的组件的描述，侧重于职责的划分。每个组件承担什么职责，完成什么任务，提供什么服务。是一种基于职责和功能的拆解。
- 对组件之间关系的描述，侧重于依赖关系和协作。系统要基于组件构建出新的能力和服务。
- 环境，就是我们常说的上下文。一个系统，必须有一个确定的上下文，必须要有一个确定的运行环境。需要明确这个上下文，否则很难在有限的资源下完成交付。
- 系统的设计和演进原则，必须提前确定。在需求或方案发生冲突时，可以根据原则进行取舍。
-
架构的特点
- 架构定义了系统的结构
- 最好是用结构图来表示架构，比如4+1试图。结构能够给我们提供对架构的洞察，以及一种独特的视角来分析质量属性。简单说就是结构图更容易理解，可以更容易抓住关键要点。
- 架构只关注一组核心要素
- 架构不能关注系统的所有细节。架构师的精力有限。关注的太细会导致架构太僵硬，缺少灵活性。架构只需要关注构建核心功能的核心元素集合即可。
- 架构捕获了系统的早期设计决策
- 架构师在系统早期通过仔细分析核心需求，做出了最初的设计决策。这些决策会极大的影响系统的后续开发和交付，需要谨慎对待。
- 架构处理涉众的需求
- 一个大的系统会牵扯很多涉众，如用户，市场销售，开发测试，运维交付等。每个角色的关注点不一样，利益诉求也不一样。大部分时候都会有冲突。架构师要拉通这些角色做出妥协。有时候我们会看到系统中一些奇怪的决策，大概率都是妥协的产物。这对架构师的能力要求很高。这难道不是产品经理的职责么？
- 架构影响组件架构
- 康威定律。系统架构和组织架构相互影响，很难说谁是主谁是次。采用微服务架构的组织，通常是扁平的小团队组织。
- 架构受其所处环境的影响
- 这里列举的环境因素有：
- 质量属性需求。质量属性需求会极大的影响系统架构的设计。比如互联网Web系统，会重点考虑系统的伸缩性和可用性。
- 标准遵从。大的公司，大的系统，通常会有各种标准的约束，比如开源组件选型，节能减排，安全隐私等方面的标准。
- 组织的影响。组织的人员构成，技术背景等因素会影响架构，比如技术选型等方面。
- 架构师的专业背景。架构师总是倾向于选用熟悉的、有历史经验的技术或方案来设计新系统的架构，以减少交付风险。
- 这里列举的环境因素有：
- 架构是系统的一种记录
- 架构捕捉了系统的核心需求，约束条件，以及涉众之间权衡。记录架构是一种很好的描述系统的方式。通过架构，我们可以更好的，更深入的理解系统。
- 可以通过4+1视图，4A架构图等方式描述架构。
- 架构通常符合某个模式
- 我们碰到的问题，通常是其他人处理过的；我们实现的需求，也通常是某种重复需求。人类的创新，是非常缓慢的一个过程。我们设计出来的架构，通常也是某种架构的重复或变体。这些重复出现的架构，可以抽象成一种模式。比如C-S架构，管道与过滤器架构等。
- 架构定义了系统的结构
-
架构的重要性
- 估计大部分人都不会问这个问题。我们早已经习惯了给每个系统设计架构，也讨厌中途变更架构。当你为系统做了架构设计，对系统就有了更深的理解和更合理的规划。
- 架构为系统选择需要优化的质量属性。系统不可能实现所有的质量属性，成本太高，也没必要。况且质量属性之间也有冲突。架构师会根据业务特点选择必要的质量属性去优化。
- 架构可以帮助构建系统原型。我们可以在开发早期，根据架构去搭建一个简单的系统原型，以验证系统的某些功能和指标。而不是等到系统开发完成后才发现某些指标无法实现，再去推倒重来。
- 架构允许系统以组件的方式构建。架构可以帮助我们从比较高的层级审视系统的功能。如果发现某些功能由已有的组件提供，那么我们就无需从头开发。这也提醒我们，在开发一个系统时，不要着急动手。先分析和拆解系统。没必要从头开始造轮子。
- 架构有助于管理对系统的修改。有了架构，我们可以通过分析找出最小的修改范围，降低变更风险和工作量。
