第一部分 安全架构基础
第1章 架构
我们都听说过“架构”这个词，那么架构是指什么呢？本章力求用最简单的语言，让读者明白“架构”并不是虚无缥缈的概念，而是一种在方案设计、系统实现、产品部署、安全改进等项目活动中所必需的思维模式、通用语言和沟通桥梁。
1.1 什么是架构
没有图纸，我们能够直接建造简易的建筑，如围墙、小棚等。但是，没有图纸，我们能够建造出埃菲尔铁塔吗？如图1-1所示。没有图纸，就没有宏伟的建筑。架构所要提供的正是类似于“图纸”这样一种东西。
图1-1 没有图纸就无法建造的埃菲尔铁塔
架构是系统中所有元素以及元素间关系的集合。简言之，架构由元素和关系组成，如图1-2所示。
图1-2 架构的定义
通俗地说，架构就是系统中包含了哪些元素，这些元素之间的关系是什么样的。也有人把架构简单地总结成“几个框”加上“几根线”，那么这几个框就是元素，框之间的线就是关系，这样就很好理解了。回到埃菲尔铁塔这个例子，元素就是铁塔有哪几个主要部分，关系就是这些部分之间是如何组合在一起的。
元素往往也称为组件或逻辑模块，比如当我们说“组件”的时候，表示这是一个独立存在的元素，是一个基本的功能单元（就像一个零部件），如开源组件：
■ Nginx提供前端Web服务功能。
■ MySQL提供数据库功能。
而逻辑模块，表示一个抽象的逻辑单元，往往并不独立存在，而是依附、融入或横跨在多个组件上，如本书即将讲到的安全架构的5个主要的逻辑模块。
由抽象到具体，架构包括如下几个常用的概念：
■ 概念架构（Conceptual Architecture）：在产品的早期，或者需要向上汇报的时候，通常会使用概念架构，以尽可能简化、抽象的方式，传达产品的概念或理念；概念架构仅涉及基本的定义（组件和组件之间的关系），不涉及接口细节等内容。
■ 逻辑架构：在产品需求逐步明确后，通常会用到逻辑架构，体现出业务逻辑模块及之间的关系。
■ 物理架构：在产品发布或部署时，需要用到物理架构，体现具体的组件及部署位置。
接下来，我们将主要使用概念架构或逻辑架构，并使用架构图来展示元素（组件或逻辑模块）以及元素之间的关系。例如，常见的三层架构如图1-3所示。
图1-3 三层架构示例
其中：用户接口层、业务逻辑层、数据访问层构成了三层架构的元素（模块），中间的箭头表示了它们之间的访问顺序关系。
提示
有关架构的进一步知识，可参考TOGAF:The Open Group Architecture Framework
等资料（TOGAF是一个被广泛接受的架构框架。除此之外，也存在其他的架构框架可供参考）。这些内容不是本书的关注重点，因此不再展开讲述。
1.2 架构关注的问题
对用户而言，一个好的产品主要体现在如下方面：
■ 是否提供预期的功能。
■ 质量是否过关，且没有副作用（不会给用户带来额外的损失或麻烦）。
如果一把菜刀，切几次菜之后刀刃就变形了，那么这把菜刀从质量上讲就是不合格的。
架构的出发点也是一样的，需要考虑的主要因素也是功能和质量，如图1-4所示。
图1-4 架构关注的问题
对于产品功能，需要对功能模块、组件进行分割与组装，且保障模块及组件之间的高内聚低耦合。这个部分主要是软件架构师或系统架构师需要关注的范围。
对于产品质量，主要关注以下方面（如图1-5所示）：
图1-5 产品质量关注的问题
■ 性能（在预期的用户量/并发数条件下，产品功能能否满足用户正常使用的需要）。
■ 安全性（防止黑客攻击、入侵，导致服务器不可用、数据被篡改、数据泄露等安全事件，以及确保安全相关的法律合规）。
■ 扩展性（在用户规模大幅增长时，能否通过扩容解决问题）。
■ 可维护性（日常运维是否尽可能自动化，降低运维人员投入，如软件更新、数据更新、日志清理、证书/License到期提醒等）。
其中安全性部分，由于专业性强，涉及的领域众多，本书将其单独提取出来，即为产品安全架构。