|
|
@@ -0,0 +1,83 @@
|
|
|
+# 上饶银行项目架构规划
|
|
|
+
|
|
|
+## 需求
|
|
|
+银行在不同的领域有不同的投资产品，银行想看到投资的实际得到的效益，以看板的形式体现得到的收益。
|
|
|
+## 目标
|
|
|
+* 业务方面:投资产品的收益，以及未来需要的大数据分析，
|
|
|
+* 技术架构:避免返工，提高程序的扩展性和负载性
|
|
|
+* 实现框架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以project为parent.
|
|
|
+ * 消费者
|
|
|
+ * provider提供对外的api
|
|
|
+### 数据库设计
|
|
|
+* mysql
|
|
|
+
|
|
|
+### 非关系型数据库
|
|
|
+#### 为什么需要缓存
|
|
|
+* 缓存是储存在内存中的，数据拿取效率上会高
|
|
|
+* 缓存经常用来储存一些常用的，不经常变的数据
|
|
|
+
|
|
|
+#### 缓存中间键
|
|
|
+* redis,Redis 支持的数据结构丰富，包括hash、set、list等
|
|
|
+* mongoDB, 更类似 MySQL，支持字段索引、游标操作，其优势在于查询功能比较强大，擅长查询 JSON 数据，能存储海量数据，但是不支持事务,
|
|
|
+MySQL 在大数据量时效率显著下降，MongoDB 更多时候作为关系数据库的一种替代
|
|
|
+
|
|
|
+### 分库分表中间键(数据量超过千万的时候再用)
|
|
|
+#### 为什么要用中间键
|
|
|
+* 数据量比较大的时候,会进入mysql的性能屏障,单库会存在性能屏障，这个时候就需要进行数据的切分管理，把数据路由的不同的库，进行主从备份
|
|
|
+* 垂直切分:不同的表路由的不同节点的数据库
|
|
|
+* 水平切分:单表数据大的时候，把单表的数据切分到不同节点的相同表里面
|
|
|
+#### 分库分表中间键工具
|
|
|
+* mycat
|
|
|
+* sharding-sphere：jar，前身是sharding-jdbc
|
|
|
+* TDDL：jar，Taobao Distribute Data Layer
|
|
|
+
|
|
|
+
|
|
|
+### 消息中间键
|
|
|
+#### 为什么要用消息中间键
|
|
|
+* 消息中间键的好处，异步处理，解耦，流量削峰，当银行项目通过api传递数据的时候，数据传输特别多，这个时候就用消息中间键进行流量削峰的作用
|
|
|
+#### 消息中间键工具
|
|
|
+* RabbitMQ、
|
|
|
+* RocketMQ、
|
|
|
+* Kafka
|
|
|
+* activityMQ
|
|
|
+
|
|
|
+### 定时任务
|
|
|
+* xxlJob 推荐
|
|
|
+* quartz
|
|
|
+* 线程池
|
