1. 数据流风格：适合于分阶段做数据处理，交互性差，包括：批处理序列、管理过滤器。
2. 调用/返回风格：一般系统都要用到，包括：主程序/子程序，面向对象，层次结构（分层越多，性能越差）。
3. 独立构件风格：构件是独立的过程，连接件是消息传递。包括：进程通信，事件驱动系统（隐式调用）。应用场景，通过事件触发操作。
4. 虚拟机风格：包括解释器与基于规则的系统，有自定义场景时使用该风格。
5. 仓库风格（以数据为中心的风格）：以共享数据源为中心，其它构件围绕中心进行处理。包括：数据库系统、黑板系统（语言处理，信号处理），超文本系统。
6. 闭环控制架构（过程控制）：定速巡航，空调温控。
7. MVC：视图（JSP），控制器（Servlet），模型（EJB）。
8. SOA：粗粒度，松耦合，标准化。Webservice 与 ESB 是 SOA 的实现技术。
9. ESB：位置透明性、消息路由、服务注册命名、消息转换、多传输协议、日志与监控。
10. REST 的 5 大原则：所有事物抽象为资源、资源唯一标识、通过接口操作资源、操作不改变资源标识、操作无状态。
11. 微服务特点：小, 且专注于做一件事情；轻量级的通信机制；松耦合、独立部署。
12. 微服务优势：技术异构性、弹性、扩展、简化部署、与结构相匹配、可组合性、对可替代性的优化。
13. 微服务与 SOA 对比：

1. ADL 的三个基本元素：构件，连接件，架构配置。
2. DSSA 基本活动：领域分析（建立领域模型），领域设计（获得 DSSA），领域实现（开发和组织可复用信息）。
3. DSSA 角色：领域专家（有经验的用户、分析、设计、实现人员，“给建议”），领域分析人员（有经验的分析师，完成领域模型），领域设计人员（有经验的设计师，完成 DSSA），领域实现人员（有经验的程序员完成代码编写）。
4. DSSA 三层次模型：领域架构师对应领域开发环境，应用工程师对应领域特定的应用开发环境，操作员对应应用执行环境。
5. ABSD 方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。
6. ABSD 方法有三个基础：功能的分解，通过选择架构风格来实现质量和业务需求，软件模板的使用。
7. ABSD 开发过程：

1. 架构需求（需求获取、生成类图、对类进行分组、打包成构件、需求评审）
2. 架构设计（提出架构模型、映射构件、分析构件相互作用，产生架构，设计评审）
3. 架构文档化：从使用者角度编写，分发给所有相关开发人员，保证开发者手中版本最新。
4. 架构复审：标识潜在的风险，及早发现架构设计中的缺陷和错误。（5）架构实现（复审后的文档化架构，分析与设计，构件实现，构件组装，系统测试）

（6）架构演化（需求变化归类，架构演化计划，构件变动，更新构件相互作用，构件组装与测试，技术评审，演化后的架构）

21、架构评审四大质量属性：

1. 性能：代表参数（响应时间、吞吐量），设计策略（优先级队列、资源调度）。
2. 可用性：尽可能少的出错与尽快的恢复。代表参数（故障间隔时间，故障修复时间），设计策略（冗余、心跳线）。
3. 安全性：破坏机密性、完整性、不可否认性及可控性等特性。设计策略（追踪审计）
4. 可修改性：新增功能多少人月能完成，设计策略（信息隐藏，低耦合）

1. 风险点：非专业术语，系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。即可能引起风险的因素

非风险点：一般以某种做法，“是可以实现的”、“是可以接受的”方式进行描述。

敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。

1. 基本场景的评估方法：ATAM，SAAM，CBAM。
2. 架构评估方法，不是代码评估方法，不做测试，不是精确的衡量方法。
3. ATAM 四大阶段：场景和需求收集、结构视图场景实现、属性模型构造和分析、折中。
4. SAAM 五个步骤：即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。
5. 产品线技术应用场景：有多年行业开发经验，做过多个同类产品。
6. 建立产品线的四种方式：基于现有产品演化式（风险最低），基于现有产品革命式，全新产品线演化式，全新产品线革命式（风险最高）。
7. 产品线实施成功的决定因素：对该领域具备长期和深厚的经验；一个用于构建产品的好的核心资源库；好的产品线架构；好的管理（软件资源、人员组织、过程）支持。
8. 构件、对象、模块的对比：

