|
|
@@ -1,83 +1,46 @@
|
|
|
-# 上饶银行项目架构规划
|
|
|
+# 上饶银行项目需求
|
|
|
|
|
|
-## 需求
|
|
|
-银行在不同的领域有不同的投资产品，银行想看到投资的实际得到的效益，以看板的形式体现得到的收益。
|
|
|
-## 目标
|
|
|
-* 业务方面:投资产品的收益，以及未来需要的大数据分析，
|
|
|
-* 技术架构:避免返工，提高程序的扩展性和负载性
|
|
|
-* 实现框架springCloud
|
|
|
+## 编写目的
|
|
|
+本需求说明书全面描述上饶银行项目的各种功能，运行环境，使客户和开发者双方对本系统的初始规定有一个共同的理解，使之成为共同开发的接触
|
|
|
|
|
|
-## 为什么用springCloud
|
|
|
-* 首先根据业务方提供的需求，银行的投资项目比较大，如果用单体架构，未来的服务化，项目的集群和负载比较难拆分
|
|
|
-* cloud比doubbo组件丰富，更好的支持分布式的场景
|
|
|
-* 提高的程序的扩展性和职能性，每个服务负责一个功能，便于维护
|
|
|
+## 预期读者
|
|
|
+* 银行管理部门
|
|
|
+* 开发人员
|
|
|
+* 测试人员
|
|
|
|
|
|
-## 技术实现
|
|
|
-### 反向代理服务器
|
|
|
-* nginx可以承受2-4w的并发,nginx可以作为反向代理和负载均衡,当并发大的时候可以搭建nginx集群,保证了程序的高可用性
|
|
|
+## 项目背景
|
|
|
+* 该项目为了方便对银行对各种投资项目的查看和分析
|
|
|
+* 方便对投资项目的详细了解
|
|
|
+* 建立一个方便银行使用的高效投资查看平台
|
|
|
|
|
|
-### 微服务架构选型
|
|
|
-* springCloud,springCloud组件丰富,提供了网关，注册中心，生产者，消费者，链路追踪，日志收集，配置中心，bus总线一系列的分布式应用
|
|
|
-* 网关:geatWay为微服务架构提供一种简单而有效的统一的API路由管理方式,提供了api路由的统一管理，还有安全，监控/埋点，和限流
|
|
|
-* 注册中心:eureka,服务的注册以及服务的发现，CAP理论保证了程序的高可用新和分析容错性
|
|
|
-* 生产者和消费者:提供服务和消费服务
|
|
|
-* 链路追踪:sleuth由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位，sleuth去跟进一个请求到底有哪些服务参与
|
|
|
-参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位
|
|
|
-* 日志收集:elk,elasticsearch、logstash、kibana
|
|
|
-* 配置中心:Apollo,SpringCloud Config,配置中心的优点，对配置的统一管理，配置的迁移和管理方便
|
|
|
-* bus总线:总的来说，就是在我们需要把一个操作散发到所有后端相关服务器的时候，就可以选择使用cloud bus了
|
|
|
-spring cloud config 配合spring cloud bus实现配置信息更新
|
|
|
+## 系统说明
|
|
|
|
|
|
-### 微服务项目规范
|
|
|
-* base-pom:项目依赖统一管理.任何服务中引入新的依赖后,需要在base-pom中添加依赖管理
|
|
|
-* common工具类
|
|
|
- * common-core:提供了基本的公共类
|
|
|
- * common-spring:各种中间件或工具与spring融合的增强
|
|
|
- * common-mvc:与springmvc相关的技术的增强和配置
|
|
|
-* 微服务结构
|
|
|
- * 生产者
|
|
|
- * project是maven主项目, 以base-pom为parent.
|
|
|
- * controller控制器层,分为web控制器和api控制器，web控制器用于对外接口,api控制用于内部接口
|
|
|
- * service业务逻辑
|
|
|
- * persistence处理映射关系
|
|
|
- * model是module
|
|
|
- * controller,service,persistence,model是module模块,以project为parent.
|
|
|
- * 消费者
|
|
|
- * provider提供对外的api
|
|
|
-### 数据库设计
|
|
|
-* mysql
|
|
|
+### 系统描述
|
|
|
+* 系统从不同的子系统获取数据,比如菜市场系统,停车场系统,餐饮系统等
|
|
|
+* 系统获取数据后对数据进行储存,然后进行数据的分析和整理,进行数据的可视化展示
|
|
|
+* 满足了银行对各种子系统详细的了解
|
|
|
+### 银行投资项目的功能需求
|
|
|
+* 在计算机网络，数据库和先进的开发平台上，利用银行提供的硬件环境
|
|
|
+搭建一个具有开放体系结构，扩展性，可维护性，不返工的人机交互方便的
|
|
|
+银行投资项目系统，为银行提供准确,精细，迅速的系统
|
|
|
+* 根据银行提供的需求,分析现有的架构，采用B/S结构，微服务架构(springCloud)
|
|
|
+把不同的模块服务化,比如菜市场服务，停车场服务，餐饮服务，后期遇见数据量大的
|
|
|
+模块方便进行扩展和负载和备份，提供了程序的扩展性
|
|
|
|
|
|
-### 非关系型数据库
|
|
|
-#### 为什么需要缓存
|
|
|
-* 缓存是储存在内存中的，数据拿取效率上会高
|
|
|
-* 缓存经常用来储存一些常用的，不经常变的数据
|
|
|
+### 界面要求
|
|
|
+* 界面美观大方，容易操作
|
|
|
+* 出现在页面的每个按钮，每个功能详细的描述信息
|
|
|
|
|
|
-#### 缓存中间键
|
|
|
-* redis,Redis 支持的数据结构丰富，包括hash、set、list等
|
|
|
-* mongoDB, 更类似 MySQL，支持字段索引、游标操作，其优势在于查询功能比较强大，擅长查询 JSON 数据，能存储海量数据，但是不支持事务,
|
|
|
-MySQL 在大数据量时效率显著下降，MongoDB 更多时候作为关系数据库的一种替代
|
|
|
|
|
|
-### 分库分表中间键(数据量超过千万的时候再用)
|
|
|
-#### 为什么要用中间键
|
|
|
-* 数据量比较大的时候,会进入mysql的性能屏障,单库会存在性能屏障，这个时候就需要进行数据的切分管理，把数据路由的不同的库，进行主从备份
|
|
|
-* 垂直切分:不同的表路由的不同节点的数据库
|
|
|
-* 水平切分:单表数据大的时候，把单表的数据切分到不同节点的相同表里面
|
|
|
-#### 分库分表中间键工具
|
|
|
-* mycat
|
|
|
-* sharding-sphere：jar，前身是sharding-jdbc
|
|
|
-* TDDL：jar，Taobao Distribute Data Layer
|
|
|
+### 运行环境
|
|
|
+* 硬件环境:两个centos服务器
|
|
|
+* 软件环境:mysql，rabbitMq,redis,mongoDB等
|
|
|
+* 部署方式，一个服务器部署开发的软件项目，一个部署其他的第三方软件
|
|
|
|
|
|
+### 接口方式
|
|
|
+* 服务内部调用:返回精准的类型数据，该是什么数据就是什么数据
|
|
|
+* 服务对外提供:统一的返回ApiResult,里面有Code(状态码),Data(数据),Message(成功或者失败)
|
|
|
|
|
|
-### 消息中间键
|
|
|
-#### 为什么要用消息中间键
|
|
|
-* 消息中间键的好处，异步处理，解耦，流量削峰，当银行项目通过api传递数据的时候，数据传输特别多，这个时候就用消息中间键进行流量削峰的作用
|
|
|
-#### 消息中间键工具
|
|
|
-* RabbitMQ、
|
|
|
-* RocketMQ、
|
|
|
-* Kafka
|
|
|
-* activityMQ
|
|
|
+### 开发语言
|
|
|
+java
|
|
|
|
|
|
-### 定时任务
|
|
|
-* xxlJob 推荐
|
|
|
-* quartz
|
|
|
-* 线程池
|
