ljwx-health/MULTI_TENANT_OPTIMIZATION_PLAN.md

🚀 LJWX多租户系统全面优化方案

📋 项目概述

基于对ljwx-admin前端、ljwx-boot后端Java服务、ljwx-bigscreen Python服务的全面分析，制定企业级多租户数据隔离与查询性能优化的完整实施方案。

🎯 优化目标

• 数据隔离: 实现严格的租户数据隔离，确保隐私和安全
• 性能提升: 多租户查询性能提升60-80%，支持百万级数据
• 零侵入: 保持现有API接口完全兼容，渐进式升级
• 企业级: 支持大规模多租户部署，稳定可靠

🏗️ 当前系统状态分析

✅ 已完成的多租户支持

• ljwx-admin前端: 全局customerId自动注入系统
• 基础表结构: sys_user, sys_org_units, sys_user_org, sys_role, sys_position
• 索引优化: 17个多租户专用索引，支持高效查询
• 租户上下文: Python服务已具备tenant_context.py基础架构

⏳ 需要完成的核心任务

• 数据库扩展: 12个核心业务表添加customer_id字段
• Java后端改造: 15+实体类, 50+DTO类, 20+服务方法, 15+控制器
• Python服务改造: 8个核心模型, 20+服务函数, 30+API端点

🎯 完整实施方案

📊 Phase 1: 数据库架构完善 (2-3天)

1.1 数据库表结构扩展

优先级1 - 核心业务表 (必须完成):

• t_user_health_data - 用户健康数据 (最高优先级)
• t_device_info - 设备信息
• t_alert_info - 告警信息 (重命名tenant_id→customer_id)
• t_device_user - 设备用户绑定

优先级2 - 扩展业务表 (推荐完成):

• t_device_message + t_device_message_detail - 设备消息
• t_alert_action_log - 告警处理日志
• t_device_bind_request - 设备绑定申请

优先级3 - 分析数据表 (可选完成):

• t_health_baseline + t_org_health_baseline - 健康基线
• t_health_score + t_org_health_score - 健康评分

1.2 数据库迁移脚本

-- 已生成完整迁移脚本: business-tables-customer-id-migration.sql
-- 包含: 字段添加、数据迁移、索引创建、数据验证
-- 执行时间预估: 30-60分钟

1.3 性能优化索引

创建18个专用索引:

• 时序查询优化: customer_id + timestamp + device_sn
• 租户隔离优化: customer_id + user_id + org_id
• 状态查询优化: customer_id + status + is_deleted

⚙️ Phase 2: ljwx-boot Java后端改造 (4-5天)

2.1 实体类改造 (1天)

需要添加customer_id的实体类:

// 高优先级实体类
- TUserHealthData.java     // 健康数据
- TDeviceInfo.java         // 设备信息
- TAlertInfo.java          // 告警信息
- TDeviceUser.java         // 设备用户绑定

// 中优先级实体类  
- TDeviceMessage.java      // 设备消息
- TAlertActionLog.java     // 告警日志
- THealthBaseline.java     // 健康基线
- THealthScore.java        // 健康评分

// 实体类标准模式
@Schema(description = "租户ID")
private Long customerId;

2.2 DTO类改造 (1天)

需要添加customer_id的DTO类:

// SearchDTO类 (15+个)
- TUserHealthDataSearchDTO
- TDeviceInfoSearchDTO  
- TAlertInfoSearchDTO
// ... 其他业务搜索DTO

// Add/Update DTO类 (15+个)
- TUserHealthDataAddDTO
- TDeviceInfoAddDTO
- TAlertInfoAddDTO  
// ... 其他业务操作DTO

// DTO标准模式
@Schema(description = "租户ID")
private Long customerId;

2.3 服务层改造 (2天)

核心服务类重构:

// 高优先级服务类
- TUserHealthDataServiceImpl    // 健康数据服务
- TDeviceInfoServiceImpl        // 设备信息服务  
- TAlertInfoServiceImpl         // 告警信息服务

// 租户感知查询模式 (参考TWechatAlertConfigServiceImpl)
if (bo.getCustomerId() != null) {
    if (bo.getCustomerId() == 0L) {
        // admin用户：查看所有数据
    } else {
        // 租户用户：查看全局数据+自己租户数据
        queryWrapper.and(wrapper -> 
            wrapper.eq(TEntity::getCustomerId, 0L)
                   .or()
                   .eq(TEntity::getCustomerId, bo.getCustomerId())
        );
    }
}

租户上下文服务:

@Component
public class TenantContextService {
    public Long getCurrentCustomerId() {
        LoginUser loginUser = getCurrentLoginUser();
        return loginUser != null ? loginUser.getCustomerId() : 0L;
    }
    
    public boolean isAdminUser() {
        return getCurrentCustomerId() == 0L;
    }
    
    public void validateTenantAccess(Long resourceCustomerId) {
        Long currentCustomerId = getCurrentCustomerId();
        if (currentCustomerId != 0L && !currentCustomerId.equals(resourceCustomerId)) {
            throw new SecurityException("Tenant access denied");
        }
    }
}

