架构设计特训

一、考点分布

• 软件架构风格（※※※※）
• 层次型软件架构风格（※※※※）
• 面向服务的软件架构风格（※※※※）
• 云原生架构风格（※※※※）
• 质量属性与架构评估（※※※※※）
• 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对应到不同的服务器