SpringBoot+Vue+SpringCloud微服务架构的日程签到系统实战解析

公司的办公系统用着用着就卡死，一到月初月末考勤统计能把后台跑挂，领导要个临时排班调整，开发改完代码还得连夜发版——这套路我太熟了。后来我们决定把员工日程安排和签到系统彻底重构，技术选型从单体SpringBoot换成了微服务分布式架构，前端用Vue，后端用SpringCloud全家桶，做出来的这套办公自动化管理系统，现在支撑公司旗下好几个园区的日常办公流转，每天上万人次访问都稳得很。这篇就完整记录一下这个SpringBoot+Vue+SpringCloud微服务架构的日程签到系统，从架构设计、服务拆分、核心业务落地到部署排查的全过程。

这套系统解决的核心问题很清楚：员工日程安排（会议、任务、个人备忘）和上下班签到（定位、打卡、统计），同时要满足OA系统最基本的组织架构和权限管理需求。项目拆成了用户、日程、签到、通知、网关等多个独立服务，配合Nacos注册发现、Redis分布式缓存与分布式锁、Seata分布式事务、Sentinel熔断降级，前端Vue3做成了多端适配的页面。如果你正在纠结微服务项目怎么拆服务、SpringCloud各组件怎么配，或者OA类系统的日程和签到业务有哪些坑，这篇文章值得花十分钟看完。

1. 项目定位：为什么日程签到系统非要走微服务

1.1 老老实实先聊清楚业务边界

先别急着堆技术栈。做微服务最忌讳的就是为了分布式而分布式。我当时接这个项目时，第一件事不是画架构图，而是跟在行政部和HR后面跑了整整三天，把业务场景一条条捋出来。这个日程签到系统看起来简单，拆开看其实是四个相对独立的业务域：

• 日程域：员工创建日程、会议邀请、日程提醒、日程冲突检测、日程共享与授权，这个域的特点是读写频繁，但与考勤没有强耦合关系。
• 签到域：上班打卡、下班签退、外勤签到、位置校验、迟到早退统计、考勤报表。这个域的特点是并发集中（早上九点前后是峰值），对时间和位置数据敏感。
• 组织与用户域：员工账号、部门结构、角色权限、审批关系。这个域是所有业务的基础底座，但变更频率很低。
• 通知域：日程提醒推送、签到异常提醒、审批通知。这个域本质上是异步消息的消费和投递。

这四个业务域如果塞进一个单体SpringBoot应用里，短期内没有任何问题，甚至部署更简单。但真正的痛点出现在业务量和组织复杂度上来之后：早晚高峰签到接口和日常的日程读写挤在同一个进程里，高峰期考勤接口响应变慢会拖累所有人查日程；权限模型升级时，签到逻辑也跟着被迫回归测试；哪天真要把签到模块单独扩容做异地多活，单体应用基本无从下手。

所以，微服务的拆分逻辑不是看代码量，而是看业务域的独立性和扩展需求。日程和签到虽然都在同一个系统里服务员工，但它们的访问模式、存储需求、扩展方向完全不一样。拿签到来说，早晚打卡就是典型的“高并发短事务”，而日程是典型的“低频长事务”。这两类业务放在同一个数据库、同一个服务进程里，相互拖累是必然的。

1.2 微服务架构图与核心组件选型思路

选型之前我做了个技术对比表，直接把候选方案拍在桌面上聊。服务注册与配置中心我们选了Nacos而不是Eureka+SpringCloud Config的组合，原因有三个：第一，Nacos把注册中心和配置中心合并了，少维护一套组件；第二，Nacos 2.x版本支持gRPC长连接，服务发现推送的实时性比Eureka的客户端轮询好很多；第三，Nacos自带控制台，配置的发布、回滚、灰度在页面上就能做，运维省事。

网关选了Spring Cloud Gateway而不是Zuul，主要考虑到Gateway基于WebFlux响应式编程模型，性能和内存占用明显优于Zuul 1.x的Servlet模型，而且Spring Cloud官方对Gateway的维护力度也更大。远程调用统一用OpenFeign，服务间HTTP调用声明式写接口，代码可读性好。熔断和限流选Sentinel，因为它的控制台是可视化的，规则可以用Nacos持久化，改限流阈值不用重启服务。分布式事务选了Seata的AT模式，这个后面第三章细讲。

