架构设计特训

一、考点分布

• 软件架构风格（※※※※）
• 层次型软件架构风格（※※※※）
• 面向服务的软件架构风格（※※※※）
• 云原生架构风格（※※※※）
• 质量属性与架构评估（※※※※※）
• Web架构综合考察（※※※※※）

二、软件架构风格

三、C/S架构与B/S架构

 

四、层次式结构

五、MVC架构风格

Model(模型)：应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型通为多个视图提供数据。提高应用的可重用性。

View（视图）：用户看到并与之交互的界面。接收用户输入数据，向用户展示数据。

Controller（控制器）：用户界面与Model的接口。解释视图的输入，将其解释为系统能够理解的对象，同时识别用户运作，将其解释为对模型特定方法的调用。处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

六、MVP架构风格

MVP是MVC的变种，其优点包括：

• 模型与视图完全分离，可以修改视图而不影响模型
• 可以高效地使用模型，因为所有交互都发生在一个地方（Presenter）内部
• 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑
• 如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑（单元测试）

 七、MVVM架构风格

MVVM强调了数据绑定

八、RIA架构风格

优点：反应速度快、易于传播、交互性强

九、数据访问层设计

ORM：对象与关系数据之间的映射

十、物联网分层架构

十一、大数据分层架构

十一、基于服务的架构（SOA）

        服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

服务、构件和标准化接口的关系

• 服务构件粗粒度，传统构件细粒度居多
• 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现
• 服务构件的实现与语言无关，传统构件绑定某种特定语言
• 服务构件可以通过构件容器提供Qos的服务，传统构件完全由程序代码直接控制

十二、WEB服务

WSDL：是WebService接口对应的WSDL文件，该文件通过xml格式说明如何调用，可以看作WebService的接口文档（使用说明书）

十三、REST（表述性状态转移）

        REST是一种通常使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

REST原则

• 网络上的所有事物都抽象为资源
• 每一个资源对应一个唯一的资源标识
• 通过通用的连接件接口对资源进行操作
• 对资源的各种操作不会改变资源标识
• 所有的操作是无状态

十四、ESB（企业服务总线）

 

ESB的特点

• 提供位置透明性的消息路由和寻址服务
• 提供服务注册和命名的管理功能
• 支持多种消息传递泛型
• 支持多种可以广泛使用的传输协议
• 支持多种数据格式及其相互转换
• 提供日志和监控功能

 十五、微服务

微服务：很小的服务，它面向服务架构一种

微服务优点

• 复杂应用解耦：化整为零
• 独立：独立开发，独立测试及独立部署，独立运行
• 技术选型灵活：支持异构（如：每个服务使用不同数据库）
• 容错：故障被隔离在单个服务中
• 松耦合，易扩展

面临的问题

• 分布式环境下的数据一致性
• 测试的复杂性（服务间依赖测试）
• 运维的复杂性

微服务架构模式方案

微服务与SOA区别

• 微服务比SOA更细，可以独立进程方式存在
• 微服务接口更通用化，如用HTTP RESTful，各种终端都可调用，语言无关，平台无关。
• 更倾向与分布式部署，更适合互联网场景

十六、云计算

         云计算是集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相互分离。

        云计算优点：超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低

云计算按服务类型分类

• SaaS（软件即服务）：基于多租户技术实现，直接提供应用程序
• PaaS（平台即服务）：虚拟中间件服务器、运行环境和操作系统
• IaaS（基础设施即服务）：包括服务器、存储和网络等服务

云计算按部署方式分类

• 公有云：面向互联网用户需求，通过开放网络提供云计算服务
• 私有云：面向企业内部提供云计算服务
• 混合云：兼顾以上两种情况的云计算服务

16.1 云计算架构

管理层：提供对所有层次云计算服务的管理功能。

用户访问层：方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口。

应用层：提供软件服务，如：财务管理，客户关系管理，商业智能