2.4 控制器改造 (1天)

控制器租户上下文注入:

// 高优先级控制器
- TUserHealthDataController     // 健康数据控制器
- TDeviceInfoController         // 设备信息控制器
- TAlertInfoController          // 告警信息控制器

// 控制器标准模式
@PostMapping("/page")
public Result<Map<String,Object>> page(PageQuery pageQuery, TEntitySearchDTO dto) {
    // 自动注入租户上下文
    dto.setCustomerId(tenantContextService.getCurrentCustomerId());
    return Result.data(facade.listEntityPage(pageQuery, dto));
}

// 租户访问验证
@PostMapping("/{id}")
public Result<Boolean> update(@PathVariable Long id, @RequestBody TEntityUpdateDTO dto) {
    // 验证资源访问权限
    TEntity existing = service.getById(id);
    tenantContextService.validateTenantAccess(existing.getCustomerId());
    
    dto.setCustomerId(tenantContextService.getCurrentCustomerId());
    return Result.status(service.updateById(dto));
}

🐍 Phase 3: ljwx-bigscreen Python服务改造 (3-4天)

3.1 数据模型改造 (1天)

需要添加customer_id的模型类 (models.py):

# 高优先级模型类
class UserHealthData(db.Model):
    __tablename__ = 't_user_health_data'
    customer_id = db.Column(db.BigInteger, nullable=False, default=0, 
                           comment='租户ID')

class DeviceInfo(db.Model):
    __tablename__ = 't_device_info'  
    customer_id = db.Column(db.BigInteger, nullable=False, default=0,
                           comment='租户ID')

class AlertInfo(db.Model):
    __tablename__ = 't_alert_info'
    customer_id = db.Column(db.BigInteger, nullable=False, default=0,
                           comment='租户ID')

# 中优先级模型类
class DeviceMessage(db.Model):
class AlertRules(db.Model):
class HealthBaseline(db.Model):
# ... 其他业务模型

3.2 服务层改造 (1天)

核心服务函数重构:

# user.py - 用户健康数据服务
@with_tenant_context
def get_user_health_data_by_tenant(org_id=None, user_id=None, customer_id=None):
    customer_id = customer_id or get_current_customer_id()
    
    query = UserHealthData.query.filter(
        UserHealthData.customer_id == customer_id,
        UserHealthData.is_deleted == False
    )
    
    if org_id:
        query = query.filter(UserHealthData.org_id == org_id)
    if user_id:
        query = query.filter(UserHealthData.user_id == user_id)
        
    return query.all()

# device.py - 设备管理服务
@with_tenant_context  
def get_device_info_by_tenant(customer_id=None):
    customer_id = customer_id or get_current_customer_id()
    
    devices = DeviceInfo.query.filter(
        DeviceInfo.customer_id == customer_id,
        DeviceInfo.is_deleted == False
    ).all()
    
    return [device.to_dict() for device in devices]

# alert.py - 告警处理服务
@with_tenant_context
def get_tenant_alerts(severity_level=None, status=None, customer_id=None):
    customer_id = customer_id or get_current_customer_id()
    
    query = AlertInfo.query.filter(
        AlertInfo.customer_id == customer_id
    )
    
    if severity_level:
        query = query.filter(AlertInfo.severity_level == severity_level)
    if status:
        query = query.filter(AlertInfo.status == status)
        
    return query.order_by(AlertInfo.create_time.desc()).all()

3.3 API端点改造 (2天)

主要API端点重构 (bigScreen.py):

# 健康数据API端点
@app.route('/api/tenant/health_data', methods=['GET'])
@with_tenant_context
def get_tenant_health_data():
    customer_id = get_current_customer_id()
    org_id = request.args.get('org_id', type=int)
    user_id = request.args.get('user_id', type=int)
    
    # 验证租户权限
    if org_id and not validate_tenant_access(org_id, customer_id):
        return jsonify({"error": "Organization not accessible"}), 403
    
    # 租户级健康数据查询
    health_data = get_user_health_data_by_tenant(org_id, user_id, customer_id)
    
    return jsonify({
        "success": True,
        "customer_id": customer_id, 
        "total_count": len(health_data),
        "data": [item.to_dict() for item in health_data]
    })

# 设备管理API端点
@app.route('/api/tenant/devices', methods=['GET']) 
@with_tenant_context
def get_tenant_devices():
    customer_id = get_current_customer_id()
    
    devices = get_device_info_by_tenant(customer_id)
    
    return jsonify({
        "success": True,
        "customer_id": customer_id,
        "devices": devices
    })

# 告警管理API端点
@app.route('/api/tenant/alerts', methods=['GET'])
@with_tenant_context  
def get_tenant_alerts_api():
    customer_id = get_current_customer_id()
    severity_level = request.args.get('severity_level')
    status = request.args.get('status')
    
    alerts = get_tenant_alerts(severity_level, status, customer_id)
    
    return jsonify({
        "success": True,
        "customer_id": customer_id,
        "alerts": [alert.to_dict() for alert in alerts]
    })

