在社区养老服务中心，护士小李每天都要通过护理系统查看老人的健康数据。可最近系统总卡顿，血压异常提醒延迟，药单更新慢半拍。后来才发现，后台的微服务架构没调好，数据一多就扛不住。
拆得太碎反而拖累系统
一开始为了灵活，开发团队把系统拆成了十几个微服务：用户管理、健康监测、用药提醒、家属通知……每个都独立运行。但老人数量一上来，服务之间来回调用频繁，网络开销大增，响应时间从200毫秒飙到两秒。
后来他们合并了几个高频交互的服务，比如把用药提醒和健康监测合并在同一个服务里处理，减少跨服务调用。就像家里做饭，如果每放一味调料都要跑一趟超市，再快的腿也忙不过来。
缓存不是越多越好
系统加了Redis缓存，本想加快访问速度，结果发现老人档案信息更新后，缓存没及时刷新，家属看到的还是三天前的饮食记录。
调整策略后，设定了合理的过期时间，并在关键操作如健康评估完成后主动清除相关缓存。现在数据既快又准，护士也不用反复解释“为什么手机上还没变”。
限流保护脆弱节点
每月初系统自动生成护理报告时，统计服务经常直接崩溃。加入限流机制后，每秒只处理固定请求数，多余请求排队处理。
spring.cloud.gateway.routes[0].filters[0]=RequestRateLimiter=100, 200这就像医院挂号，哪怕病人再多，窗口一次也只能接待一人，其他人按顺序等，避免现场混乱。
日志要看得懂，查得快
以前出问题要翻好几个服务的日志，时间对不上，字段不统一。现在所有服务都加上统一的请求追踪ID，在Kibana里输入一个编号，整个调用链清清楚楚。
有次张奶奶的跌倒警报没响，运维人员五分钟就定位到是消息队列积压导致，而不是传感器失灵，省下一场设备大检查。
别忽视数据库连接池
每个微服务都连同一个老人健康数据库，连接数没控制，高峰期直接把数据库拖死。调整HikariCP配置后，连接复用效率提升，数据库压力降了一半。
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.idle-timeout=30000就像小区电梯，同时只能进十几人，大家轮流上下，总比挤成一团谁也动不了强。