mirror of
https://github.com/abcv7/sfbx-cloud.git
synced 2026-08-16 11:47:00 +00:00
功能：在保险、规则、交易、积分和短信模块中实现初始功能和基础组件。
This commit is contained in:
abcv7
+423
-25
@@ -1,37 +1,435 @@
|
||||
# sfbx-cloud
|
||||
# 第 1 章-项目介绍&环境搭建
|
||||
|
||||
#### 介绍
|
||||
四方保险
|
||||
# 学习目标
|
||||
|
||||
#### 软件架构
|
||||
软件架构说明
|
||||
- 了解保险行业背景与发展趋势前景
|
||||
- 掌握《四方保险》项目核心架构、项目模板、技术架构、数据库总述
|
||||
- 快速搭建《四方保险》项目环境并建立 git 项目管理
|
||||
|
||||
# 1、背景与趋势
|
||||
|
||||
#### 安装教程
|
||||
## 1.1、行业背景
|
||||
|
||||
1. xxxx
|
||||
2. xxxx
|
||||
3. xxxx
|
||||
在过去的十年内保险行业的发展如何？IT 行业对于保险行业的发展又如何呢？下面我们来看下一组数据：
|
||||
|
||||
#### 使用说明
|
||||
|
||||
|
||||
1. xxxx
|
||||
2. xxxx
|
||||
3. xxxx
|
||||
上述数据可以看出从 2014 开始保险的总体保费收入在逐年上升，并且中国的保险 IT 行业呈现稳定增长趋势：
|
||||
|
||||
#### 参与贡献
|
||||
- 数字化转型已成为保险行业的趋势，这为保险 IT 市场创造了巨大的机会
|
||||
- IT 技术为保险公司提供了创新工具和支持，有助于提高业务效率和客户体验
|
||||
- 人工智能、大数据分析、规则引擎计算等先进技术的应用使保险公司能够更好地评估风险、优化产品，实现个性化定制
|
||||
- 从 2018 年到 2021 年，保险 IT 市场投资规模增长了约 128.4 亿元，这表明行业在资本支持方面表现强劲
|
||||
- 平均复合增速为 12.06%，显示了市场的持续健康发展。示着市场在未来依然有望保持增长。
|
||||
|
||||
1. Fork 本仓库
|
||||
2. 新建 Feat_xxx 分支
|
||||
3. 提交代码
|
||||
4. 新建 Pull Request
|
||||
对于学习保险类项目对于后期的个体发展、职业规划将会有巨大的支持：
|
||||
|
||||
- 拥有特有行业的项目经验，提升个人在就业职业发展竞争力
|
||||
- 提升个人对于复杂业务系统的分析设计能力、开发能力、维护能力
|
||||
|
||||
#### 特技
|
||||
## 1.2、项目背景
|
||||
|
||||
1. 使用 Readme\_XXX.md 来支持不同的语言，例如 Readme\_en.md, Readme\_zh.md
|
||||
2. Gitee 官方博客 [blog.gitee.com](https://blog.gitee.com)
|
||||
3. 你可以 [https://gitee.com/explore](https://gitee.com/explore) 这个地址来了解 Gitee 上的优秀开源项目
|
||||
4. [GVP](https://gitee.com/gvp) 全称是 Gitee 最有价值开源项目，是综合评定出的优秀开源项目
|
||||
5. Gitee 官方提供的使用手册 [https://gitee.com/help](https://gitee.com/help)
|
||||
6. Gitee 封面人物是一档用来展示 Gitee 会员风采的栏目 [https://gitee.com/gitee-stars/](https://gitee.com/gitee-stars/)
|
||||
在整个金融保险行业，保险 IT 行业是保险行业数字化转型的重要组成部分，涵盖了多个细分领域。其中包括传统保险业务系统，官方直销系统，专业中介代理平台，互联网保险平台，以及其他保险系统。学习 `《四方保险》` 项目后各位小伙伴可以向不同方向的保险项目进行个人发展学习。
|
||||
|
||||
|
||||
|
||||
《四方保险》属于专业互联网保险平台（**保险销售平台**），是一种在线保险销售平台；提供不同保险公司的保险产品销售、试算、投保和支付等功能。这些平台通常涵盖了整个保险业务流程，从产品购买、保单管理到理赔服务，主要作用是提高用户体验、降低交易成本、加强风险**、可以对比多家保险公司的保险产品管理。**
|
||||
|
||||
|
||||
|
||||
> [!TIP]
|
||||
> Tips：互联网保险知多点
|
||||
> 2C 表示 to customer，即产品是直接面向客户；一般保险公司自己网站直接销售保险产品属于这种类型
|
||||
> 2B 表示 to branch，即产品是直接面向渠道；比如：中介公司、互联网公司都属于渠道
|
||||
> 2A 表示 to agent，即保险代理人；代理人自行拉客户
|
||||
|
||||
《四方保险》项目中功能介绍：
|
||||
|
||||
- 在线购买和投保： 用户可以通过互联网平台方便地浏览、**比较和购买不同保司的各类保险产品**，完成投保流程。
|
||||
- 个性化推荐产品： 平台可能提供根据用户需求定制的保险产品，满足个性化的保险需求。
|
||||
- 数字化保单管理： 用户可以在平台上轻松管理和查看自己的保单信息，包括保单状态、保费支付等。
|
||||
- 在线理赔服务： 提供在线理赔服务，用户可以通过平台提交理赔申请、上传必要的文件和信息，加速理赔流程。
|
||||
- 风险评估和数据分析： 利用大数据和规则引擎技术对用户进行风险评估，提供更精准的保险方案。
|
||||
- 移动端应用支持： 提供移动端应用，方便用户随时随地进行保险业务的管理和操作。
|
||||
- 数字化营销和推广： 利用数字化营销手段，通过社交媒体、搜索引擎等渠道推广保险产品，吸引更多用户。
|
||||
- 合作伙伴关系： 与其他互联网平台、金融机构等建立合作伙伴关系，拓展渠道，提供更全面的保险服务。
|
||||
|
||||
## 1.3、项目演示
|
||||
|
||||
管理端演示地址：[http://sf.mgt.itheima.net/](http://sf.mgt.itheima.net/)
|
||||
|
||||
默认账号：admin@qq.com 密码：pass
|
||||
|
||||
|
||||
|
||||
用户端演示地址：[http://sf.app.itheima.net/](http://sf.app.itheima.net/)
|
||||
|
||||
默认账号：15156403088 默认验证码：123456
|
||||
|
||||
|
||||
|
||||
# 2、项目介绍
|
||||
|
||||
## 2.1、系统架构
|
||||
|
||||
四方保险属于一个保险销售平台；有两个终端：
|
||||
|
||||
- 后台管理端
|
||||
- APP 用户端
|
||||
|
||||
业界同类销售平台（[https://www.zhongmin.cn/](https://www.zhongmin.cn/)）
|
||||
|
||||
整体架构如下：
|
||||
|
||||
|
||||
|
||||
**代理服务：**保险平台和保险销售平台通过的 nginx、gateway 网关
|
||||
|
||||
**路由处理：**gateway 网关负责路由通用服务和业务服务，同时做数据埋点和网关权限校验
|
||||
|
||||
**服务治理：**gateway 网关、通用服务、业务服务、seata 等服务注册和配置都放入 nacos 中统一管理
|
||||
|
||||
**通用服务：**抽离出加密安全、统一鉴权、消息系统、支付结算、配置存储、数据埋点、数字字典等基础微服务
|
||||
|
||||
**基础支持：**在线文档 knife4j、时序数据库 influxDB、redisson 缓存客户端、xxl-job 计划任务、spring-cloud-stream
|
||||
|
||||
**外部服务：**支付宝、微信支付、ocr、三方核保、批单、承保平台
|
||||
|
||||
## 2.2、核心业务
|
||||
|
||||
管理后端的核心流程：
|
||||
|
||||
app 端核心流程：
|
||||
|
||||
## 2.3、课程内容
|
||||
|
||||
- 项目介绍&环境搭建
|
||||
- 保险基础数据管理-分析与设计
|
||||
- 保险产品
|
||||
- 产品附件—对象存储
|
||||
- 产品详情-性能优化与数据脱敏
|
||||
- 投保试算-保障类
|
||||
- 投保试算-理财类
|
||||
- 投保处理-投保处理
|
||||
- 支付处理-一次性支付
|
||||
- 支付处理-周期性扣款
|
||||
- 数据埋点
|
||||
- 数据中心——时序数据库
|
||||
- 短信服务
|
||||
|
||||
# 3、环境搭建
|
||||
|
||||
在了解了系统架构和核心业务流程后；我们把项目跑起来直接运行感受会更加直接。项目的运行需要使用到系列的组件等环境；步骤如下：
|
||||
|
||||
1）导入虚拟机到 vmware；验证各个组件启动情况
|
||||
|
||||
2）IDEA 打开项目并启动；
|
||||
|
||||
3）启动前端应用服务器；
|
||||
|
||||
4）设置系统 hosts 文件中 IP 与域名；
|
||||
|
||||
详细的操作请参考：[第 0 章-环境搭建](https://j1wtmv7ajj.feishu.cn/wiki/FG5AwAXHCivrwskoxTIcQcSfn4e)
|
||||
|
||||
# 4、修复 BUG
|
||||
|
||||
在刚刚进入项目组后，一般不会布置开发任务，而是先熟悉项目代码。为了帮助大家熟悉整个项目，我们预留了个 BUG，让大家在修复 BUG 的过程中熟悉项目代码。
|
||||
|
||||
一般修复 BUG 的过程是这样的:
|
||||
|
||||
- 熟悉项目
|
||||
- 重现 bug
|
||||
- 分析解决
|
||||
- 测试
|
||||
|
||||
因此，解决 BUG 的过程，就是熟悉项目的过程。
|
||||
|
||||
## 4.1、熟悉项目
|
||||
|
||||
熟悉项目的第一步是熟悉项目的结构、用到的技术、编码的一些规范等。
|
||||
|
||||
### 4.1.1、项目结构
|
||||
|
||||
下面我们介绍一下各个模块的主要职能：
|
||||
|
||||
├── sfbx-cloud # 项目模块父工程，统一管理 JAR 版本和插件内容
|
||||
|
||||
│ ├── sfbx-apache-httpclient # 远程调用通信框架（第三方、保司接口调用）
|
||||
|
||||
│ ├── sfbx-dict # 数字字典：其他功能用到的常用字段维护
|
||||
|
||||
│ ├── sfbx-file # 对象存储：支持 OSS、七牛云的文件存储服务
|
||||
|
||||
│ ├── sfbx-framework # 基础支持：缓存、消息中间件、分布式事务、线程池、脱敏、调度等支持
|
||||
|
||||
│ ├── sfbx-gateway # 网关路由：销售端、运营端、接口端网关路由
|
||||
|
||||
│ ├── sfbx-insurance # 保险业务：四方保险主业务服务包括用户端和管理端
|
||||
|
||||
│ ├── sfbx-points # 数据埋点：数据采集、存储、分析
|
||||
|
||||
│ ├── sfbx-rule # 规则引擎：规则引擎的 UI 支持服务
|
||||
|
||||
│ ├── sfbx-security # 权限系统：基于 oauth2.0 的权限管理
|
||||
|
||||
│ ├── sfbx-sms # 短信服务：支持阿里云短信、简单短信、腾讯云短信的短信微服务
|
||||
|
||||
│ ├── sfbx-task # 计划监听：统一调度响应和监听
|
||||
|
||||
│ ├── sfbx-trade # 交易服务：支持支付宝、微信支付的多种场景的支付平台
|
||||
|
||||
> 14 个微服务；我日常开发只需要启动 3-5 个就可以了
|
||||
> 注意：
|
||||
> 一般正式使用和发布的系统；如果所有的微服务加起来，数据库中的表大概 200+
|
||||
> 例如：商城 300 - 500 张表； 四方保险类的大概 300 左右
|
||||
|
||||
### 4.1.2、开发规范
|
||||
|
||||
- 在项目模块中；*-app 的是针对 app 端的应用服务；*-mgt 的是针对 web 后台管理的应用服务；
|
||||
- 项目中带有 *-interface 的模块是 feign 客户端放置的模块工程；而应用到的 dto 放置在 `framework-commons` 模块中，该模块中的实体类以* VO 结尾命名；
|
||||
- 有需要使用到其它微服务提供的接口的话就引入对应的 *-interface 即可；
|
||||
- 一般项目中，如 insurance-mgt 的 feign 包内的相当于当前服务中某些业务对外提供的接口功能（不是接口类）；这些对外业务接口处理器的请求路径命名一般为 *-feign
|
||||
|
||||
|
||||
|
||||
### 4.1.3、配置文件
|
||||
|
||||
四方保险的项目公共配置项目全部都由 nacos 管理；所以在每个项目中会有一个 bootstrap.yml 的启动配置文件。这个文件几乎不需要修改，只保留了最基础的内容；而对应项目需要使用到的公共组件或配置都在这个配置文件中引入了，要修改的话需要到 `nacos` 的配置中找对应的配置项修改即可。
|
||||
|
||||
|
||||
|
||||
## 4.2、复现 BUG
|
||||
|
||||
1）访问 [http://sf.app.itheima.net/#/pages/login/login](http://sf.app.itheima.net/#/pages/login/login) 点击 `注册`
|
||||
|
||||
2）注册新账号之后，使用新账号登录 [http://sf.app.itheima.net/#/pages/login/login](http://sf.app.itheima.net/#/pages/login/login)
|
||||
|
||||
3）任意查看一个保险产品；如：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在上述的 `为谁买` 填写了 姓名、身份证号码 之后；点击 `保存` 。
|
||||
|
||||
> 注意；不用点击 我要投保
|
||||
|
||||
4）返回到首页——》再次找任意一个产品；产品详情页面中发现刚刚填写的 `本人` 信息还是空。
|
||||
|
||||
|
||||
|
||||
## 4.3、修复 BUG
|
||||
|
||||
### 4.3.1、分析
|
||||
|
||||
如果是我们自己写的代码，肯定很容易找到业务入口、整个业务线路。但现在我们是接手他人项目，所以只能通过其它途径来梳理业务:
|
||||
|
||||
- 1)如果开发业务的同事还在，直接与开发该业务的同事交流
|
||||
- 2)如果开发者已离职，可以查看相关接口文档
|
||||
- 3)如果没有文档，也可以查看前端请求，顺藤摸瓜
|
||||
|
||||
此处由于我们没有人可以交流，只能通过查看前端请求来分析了。
|
||||
|
||||
#### 1）保存
|
||||
|
||||
|
||||
|
||||
上述的 保存 的时候；使用浏览器查看其请求地址如下：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
按照之前我们的环境部署方案，sf.app.itheima.net 这个域名会被解析到 `127.0.0.1` 这个地址，然后被 Nginx 反向代理到网关微服务。
|
||||
|
||||
而网关则会根据请求路径和路由规则，把请求再路由到具体微服务。这里请求路径以 `/api/insurance-app` 开头，对应的微服务是 `insurance-app`，也就是保险 app 端微服务。
|
||||
|
||||
这样，整个请求链路就比较清楚了：
|
||||
|
||||
找到了具体的微服务，接下来，我们就进入微服务，查看对应源码，找出问题即可。
|
||||
|
||||
请求到达保险 app 服务后的路径是 ` ``/insurance-app/mine-home/customer-relation`，对应的 `controller` 是：
|
||||
|
||||
|
||||
|
||||
跟入 service 代码；发现是比较正常的，保存也没有报错；但是为何再次返回详情页面的时候没有查到呢？
|
||||
|
||||
接下来；我们看在详情页面的时候；它是怎么查的。
|
||||
|
||||
#### 2）详情页面查询
|
||||
|
||||
还是在 app 端；点击产品后跳转到的详情页面；发现有如下的请求：
|
||||
|
||||
|
||||
|
||||
尝试测试之后；只有在返回的数据中 relation 字段的值为 0 的情况下；才会回显。而提交的时候是 u。
|
||||
|
||||
说明前端在上述的请求返回数据之后；根据返回的对象的 relation 的值进行了过滤显示。relation 属性的值必须要为 0 。
|
||||
|
||||
### 4.3.2、修复
|
||||
|
||||
已经分析问题：
|
||||
|
||||
- 1、在用户注册的时候；携带的状态为 `u` 保存到了 `sfbx-insurance.tab_customer_relation` 数据库表中
|
||||
- 2、而查询的时候，回显的时候；前端中对 relation 的值为 `0` 才会回显；
|
||||
|
||||
解决方法：
|
||||
|
||||
找到注册时候；保存的业务代码，在前端不配合或者不便于修改的情况下；我们在保存的业务代码中，将 `u` 替换为 `0` 即可
|
||||
|
||||
修改如下：
|
||||
|
||||
|
||||
|
||||
再次进行测试即可。
|
||||
|
||||
# 5、数据库建模-Power Designer
|
||||
|
||||
在需求分析之后；需要进行数据库表的创建，如果系统功能模块多，也就是数据库表多；逐个表创建不太现实，而且表之间的关系不那么明显能看出。**通过数据库建模可以更加从整体上查看对于需求的理解是否到位；数据库表设计是否存在问题。**
|
||||
|
||||
在更加规范或者正式的单位、机构他们要求项目验收需要对应的数据库建模文档；
|
||||
|
||||
- **常见的模型**
|
||||
|
||||
- 概念模型 CDM
|
||||
- 物理模型 PDM
|
||||
- **常见的设计工具**
|
||||
|
||||
- **Power Designer**
|
||||
- pdman
|
||||
|
||||
## 5.**1、概念模型 CDM**
|
||||
|
||||
- **为什么？**
|
||||
|
||||
> 在需求、产品原型评审之后，可以通过图形的方式更加直观的了解是否对需求理解到位。还可以对后续的开发做出引导。
|
||||
> 在做需求分析的过程中；常常看到很多要实现的模块，这些模块或者功能基本上都是要处理的实体（名词；领域模型）。例如：在原型或者需求文档中的 xx 管理；xx 一般就是实体；系统中这些实体之间是有关系的，开发与其息息相关。；由这些领域模型画出来的图就是概念模型，也被称为 **ER 图**
|
||||
> 在实际开发中；一开始立项的时候是不知道使用哪款 DBMS（Oracle/DB2/Sybase/SQL Server/MySQL）的；所以不能直接基于某一款数据库创建对应的建表语句。可以先创建概念模型，一旦定下来 DBMS 则可以直接转换。
|
||||
|
||||
- **是什么**
|
||||
|
||||
用于描述**实体与实体之间的关系的****图形**；也被业界称为 `ER图`
|
||||
|
||||
- **怎么画**（9 字诀）
|
||||
**1、****列实体**
|
||||
|
||||
- 将原型、需求中的那些实体（名词、领域模型）先列出来；在原型中常见的有模块名称、下拉框（内容是变化的）。
|
||||
- 例如：产品
|
||||
**2、****填属性**
|
||||
根据原型、需求文档中对于上述列出的实体设置属性；做法就是结合**输入**和**输出**的综合。（输入：新增、添加 等按钮之后的页面；输出；列表、详情页）
|
||||
- 例如：产品（<u>ID</u>，保险代码，名称，类型 ID，排序，状态，创建时间...）
|
||||
|
||||
**3、****画关系**
|
||||
要将需求中实体之间的关系画出来；常见的关系：
|
||||
|
||||
## 5.2**、物理模型 PDM**
|
||||
|
||||
- **为什么？**
|
||||
|
||||
可以通过物理模型 PDM **直接创建整个数据库的表及其关系**。创建数据库及表的时候使用 pdm 非常方便。
|
||||
|
||||
如果已经确定使用哪种 DBMS 之后或者数据库表设计比较特殊，那么也可以直接画 PDM 而不画 CDM。
|
||||
|
||||
- **是什么**
|
||||
|
||||
是一个**描述表与表之间关系的图形**。可以通过该图形直接获得整个库的 sql 语句。
|
||||
|
||||
- **怎么画**
|
||||
|
||||
在确定了客户使用哪种 DBMS 之后；可以通过 CDM 直接转换为 PDM。
|
||||
|
||||
也很多公司，开发之初就确定使用哪款 DBMS 了；所以可以跳过概念模型直接创建物理模型。
|
||||
|
||||
## 5.3**、案例**
|
||||
|
||||
**需求**：将人员组织架构的 CDM 画出来。
|
||||
|
||||
人员组织架构：用于管理人员的系统；里面会涉及到：机构、部门、角色、权限、人员
|
||||
|
||||
**1、列实体**
|
||||
|
||||
- 机构、部门、角色、权限、人员
|
||||
|
||||
**2、填属性----》（基础，关联，辅助）**
|
||||
|
||||
- 机构（机构 ID，名称，状态）
|
||||
- 部门（部门 ID，名称，状态）
|
||||
- 角色（角色 ID，名称，状态）
|
||||
- 权限（权限 ID，名称，状态）
|
||||
- 人员（人员 ID，姓名，性别，... 状态）
|
||||
|
||||
**3、画关系**
|
||||
|
||||
- 一个机构可以有多个部门；——》一对多
|
||||
- 一个部门下可以有多个人员；——》一对多
|
||||
- 一个角色可以有多个权限；一个权限可以被多个角色使用 ——》多对多
|
||||
- 一个人可以有多个角色；一个角色可以被多个人使用 ——》多对多
|
||||
|
||||
## 5.4、PD 画图
|
||||
|
||||
### 5.4.1、pd 设置
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
设置概念模型中可以使用同一个字段名字：
|
||||
|
||||
|
||||
|
||||
### 5.4.2、模型
|
||||
|
||||
概念模型
|
||||
|
||||
|
||||
|
||||
物理模型
|
||||
|
||||
|
||||
|
||||
## 5.5、误区
|
||||
|
||||
|
||||
|
||||
> **思考**：数据库表范式
|
||||
> 越符合范式则说明连接的表越多，查询效率就相应的低
|
||||
> 并不是范式越高性能越好的；而且一般反范式反而数据库表查询性能好
|
||||
|
||||
# 6、作业
|
||||
|
||||
访问 [http://sf.mgt.itheima.net/#/base/type](http://sf.mgt.itheima.net/#/base/type)
|
||||
|
||||
分析：筛选、保障项、系数、分类这四类数据的关系。
|
||||
|
||||
保险-基础数据。通过基础数据功能的学习我们主要解决下列问题：
|
||||
|
||||
- 什么是基础数据，包含哪些，分表有什么作用？
|
||||
- 基础数据的表结构如何设计进行设计？
|
||||
- 分类项与保障项、系数项、筛选项有什么关系？
|
||||
|
||||
|
||||
|
||||
上图是用户端功能截图，从中我们提炼并定义下列 4 个名词：
|
||||
|
||||
- **保障项：**通常是指在购买保险时所包含的具体风险或事件，以及在这些风险或事件发生时，保险公司愿意提供的经济赔偿或保障。不同类型的保险产品涵盖不同的保障项
|
||||
- **系数项：**通常是指一系列用于计算保险费率的因子或系数。这些因子可以包括被保险人的年龄、性别、健康状况、驾驶记录、保险类型、地理位置等，它们会影响最终的保险费率计算。
|
||||
- **筛选项：**通常是指一系列因素和选项，需要根据你的具体需求和情况来考虑，来选择自己需要的保险服务。
|
||||
- **分类项：**通常是指保险根据不同的标准和覆盖范围进行的分类，不同的分类涵盖的方面不同，此处我们主要讨论下列几类保险：医疗、重疾、意外、养老金、旅游等分类
|
||||
|
||||
> [!TIP]
|
||||
> Tips:
|
||||
> 结合 app 端的界面分析；从分类开始分析起
|
||||
|
||||
# 7、午间问题
|
||||
|
||||
- 你们与保险公司有什么关系
|
||||
- 为什么到你们平台来购买保险？直接到保险公司对应的 app 上买不是更好吗？
|
||||
- 你们常卖的保险有哪些类型
|
||||
- 描述一下系统的技术架构
|
||||
- 说一下你们开发团队情况
|
||||
- 介绍一下你们项目的集群部署情况？有几个微服务；你开发的话要启动几个微服务
|
||||
- 面试：介绍一下你简历中写的保险项目
|
||||
|
||||
- 是什么、做什么的
|
||||
- 有什么功能
|
||||
- 技术栈
|
||||
|
||||
Reference in New Issue
Block a user