举一个实际场景说明这个架构怎么玩游戏：员工早上到了公司，微信端打开签到页面，前端请求通过Nginx到了Gateway网关，网关做JWT令牌校验，再把请求路由到签到服务的某个实例。签到服务先查Redis判断这个员工今天有没有已经签到过（防重复），再调用户服务拿到员工绑定的考勤地点和设备信息，做打卡位置校验，最后写入PostgreSQL并异步发一条签到成功消息给通知服务，通知服务推送站内信。整个链路走下来，签到请求200毫秒以内返回。员工打开日程页面的时候，完全是另一条链路，彼此不干扰。

这里还要补一句：服务拆分别一步到位，我们第一版拆分的时候保留了用户服务的用户表和日程表在一个物理库里（分schema），签到独立一个库，通知服务只连Redis和消息队列。后来流量上来了，才把用户服务和日程服务的库也拆了。技术规划要提前做，但物理拆分可以分批做，步子太大容易扯着蛋。

1.3 单体架构到微服务架构的迁移策略

如果是旧系统改造，别想着直接推倒重来。我们的迁移策略是“绞杀者模式”：老的单体SpringBoot应用先继续跑，新功能按微服务的方式开发和上线。比如外勤签到这个新需求出来的时候，我们不改老系统的考勤模块，直接新建一个attendance-service，老系统里的用户登录认证逻辑通过OpenFeign调用新服务的接口来复用。

迁移过程中的数据一致性是最大的坑。老系统用户表里有一个字段是部门路径字符串，新服务却要做成部门表加层级关系。如果新老服务各写各的，数据同步就乱套。我们的做法是在新服务里建好新表结构，写一个数据迁移组件，每天凌晨从老库全量同步增量更新。切流的时候先切读流量，线上对比一周，再切写流量。宁可多花两周灰度时间，也别拿全公司员工的考勤数据开玩笑。

2. 后端微服务拆分与SpringCloud组件落地

2.1 服务拆分清单与数据库独立策略

服务清单和职责边界如下表所示，这个表也是我每次和团队新人对齐需求的基准：

每个服务的数据库完全独立，服务之间禁止绕过API直接连别人的库。这一点是微服务的铁律，但在实际项目中总有人图方便去跨库join查询。我们通过代码评审和数据库账号权限双重卡控：每个服务只分配自己库的读写账号，别的库的IP白名单也不放行。宁可多写几个Feign调用组合数据，也不破坏服务边界。

2.2 Nacos注册中心与配置中心的最佳实践

Nacos部署我们用的是集群模式，三台机器，MySQL作为Nacos的存储后端。这里提醒一个坑：Nacos 2.x默认会开启gRPC服务端口（9529），这个端口必须和Nacos主端口（8848）一起放通，否则服务注册会时好时坏，我排查过好几个“服务找不到实例”的问题都是因为这个。

配置管理方面，我们把所有服务共用的配置放到共享配置里（比如Redis地址、MySQL连接池大小、日志级别），每个服务独有的配置放在服务配置里。配置文件的Data ID命名规则是：{service-name}-{profile}.yaml，例如attendance-service-prod.yaml。发布配置时走Nacos控制台的“历史版本”功能，出问题可以一键回滚。

关键的一点是，热加载不要无脑用。@RefreshScope注解可以让配置动态刷新，但数据库连接池、Redis连接池这种初始化成本高的Bean，热刷新容易出问题。我们只对开关类配置（比如功能开关、限流阈值、灰度比例）做动态刷新，连接池参数改了就直接重启服务。

2.3 OpenFeign远程调用与Sentinel熔断降级

服务间调用统一走OpenFeign，代码示例如下：