平台层：为用户提供对资源层服务的封装，使用户可以构建自己的应用

资源层：提供虚拟化的资源，从而隐藏物理资源的复杂性。如：服务器，存储

十七、云原生架构

云原生：是基于分布部署和统一运营的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术体系。

17.1 云原生架构的设计原则

• 服务化原则：使用微服务
• 弹性原则：可根据业务变化自动伸缩
• 可观测原则：通过日志、链路跟踪和度量
• 韧性原则：面对异常的抵御能力
• 所有过程自动化原则：自动化交付工具
• 零信任原则：默认不信任网络内部和外部的任何人/设备/系统
• 架构持续演进原则：业务高速迭代情况下的架构与业务平衡

17.2 云原生架构模式

1. 服务化架构模式：微服务，服务拆分使维护压力大增
2. Mesh化架构模式：把中间件框架（RPC、缓存、异步消息）从业务进程中分离，由Mesh进程完成
3. Serverless模式：非常适合于事件驱动的数据技术任务
4. 存储计算分离模式：各类暂时的数据有云服务保存
5. 分布式事务模式：解决微服务模式中多数据源事务问题
6. 可观测架构：包括Logging、Tracing、Metrics三个方面
7. 事件驱动架构：本质上是一种应用/组件间的集成架构模式

17.3 云原生架构反模式

1. 庞大的单体应用：需要多人开发业务模块，考虑通过服务化进行拆分，并让组织与架构匹配
2. 单体应用“硬拆”为微服务（服务拆分要适度）
3. 缺乏自动化能力的微服务

17.4 微服务设计约束

1.  微服务个体约束：每个微服务都是独立的，修改一个微服务不能影响另一个微服务
2. 微服务与微服务之间的横向关系：通过第三方服务注册中心来满足服务的可发现性
3. 微服务与数据层之间的纵向约束：数据是微服务的“私产”，访问时需要通过微服务
4. 全局视角下的微服务分布式约束：高效运维整个系统

 17.5 云原生架构与普通架构对比

十八、边缘计算

边缘计算：指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。

边缘计算的本质：计算处理职能的本地化

十九、大型网站系统架构演化

19.1 单体架构到垂直架构

 

第三个阶段使用缓存改善网站性能

19.2 缓存问题

数据读取

1. 根据key从缓存读取
2. 若缓存中没有，则根据key在数据库中查找
3. 读取到“值”之后，更新缓存

数据写入

1. 根据key值写数据库
2. 根据key更新缓存（或删除缓存）

19.3 redis分布式存储方案

• 主从模式：一主多从，故障时手动切换

        

• 哨兵模式：有哨兵的一主多从，主节点故障自动选择新的主节点

        

• 集群模式：分节点对等集群，分slots，不同的slots的信息存储到不同节点

        

 19.4 redis集群切片的常见方式

• 客户端分片：在客户端通过key的hash值对应到不同的服务器
• 中间件实现分片：在应用软件和redis中间，例如：Twemproxy、Codis等，由中间件实现服务到后台redis节点的路由分派
• 客户端服务端协作分片：客户端采用一致性哈希，服务端提供错误节点的重定向服务slot上，不同的slot对应到不同的服务器

19.4 Redis数据分片方案

• 范围分片：按数据范围值做分片
• 哈希分片：通过对key进行hash运算分片
• 一致性哈希分片：哈希分片的改进，利于扩展节点

19.5 Redis数据类型

19.6 redis数据淘汰策略

19.7 redis的持久化

RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储

AOF:把每条改变数据的命令追加到AOF文件末尾

 19.8 redis常见问题

1、缓存雪崩：大部分缓存失效，导致数据库崩溃。解决方案如下：

1. 使用锁或队列：保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上
2. 为key设置不同的缓存失效时间：在固定的一个缓存时间的基础上+随机一个时间作为缓存失效时间
3. 二级缓存：设置一个有时间限制的缓存+一个无时间限制的缓存，避免大规模访问数据库。

