1. 业务上：网关的过滤规则、断言规则后台管理，支持策略多版本发布，新版本上线后不会立刻删掉旧版本，会保留一段时间，因为车主在路上正在导航，不能直接切版本，避免导航异常；用逻辑删除字段做版本区分。
2. 技术实现：SpringBoot + MyBatis + MySQL 存全量配置，Redis 做热点缓存，用 Hash 存单版本完整规则，List 用来管理版本排序；
3. 自研模块：定时任务，一是控制旧版本延时下线；二是心跳检测，定时探测网关服务可用性，服务失联自动发邮件告警；
4. 日常工作：需求评审、接口开发、版本发布、线上故障排查、缓存问题优化，保障车端导航网关高可用。
独立负责车载导航网关配置管理后端模块开发，技术栈 SpringBoot + MyBatis + MySQL + Redis + Nacos，服务容器化打包为镜像，基于 Docker、K8s 滚动部署。
服务面向车机导航场景，核心负责网关过滤规则、断言路由规则管理，支持多版本规则并存；通过逻辑删除字段区分新旧版本，版本发布后不会立即下线旧规则，设置过渡期平滑切换，避免行车途中导航规则突变引发故障。
采用 Redis Hash 存储各版本完整路由配置，加速读取；早期使用 List 维护版本列表，因 List 仅保证插入顺序、无法按版本号排序引发线上读取旧规则问题，优化为 ZSet，以版本号作为分数实现有序管理。
依托 Nacos 实现服务注册发现与统一配置中心，结合 `@RefreshScope` 支持配置热更新，无需重启服务。开发两套定时任务：到期自动下线过期旧版本规则、网关心跳健康检测，服务异常时自动邮件告警。
参与需求评审、接口设计、编码开发、上线发布及线上问题复盘；编写 Dockerfile 构建镜像，配合运维完成 K8s 滚动发布，通过 Pod 日志定位启动、配置加载类线上故障。
我独立负责车载导航网关配置管理后端模块开发，技术栈是 SpringBoot + MyBatis + MySQL + Redis + Nacos，项目打包成镜像，部署在 Docker 和 K8s 上。
这个服务是给车机导航用的，主要管理网关的过滤规则、断言路由规则。支持多个版本的规则同时存在，用表里面的逻辑删除字段区分新版本和旧版本。
新版本推上去之后不会立刻把旧版本删掉下线，因为车主正在开车、正在用导航，如果突然换规则，导航就会出问题，所以要留一段时间慢慢过渡。
我用 Redis 的 Hash 结构存每一个版本完整的过滤、断言配置，加快读取速度。最开始用 Redis List 存版本列表，踩了一个线上坑：List 只保证插入先后顺序，不是按版本号大小排序，导致有时候读到旧的错误规则。优化方案是换成 ZSet，拿版本号当分数自动排序。
用 Nacos 做服务注册发现和统一配置管理，加上 @RefreshScope 可以做到配置改了不用重启服务。
我写了两个定时任务：第一个定时任务，到时间自动下线旧版本；第二个定时任务是心跳检测，隔一段时间探测网关服务还能不能用，如果挂了，自动发邮件告警。
平时我做需求评审、设计接口、写代码、上线发布、线上问题排查复盘。发布的时候写 Dockerfile 打包镜像，配合运维在 K8s 做滚动发布，出问题我就看 Pod 日志排查启动、配置加载的问题。
评论