java复制@FeignClient(name = "user-service", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {

    @GetMapping("/user/info/{userId}")
    Result<UserInfoDTO> getUserInfo(@PathVariable("userId") Long userId);
    
    @PostMapping("/user/batch")
    Result<List<UserInfoDTO>> batchGetUsers(@RequestBody List<Long> userIds);
}

OpenFeign配置里最容易被忽略的是超时时间和连接池。默认的connectTimeout只有10秒，readTimeout是60秒，而且没有连接池，每次请求都新建连接。我们实际配置如下：

yaml复制feign:
  client:
    config:
      default:
        connectTimeout: 3000
        readTimeout: 10000
  httpclient:
    enabled: true
    max-connections: 500
    max-connections-per-route: 100

这里特别说明一下fallbackFactory和fallback的区别：fallbackFactory能拿到具体异常，方便做降级日志记录，比fallback好用得多。降级逻辑里我习惯返回一个默认值或者空对象，然后异步记录一条降级日志，后续通过日志分析发现哪些接口依赖不稳定。

Sentinel的规则我们用Nacos持久化。核心规则就几条：签到接口/attendance/checkin设置QPS限流，单机阈值100；网关层对每个用户设置一分钟内最大请求数；Feign调用用户服务设置熔断规则，当异常比例超过50%时熔断10秒。熔断降级比无限重试更有意义——服务已经扛不住了，重试只会加剧雪崩。

2.4 网关统一认证与动态路由

网关是流量的唯一入口，我们所有请求都走/api/{service}/{path}的路径格式转发。JWT校验放在网关的全局Filter里，只做两件事：验证token签名和有效期，然后解析出用户ID和角色放进请求头，下游服务通过X-User-Id头拿到当前用户信息。

yaml复制spring:
  cloud:
    gateway:
      routes:
        - id: attendance-service
          uri: lb://attendance-service
          predicates:
            - Path=/api/attendance/**
          filters:
            - StripPrefix=2
        - id: schedule-service
          uri: lb://schedule-service
          predicates:
            - Path=/api/schedule/**
          filters:
            - StripPrefix=2
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOriginPatterns: "*"
            allowedMethods: "*"
            allowedHeaders: "*"
            allowCredentials: true

网关的CORS配置是个容易踩坑的点。因为我们的前端服务在独立端口，前端代码里遭遇跨域，我们统一在网关处理CORS，只要在网关层配置了允许跨域，下游服务就不需要再处理跨域了，否则会重复设置响应头导致前端报错。

路由发布采用配置文件的方式，不通过控制台手动添加路由。因为配置在Nacos里，改完配置刷新即可，发路由变更也会走代码评审和Git提交记录。——如果是小团队临时调试，可以用Gateway的控制台API添加临时路由，但生产环境别这么干，监管和回溯上用Git流程最稳。

3. 核心业务模块设计与实现细节

3.1 日程模块：冲突检测与共享授权

日程模块的逻辑核心是时间段冲突检测和日程共享权限控制。

冲突检测的算法不复杂，但有个数据库设计细节很关键：日程表需要同时支持单次日程和循环日程（比如每周一例会），存储时要区分recurrence_type字段。我们规定：所有日程记录都存UTC时间，查询时按员工时区做转换。

java复制public boolean checkConflict(Long userId, LocalDateTime startTime, LocalDateTime endTime, Long excludeScheduleId) {
    LambdaQueryWrapper<Schedule> wrapper = Wrappers.lambdaQuery();
    wrapper.eq(Schedule::getUserId, userId);
    wrapper.ne(excludeScheduleId != null, Schedule::getId, excludeScheduleId);
    wrapper.apply("start_time < {0} AND end_time > {1}", endTime, startTime);
    return scheduleMapper.selectCount(wrapper) > 0;
}

这里有个容易踩的坑：冲突检测要用start_time < 新结束时间 AND end_time > 新开始时间这个区间重叠判断，而不是简单的start_time = 新开始时间。两个日程边界恰好相接（比如9:00-10:00和10:00-11:00）不算冲突，这点要和业务方确认清楚，我们的规则是中间留5分钟缓冲才算不冲突。

日程共享授权我们用了类似文件权限的做法：日程创建者可以把某条日程共享给指定同事，权限分为“只读”“可编辑”“可管理”。实现上不需要引入复杂的RBAC框架，就是在日程表里加一个共享表schedule_share，记录共享人和权限级别，查询时先查自己创建的，再join共享表查别人共享给自己的。

日程提醒通过延迟消息实现：日程创建或更新后，向RabbitMQ延迟队列投递一条提醒消息，延迟时间根据用户提前设置的提醒时间（比如提前15分钟、30分钟、1小时）计算。注意，延迟队列的延时上限受插件版本影响，超过上限的消息需要做降级处理。我们用的是RabbitMQ的x-delayed-message插件，单条消息延迟上限约24小时，超过24小时的提醒改为用Quartz定时任务扫描。

3.2 签到模块：防重复、位置校验与签退逻辑

签到模块是整个系统里并发压力最大的地方。早晚打卡的人一涌而来，假设公司五千员工，早高峰集中在8:30到9:00，平均每秒要有几十甚至上百个签到请求。如果每个人直接打到数据库，数据库瞬间就被打爆了。

我们设计签到请求的完整流程是这样的：

java复制public CheckinResult checkin(CheckinRequest request) {
    Long userId = request.getUserId();
    // 0. 查询缓存，判断是否已经签到
    String cacheKey = "attendance:checkin:" + LocalDate.now() + ":" + userId;
    // 1. 使用分布式锁防止重复签到
    RLock lock = redissonClient.getLock(cacheKey + ":lock");
    lock.lock(5, TimeUnit.SECONDS);
    try {
        // 2. 数据库唯一索引兜底
        AttendanceRecord record = new AttendanceRecord();
        record.setUserId(userId);
        record.setCheckinDate(LocalDate.now());
        record.setCheckinTime(LocalDateTime.now());
        record.setLocation(buildLocation(request));
        // 3. 位置校验
        validateLocation(userId, record);
        attendanceMapper.insert(record);
        // 4. 写缓存标记
        redisService.set(cacheKey, "1", Duration.ofHours(12));
        // 5. 异步通知
        notificationService.sendCheckinSuccess(userId);
        return CheckinResult.success(record);
    } finally {
        lock.unlock();
    }
}

关键细节有四个：唯一索引兜底、分布式锁防并发、位置校验和缓存标记。数据库表在设计时就给user_id + checkin_date加了一个唯一索引，就算分布式锁偶尔没生效，数据库级别的约束也能保证每个员工每天只有一条签到记录。Redis缓存标记用于快速判断“今天是否已签到”，大部分查询直接走缓存，不查库。

位置校验这一块，企业考勤分两类：固定地点的GPS定位考勤和连接指定WiFi的考勤。GPS定位需要计算经纬度距离，公式如下：

java复制private static final double EARTH_RADIUS = 6371.0088;

public static double distance(double lat1, double lng1, double lat2, double lng2) {
    double radLat1 = Math.toRadians(lat1);
    double radLat2 = Math.toRadians(lat2);
    double a = radLat1 - radLat2;
    double b = Math.toRadians(lng1) - Math.toRadians(lng2);
    double s = 2 * Math.asin(Math.sqrt(
            Math.pow(Math.sin(a / 2), 2) +
            Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2)));
    return s * EARTH_RADIUS * 1000;
}

考勤规则运营上定了300米半径，超过就不能打卡。实际测试下来，GPS在室外空旷地带的精度可以达到10-30米，但在写字楼密集区会有100-200米的漂移。建议位置校验加一层宽容机制：配置一个“考勤点缓冲半径”，默认300米，如果员工反馈定位不准，管理员可以按楼栋微调。这里踩过的坑是：必须用员工上报的GPS坐标和服务端存储的考勤点坐标算距离，绝不能直接用前端算好的距离值传上来，否则会被抓包篡改。

签退逻辑和签到类似，但不用防重复到那么严格，大多数公司允许员工一天多次上下班（比如中午外出下午回来）。我们做了签到状态机：未签到 → 已签到 → 已签退 → 已签退（可循环）。状态流转记录在Redis里，避免频繁查询数据库。

3.3 数据权限与组织架构权限设计

OA系统躲不开权限问题。我们没有引入Spring Security OAuth2那套完整的东西，而是做了精简：JWT令牌负责认证，RBAC负责授权，数据权限通过一个自定义的@DataScope注解实现。

数据权限的规则是这样的：员工只能看自己创建的日程；部门主管能看本部门员工的日程；HR和考勤管理员能看全公司考勤数据。后端拦截器解析JWT里的部门ID和角色编码，在查询时自动追加数据权限过滤条件，不用每个Mapper都写一遍。

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DataScope {
    String type() default "self";   // self, dept, all
}

这个注解加在Service方法上，AOP切面在进入方法前查一次用户角色，把过滤条件设置到ThreadLocal里，Mapper查询时通过拦截器自动拼接SQL条件。优点是代码侵入性小，缺点是SQL拼接调试起来要格外小心，建议给所有数据权限表都加上对应的索引，否则全表扫描会拖垮数据库。

4. Vue3前端工程化与核心页面实现

4.1 前端技术栈选型与工程初始化

前端我们选了Vue3 + Vite + Element Plus + Pinia + Vue Router。Vite比Webpack启动快太多，开发体验天差地别。初始化使用官方脚手架：

bash复制npm create vite@latest frontend -- --template vue
cd frontend
npm install element-plus @element-plus/icons-vue pinia vue-router axios

Vite的代理配置有必须注意的点。开发环境下前端服务和后端网关不在同一个端口，需要在vite.config.js里配置proxy代理，把/api请求转发到网关地址：

js复制server: {
  port: 5173,
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true,
      ws: false
    }
  }
}

生产环境下，前端的打包产物会统一放进Nginx，Nginx反向代理把/api转发到网关，所以代码里所有请求的baseURL写/api即可，不需要区分环境。

4.2 动态路由与菜单权限控制

前端权限控制的核心点是动态路由。不同角色登录进来看到的菜单不一样，后端登录接口返回用户信息和角色列表，前端根据角色动态生成可访问的路由表。

具体做法是：路由表分成两部分，基础路由（登录页、404、首页）在代码里静态注册，业务路由（日程管理、签到、考勤统计、系统管理）通过路由表配置，由后端接口返回菜单树，前端用router.addRoute()动态添加。

js复制const buildRouter = (menuList) => {
  menuList.forEach(menu => {
    const route = {
      path: menu.path,
      name: menu.name,
      component: () => import(`../views/${menu.component}.vue`),
      meta: { title: menu.title, icon: menu.icon },
      children: buildRouter(menu.children || [])
    };
    router.addRoute(route);
  });
};

这里有个Vite动态import的坑必须说：import('../views/xxx.vue')的路径必须是相对路径且不能是纯变量，如果直接用import(../views/${variable}.vue)这种写法，Vite构建时无法静态分析，打包会报错或者生成一堆chunk。解决方案是用import.meta.glob预先加载所有页面组件：

js复制const viewModules = import.meta.glob('../views/**/*.vue');
// 使用时按路径取模块
const loadView = (path) => viewModules[`../views/${path}.vue`]();

菜单和路由生成以后，还要做一步按钮权限控制。我们把按钮操作（比如“创建日程”“导出考勤”“审批通过”）也配置成权限点，后端接口返回当前用户拥有哪些权限点，前端封装一个v-permission指令控制按钮的显隐。

4.3 日程管理页与签到页关键实现

日程管理页用的是Element Plus的el-calendar组件，在此基础上做了二次封装。el-calendar默认不支持拖动创建日程，但OA场景里用户最习惯的就是在日历上鼠标框选时间段来建日程，我通过date-cell插槽监听日历格子的mousedown、mousemove、mouseup事件实现了这个交互。框选范围从起止日期和时间双重校验，起止时间不能超过当天24点。

日程详情弹窗里要展示部门同事列表，方便把日程共享给别人。共享人列表用远程搜索接口实现，输入关键词调用user-service的搜索接口，防抖300毫秒，避免每敲一个字就发一次请求。

签到页的核心是定位组件的封装。浏览器navigator.geolocation在HTTPS环境下才能不弹权限警告，这个要提前和运维确认。获取到的经纬度通过后端距离计算接口校验后，再把状态显示在页面。为了让用户对漏签有感知，签到页顶部显示今天的签到状态和时间线：未签到、迟到、已签退这些状态用不同颜色标识。组件代码核心逻辑如下：

js复制const getLocation = () => {
  return new Promise((resolve, reject) => {
    if (!navigator.geolocation) {
      reject(new Error('浏览器不支持定位'));
      return;
    }
    navigator.geolocation.getCurrentPosition((pos) => {
      resolve({
        latitude: pos.coords.latitude,
        longitude: pos.coords.longitude,
        accuracy: pos.coords.accuracy
      });
    }, (err) => {
      reject(err);
    }, {
      enableHighAccuracy: true,
      timeout: 5000,
      maximumAge: 1000
    });
  });
};

实际部署时遇到过iOS微信浏览器内打开签到页，定位接口返回权限拒绝的问题。排查下来是微信内置浏览器需要额外的JS-SDK配置，而且必须在HTTPS域名下。建议在签到页增加一个手动选择考勤点的兜底方案，用户如果定位失败，可以手动选择最近考勤点，并标明“手动定位”标记，由考勤管理员抽查复核。

4.4 前端鉴权封装与请求拦截

Axios请求拦截统一在请求头加token，响应拦截统一处理业务错误码和401跳转。有个细节：token过期后，我们要做静默刷新，避免用户刚好在填日程的时候突然被踢到登录页。

js复制service.interceptors.response.use(
  (response) => {
    const code = response.data.code;
    if (code === 401) {
      // token失效，尝试刷新token
      return refreshToken().then(() => {
        // 重放原始请求
        return service(response.config);
      });
    }
    return response.data;
  },
  (error) => {
    return Promise.reject(error);
  }
);

静默刷新用的refresh_token存放在HttpOnly的Cookie里，access_token存在内存（Pinia）里，这样XSS攻击拿不到长效凭证。后端auth-service每次刷新时校验refresh_token的有效期和签发设备信息，refresh_token有效期设7天，access_token设30分钟。

5. 分布式场景下的关键难点突破

5.1 分布式锁在签到防重中的应用

前面签到流程里提到了Redis分布式锁。我们用的是Redisson的RLock，而不是自己用SETNX命令手写锁。这是因为Redisson的锁有看门狗机制，默认每10秒自动续期一次，避免了业务还没执行完锁就过期的问题。手写SETNX锁最大的问题是锁超时时间设多长不好把控：设短了业务没跑完锁就过期，设长了万一宕机锁要等满时间才能释放。

java复制RLock lock = redissonClient.getLock("attendance:checkin:" + date + ":" + userId);
boolean locked = lock.tryLock(3, TimeUnit.SECONDS);
if (!locked) {
    throw new BusinessException("请勿重复提交，正在处理中");
}

注意Redisson和SpringBoot的版本匹配问题。我们用的是Redisson 3.20.0，对应SpringBoot 2.7.x没问题。如果SpringBoot升级到3.x，必须用Redisson 3.22.0以上版本，否则会有Redis客户端兼容问题。这个坑我踩过，排查了半天发现是Redisson和SpringBoot自带的commons-pool版本冲突。

分布式锁的粒度也要想清楚。我们锁的粒度是“用户+日期”，也就是同一用户同一天只能一个线程执行签到，这是业务需求的正确粒度。如果你锁的粒度太粗（比如锁整个服务实例），那并发性能就废了；太细（比如锁到记录ID），业务上又不能防止重复签到。

5.2 分布式事务：Seata AT模式与最终一致性

这张系统的跨服务事务场景有四处：创建日程同时插入日程提醒、签到成功同时更新考勤汇总、导入用户同时创建账号和默认部门关系、日程共享发送通知。我们选了Seata AT模式来管理强一致事务，AT模式的特点是业务无侵入，只需要在业务代码上加@GlobalTransactional注解。

java复制@GlobalTransactional(rollbackFor = Exception.class)
public void createScheduleWithShare(ScheduleCreateRequest request) {
    scheduleService.create(request);          // 操作schedule_db
    notificationService.sendInvite(request);  // 操作notify_db
}

AT模式的核心机制是两阶段提交：第一阶段业务SQL正常执行，Seata把涉及的数据快照保存在undo_log表；第二阶段如果所有分支都成功，删除undo_log；如果有分支失败，根据undo_log逆向补偿回滚。这里有个性能代价需要知道：AT模式在数据修改时会加上全局锁，并发高的场景下吞吐有损耗。签到链路广泛用到，建议别启用分布式事务，签到服务异步通知通知服务，采用消息最终一致性的方案。

实际项目中我更喜欢把强一致事务控制在最小范围：日程和当日提醒消息要求一致（用Seata AT），签到的异步通知用RabbitMQ消息队列保证最终一致（签到成功就往queue发一条消息，通知服务消费后写站内信）。消息最终一致性的实现路径是：签到服务本地事务提交后，通过Spring的@TransactionalEventListener（AFTER_COMMIT）再发送MQ消息，这样避免事务还没提交就先发消息导致消费者查不到数据的问题。

5.3 分布式ID生成方案选型

微服务环境下，各服务的数据库表主键不能再靠数据库自增ID，因为多服务写各自的库会产生ID冲突。我们的分布式ID方案用的是Leaf的号段模式，基于美团开源的Leaf框架改造。核心逻辑：每次从数据库拿一批ID号段缓存到本地内存，用完再拿下一批。

号段模式的表结构就一行记录——某个biz_tag的最大ID和步长。拿号段时用UPDATE语句把max_id加步长，哪个服务实例抢到了就获得这批号段的所有权。

code复制Leaf号段模式在大批量插入日程、签到记录时的性能非常高，
一次数据库交互能拿到上千个ID，本地内存分配ID几乎无网络开销。

Redis发号或者UUID的方案也行，但各自有短板：UUID是字符串类型，做主键占空间大、影响索引性能；Redis发号虽然快但需要保证Redis高可用，否则Redis挂了系统就发不了号。Leaf号段模式的短板是数据库一旦故障，拿到本地缓存的号段还能撑一会儿，整体可用性已经不错了。Leaf源码里有现成的SpringBoot集成包，我们直接引依赖配置数据源即可。

5.4 消息队列在日程提醒与签到通知中的角色

RabbitMQ在系统里承担了两类消息：延迟消息和普通事件消息。延迟消息用于日程提醒，普通事件消息用于签到成功后的通知、考勤异常告警。

延迟消息的实现之前提到过x-delayed-message插件，实际上在编码层是这么用的：

java复制@Component
public class DelayMessageSender {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    public void sendDelay(String exchange, String routingKey, Object message, long delayMillis) {
        MessageProperties props = new MessageProperties();
        props.setDelay((int) delayMillis);
        rabbitTemplate.convertAndSend(exchange, routingKey, message, props);
    }
}

配置交换机时要把类型声明为x-delayed-message：

java复制@Bean
public CustomExchange delayExchange() {
    Map<String, Object> args = new HashMap<>();
    args.put("x-delayed-type", "direct");
    return new CustomExchange("schedule.delay.exchange", "x-delayed-message", true, false, args);
}

生产环境遇到的消息可靠性问题主要集中在消息丢失上。解决方案是：生产者开启publisher-confirm-type: correlated，确认回调里处理发送失败的消息重发；消费者开启手动ack，业务处理完成才确认，处理失败的消息进入死信队列。这个流程我强烈建议每个微服务项目都配上，因为消息不可靠，最终一致性就无从谈起。

6. 部署、运维与性能优化实践

6.1 Docker化部署与编排实践

整套系统我们用Docker部署，应用打成镜像，编排用Docker Compose在单机环境先跑，测试无误后迁移到Kubernetes集群。每个服务的Dockerfile保持简单，使用多阶段构建来减小镜像体积：

dockerfile复制FROM maven:3.8.6-jdk8 AS builder
COPY . /app
WORKDIR /app
RUN mvn package -DskipTests

FROM openjdk:8-jre-alpine
COPY --from=builder /app/target/attendance-service.jar /app/attendance-service.jar
ENTRYPOINT ["java", "-jar", "/app/attendance-service.jar"]

镜像体积从400MB降到150MB左右收益很明显，但构建时Maven依赖下载是重复劳动，建议使用Maven的mvn dependency:go-offline在镜像构建前预下载依赖，大幅提速。

编排方面，Nacos、Redis、RabbitMQ、MySQL、MinIO等服务用docker-compose启动，开发环境一条命令全拉起来。应用服务可以单节点运行，测试环境用Docker Compose部署5-6个服务实例，生产环境上了Kubernetes。

6.2 环境分离与配置管理

开发（dev）、测试（test）、预生产（staging）、生产（prod）四套环境完全隔离，配置通过Nacos管理，每个环境使用不同的命名空间。这个做法的好处是：同一个应用镜像可以在四个环境之间无差别部署，差异全部收口在Nacos配置。

不同环境的数据库连接、Redis地址、日志级别都不同，注意不要在配置里明文写密码。我们用Nacos的加密插件或者K8s的Secret管理敏感配置，线上数据库密码只有运维一个人有权限查看。

6.3 性能测试与容量规划实录

系统上线前做了两轮压测。第一轮针对签到接口，用JMeter模拟500个用户同时签到，结果发现数据库连接池是瓶颈。默认Tomcat连接池上限是10个，签到线程全排队了。我们把连接池调大，并设置了合理的等待时间：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      connection-timeout: 3000
      max-lifetime: 1800000

第二轮压测发现RabbitMQ消费者处理速度跟不上签到高峰，导致签到消息积压。解决方式是消费者配置并发消费，每台机器起10个消费线程，并把消费者的prefetch设置为50，一次多拉取几条消息减少网络往返。

压测数据也要留档。我们产线高峰期QPS约200，签到接口的TP99控制在180毫秒；日程接口TP99是120毫秒。核算下来，生产环境核心服务4个节点足够扛住未来一年的增长——这个容量数据不是拍脑袋，是压测和线上监控结合得出来的。

6.4 链路追踪与告警策略

微服务架构排障最头疼的问题是“一个请求到底经过了哪些服务？”每个服务各自打日志，没有一次完整的调用链，很难定位瓶颈。我们接入了SkyWalking做链路追踪，每个服务接入探针后自动上报链路数据。

SkyWalking部署起来不复杂，服务端用docker跑，客户端在JVM启动参数里加-javaagent:/opt/skywalking-agent/skywalking-agent.jar即可。接入后，开发在控制台就能看到每次请求的调用链路，哪一段耗时高一目了然。

告警规则的设置要避免告警轰炸。我们只在服务可用性异常和调用错误率突增时发告警，具体的告警规则写在Prometheus里：

code复制- alert: 签到服务5分钟错误率超5%
  expr: sum(rate(http_server_requests_seconds_count{application="attendance-service",status=~"5.."}[5m])) / sum(rate(http_server_requests_seconds_count{application="attendance-service"}[5m])) > 0.05
  for: 5m
  labels:
    severity: critical

7. 常见问题排查与避坑实录

7.1 服务间调用超时的隐藏陷阱

我们上线初期遇到一个很诡异的问题：日程查询接口时快时慢，偶尔直接超时。排查发现是Feign调用用户服务的时候，用户服务里有一个批量查询接口没有做超时控制，一个慢SQL拖垮了整个线程池。

后来约定：所有Feign调用的超时时间必须短于网关的超时时间，否则网关等不到下游响应，直接给用户报504。同时，批量接口一定要做并发限制，防止上游一个请求就把下游打满。我们给用户服务的批量接口加了一个信号量限流，最大并发20个，超过的请求直接降级返回空数据。

7.2 签到高峰期的数据库死锁与慢SQL

上线一周后，签到高峰期偶发死锁异常。日志里看到死锁都是插入attendance_record时发生，排查下来是唯一索引的插入顺序导致的。因为多个线程同时插入不同userId的记录，InnoDB的间隙锁互相等待，形成死锁。

解决办法是插入前先查一遍记录是否已存在，存在直接返回，不存在再插入，并捕获死锁异常做重试。其实更彻底的做法是签到入口用分布式锁直接串行化，保证同一个用户不会并发插入。这个经验也验证了：高性能场景下，数据库总是最后一道防线，但绝不能是第一道防线。

7.3 前端生产环境跨域与Nginx配置

前端打包放到Nginx后，接口请求出现跨域报错。开发环境用的Vite代理没问题，但生产环境实际请求是从https://oa.example.com到https://api.example.com的跨域请求。我们一开始尝试在前端Nginx配反向代理：

code复制location /api {
  proxy_pass http://gateway-service:8080;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

这个配置解决了跨域问题，但部署时遇到一个Nginx的坑：proxy_pass的URL结尾有没有斜杠行为完全不一样。proxy_pass http://gateway-service:8080;（没斜杠）会把请求的完整URI传给后端，proxy_pass http://gateway-service:8080/;（有斜杠）会替换掉匹配的前缀。因为我们路由配置里网关本来就期望完整的/api/xxx路径，所以不能用斜杠。这类问题用一根烟的功夫就能踩，排查起来却可能花一整天。

7.4 日程提醒消息积压问题

还有一次，日程提醒的延迟消息大量积压在RabbitMQ队列里，消费者处理不过来。看监控发现是某次定时任务批量给全公司几千人创建了日程，瞬间生成了几万条延迟消息，全部堆积在队列队列中。

解决思路是：日程提醒消息没必要每条都保证秒级投递，可以降级为每分钟批量扫描一次数据库，把到期的提醒一次性捞出来批量推送。延迟消息只对实时性要求高的场景保留（比如签到确认）。架构设计要区分“必须实时”和“可以准实时”的业务，不同可靠性级别的消息走不同处理通道。

8. 写在最后

做的过程中总有人问我，这种规模的项目是不是单体加缓存就能搞定？我的答案是：单体能扛住现状，但扛不住增长和运维效率的提升。微服务带来的不只是性能弹性，更是一种组织方式——每个服务独立迭代、独立部署、独立容错，出了问题爆炸半径被收敛在一个域里，而不是整个系统瘫掉。

这套日程签到系统从拆解业务到上线稳定运行，前后经历了三轮迭代。第一轮做透了核心链路，第二轮补全了权限和消息可靠性，第三轮才做的性能和监控加固。如果你准备动手，我给三条建议：第一，先把业务边界画清楚再谈技术方案；第二，能最终一致就别强一致；第三，不要追求一步到位的微服务，迁移和改造本身就是演进过程。

签到链路里还有很多可以扩展的地方，比如人脸识别打卡、考勤异常自动审批、会议日程的智能分析。这些后续都是基于当前服务架构往上加。希望这篇折腾出来的实战记录，能帮你少踩几个坑。