软考高级系统架构设计师之架构设计扩展篇（一）

一、层次式架构设计理论与实践

软件架构贯穿于软件研发的整个生命周期内，具有三方面的重要影响:

• (1)利益相关人员之间的交流。
• (2)系统设计的前期决策。
• (3)可传递的系统级抽象。

作为下层的客户（调用、返回）为上层提供服务（调用、返回）
每一层最多只影响两层【严格分层的情况下】

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

架构演变：两层 C/S => 三层 C/S => 三层 B/S

两层 C/S： 胖客户端，客户端应用程序 《-网络-》 瘦服务器，数据库服务器 【升级维护困难】
三层 C/S： 瘦客户端【表示层】《-应用服务器【功能层】-》数据库服务器【数据层】 业务逻辑变化不再需要更新客户端。
三层 B/S： 零客户端【Web浏览器/表示层】《-Web应用服务器【功能层/数据访问层】-》数据服务器【数据层】 升级完全不需要客户端，升级维护容易。

在手机端用得不多 B/S模式
用小程序来做比较方便。

三、常见的层次架构

【N 层架构模式(n-tierarchitecture pattern)】
层次架构是最通用的架构，“常作为初始架构”。
【关注分离】每层只负责本层的工作

• 表现层【UI】（MVC、MVP、MVVM设计模式）
• -中间层【业务逻辑】
• -访问层【访问数据】
• -数据层【存储】

【设计时注意两点】
1、污水池反模式。请求简单穿透多层，但没做业务逻辑。
2、分层架构可能会让应用变得庞大。

四、MVC架构风格

Model(模型): 应用程序的主体部分。型表示 业务数据和业务逻辑。一个模型能为多个视图提供数据。 提高应用的可重用性。
View(视图): 用户看到并与之交互的界面。接收用户输入数据，向用户展示数据。Controller(控制器):用户界面与Model的接口。 解释视图的输入，将其解释为系统能够理解的对象，同时识别用户运作，将其解释为对模型特定方法的调用。处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

J2EE体系结构中:
视图(View):JSP
控制(Controller):Servlet
模型(Model):EntityBean、Session Bean

五、MVP架构风格

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

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

解耦、高效使用模型

六、MVVM架构风格

视图模型 （ViewModel）只是完成数据的双向绑定，最核心的功能。

七、RIA架构风格

C/S -> B/S -> RIA (富互联网 临时下载客户端) 如 Ajax、Flex、Bindows、HTML5、小程序
【优点】
反应速度快、易于传播、交互性强

八、表现层UIP设计思想

【UIP框架】
【User Interface Components】原来的表现层，用户看到的和进行交互都是这 个组件。
【User Interface Process Components】这个组件用于协调用户界面的各部分，使其配合后 台的活动，例如导航和工作流控制，以及状态和视图的管理。用户看不到这一组件，但是这些组件为User InterfaceComponents提供了重要的支持功能。

【表现层动态生成设计思想】
基于XML界面管理技术，包括【界面配置】、【界面动态生成】和【界面定制】三部分。

九、中间层

业务逻辑层工作流设计

