工程结构、术语描述、缩略语

琴韵

于 2022-11-17 14:45:46 发布

阅读量180

点赞数

分类专栏：知识库文章标签：知识库

本文链接：https://blog.csdn.net/u012549626/article/details/127902636

版权

知识库专栏收录该内容

11 篇文章 0 订阅

订阅专栏

1.术语

PO

persistent object 持久对象

一个PO对应数据库中的一条记录。
PO中不应该包含任何对数据库的操作

POJO

plain ordinary java object 简单java对象

一个中间对象，可以转化为PO、DTO、VO。
- POJO持久化之后==〉PO
- POJO传输过程中==〉DTO （Data Transfer Object）
- POJO用作表示层==〉VO （value object 值对象 / view object 表现层对象）
- PO 和VO都应该属于它。

BO

business object 业务对象

业务对象主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。

关于BO主要有三种概念
- 只包含业务对象的属性；
- 只包含业务方法；
- 两者都包含。
可以由Service层输出的封装业务逻辑对象。

VO

value object 值对象 / view object 表现层对象

主要对应页面显示的数据对象。
可以和表对应，也可以不，这根据业务的需要。
通常是Web向模版渲染引擎层传输的对象。

DO

Domain Object 领域对象

从现实世界中抽象出来的有形或无形的业务实体
此对象与数据库表结构一一对应，通过DAO层向上传输数据源对象。

DTO（TO）

Data Transfer Object 数据传输对象

用在需要跨进程或远程传输时，它不应该包含业务逻辑。
比如一张表有100个字段，那么对应的PO就有100个属性（大多数情况下，DTO内的数据来自多个表）。但view层只需显示10个字段，没有必要把整个PO对象传递到client，这时我们就可以用只有这10个属性的DTO来传输数据到client，这样也不会暴露server端表结构。到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO。
Service或Manager向外传输的对象。

DAO

data access object 数据访问对象

主要用来封装对DB的访问（CRUD操作）
通过接收Business层的数据，把POJO持久化为PO。

在这里插入图片描述

Query

数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类传输

2.结构

2.1.应用分层

开放 API 层：可直接封装 Service 接口暴露成 RPC 接口；通过 Web 封装成 http 接口；网关控制层等。
终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。
Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
Service 层：相对具体的业务逻辑服务层。
Manager 层：通用业务处理层，它有如下特征
- 1）对第三方平台封装的层，预处理返回结果及转化异常信息，适配上层接口。
- 2）对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。
- 3）与 DAO 层交互，对多个 DAO 的组合复用。
DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase、OceanBase等进行数据交互。
第三方服务：包括其它部门 RPC 服务接口，基础平台，其它公司的 HTTP 接口，如淘宝开放平台、支付宝付款服务、高德地图服务等。
外部数据接口：外部（应用）数据存储服务提供的接口，多见于数据迁移场景中。

2.2.工程结构

annotation (通用注解程序包)
client (通用客户端程序包)
common (通用系统统一通用程序包)
controller (控制器程序包)
domain (领域数据模型程序包)
manager (通用业务处理程序包)
mapper (Mybatis持久化操作接口定义程序包)
model (实体类模型定义程序包)
repository (JPA持久化操作接口定义程序包)
runtime (实时数据程序包)
service (通用逻辑接口定义程序包)
service.impl (通用逻辑接口实现程序包)
resources.mappers (Mybatis持久化mapper.xml的SQL逻辑程序包)
resources.sql (数据库的表定义,数据备份等)

2.3.系统架构设计目标

确定系统边界。确定系统在技术层面上的做与不做。
确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。
确定指导后续设计与演化的原则。使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化。
确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。

3.缩略语

QPS

（Query Per Second）每秒钟 request / 事务数量

响应时间

对请求作出响应所需要的时间

网络传输时间：N1
应用服务器处理时间：A1
数据库服务器处理时间：B1
响应时间 = N1+A1+B1

并发用户数

系统用户数：系统额定的用户数量

同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数 = 每秒请求数 RPS（吞吐量）+ 并发连接数 + 平均用户思考时间
平均并发用户数的计算：C=nL / T
- C 是平均的并发用户数
- n 是平均每天访问用户数（login session）
- L 是一天内用户从登录到退出的平均时间（login session 的平均时间）
- T 是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值计算：C^ 约等于 C + 3 * 根号 C
- 其中 C^ 是并发用户峰值，C 是平均并发用户数，该公式遵循泊松分布理论。

吞吐量

指单位时间内系统处理用户的请求数

从业务角度看，吞吐量可以用：请求数 / 秒、页面数 / 秒、人数 / 天或处理业务数 / 小时等单位来衡量
从网络角度看，吞吐量可以用：字节 / 秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数 / 秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数 / 秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R /
- 其中 F 为吞吐量，VU 表示虚拟用户个数，R 表示每个虚拟用户发出的请求数，T 表示性能测试所用的时间