系统架构设计师 1：绪论
一、系统架构
系统架构是系统的一种整体的高层次的结构表示。
1 软件架构的常用分类
1.1 分层架构
分层架构是最常见的软件架构，也是事实上的标准架构。
这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口进行通信。
分层架构通常明确约定软件一定要分成多少层，但是，最常见的是四层结构：
1. 表现层：用户界面，负责视觉和用户互动。
2. 业务层：实现业务逻辑。
3. 持久层：提供数据。
4. 数据库：保存数据。
1.2 事件驱动模型
事件是状态发生变化时软件发出的通知。
事件驱动架构是通过事件进行通信的软件架构，它分成四个部分：
1. 事件队列：接收事件的入口。
2. 分发器：将不同的事件分发到不同的业务逻辑单元。
3. 事件通道：分发器与处理器之间的联系通道。
4. 事件处理器：实现业务逻辑，处理完成后会发出事件，触发下一步操作。
1.3 微核架构
微核架构又称为插件架构，是指软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
1.4 微服务架构
微服务架构是服务导向架构（SOA）的升级。
每一个服务就是一个独立的部署单元。这些单元都是分布式的，互相解耦就，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式：
1. RESTful API模式：服务通过API提供，云服务就属于这一类。
2. RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部。
3. 集中消息模式：采用消息代理可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。
1.5 云架构
云架构主要解决扩展性和并发问题，是最容易扩展的架构。
它的高扩展性体现在将数据都复制到内存中，变成可复制的内存数据单元，然后将业务处理能力封装成一个个处理单元。若访问量增加，就新建处理单元；若访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，需要进行数据持久化。
云架构主要分成两部分：
1. 处理单元：实现业务逻辑。
2. 虚拟中间件：负责通信、保持会话控制、数据复制、分布式处理和处理单元的部署。
其中虚拟中间件又包含四个组件：
1. 消息中间件：管理用户请求和会话控制，当一个请求进来以后，它决定分配给哪一个处理单元。
2. 数据中间件：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
3. 处理中间件：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元。
4. 部署中间件：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。
2 常用建模方法
根据建模的侧重点不同，可以将软件架构的模型分成四种：
2.1 结构模型
最直观、最普遍的建模方法。
此方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。
研究结构模型的核心是架构描述语言。
2.2 框架模型
框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的结构。
框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
2.3 动态模型
动态模型是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性质。例如，描述系统的重新配置或演化。
这里的动态可以是指系统总体结构的配置、建立或拆除通信或计算的过程，这类系统模型常是激励型的。
2.4 过程模型
过程模型是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。
二、系统架构师
1 主要任务
架构设计师在项目中的主要任务可以概述如下：
1. 领导与协调整个项目中的技术活动（分析、设计和实施等）。
2. 推动主要的技术决策并最终表达为系统架构。
3. 确定系统架构，并促使其架构设计的文档化，这里的文档化应包括需求、设计、实施和部署等“视图”。
2 应具备的专业素养
架构设计师应该具备以下专业知识：
1. 掌握业务领域的知识。
2. 掌握技术知识。
3. 掌握设计技能。
4. 具备编程技能。
5. 具备沟通能力。
6. 具备决策能力。
7. 知道组织策略。
8. 应是谈判专家。
3 从工程师到系统架构设计师的演化
1. 工程师：在别人的指导下完成开发。
2. 高级工程师：独立完成开发。
3. 技术专家：某个领域的专家，只要是这个领域的问题，都可以解决。
4. 系统架构设计师（初级）：独立完成一个系统的架构设计。
5. 系统架构设计师（中级）：能够完成复杂系统的架构设计。
6. 系统架构设计师（高级）：创造新的架构模式。