🧪 Phase 4: 测试与验证 (2天)

4.1 功能测试

多租户数据隔离测试:

• 租户A无法访问租户B的健康数据
• 租户A无法访问租户B的设备信息
• 租户A无法访问租户B的告警信息
• 超级管理员(customer_id=0)可以访问所有租户数据

API接口测试:

• 健康数据API租户隔离验证
• 设备管理API租户隔离验证
• 告警管理API租户隔离验证
• 用户权限边界测试

4.2 性能测试

查询性能验证:

• 多租户查询使用正确索引 (EXPLAIN验证)
• 大数据量下的查询响应时间 (<3秒)
• 并发多租户查询的稳定性测试
• 索引命中率和查询计划分析

数据完整性验证:

• 数据迁移完整性检查
• 跨表数据关联一致性验证
• 租户ID数据分布统计
• 历史数据迁移准确性验证

📈 预期性能提升

查询性能指标

• 多租户查询性能提升: 60-80%
• 索引查询 vs 全表扫描: 从数千行扫描减少到个位数
• 查询响应时间: 大数据量场景下 <3秒
• 并发处理能力: 支持100+并发租户查询

数据处理能力

• 支持租户数量: 1000+独立租户
• 单租户用户容量: 10万+用户
• 健康数据处理: 千万级时序数据高效查询
• 设备管理规模: 10万+设备的企业级管理

📅 实施时间规划

总体时间线: 2-3周

Week 1: 数据库架构完善

• Day 1-2: 执行数据库迁移脚本
• Day 3: 数据完整性验证和索引优化
• Day 4-5: Java后端实体类和DTO改造

Week 2: 服务层全面改造

• Day 1-2: Java服务层和控制器改造
• Day 3-4: Python服务层和模型改造
• Day 5: API端点租户上下文集成

Week 3: 测试优化和上线

• Day 1-2: 功能测试和性能验证
• Day 3-4: 缺陷修复和优化调整
• Day 5: 生产环境部署和监控

🛡️ 风险控制

数据安全风险

• 数据备份: 完整数据库备份和恢复方案
• 迁移验证: 严格的数据完整性和一致性检查
• 权限控制: 多层次的租户访问权限验证

性能风险

• 索引优化: 预创建所有必要的多租户查询索引
• 查询监控: 实时监控慢查询和性能指标
• 降级方案: 性能问题时的服务降级策略

兼容性风险

• API兼容: 保持所有现有API接口的向后兼容
• 渐进迁移: 支持新旧版本并行运行的平滑过渡
• 回滚机制: 快速回滚到迁移前状态的应急方案

🎯 成功标准

功能标准

• ✅ 100%数据租户隔离，零数据泄露
• ✅ 所有核心业务功能支持多租户
• ✅ 管理员和租户用户权限正确区分
• ✅ 新老API接口完全兼容

性能标准

• ✅ 多租户查询性能提升60%以上
• ✅ 大数据量查询响应时间<3秒
• ✅ 支持1000+租户并发访问
• ✅ 系统稳定性和可用性99.9%+

技术标准

• ✅ 代码质量和规范符合企业标准
• ✅ 完整的单元测试和集成测试覆盖
• ✅ 详细的技术文档和操作手册
• ✅ 监控报警和运维工具完善

📋 执行清单

Phase 1: 数据库架构

• 备份生产数据库
• 执行business-tables-customer-id-migration.sql
• 验证数据迁移完整性
• 创建性能监控索引
• 数据分布统计和验证

Phase 2: Java后端改造

• 添加customer_id到15+实体类
• 更新50+DTO类支持customer_id
• 实现TenantContextService租户上下文
• 重构20+服务方法实现租户隔离
• 更新15+控制器支持租户上下文

Phase 3: Python服务改造

• 更新8个核心模型类添加customer_id
• 重构20+服务函数实现租户过滤
• 更新30+API端点添加租户装饰器
• 完善tenant_context.py租户上下文管理
• 集成现有admin_helper.py权限体系

Phase 4: 测试验证

• 多租户数据隔离功能测试
• API接口租户权限测试
• 查询性能和索引使用验证
• 并发访问和稳定性测试
• 生产环境部署和监控配置

---

🚀 总结

这个完整的多租户优化方案基于对现有系统的深入分析，提供了从数据库到应用层的全栈解决方案。通过分阶段实施，可以在保证系统稳定性的前提下，实现企业级的多租户数据隔离和查询性能优化。

关键优势:

• 🔒 严格数据隔离: 确保租户数据安全和隐私
• ⚡ 显著性能提升: 60-80%的查询性能改进
• 🔄 零侵入升级: 完全向后兼容，平滑过渡
• 🏢 企业级扩展: 支持大规模多租户部署

预期收益:

• 支持1000+独立租户的企业级部署
• 健康数据查询性能提升60-80%
• 系统安全性和可靠性显著增强
• 为未来业务扩展奠定坚实基础