在郑州做宠物服务软件这件事，总是从各种碎片化的需求开始。兽医排班混乱、上门护理无法实时跟踪、宠物档案分散——这些痛点把我拉进了系统设计的泥潭。第一次上线预约模块时，突发的并发写入把我的事务锁暴露无余，我才真切体会到业务模型和数据库模式不能脱节。

      架构上，我最终选择了微服务边界：Go 做核心 API，采用 gRPC 做服务间通信，PostgreSQL 存储关系数据，Redis 做缓存与分布式锁，MinIO 承担对象存储。为什么不用单体？不是反对复杂性，而是为了把宠物档案、支付、影像、实时视频拆成独立演进的单元。实操感悟：定义事务边界前，多画几版时序图；遇到死锁别急着扩库，先检查索引和 SQL 执行计划。

      移动端我同时维护了微信小程序和 Flutter 原生客户端。离线优先策略用 SQLite 做写时缓存，带变更队列的同步器负责合并。图片上传常常成性能瓶颈，采用分片上传（tus 协议兼容）并转码为 WebP 后入 CDN，用户体验提升明显。教训是：别低估手机网络的波动，断点续传和进度反馈不是可选。

      实时功能采用 WebSocket 做业务通知，用 mediasoup 作为 SFU 支撑远程问诊。遇到过大规模并发断连，起因是 TURN 配置不足与 NAT 超时。实践里我学会了用短会话心跳、合理的重连策略和流控来减少重连洪峰；还有，要在客户端做一些回退逻辑，避免单点依赖。

      后台任务用 Redis Streams + BullMQ 实现幂等消费，日志和链路追踪靠 Prometheus + Grafana、Jaeger。一次慢请求调查，正是通过分布式追踪找到 N+1 查询，加了联合索引后延迟回落一半。体会是：监控不是事后补丁，尽早埋点，能省下很多盲搜时间。

      安全与合规上，全部接口走 mTLS，敏感字段在应用层做字段级加密，支付接入走支付网关的代付与 token 化。曾经把密钥写进环境变量错误地暴露到日志，这教会我用密钥管理服务并且对日志做脱敏。工具上常用 Trivy 做镜像扫描，CI 用 GitLab CI 做多阶段构建。

      结尾给点实操建议：先把核心闭环做通——预约、到诊、支付、跟踪；再逐步拆功能独立部署。持续交付和灰度、以及充足的自动化用例，会让本地调试的问题少很多。展望上，设备端推理与 MQTT 接入算是下一步，值得在原型就留接口，不然改起来很痛。