更新 README.md
This commit is contained in:
17
README.md
17
README.md
@@ -48,15 +48,14 @@
|
|||||||
## 蜂羽(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)
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user