架构是什么
- 架构是定义系统的结构，行为及其他视图的模型
- 架构虚设是有关系统的正是描述以及呈现，以有助于了解系统结构和行为的方式来组织
认识架构4+1视图模型
在4+1视图将系统的架构用5种视图来表示：
场景视图
用于描述系统的参与者和功能用例之间的关系，反应系统最终的需求和交互设计
逻辑视图
逻辑视图主要用来支持功能性需求，系统应该提供什么样的服务给用户
开发视图
处理视图
又称进程试图。用于描述系统软件组件之间的通信时序，数据的输入输出。系统之间的各个进程调用关系：性能，伸缩性，吞吐量等
物理视图
组件化思维
最简化思维是一种应用复杂的系统分解方式，把大的系统分解为组件。同时也利用了面向对象中的抽象和封装，模块化，层次结构思想。抽象了组件对外展现的公共接口，封装了隐藏组件内部的逻辑。
组件本身即是一种模块化的思想。组件可以套用行成父子组件，组件上的一层子系统，也可以理解为一个更大的组件。万物皆实体，皆对象，皆系统。
特定模式化的系统分解
一种识别组件的方式
优秀架构的一些标准
好的架构是怎么样的
- 架构是否满足了利益相关者的需求（通过对结构和行为的设计）
- 架构是具体好的结构能够支持持续最低成本应对变化（两个号的结构和行为交互）
- 可审计性
- 性能
- 安全性
- 数据
- 合法性
- 伸缩性
- 扩展性
- 可测试性
运行架构特征
| 类型 | 定义 |
|---|---|
| 可用性 | 系统可用时间，如果是24/7,则需要使系统在发生任何故障时能够迅速启动和运行 |
| 持续性 | 灾难恢复能力 |
| 性能 | 包括压力测试，峰值分析，分析功能的使用频率，所需容量和响应时间，性能报告有时需要自行演练，需要几个月才能完成 |
| 可恢复性 | 业务持续性要求 |
| 可靠性/安全性 | 评估系统是否需要具备某些安全功能，如果发生故障是否会给公司带来大笔资金损失 |
| 稳健性 | 在网络连接中段，断电或者硬件故障时，系统是否能够处理运行中的错误和边界条件 |
| 可扩展性 | 随着用户或请求数量的增加，系统执行和运行的能力 |
结构架构特征
| 类型 | 定义 |
|---|---|
| 可配置性 | 能够轻松的变更软件配置 |
| 可扩展性 | 添加新的功能是多么重要 |
| 可安装性 | 方便在所有必要的平台安装 |
| 可利用性/重复使用 | 能够重复利用通用组件 |
| 本地化 | 文字输入，多语言支持；报表，计量单位，货币支持 |
| 可维护性 | 轻松的进行应用变更和系统维护 |
| 可移植性 | 系统是否需要在超过一个平台上 |
| 支持性 | 应用需要什么级别的技术支持， |
| 可升级性 | 能够在服务器和客户端轻松快速升级 |
跨领域架构特征
| 类型 | 定义 |
|---|---|
| 可访问性 | 让所用用户，包括色盲残疾听障人士都能访问（iphone 有类似支持） |
| 归档性 | 数据是否需要在一段时间后归档或者删除 |
| 认证 | 安全要求，确保用户是那个人 |
| 权限 | 安全性要求，确保用户只能访问程序中的某些功能 |
| 法律要求 | 符合当地法律法规 |
| 隐私 | 个人信息数据加密存储，不泄露，不传播 |
| 安全性 | 随着用户或请求数量的增加，系统执行和运行的能力 |
最差可用架构
永远不要为了最好的架构努力，而要为最差可用的架构努力。--《软件架构指南》
架构师很少能够设计系统并使每个架构特征最大化，通常决策归结为几个相互竞争的问题的之间的权衡。
架构风格
单体架构
1. 分层架构
2. 管道架构
3. 微核架构
分布式架构
1. 基于SOA服务
2. 事件驱动
3. 微服务架构
