- 数据流风格：适合于分阶段做数据处理，交互性差，包括：批处理序列、管理过滤器。
- 调用/返回风格：一般系统都要用到，包括：主程序/子程序，面向对象，层次结构（分层越多，性能越差）。
- 独立构件风格：构件是独立的过程，连接件是消息传递。包括：进程通信，事件驱动系统（隐式调用）。应用场景，通过事件触发操作。
- 虚拟机风格：包括解释器与基于规则的系统，有自定义场景时使用该风格。
- 仓库风格（以数据为中心的风格）：以共享数据源为中心，其它构件围绕中心进行处理。包括：数据库系统、黑板系统（语言处理，信号处理），超文本系统。
- 闭环控制架构（过程控制）：定速巡航，空调温控。
- MVC：视图（JSP），控制器（Servlet），模型（EJB）。
- SOA：粗粒度，松耦合，标准化。Webservice 与 ESB 是 SOA 的实现技术。
- ESB：位置透明性、消息路由、服务注册命名、消息转换、多传输协议、日志与监控。
- REST 的 5 大原则：所有事物抽象为资源、资源唯一标识、通过接口操作资源、操作不改变资源标识、操作无状态。
- 微服务特点：小, 且专注于做一件事情；轻量级的通信机制；松耦合、独立部署。
- 微服务优势：技术异构性、弹性、扩展、简化部署、与结构相匹配、可组合性、对可替代性的优化。
- 微服务与 SOA 对比：
- ADL 的三个基本元素：构件，连接件，架构配置。
- DSSA 基本活动：领域分析（建立领域模型），领域设计（获得 DSSA），领域实现（开发和组织可复用信息）。
- DSSA 角色：领域专家（有经验的用户、分析、设计、实现人员，“给建议”），领域分析人员（有经验的分析师，完成领域模型），领域设计人员（有经验的设计师，完成 DSSA），领域实现人员（有经验的程序员完成代码编写）。
- DSSA 三层次模型：领域架构师对应领域开发环境，应用工程师对应领域特定的应用开发环境，操作员对应应用执行环境。
- ABSD 方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。
- ABSD 方法有三个基础：功能的分解，通过选择架构风格来实现质量和业务需求，软件模板的使用。
- ABSD 开发过程：
- 架构需求（需求获取、生成类图、对类进行分组、打包成构件、需求评审）
- 架构设计（提出架构模型、映射构件、分析构件相互作用，产生架构，设计评审）
- 架构文档化：从使用者角度编写，分发给所有相关开发人员，保证开发者手中版本最新。
- 架构复审：标识潜在的风险，及早发现架构设计中的缺陷和错误。（5）架构实现（复审后的文档化架构，分析与设计，构件实现，构件组装，系统测试）
（6）架构演化（需求变化归类，架构演化计划，构件变动，更新构件相互作用，构件组装与测试，技术评审，演化后的架构）
21、架构评审四大质量属性：
- 性能：代表参数（响应时间、吞吐量），设计策略（优先级队列、资源调度）。
- 可用性：尽可能少的出错与尽快的恢复。代表参数（故障间隔时间，故障修复时间），设计策略（冗余、心跳线）。
- 安全性：破坏机密性、完整性、不可否认性及可控性等特性。设计策略（追踪审计）
- 可修改性：新增功能多少人月能完成，设计策略（信息隐藏，低耦合）
- 风险点：非专业术语，系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。即可能引起风险的因素
非风险点：一般以某种做法，“是可以实现的”、“是可以接受的”方式进行描述。
敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
- 基本场景的评估方法：ATAM，SAAM，CBAM。
- 架构评估方法，不是代码评估方法，不做测试，不是精确的衡量方法。
- ATAM 四大阶段：场景和需求收集、结构视图场景实现、属性模型构造和分析、折中。
- SAAM 五个步骤：即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。
- 产品线技术应用场景：有多年行业开发经验，做过多个同类产品。
- 建立产品线的四种方式：基于现有产品演化式（风险最低），基于现有产品革命式，全新产品线演化式，全新产品线革命式（风险最高）。
- 产品线实施成功的决定因素：对该领域具备长期和深厚的经验；一个用于构建产品的好的核心资源库；好的产品线架构；好的管理（软件资源、人员组织、过程）支持。
- 构件、对象、模块的对比：
- 构件系统架构：构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。
- 构件的复用：（1）检索与提取构件；（2）理解与评价构件；（3）修改构件；（4）组装构件。
- 在构件组装阶段失配问题：由构件引起的失配；由连接子引起的失配；由于系统成分对全局体系结构的假设存在冲突引起的失配等。
- 中间件：中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。
- 中间件功能：客户机与服务器之间的连接和通信，客户机与应用层之间的高效率通信；应用层不同服务之间的互操作，应用层与数据库之间的连接和控制；多层架构的应用开发和运行的平台，应用开发框架，模块化的应用开发；屏蔽硬件、操作系统、网络和数据库的差异；应用的负载均衡和高可用性、安全机制与管理功能，交易管理机制，保证交易的一致性、一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。
- 采用中间件技术的优点：面向需求；业务的分隔和包容性；设计与实现隔离；隔离复杂的系统资源；符合标准的交互模型；软件复用；提供对应用构件的管理。
- 主要的中间件：远程过程调用；对象请求代理；远程方法调用；面向消息的中间件；事务处理监控器。
- 中间件技术-Corba(公共对象请求代理体系结构)（代理模式）：
伺服对象（Servant）：CORBA 对象的真正实现，负责完成客户端请求。
对象适配器（Object Adapter）：用于屏蔽 ORB 内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用 ORB 内部的某些功能。
对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
- Bean 的分类：
- 会话 Bean：描述了与客户端的一个短暂的会话。
- 实体 Bean：持久化数据，O/R 映射。
- 消息驱动 Bean：会话 Bean+JMS，客户把消息发送给 JMS 目的地，然后，JMS 提供者和 EJB 容器协作，把消息发送给消息驱动 Bean。支持异步消息。
40、重量级与轻量级区别：
- 重量级：占用资源过多，在开发的过程中效率很低；大部分时间花在配置、运行的过程上，修改复杂；单元测试也比较麻烦。
- 轻量级：提高了开发的速度；立即可以看到结果；做单元测试也非常简单；大量现成可供参考的开源代码。
41、WEB 设计维度：
- 从架构来看：MVC，MVP，MVVM，REST，Webservice，微服务。
- 从缓存来看：MemCache，Redis，Squid。
- 从并发分流来看：集群（负载均衡）、CDN。
- 从数据库来看：主从库（主从复制），内存数据库，反规范化技术，NoSQL，分区（分表）技术，视图与物化视图。
- 从持久化来看：Hibernate，Mybatis。
- 从分布存储来看：Hadoop，FastDFS，区块链。
- 从数据编码看： XML，JSON。
- 从 Web 应用服务器来看： Apache，WebSphere，WebLogic，Tomcat，JBOSS，IIS。
- 其它：静态化，有状态与无状态，响应式 Web 设计。
- 集群：（1）应用服务器集群；（2）主从集群。
- 负载均衡技术：（1）应用层负载均衡：http 重定向、反向代理服务器；（2）传输层负载均衡：DNS 域名解析负载均衡、基于 NAT 的负载均衡；（3）硬件负载均衡：F5；（6）软件负载均衡：LVS、Nginx、HAproxy。
静态算法 (不考虑动态负载)
(1)轮转算法:轮流将服务请求 (任务) 调度给不同的节点 (即:服务器)0
(2)加权轮转算法:考虑不同节点处理能力的差异。
(3)源地址哈希散列算法:根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点。
(4)目标地址哈希散列算法:根据请求目标IP做散列找出对应节点。
(5) 随机算法:随机分配，简单，但不可控。
动态算法(考虑动态负载)
(1)最小连接数算法:新请求分配给当前活动请求数量最少的节点，每个节点处理能力相同的情况下(2)加权最小连接数算法:考虑节点处理能力不同，按最小连接数分配。
(3)加权百分比算法:考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力。
- 有状态和无状态：
- 无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
- 有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。
解决方法：
- 携带session
- 服务器间同步session
- 将session存入redis
- Redis 与 Memcache 能力比较
| 工作 | MemCache | Redis | |
| 数据类型 | 简单 key/value 结构 | 丰富的数据结构 | |
| 持久性 | 不支持 | 支持 | |
| 分布式存储 | 客户端哈希分片/一致性哈希 | 多种方式，主从、Sentinel、Cluster 等 | |
| 多线程支持 | 支持 | 不支持（Redis6.0 开始支持） | |
| 内存管理 | 私有内存池/内存池 | 无 | |
| 事务支持 | 不支持 | 有限支持 | |
| 数据容灾 | 不支持，不能做数据恢复 | 支持，可以在灾难发生时，恢复数据 |
- Redis 集群切片的常见方式
| 集群切片方式 | 核心特点 |
| 客户端分片 | 在客户端通过 key 的 hash 值对应到不同的服务器。 |
| 中间件实现分片 | 在应用软件和 Redis 中间，例如：Twemproxy、Codis 等，由中间件实现服务到后台 Redis 节点的路由分派。 |
| 客户端服务端协作分片 | RedisCluster 模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务 slot 上。不同的 slot 对应到不同服务器。 |
- Redis 分布式存储方案
| 分布式存储方案 | 核心特点 |
| 主从（Master/Slave）模式 | 一主多从，故障时手动切换。 |
| 哨兵（Sentinel）模式 | 有哨兵的一主多从，主节点故障自动选择新的主节点。 |
| 集群（Cluster）模式 | 分节点对等集群，分 slots，不同 slots 的信息存储到不同节点。 |
- Redis 数据分片方案
| 分片方案 | 分片方式 | 说明 |
| 范围分片 | 按数据范围值来做分片 | 例：按用户编号分片，0-999999 映射到实例 A；1000000-1999999 映射到实例 B。 |
| 哈希分片 | 通过对 key 进行 hash 运算分片 | 可以把数据分配到不同实例，这类似于取余操作，余数相同的，放在一个实例上。 |
| 一致性哈希分片 | 哈希分片的改进 | 可以有效解决重新分配节点带来的无法命中问题。 |
- redis持久化
Redis的持久化主要有两种方式: RDB和AOF。
RDB:传统数据库中快照的思想。指定时间间隔将数据进行快照存储
AOF:传统数据库中日志的思想，把每条改变数据集的命令追加到AOF文件未尾，这样出问题了.可以重新执行AOF文件中的命令来重建数据集
| 对比维度 | RDB持久化 | AOF持久化 |
| 备份量 | 重量级的全量备份，保存整个数据库 | 轻量级增量备份，一次只保存一个修改命令 |
| 保存间隔时间 | 保存间隔时间长 | 保存间隔时间短，默认1秒 |
| 还原速度 | 数据还原速度快 | 数据还原速度慢 |
| 阻塞情况 | save会阻塞，但bgsave或者自动不会阻寒 | 无论是平时还是AOF重写，都不会阻寒 |
| 数据体积 | 同等数据体积:小 | 同等数据体积:大 |
| 安全性 | 数据安全性:低，容易丢数据 | 数据安全性:高，根据策略决定 |
- 淘汰策略
| 淘汰作用范围 | 策略 |
| 不淘汰 | 禁止驱逐数据，内存不足以容纳新入数据时，新写入操作就会报错。系统默认的一种淘汰策略。。 |
| 设置了过期时间的键空间 |
|
| 全键空间 | 1、随机移除某个key 2、优先移除最近未使用的key |
- 缓存常见问题
1、缓存雪崩
1、使用锁或队列:保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
2、为key设置不同的缓存失效时间:在固定的一个缓存时间的基础上+随机一个时间作为缓存失效时间.
3、二级缓存:设置一个有时间限制的缓存+一个无时间限制的缓存。避免大规模访问数据库。
2、缓存穿透
查询无数据返回->直接查数据库
- 如果查询结果为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了。设置一个不超过5分钟的过期时间，以便能正常更新缓存。
2、设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个-定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
查询无数据返回->直接查数据库
- 缓存预热
系统上线后，将相关需要缓存数据直接加到缓存系统中。
解决方案
- 直接写个缓存刷新页面，上线时手工操作。
- 数据量不大时，可以在项目启动的时候自动进行加载
3、定时刷新缓存。
- 缓存与数据库的协作
数据读取：根据 key 从缓存读取；若缓存中没有，则根据 key 在数据库中查找；读取到“值”之后，更新缓存。
数据写入：根据 key 值写数据库；根据 key 更新缓存。
- REST 概念：REST（Representational State Transfer，表述性状态转移）是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。
REST 的五个原则：网络上的所有事物都被抽象为资源；每个资源对应一个唯一的资源标识；通过通用的连接件接口对资源进行操作；对资源的各种操作不会改变资源标识；所有的操作都是无状态的。
- 响应式 Web 设计：响应式 WEB 设计是一种网络页面设计布局，其理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境进行相对应的布局。方法：采用流式布局和弹性化设计、响应式图片。
- 业务中台和数据中台区分：
- 多个电商渠道使用一个下单服务，一个订单接口同时为多个前台系统提供服务，这是业务中台提供的能力。
- 多个前台系统，根据一个用户的手机号，获取对应的画像，用户的标签，这是数据中台提供的服务。
- 将多个支付通道，抽象建立成一个支付 API，暴露给前台业务系统，这是业务中台提供的能力。
-
通过一个订单编号，来获取可能的商品推荐清单，从而做到交叉销售，这是数据中台提供的服务。
- MDA(Model Driven Architecture)：Model-客观事物的抽象表示；Architecture-构成系统的部件、连接件及其约束的规约；Model-Driven-使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。
- 主从数据库结构特点：
一般：一主多从，也可以多主多从。
从库做写操作，从库做读操作。
主从复制步骤：
主库（Master）更新数据完成前，将操作写 binlog 日志文件。
从库（Salve）打开 I/O 线程与主库连接，做 binlog转存处理，并将事件写入中继日志。
从库执行中继日志事件，保持与主库一致。
55、DFD是表达系统内数据的流动并通过数据流描述系统功能的一种方，DFD还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD作为需
求规格说明书的一个组成部分
- 类图：静态图，为系统的静态设计视图，展现一组对象、接口、协作和它们之间的关系
- 状态图:动态图，展现了一个状态机，描述单个对象在多个用例中的行为，转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。
- 动态图，是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。用来描述操作的行为，也用于描述用例和对象内部的工作过程。
- 序列图:即顺序图，动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。侧重以时间为参照描述对象发送消息、接收消息、处理消息、返回消息的顺序。
- 通信图（协作图）它强调收发消息的对象的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构
- 嵌入式操作系统特点:可裁剪性、可移植性、可固化性、强实时性、强确定性、强定制性、强稳定性、强紧凑性、较强的硬件适应性、高质量代码、标准接口弱交互性、操作简洁方便、。
- 从嵌入式操作系统体系架构看，主要存在 4 种结构:整体结构、层次结构、客户/服务器结构和面向对象结构。