1. 构件系统架构：构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。
2. 构件的复用：（1）检索与提取构件；（2）理解与评价构件；（3）修改构件；（4）组装构件。
3. 在构件组装阶段失配问题：由构件引起的失配；由连接子引起的失配；由于系统成分对全局体系结构的假设存在冲突引起的失配等。
4. 中间件：中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。
5. 中间件功能：客户机与服务器之间的连接和通信，客户机与应用层之间的高效率通信；应用层不同服务之间的互操作，应用层与数据库之间的连接和控制；多层架构的应用开发和运行的平台，应用开发框架，模块化的应用开发；屏蔽硬件、操作系统、网络和数据库的差异；应用的负载均衡和高可用性、安全机制与管理功能，交易管理机制，保证交易的一致性、一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。
6. 采用中间件技术的优点：面向需求；业务的分隔和包容性；设计与实现隔离；隔离复杂的系统资源；符合标准的交互模型；软件复用；提供对应用构件的管理。
7. 主要的中间件：远程过程调用；对象请求代理；远程方法调用；面向消息的中间件；事务处理监控器。
8. 中间件技术-Corba(公共对象请求代理体系结构)（代理模式）：

伺服对象（Servant）：CORBA 对象的真正实现，负责完成客户端请求。

对象适配器（Object Adapter）：用于屏蔽 ORB 内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用 ORB 内部的某些功能。

对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

1. Bean 的分类：

1. 会话 Bean：描述了与客户端的一个短暂的会话。
2. 实体 Bean：持久化数据，O/R 映射。
3. 消息驱动 Bean：会话 Bean+JMS，客户把消息发送给 JMS 目的地，然后，JMS 提供者和 EJB 容器协作，把消息发送给消息驱动 Bean。支持异步消息。

40、重量级与轻量级区别：

1. 重量级：占用资源过多，在开发的过程中效率很低；大部分时间花在配置、运行的过程上，修改复杂；单元测试也比较麻烦。
2. 轻量级：提高了开发的速度；立即可以看到结果；做单元测试也非常简单；大量现成可供参考的开源代码。

41、WEB 设计维度：

1. 从架构来看：MVC，MVP，MVVM，REST，Webservice，微服务。
2. 从缓存来看：MemCache，Redis，Squid。
3. 从并发分流来看：集群（负载均衡）、CDN。
4. 从数据库来看：主从库（主从复制），内存数据库，反规范化技术，NoSQL，分区（分表）技术，视图与物化视图。
5. 从持久化来看：Hibernate，Mybatis。
6. 从分布存储来看：Hadoop，FastDFS，区块链。
7. 从数据编码看： XML，JSON。
8. 从 Web 应用服务器来看： Apache，WebSphere，WebLogic，Tomcat，JBOSS，IIS。
9. 其它：静态化，有状态与无状态，响应式 Web 设计。

1. 集群：（1）应用服务器集群；（2）主从集群。
2. 负载均衡技术：（1）应用层负载均衡：http 重定向、反向代理服务器；（2）传输层负载均衡：DNS 域名解析负载均衡、基于 NAT 的负载均衡；（3）硬件负载均衡：F5；（6）软件负载均衡：LVS、Nginx、HAproxy。

静态算法 (不考虑动态负载)

(1)轮转算法:轮流将服务请求 (任务) 调度给不同的节点 (即:服务器)0

(2)加权轮转算法:考虑不同节点处理能力的差异。

(3)源地址哈希散列算法:根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点。

(4)目标地址哈希散列算法:根据请求目标IP做散列找出对应节点。

(5) 随机算法:随机分配，简单，但不可控。

动态算法(考虑动态负载)

(1)最小连接数算法:新请求分配给当前活动请求数量最少的节点，每个节点处理能力相同的情况下(2)加权最小连接数算法:考虑节点处理能力不同，按最小连接数分配。

(3)加权百分比算法:考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力。

1. 有状态和无状态：

1. 无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
2. 有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。

解决方法：

1. 携带session
2. 服务器间同步session
3. 将session存入redis

1. Redis 与 Memcache 能力比较

1. Redis 集群切片的常见方式