某人事系统架构搭建设计记录

首发博客地址

https://blog.zysicyj.top/

先大致列一下基础情况

• 架构必须是微服务
• 场景上涉及大量查询操作，分析操作
• 存在临时大量写入的场景
• 并发并不高
• 对高可用要求较高，不能挂掉
• 对安全要求高
• 要能过等保测试等三方测试
• 使用人数并不多，十万内
• 涉及很多在线编辑，预览等操作
• 对大屏展示有需求
• 数据库还不确定，如果要求高的话mysql必须换成达梦
• 中间件也不确定，要求高的话必须换成东方通
• 加密必须是国密

前言

好的代码，肯定最基本的有一套开发规范去约束的，不然堆砌的代码肯定成”屎山“。扩展性，性能啥的先不谈，单单维护代码成本就会很高，也很容易出BUG。

所以呀，我们必须先有一套开发规范，我这里拟了一套规范供内部使用：

1. MySQL开发规范
2. 后台开发规范
3. 前端开发规范
4. 代码提交规范

架构

这里微服务框架我推荐直接使用Spring Cloud Alibaba体系组件，原因如下：

1. Spring Cloud Alibaba 已经是国内实际上微服务标准
2. 服务于阿里集团大大小小各种业务，生产使用稳定
3. 社区庞大，遇到问题容易解决
4. 文档齐全，中文文档详细，方便查阅
5. 与 Spring Cloud 集成，可以充分使用 Spring Cloud 特性
6. 组件丰富

系统架构图

高清大图地址：https://www.processon.com/view/link/64ef11baa8c890267a8a023d

聊聊组件选型

那么，具体我们需要哪些组件呢？这里的组件并不是必须的，需要后续综合考虑

1. ES：数据检索
2. Redis：缓存
3. JetCache：多级缓存
4. MySQL，如果有国产化需求，考虑 达梦数据库
5. Druid：数据源管理框架
6. ShardingSphere：对数据库进行增强，比如 分库分表，加密的支持
7. Minio：文件存储
8. Seata：分布式事务
9. Spring Cloud Gateway：由于并发量并不大，所以我们可以不需要 Nginx网关
10. Sentinel: 熔断限流
11. Spring Cloud Alibaba Sidecar：项目中很有可能涉及其他非 Spring Cloud 应用，此时就需要将其接入 Spring Cloud
12. 引入 GraalVM，可以看到，对比 JVM 启动速度提升
13. JimuReport+EasyExcel：报表设计
14. KkFileView：在线预览各种文件
15. Activity：工作流支持
16. Hutool：最全工具类库
17. Nacos：服务注册和配置中心
18. RocketMQ：消息队列，削峰填谷
19. Docker：使用 Docker 进行容器化部署
20. GitLab：源码管理
21. Nexus：构建仓库
22. Jenkins：部署平台
23. SkyWalking：链路追踪
24. SaToken 或 Spring Cloud Security+Oauth：授权
25. Leaf：分布式 ID 生成器
26. MybatisFlex：ORM 框架
27. Dubbo 或 Feign：服务间通信

一些细节

再次声明一点，业务上是读多写少，分析报表多，所以很多设计上要优化

• MySQL：读写分离，分库分表
• Redis：主从从架构，哨兵集群
• 项目使用多级缓存
• 数据国密加密
• 账号最小权限分配，严格限制超级管理员账号
• 统一线程池使用

打任务量导入导出

• 通过优化线程池提高效率
• 通过逻辑过滤重复任务
• 使用消息队列削峰
• 使用缓存优化查询速度

查询流程

1. 客户端发送请求
2. 前端请求加密
3. 请求发送到网关
4. 网关校验请求合法性
5. 网关根据路由规则转发到具体的服务器上处理
6. 服务器解密请求数据
7. 查询本地缓存
8. 若无则查询 Redis
9. 若无则进行业务流转，最终查询 MySQL
10. 根据路由规则，查询只读 MySQL 节点并返回数据
11. 数据本地缓存，然后 Redis 缓存
12. 返回响应数据
13. 对响应加密，转发到网关
14. 网关转发给客户端
15. 客户端解密，展示数据

部署流程

开发环境

1. 开发提交代码
2. 基于 GitLab CI/CD 自动拉取代码生成 Docker 镜像并提供服务

测试环境

1. 合并代码到测试分支
2. 基于 GitLab CI/CD 自动拉取代码生成 Docker 镜像并提供服务

生产环境

1. 合并代码到生产分支
2. 基于 GitLab，手动用 Jenkins 部署项目

详细部署策略

如果中台能提供，那肯定是最好的，不用考虑那么多了

现在假设有10台服务器

1. 服务器1和服务器2：MySQL数据库服务器，部署主从复制架构。

   • 服务器1作为主数据库（Master），负责写入操作和部分读取操作。
   • 服务器2作为从数据库（Slave），负责复制主数据库的数据，并提供读取操作，实现读写分离。
   • 主从复制可以提高数据库的可用性和性能，当主数据库出现故障时，可以快速切换到从数据库。

2. 服务器3和服务器4：Redis缓存服务器，部署主从架构。

   • 服务器3作为主节点（Master），负责处理写入和读取操作。
   • 服务器4作为从节点（Slave），复制主节点的数据，并提供读取操作。
   • Redis主从架构可以提高缓存的可用性和读取性能。

3. 服务器5：Minio文件存储服务器，用于存储上传的文件。

   • Minio是一个开源的对象存储服务器，提供高可用性和可扩展性的存储解决方案。

4. 服务器6和服务器7：Nacos服务注册和配置中心，用于服务的注册和配置管理。

   • Nacos提供了服务注册、发现和配置管理的功能，支持高可用和可靠的服务部署。

5. 服务器8：RocketMQ消息队列服务器，用于削峰填谷，异步处理导入任务。

   • RocketMQ提供了高吞吐量、低延迟的消息传递能力，可以将导入任务放入消息队列中，由异步消费者进行处理。

6. 服务器9和服务器10：用于部署应用程序和其他中间件，如Spring Cloud Gateway、Sentinel、SkyWalking等。

   • 这些服务器用于部署应用程序和其他中间件，如API网关、熔断限流、链路追踪等，提供服务的访问和监控。

将MySQL数据库和Redis缓存部署为主从架构的原因如下：

1. 高可用性：主从复制可以提供故障容错能力，当主节点出现故障时，可以快速切换到从节点，保证服务的连续性和可用性。
2. 读写分离：通过将读操作分发到从节点，可以减轻主节点的负载，提高数据库的读取性能。同时，从节点的复制过程对主节点的影响较小，不会对主节点的写入操作产生影响。

本文由 mdnice 多平台发布