doc/me
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

更新 README.md

Browse Source
This commit is contained in:
8ga
2026-04-15 14:32:14 +08:00
parent 0c208bf4fb
commit b67b96f2d7
1 changed files with 9 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
README.md
View File

@@ -47,16 +47,15 @@
## 蜂羽（2019/07 ~ 2023/05） ## 蜂羽（2019/07 ~ 2023/05）
- 技术栈：Java 8、MySQL、Redis、RocketMQ、Seata、Spring Boot、Spring Cloud、Skywalking、OTel、Spring Boot Actuator、Prometheus、Grafana - 技术栈：Java 8、MySQL、Redis、RocketMQ、Seata、Spring Boot、Spring Cloud、Skywalking、OTel、Spring Boot Actuator、Prometheus、Grafana
- 职责： - 日常迭代需求评审、编写技术方案文档、服务巡检、跟踪并修复生产环境中的问题、不定期组织技术分享会。
- 日常迭代需求评审、编写技术方案文档、服务巡检、跟踪并修复生产环境中的问题、不定期组织技术分享会。 - **架构重构，Spring MVC -> Spring Cloud**：第一版项目源码来自外包公司，随着团队成员增加、系统请求量攀升，单体架构的运维成本开始抬升，也不能满足更高效的团队协作。与领导协商后决定花3个月的时间，一边继续业务迭代，一边重构成 Spring Cloud 微服务架构，最终拆成了8个微服务，并完成了前后端分离。
- **架构重构，Spring MVC -> Spring Cloud**：第一版项目源码来自外包公司，随着团队成员增加、系统请求量攀升，单体架构的运维成本开始抬升，也不能满足更高效的团队协作。与领导协商后决定花3个月的时间，一边继续业务迭代，一边重构成 Spring Cloud 微服务架构，最终拆成了8个微服务，并完成了前后端分离。 - **微服务网关**：使用 zuul 1.x、Nacos 实现请求路由、负载均衡，每个服务的负载均衡算法插件化，适应灵活多变的业务需求。
- **微服务网关**：使用 zuul 1.x、Nacos 实现请求路由、负载均衡，每个服务的负载均衡算法插件化，适应灵活多变的业务需求。 - **统一登录/认证服务**：短信验证码、账号密码注册/登录，为网关提供鉴权服务，每个微服务的权限验证机制，仍然插件化。
- **统一登录/认证服务**：短信验证码、账号密码注册/登录，为网关提供鉴权服务，每个微服务的权限验证机制，仍然插件化。 - **身份认证服务**：对接上上签、E签宝开放平台的人脸识别、实名信息验证、企业信息验证等能力，对接2个供应商是防止其中1个供应商因系统升级或不可抗力因素造成服务中断，支持故障自动切换或强制切换。将多个外部平台 API 收敛成一套内部 API，提供一个 starter 方便业务域的微服务快速接入相关能力。
- **身份认证服务**：对接上上签、E签宝开放平台的人脸识别、实名信息验证、企业信息验证等能力，对接2个供应商是防止其中1个供应商因系统升级或不可抗力因素造成服务中断，支持故障自动切换或强制切换。将多个外部平台 API 收敛成一套内部 API，提供一个 starter 方便业务域的微服务快速接入相关能力。 - **分布式事务**：随着微服务之间跨服务调用，不可避免的出现了多个服务之间事务一致性的问题，引入 Seata（AT模式）提供分布式事务强一致性的能力。但是 AT 模式的并发度太低，在请求量较大且无法限流的情况下（比如订单支付）同时采用 RocketMQ 的柔性事务方案，提高吞吐量。
- **分布式事务**：随着微服务之间跨服务调用，不可避免的出现了多个服务之间事务一致性的问题，引入 Seata（AT模式）提供分布式事务强一致性的能力。但是 AT 模式的并发度太低，在请求量较大且无法限流的情况下（比如订单支付）同时采用 RocketMQ 的柔性事务方案，提高吞吐量。 - **监控、告警系统**：随着架构变得复杂，排查问题越来越费时间，所以研究了一下 Skywalking、OTel、Spring Boot Actuator、Prometheus、Grafana 相关中间件，监测每个HTTP端点的请求量、最长耗时、内存与CPU占用、通过 Skywalking 的一系列探针，观测每个HTTP端点的耗时情况，包括跨服务调用、JDBC等耗时。除了收集数据，还做了达到阈值自动告警的能力，例如：当某个HTTP请求耗时超过5s，通过钉钉群聊机器人发送一条消息并@负责人，每个微服务都会登记负责人、至少2个人，方便相关研发团队及时响应并优化问题。
- **监控、告警系统**：随着架构变得复杂，排查问题越来越费时间，所以研究了一下 Skywalking、OTel、Spring Boot Actuator、Prometheus、Grafana 相关中间件，监测每个HTTP端点的请求量、最长耗时、内存与CPU占用、通过 Skywalking 的一系列探针，观测每个HTTP端点的耗时情况，包括跨服务调用、JDBC等耗时。除了收集数据，还做了达到阈值自动告警的能力，例如：当某个HTTP请求耗时超过5s，通过钉钉群聊机器人发送一条消息并@负责人，每个微服务都会登记负责人、至少2个人，方便相关研发团队及时响应并优化问题。 - **下载中心**：系统用户经常在月底导出 Excel 报表满足对账等需求，服务器内存是有限的，直接限流的话用户体现很差，所以做了一个集中管理的下载中心。业务服务把导出的 HTTP 请求端点添加到下载中心，下载中心会分配一个唯一标识。前端在导出 excel 的功能，不直接请求业务系统，而是携带唯一标识、相关参数请求至下载中心。下载中心会创建一个下载任务，并通过线程池异步处理，处理完以后更新任务状态，把 excel 上传到 oss 生成一个有效期7天的下载链接。线程池的队列就是最大吞吐量，用户提交下载任务后，只是等待时间变长一点，最终一定会下载成功，也保障了业务服务的健康。
- **下载中心**：系统用户经常在月底导出 Excel 报表满足对账等需求，服务器内存是有限的，直接限流的话用户体现很差，所以做了一个集中管理的下载中心。业务服务把导出的 HTTP 请求端点添加到下载中心，下载中心会分配一个唯一标识。前端在导出 excel 的功能，不直接请求业务系统，而是携带唯一标识、相关参数请求至下载中心。下载中心会创建一个下载任务，并通过线程池异步处理，处理完以后更新任务状态，把 excel 上传到 oss 生成一个有效期7天的下载链接。线程池的队列就是最大吞吐量，用户提交下载任务后，只是等待时间变长一点，最终一定会下载成功，也保障了业务服务的健康。
## SmartCC外呼中心（2017/05 ~ 2019/06） ## SmartCC外呼中心（2017/05 ~ 2019/06）