核心是工作流设置服务器、包括过程定义工具、管理监控工具、工作流客户端应用、其他工作流设置服务器、相关应用。
其中
接口1【过程定义导入/导出接口】转换格式和API调用，支持过程定义信息间的互相转换。
接口2(客户端应用程序接口人通过这个接口工作流机可以与任务表处理器交互，代表用户资源来组织任务，然后由任务表处理器负责，从任务表中选择、推进任务项，由任务表处理器或者终端用户来控制应用工具的活动。
接口3【应用程序调用接口】允许工作流机直接激活一个应用工具，来执行一个活动。
接口4【工作流机协作接口】使不同开发的工作流系统产品相互间能够进行无缝的任务项目。
接口5【管理和监视接口】提供的功能包括用户管理、角色管理、审查管理、资源控制、过程管理和过程状态处理器等

十、数据访问模式

5种数据访问模式

• 在线访问【每个数据库操作都会通过数据库连接不断地与后台的数据源进行交互】
• Data Access Object【底层数据访问操作 与 高层业务逻辑 分离】
• Data Transfer Object 【跨不同的进程或是网络的边界来传输数据】
• 离线数据模式 【从数据源获取数据后，存放到本地处理】
• 对象/关系映射 【应用系统中的对象与数据库中的数据表形成映射关系】ORM

ORM(Object RelationalMapping):对象与关系数据之间的映射。
映射关系表：
面向对象 <----> 关系数据库
类(class) <----> 数据库的表(table)
对象(object) <----> 记录(record，行数据)
对象的属性(attribute) <----> 字段(field)

实现技术对比表
维度 <–> Hibernate <–> MyBatis(iBatis)
简单对比 <–>强大，复杂，间接，SQL无关 <–>小巧，简单，直接，SQL相关
可移植性 <–>好(不关心具体数据库)<–> 差(根据数据库SOL编写)
复杂多表关联<–>不支持<–>支持

应用-》持久对象（Hibernate,Hibernate属性、XML映射）-》数据库

十一、物联网分层架构

应用层 解决信息处理和人机交互问题 应用服务 智能终端
平台层 操作系统 软件开发 设备管理平台连接管理平台
网络层 传递信息和处理信息 网络 通信标准/协议
感知层 解决数据获取问题 传感器 芯片 通信模组

十二、大数据分层架构

数据应用层
数据接口层
数据层
数据采集层
数据源

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

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

松散耦合
粗粒度
标准化接口

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

十四、Web Service(WEB服务)

注册中心：类似于搜索引擎 （服务描述）
服务请求者：通过UDDI查找
服务提供者：通过UDDI发布 （服务、服务描述）

各个层次的协议
发现服务 UDDI、DISCO
描述服务 WSDL、XML Schema
消息格式层 SOAP、REST
编码格式层 XML(DOM，SAX)
传输协议层 HTTP、TCP/IP、SMTP等

十五、REST(表述性状态转移)

REST(RepresentationalState Transfer，表述性状态转移)是一种通常使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

资源:如架构课程订单
表述:资源某一时间的状态，呈现形式有HTML、JSON、XML
状态转移:使用GET、POST等方法
超链接:通过超链接可与其它资源联系
REST的5个原则
（1）网络上的所有事物都被抽象为资源。
（2）每个资源对应一个唯一的资源标识(反过来不成立)
（3）通过通用的连接件接口对资源进行操作。
(4) 对资源的各种操作不会改变资源标识。
（5）所有的操作都是无状态的。

十六、ESB(企业服务总线)

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

十七、微服务

【微服务】顾名思义，就是很小的服务，所以它属于面向服务架构的一种。
雕版印刷 VS 活字印刷

微服务的优点解读
优点 解读
【复杂应用解耦】 小服务(且专注于做一件事情)化整为零，易于山团队开发
【独立] 独立开发、独立测试及独立部署(简单部署)独立运行(每个服务独立在其独立进程中)
【技术选型灵活】支持异构(如:每个服务使用不同数据库
【容错】 故障被隔离在单个服务中，通过重试、平稳退化等机制实现应用层容错
【松耦合，易扩展】 可根据需求独立扩展

面临的问题与挑战
分布式环境下的数据一致性【更复杂】
测试的复杂性【服务间依赖测试】
运维的复杂性

【微服务架构模式方案】
聚合器微服务

链式微服务

数据共享微服务

异步消息传递微服务

十八、云计算概念、优点、分类

【云计算】 是集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相分离的。
【云计算优点】超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低【前期投入低、综合使用成本也低】

云计算【按服务类型分类】
SaaS【软件即服务】 基于多租户技术实现，直接提供应用程序
PaaS【平台即服务】虚拟中间件服务器、运行环境和操作系统
laaS 【基础设施即服务】 包括服务器、存储和网络等服务

云计算【按部署方式分类】
公有云: 面向互联网用户需求，通过开放网络提供云计算服务
私有云: 面向企业内部提供云计算服务
混合云: 兼顾以上两种情况的云计算服务

【管理层】提供对所有层次云计算服务的管理功能。
【用户访问层】方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口。
【应用层】提供软件服务，如:财务管理，客户关系管理，商业智能。
【平台层】为用户提供对资源层服务的封装，使用户可以构建自己的应用。
【资源层】提供虚拟化的资源，从而隐藏物理资源的复杂性。如:服务器，存储。

十九、云原生架构

【云原生(Cloud Native)】 一开始就是基于云环境、专门为云端特性而设计，可充分利用和发挥云平台的弹性+分布式优势，最大化释放云计算生产力。

【本质】
Oncloud->Incloud

云原生组成
微服务、持续交付、DevOps、容器 声明式API、服务网格(Service Mesh)

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

【云原生架构模式】
1、服务化架构模式:典型代表**【微服务】，服务拆分使维护压力大增。业务进程（业务逻辑代码、非业务逻辑代码、FastSDK）、基础设施
2、Mesh化架构模式:把中间件框架(RPC、缓存、异步消息)从业务进程中分离，由Mesh进程完成。 业务进程（业务逻辑代码、非业务逻辑代码、）、基础设施（【Mesh进程】 FastSDK）
3、Serverless模式:非常适合于事件驱动的数据计算任务**。业务进程（业务逻辑代码、）、基础设施（非业务逻辑代码、【Mesh进程】 FastSDK）
4、存储计算分离模式:各类暂态数据(如session)用云服务保存。
5、分布式事务模式:解决微服务模式中多数据源事务问题。
6、**可观测架构:**包括Logging、Tracing、Metrics三个方面。
7、事件驱动架构:本质上是一种应用/组件间的集成架构模式。

【云原生架构反模式】
1、庞大的单体应用【需要多人开发的业务模块，考虑通过服务化进行拆分，并让组织与架构匹配】
2、单体应用“硬拆”为微服务(服务拆分要适度)性能降低】【小规模软件的服务拆分(为拆而拆)、数据依赖(服务间数据依赖)、
3、缺乏自动化能力的微服务
【手动维护大量微服务是不现实的】

【容器技术】docker

传统部署模式->虚拟化部署模式【虚拟机/操作系统/bin Library /App】->容器部署模式【硬件/操作系统/Container Runtime/Container/Bin/LibraryApp】

Kubernetes
【容器技术】
Kubernetes提供了分布式应用管理的核心能力。
【资源调度】 根据请求资源量在集群中选择合适的节点来运行应用。
【应用部署与管理】 支持应用的自动发布与应用的回滚。
【自动修复】当宿主机或者0S出现故障，节点健康检查会自动进行应用迁移。
【服务发现与负载均衡】 结合DNS和负载均衡机制，支持容器化应用之间的相互通信。
【弹性伸缩】 可以对这个业务进行自动扩容。
【声明式API】 开发者可以关注于应用自身，而非系统执行细节。
【可扩展性架构】 所有K8s组件都是基于一致的、开放的API实现和交互。
【可移植性】 K8s通过一系列抽象如Load BalanceService(负载均衡服务)、CNI(容器网络接口)、CSI(容器存储接口)，帮助业务应用可以屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标。

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

例子：
()为用户提供对资源云计算可以按需提供弹性资源，它它的体系结构由5部分组成。其中，层的各项云计算服务的封装，帮助用户构建所需的应用。
A应用层
B 平台层
C用户访问层
D 管理层

参考：B

这个动作从运维中“收走”，把应用的整个运行都委托给云Serverless将“部署”这样能带来很多好处，以下()场景比较适合Serverless架构模式。
A 应用是有状态的
B 应用会长时间在后台运行密集型计算任务
C 事件驱动的数据计算任务
D应用涉及较多的外部I/0
参考：C