2、缓存穿透：查询无数据返回，则直接查询数据库

1. 设置一个布隆过滤器
2. 如果查询为空，直接设置一个默认值存放到缓存，并设置一个过期时间

3、缓存预热：系统上线后，将相关需要缓存数据直接加到缓存系统中

1. 手动刷新缓存
2. 定时刷新缓存

4、缓存更新：

1. 定时清理过期的缓存
2. 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存

5、缓存降级：目的保证核心业务服务可用

 二十、使用服务集群改善网站并发处理能力

应用服务器集群面临的问题

1. 用户的请求由谁来转发到具体的应用服务器（负载均衡）
2. 用户如果每次访问到的服务器不一样，那么如何维护session的一致性（有状态与无状态问题）

负载均衡技术

1、http重定向：实现简单，但性能较差

2、反向代理服务器：部署简单，但代理服务器可能成为性能的瓶颈（nginx）

3、DNS域名解析负载均衡：在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器ip地址。特点：效率比http重定向高，减少维护负载均衡服务器的成本，但由于服务器故障而不能及时通知DNS导致网站无法打开，失效性差。

4、基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点的地址。特点：技术较为成熟，一般在网关位置，可以通过硬件实现。

负载均衡算法

静态算法（不考虑动态负载）

1. 轮转算法：轮流将服务请求（任务）调度给不同的节点（即：服务器）。
2. 加权轮转算法：考虑不同节点处理能力的差异
3. 源地址哈希散列算法：根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点
4. 目标地址哈希散列算法：根据请求目标IP做散列找出对应节点。
5. 随机算法：随机分配，简单，但不可控。

动态算法（考虑动态负载）

1. 最小连接数算法：新请求分配给当前活动请求数量最少的节点，每个节点处理能力相同的情况下。
2. 加权最小连接算法：考虑节点处理能力不同，按最小连接数分配。
3. 加权百分比算法：考虑了节点的利用率、磁盘效率、进程个数等，使用利用率来表现剩余处理能力。

硬件负载均衡：F5

软件负载均衡：LVS、Nginx、HAproxy

无状态服务：对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。

有状态服务：它会在自身保存一些数据，先后的请求是有关联的。

二十一、数据库的读写分离

主从数据库结构特点：

1. 一主多从，也可以多主多次
2. 主库做写操作，从库做读操作

主从复制步骤：

1. 主库（Master）更新数据完成前，将操作写binlog日志文件。
2. 从库（Salve）打开I/O线程与主库连接，做binlog dump process，并将事件写入中继日志。
3. 从库执行中继日志事件，保持与主库一致。

使用缓存缓解读库的压力

二十二、使用反向代理和CDN加速网站响应

CDN（Content Delivery Network），即内容分发网络。其基本思路是尽可能避开互联网上可能影响传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。（CDN处于外网）

 二十三、使用分布式文件系统和分布式数据库系统

二十四、使用NoSQL和搜索引擎

 二十五、业务拆分

二十六、分布式服务

二十七、Web应用服务器

二十八、响应式Web设计

响应式Web设计是一种网络页面设计布局，其理念是：集中创建页面的图片排版大小，可以只能地根据用户行为以及使用的设备环境进行相对应的布局。

方法与策略

（1）采用流式布局和弹性化设计：使用相对单位，设定百分比而非具体值的方式设置页面元素的大小。

（2）响应式图片：不仅要同比的缩放图片，还要在小设备上降低图片自身的分辨率。

二十九、中台

• 业务中台：提供重用服务
• 数据中台：提供数据整合分析能力，帮助企业从数据中学习改进，调整方向
  • 数据汇聚整合能力、数据提纯加工能力、数据服务可视化、价值变现方面
• 技术中央：提供技术重用组件能力，帮助解决基础技术平台的复用。

三十、常见架构分析