一、特定领域软件架构【DSSA】
定义：以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。
基本活动
垂直域：某一个狭小领域或者说某个行业的共性抽象。
水平域：多个行业可通用的一些共性的抽象。
领域分析中各角色职能
- 领域专家：从事该领域中系统的需求分析、设计、实现以及项目管理。【提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领城字典,帮助选择样本系统作为领域工程的依据，复审领域模型、DSS等领域工程产品等等。】
- 领域分析人员：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，给护领域模型。
- 领域设计人员：控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的系。
- 领域实现人员：根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件间的联系。
建立过程
- 1、定义领域范围
- 2、定义领域特定的元素
- 3、定义领域特定的设计和实现需求约束
- 4、定义领域模型和架构
- 5、产生、搜集可复用的产品单元
三层次模型
- 领域架构师【一层】：领域开发环境【输出：参考结构、架构、开发工具等】
- 应用工程师【二层】：领域特定的应用开发环境【输出：实例化的架构】
- 操作员【三层】：应用执行环境【输出：实施的代码】
二、基于架构的软件开发方法【重点！！！！！】
1、基于架构的软件设计 【ABSD】
定义：ABSD方法是架构驱动，即强调由业务【商业】、质量和功能需求的组合驱动架构设计。
特点：很好的支持软件重用，自顶向下、递归细化，直到能产生构件和类。
关键因素：文档的完整性、质量
基础：
- 1、使用已有的基于模块的内聚和耦合技术【功能分解】
- 2、通过选择架构风格来实现质量和业务需求【架构风格选择】
- 3、借鉴一些软件系统的结构【使用软件模板】
视角与视图：从不同的视角来检查，所以会有不同的视图。
需求的捕获：
- 功能需求：【通过用例捕获】、
- 质量需求：【通过特定场景（刺激、环境、响应）捕获】
2、开发过程
基于架构的软件开发方法过程
- 架构需求
- 架构设计
- 架构文档化【输出：1、架构规格说明，2、测试架构需求的质量设计说明】
- 架构复审
- 架构实现
- 架构演化
关于文档的三大注意事项【文档的完整性和质量是软件架构成功的关键因素】
- 从使用者的角度进行编写
- 分发给所有与系统有关的开发人员
- 保证开发者手上的文档是最新版本
架构需求过程
- 需求获取
- 生成类图【标识构件的步骤1】
- 对类进行分组【标识构件的步骤2】
- 把类打包成构件【标识构件的步骤3】
- 需求评审
架构设计过程
- 提出架构模型
- 映射构件
- 分析构件相互作用
- 产生架构
- 设计评审
架构实现过程
- 复审后的文档化的架构
- 分析与设计
- 构件实现
- 构件组装
- 系统测试
- 架构演化
架构演化过程
- 需求变化归类
- 架构演化计划
- 构件变动
- 更新构件的相互作用
- 构件组装与测试
- 技术评审
- 演化后的架构
三、架构评估【重点！！！！！】
评估内容：架构是否符合需求。
质量属性：
性能
定义：系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
代表参数：响应时间、吞吐量
设计策略：优先级队列、资源调度
可用性
定义：系统能够正常运行的时间比例。【经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。】
代表参数：故障间隔时间
设计策略：冗余、心跳线
安全性
定义：系统在向合法用户提供服务的同时能够阻止非授权用户使用的企留或拒绝服务的能力。【安全性又可划分为机密性（信息不泄露给未授权的用户）完整性（防止信息被纂改）不可否认性（不可抵赖）可控性（对信息的传播及内容具有控制的能力）】
代表参数：鉴权、弱密码
设计策略：追踪审计
可修改性
定义：能够快速地以较高的性能价格比对系统进行变更的能力。
代表参数：开发时常、变更代价
主要策略：信息封装隐藏，权限控制
易用性
定义：完成某个期望任务的容易程度和系统所提供的用户支持的种类。
可测试性
定义：通过测试揭示软件缺陷的容易程度。
四、软件架构评估方法【重点！！！！！】
相关概念
- 风险点：架构设计中潜在的、存在问题的架构决策所带来的隐患。
- 非风险点：不会带来隐患，一般以“XXX要求是可以实现【或接受】的”方式表达
- 敏感点：敏感点是一个或多个构件的特性，它能影响系统的某个质量属性。
- 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
- 场景：从风险承担者的角度与系统交互的简短描述。【刺激源、刺激、制品、环境、响应、响应度量】
基于场景的评估方法
过程：
- 确定应用领域的功能和软件架构的结构之间的映射
- 设计用于体现待评估质量属性的场景
- 分析软件架构对场景的支持程度
软件架构分析法（SAAM）
- 单个场景评估【由场景开发和需求描述两方面推演】
- 场景交互评估【单个架构内部交互评估】
- 总体评估【比较多个架构】
架构权衡分析法（ATAM）
定义：在SAAM 的基础上发展起来的，主要针对性能、实用性、安全性和可修改性。
五、产品线
概念：多个知识领域的综合体，软件产品线会包括特定领域架构DSSA。
特点：核心资源、产品集合、过程驱动、特定领域、技术支持、以架构为中心。
建立方式：
组织结构类型：
- 1、设立独立的核心资源小组
- 2、不设立独立的核心资源小组
- 3、动态的组织结构
六、构件和中间件【重点！！！！！】
构件
定义：
- 1、一种组装单元，它具有规范的接口规约和显式的语境依赖。【可独立地部署并由第三方任意组装】
- 2、一个独立发布的功能部分，可以通过其接口访问它的服务。
三大构件标准：
- 1、COBRA
- 2、J2EE【EJB】
- 会话Bean：实现业务逻辑，负责完成服务端与客户端的交互
- 实体Bean：实现O/R映射，简化数据库开发工作
- 消息驱动Bean：处理并发与异常访回
- 3、DNA2000
构件、对象、模块的对比：
模块：结构化开发的产物
对象：有唯一标志的一个实例单元；可能具有外部可见的状态，同时封装了自己的状态和行为
构件：一种独立部署单元；可作为第三方的组装单元，没有外部可见状态
构件的复用：
- 1、构件的开发过程遵循公共标准
- 2、理想状态是直接复用构件库中现成的构件
- 3、构件的功能、行为和接口设计要求抽象化、通用化和参数化
中间件
定义：一种独立的系统软件或服务程序。【PS：中间件是一类构件】
意义：帮助分布式应用软件在不同的技术之间共享资源。
优势：简化结构、屏蔽差异、利于复用
分类：
- 通信处理中间件：可靠、高效、实时跨平台通信，eLink，MQSeries
- 事务处理中间件：事务分发，负载均衡，Tuxedo
- 数据存取管理中间件：为虚拟缓冲存取、格式转换、解压等带来方便 Web
- 服务器中间件：负载均衡、缓存、安全性保障
- 安全中间件：加密、认证
- 跨平台和架构的中间件：CORBA【通用对象请求代理结构，解决跨平台问题】
- 专用平台中间件：为特定应用领域设计领域参考模式，建立相应架构
- 网络中间件：网闸、网络测试、虚拟社区、虚拟缓冲
中间件应用【Corba】（公共对象请求代理体系结构）（代理模式）
- 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
- 对象适配器（ObjectAdapter）： 用于屏蔽ORB【对象请求代理】内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
- 对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。
- PS：客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
七、大型网站系统架构演化【前三阶段】
1、维度
2、第一阶段【单体架构】到第二阶段【垂直架构】
3、第三阶段【使用缓存改善网站性能】
Redis和MemCache对比
Redis常见问题
1、缓存雪崩
现象：大部分缓存失效 -> 请求全部进入数据库查询 -> 数据库崩溃
解决方案：
- 1、使用锁或队列：保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
- 2、为key设置不同的缓存失效时间：在固定的一个缓存时间的基础上 + 随机一个时间作为缓存失效时间。
- 3、二级缓存：设置一个有时间限制的缓存 + 一个无时间限制的缓存。避免大规模访问数据库。
2、缓存穿透
现象：查询无数据返回 -> 请求全部进入数据库查询 -> 数据库崩溃
解决方案：
- 1、如果查询结果为空，设置默认值存放到缓存：避免多次访问缓存都是空值。PS：一般设置一个不超过5分钟的过期时间，以便能正常更新缓存。
- 2、布隆过滤器：将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统造成的查询压力。
- 作用：快速识别1个元素是否在一个集合中。
- 原理：通过一个长二进制向量和一系列随机映射函数（一般用多种hash算法来计算）来记录与识别某个数据是否在一个集合中。
- 优点：占用内存小、查询效率高、不需要存储元素本身
- 缺点：有一定的误判率、一般情况下不能从布隆过滤器中删除元素、不能获取元素本身
3、缓存预热
现象：系统上线后，将相关需要缓存数据直接加到缓存系统中。
解决方案：
- 1、缓存页面：直接写个缓存刷新页面，上线时手工操作。
- 2、自加载：数据量不大时，可以在项目启动的时候自动进行加载。
- 3、定时刷新：定时器刷新缓存。
4、缓存更新
现象：对失效的缓存更新
解决方案：
- 1、定时清理：定时清理过期的缓存。
- 2、被动清理：当有用户请求过来时，判断这个请求所用到的缓存是否过期，过期的话就从底层系统获取新数据并更新缓存。
5、缓存降级
现象：主缓存服务器（可读可写）失联或宕机时，从紧急缓存服务器（只读）进行默认值返回。
解决方案：
- 1、自动切换：通过代码或脚本实现
- 2、人工切换：通过人工监控，并进行调整
缓存与数据库交互
集群数据切片方式
- 客户端切片：在客户端通过key的hash值对应到不同的服务器。
- 中间件切片：由中间件实现服务到后台Redis节点的路由分派。
- 客户端服务端协作分片：集群模式下，客户端可采用一致性哈希，服务端提供错误节点重定向服务，重定向到对应的slot上。不同的slot对应到不同服务器。
Redis分布式存储方案
- 主从模式：一主多从，故障时手动切换。
- 哨兵模式：加入哨兵机制的一主多从，主节点故障自动选择新的主节点。
- 集群模式：分节点对等集群，分slots，不同 slots 的信息存储到不同节点。
Redis分片方案
- 范围分片：按数据范围分片
- 哈希分片：通过对key进行hash运算分片
- 一致性哈希分片：哈希分片的改进。【PS：可以有效解决重新分配节点带来的无法命中问题。】
Redis数据类型
- String【字符串】：储存二进制数据。【缓存、计数、共享session】
- Hash【字典】：无序字典，数组 + 链表，适合存对象。【一组有关联的对象】
- List【列表】：双向链表，有序，增删快，查询慢。【消息队列、文章列表】
- Set【集合】：无序且唯一的元素集合。【独立IP、去重统计】
- Sorted Set【有序集合】：有序且唯一，加入权重的元素集合。【排行榜】
Redis持久化
RDB：快照。指定时间间隔将数据进行快照存储。
AOF：日志。把每条改变数据集的命令追加到AOF文件未尾，这样出问题了，可以重新执行AOF文件中的命令来重建数据集。
Redis淘汰策略
