DM-ROW 接口文档

Appearance

高可用性设计 ​

**本文引用的文件** - [lemes-cloud/pom.xml](file://lemes-cloud/pom.xml) - [lemes-gateway/src/main/resources/bootstrap.yml](file://lemes-cloud/lemes-gateway/src/main/resources/bootstrap.yml) - [lemes-auth/src/main/resources/bootstrap.yml](file://lemes-cloud/lemes-auth/src/main/resources/bootstrap.yml) - [lemes-business-devicemate/lemes-service-dm-device/pom.xml](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-device/pom.xml) - [lemes-business-devicemate/lemes-service-dm-store/pom.xml](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-store/pom.xml) - [lemes-business-devicemate/lemes-service-dm-workflow/pom.xml](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/pom.xml) - [lemes-business-devicemate/lemes-service-dm-device/lemes-service-dm-device-server/src/main/resources/application.yml](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-device/lemes-service-dm-device-server/src/main/resources/application.yml) - [lemes-business-devicemate/lemes-service-dm-store/lemes-service-dm-store-server/src/main/resources/application.yml](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-store/lemes-service-dm-store-server/src/main/resources/application.yml) - [lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-server/src/main/resources/application.yml](file://lemes-cloud/lemes-business-devicemate/lemes-service-dm-workflow/lemes-service-dm-workflow-server/src/main/resources/application.yml) - [src/devops/docker-compose/docker-compose.yml](file://lemes-cloud/src/devops/docker-compose/docker-compose.yml) - [src/devops/k8s/baremetal-nginx-ingress.yaml](file://lemes-cloud/src/devops/k8s/baremetal-nginx-ingress.yaml)

目录 ​

  1. 引言
  2. 项目结构
  3. 核心组件
  4. 架构总览
  5. 详细组件分析
  6. 依赖分析
  7. 性能考虑
  8. 故障排查指南
  9. 结论
  10. 附录

引言 ​

本设计文档面向DeviceMate项目的高可用性建设，围绕微服务高可用（冗余部署、自动切换、负载均衡、熔断）、数据库高可用（主从复制、读写分离、故障转移、数据同步）、缓存高可用（Redis集群/哨兵、备份与恢复）、网络高可用（多节点、跨机房容灾、DNS与CDN）以及灾难恢复（备份、异地容灾、业务连续性与RTO/RPO目标）给出系统化方案，并配套故障演练与应急预案，帮助系统架构师与运维工程师落地实施。

项目结构 ​

DeviceMate采用多模块Maven聚合工程组织，核心由网关、认证、框架层、通用服务、设备、库存、工作流等子模块构成；同时提供Docker Compose与Kubernetes部署样例，支撑容器化与云原生高可用部署。

图表来源

章节来源

核心组件 ​

  • 微服务网关：统一入口、路由、鉴权放行白名单、限流与可观测性暴露。
  • 认证服务：令牌有效期配置、客户端维度的访问/刷新令牌策略。
  • 业务服务：设备、库存、工作流三大域服务，均具备server与common子模块，便于复用与隔离。
  • 注册与配置：基于Nacos的服务发现与配置管理，支持多环境命名空间与分组。
  • 容器编排：Docker Compose用于本地/单机部署；K8s Ingress控制器用于生产级流量接入与高可用。

章节来源

架构总览 ​

DeviceMate采用“网关+认证+多业务域服务”的微服务体系，结合Nacos实现服务注册与配置下发；通过Docker/K8s实现多副本与弹性伸缩；Ingress作为外部流量入口，承担高可用与健康检查职责。

图表来源

详细组件分析 ​

组件A：网关高可用与限流 ​

  • 能力要点
    • 优雅关闭与超时控制，确保平滑重启与降载。
    • 白名单URL免鉴权放行，降低网关压力。
    • 可选请求限流规则（注释示例），可按全局或用户/IP维度配置。
    • Nacos注册与配置，支持多命名空间与分组。
  • 高可用策略
    • 多副本部署，结合Ingress健康检查与就绪探针。
    • 与认证服务协同，前置鉴权与路由转发。
  • 运维建议
    • 将限流规则纳入配置中心，动态生效。
    • 结合监控告警，对异常流量进行快速隔离。

图表来源

章节来源

组件B：认证服务与令牌策略 ​

  • 能力要点
    • 客户端维度的访问令牌与刷新令牌有效期配置。
    • 与网关配合完成统一鉴权与放行。
  • 高可用策略
    • 多副本部署，结合Nacos注册与健康检查。
    • 令牌签发/校验逻辑应尽量无状态化，便于横向扩展。

图表来源

章节来源

组件C：业务域服务（设备/库存/工作流） ​

  • 能力要点
    • 各域服务均包含server与common模块，便于共享能力与独立演进。
    • MyBatis拦截器针对查询/更新方法进行规则化配置，便于治理与审计。
  • 高可用策略
    • 多副本部署，结合注册中心与负载均衡。
    • 数据库侧建议启用读写分离与主从复制，提升吞吐与可用性。

图表来源

章节来源

组件D：数据库高可用（主从复制、读写分离、故障转移、数据同步） ​

  • 设计原则
    • 主库负责写入，多台从库负责读取，结合半同步/增强半同步保障一致性与可靠性。
    • 通过中间件或ORM层实现读写分离，自动路由读写请求。
    • 故障转移采用自动化切换（如基于VIP/代理层），并配合监控与告警触发。
    • 数据同步采用增量日志（binlog/逻辑日志）+全量快照，缩短RTO/RPO。
  • 实施建议
    • 对热点表建立合理的索引与分区策略，降低主库压力。
    • 读库延迟监控与阈值告警，避免脏读。
    • 定期演练主从切换，验证自动化脚本与回切流程。

[本节为通用架构建议，不直接分析具体文件，故无章节来源]

组件E：缓存高可用（Redis集群/哨兵、备份与恢复） ​

  • 设计原则
    • Redis Sentinel：主从监控与自动故障转移，确保单点故障下的持续可用。
    • Redis Cluster：水平扩展与数据分片，提升容量与吞吐。
    • 持久化：RDB快照+AOF增量，定期备份与异地容灾。
    • 缓存一致性：写时更新DB与缓存双写，或采用失效策略，避免脏读。
  • 实施建议
    • 配置Sentinel多实例与Quorum，避免脑裂。
    • 集群模式下合理设置分片数量与副本数，平衡可用性与性能。
    • 定期备份与恢复演练，验证备份链路与恢复时间目标。

[本节为通用架构建议，不直接分析具体文件，故无章节来源]

组件F：网络高可用（多节点、跨机房容灾、DNS负载均衡、CDN加速） ​

  • 设计原则
    • 多节点部署：网关、认证、业务服务均至少两副本以上，跨可用区部署。
    • 跨机房容灾：通过多活或多备中心，结合DNS多线路解析与就近路由。
    • DNS负载均衡：基于权重/健康检查的轮询/最少连接策略。
    • CDN加速：静态资源与热点接口通过CDN缓存，降低源站压力。
  • 实施建议
    • Ingress使用NodePort/LoadBalancer暴露，结合健康检查与就绪探针。
    • DNS侧配置多地域解析与故障切换策略，配合SLB/ GSLB实现跨机房容灾。
    • CDN缓存策略与失效机制需与业务缓存策略协同，避免冲突。

图表来源

依赖分析 ​

  • 技术栈与版本
    • Spring Cloud、Spring Boot、Spring Cloud Alibaba 版本在父POM中集中管理。
    • MyBatis/MyBatis-Plus、Druid、Fastjson、Hutool、Guava、JSoup、EasyExcel、Apache POI 等工具库统一管理。
    • Nacos客户端版本统一，便于服务发现与配置中心一致性。
  • 模块耦合
    • 网关依赖认证服务进行统一鉴权；业务域服务通过注册中心发现彼此与通用模块。
    • 业务域服务各自维护server与common，降低相互依赖，提升内聚性。

图表来源

章节来源

性能考虑 ​

  • 网关层
    • 合理设置优雅关闭超时与探针周期，避免雪崩效应。
    • 白名单放行与限流策略需动态调整，结合实时指标优化。
  • 认证层
    • 令牌签发/校验尽量无状态化，减少会话存储压力。
  • 业务层
    • MyBatis拦截器规则化查询/更新，有助于识别慢SQL与热点接口。
    • 数据库层面采用读写分离与索引优化，减少主库压力。
  • 缓存层
    • 合理设置过期与淘汰策略，避免缓存穿透与击穿。
  • 网络层
    • Ingress探针与健康检查参数需与业务峰值匹配，防止误判。

[本节提供通用性能建议，不直接分析具体文件，故无章节来源]

故障排查指南 ​

  • 网关与认证
    • 关注网关优雅关闭与探针日志，确认重启期间的流量接管情况。
    • 认证服务令牌有效期与客户端配置是否一致，避免频繁刷新导致抖动。
  • 业务服务
    • 通过application.yml中的MyBatis拦截器规则定位热点查询与高频更新接口。
  • 部署与编排
    • Docker Compose中各服务端口映射与日志挂载是否正确。
    • K8s Ingress控制器健康检查与NodePort配置是否生效。

章节来源

结论 ​

DeviceMate的高可用建设以“网关+认证+多业务域服务”为核心，结合Nacos实现服务治理，借助Docker/K8s实现弹性与高可用。数据库与缓存层面建议采用主从复制/哨兵/集群等组合方案，网络层面通过多节点与跨机房容灾、DNS/GSLB/CDN实现全局高可用。最后，完善的灾难恢复与故障演练体系是保障业务连续性的关键。

附录 ​

  • 灾难恢复策略
    • 数据备份：全量+增量备份，定期校验与异地归档。
    • 异地容灾：跨机房/跨地域多活，DNS/GSLB实现故障切换。
    • 业务连续性：RTO/RPO目标明确，演练常态化。
  • 故障演练与应急预案
    • 模拟网关/认证/数据库/缓存/网络等多场景故障，验证自动切换与人工干预流程。
    • 明确应急响应角色与升级路径，固化恢复流程并持续改进。

[本节为通用实践建议，不直接分析具体文件，故无章节来源]