简介：面向计算机相关专业学生及开发者，该项目提供基于SDN的流量预测与调度系统Python完整源码，适合作为毕业设计、课程设计或初期项目立项演示。系统不仅包含流量预测与调度核心逻辑，还内置菜单管理、部门管理、角色权限、用户管理、接口白名单、字典管理等基础模块，便于在此基础上进行二次开发与功能扩展。压缩包共439个文件，大小11.28MB，文件类型以Python脚本、Vue组件、JavaScript文件为主，另含CSS样式、图片资源、Dockerfile及多项配置文件，完整覆盖前端页面、后端服务、数据库配置与容器化部署脚本，结构清晰，便于按需查看与修改。项目支持Docker部署，并附有简明的项目说明，可直接参考启动流程。当前已有202人学习浏览，适用于希望借助完整项目理解SDN流量调度设计思路、练习前后端联调及容器化部署的读者。代码经过测试运行成功，可在个人环境中快速启动验证，也可作为学习SDN实验与系统开发的实用参考。

1. 基于SDN的流量预测与调度系统，值得你下来跑一遍吗

做SDN相关课题的人应该都有同感：控制器搭起来了，OpenFlow流表也能下发，但网络流量到底什么时候暴涨、哪条链路会先堵，基本靠猜。这套基于SDN的流量预测与调度系统，就是把“猜”换成“算”的一套Python工程——它把流量预测、调度决策和管理后台放在同一个项目里，前端用Vue，后端用Python，默认SQLite就能直接跑，MySQL和Redis作为可选增强，还支持Docker一键部署。对正在做毕设、课程设计或企业SDN项目的人来说，它最大的价值不是算法有多深，而是“整套东西能演示、能答辩、能改”。内置菜单管理、部门管理、角色管理、用户管理、接口白名单、字典管理、操作日志等一整套RBAC后台功能，登录账号superadmin，进去就能看到全貌。

2. 系统拆解：从SDN流量预测到调度管理，这套代码在解决什么

2.1 先想清楚：预测和调度在SDN里分别站在哪一层

SDN的经典架构是控制平面和数据平面分离，控制器负责全局视图和决策，交换机只管按流表转发。流量预测和调度这两个动作，本质上都属于控制器上层的管理面业务——预测模块拿到全网流量历史数据，算出未来一段时间各链路的负载趋势；调度模块根据这个趋势，决定是把新流量引到低负载链路，还是给即将拥堵的链路做限速或重路由。

这套系统在架构里扮演的是“运营管理平台”的角色。它不替代控制器本身，而是把预测结果、调度策略、设备状态做成可视化后台，再通过接口和控制器对接。这和市面上很多SDN管控平台的做法一致，也是为什么它的源码里除了业务代码，还带着一整套用户权限和日志模块——因为这类系统最终是要给运维人员用的，不是实验室里跑一次就扔的脚本。

2.2 内置模块拆解：九个功能各自管什么

资源说明里列了九个内置功能，我按实际使用频率重新排个序。这些模块是典型的RBAC后台标配，也是毕设答辩时最容易被评委追问的部分。

接口白名单这个模块在SDN对接场景里特别实用。控制器或者sFlow采集器向平台推送流量数据时，通常走HTTP回调，如果每个请求都要求带Token，集成成本会高很多。白名单直接把这些上报接口放行，只保留管理端接口的鉴权，这是实际项目里经常用到的手法。

2.3 技术栈和源码目录：先认路再动手

从资源里的d2-admin.babel、browserslistrc、my.cnf、my.conf这些文件能看出，前端用的是Vue生态，d2-admin是业界比较成熟的中后台框架，babel和browserslistrc是Vue项目标配的转译和浏览器兼容配置。后端是Python写的RuoYi-Vue系列风格。数据库层面，默认SQLite保证零配置启动，MySQL 5.7以上用来做正式环境，Redis做缓存可选。

sdn-traffic-scheduling/ ├── web/ # 前端工程 (Vue + d2-admin) │ ├── .env.development # 开发环境配置：端口、接口代理地址 │ ├── .env.production # 生产环境配置 │ ├── package.json # 前端依赖清单 │ └── src/ # 前端源码 ├── backend/ # 后端工程 (Python) │ ├── requirements.txt # Python依赖清单 │ ├── config.py # 数据库、Redis、端口配置 │ ├── apps/ # 业务模块：用户、角色、字典、日志等 │ └── run.py # 后端启动入口 ├── db/ # SQL脚本 (MySQL初始化数据) ├── docker/ # Dockerfile 和 docker-compose.yml └── 项目说明.md # 部署文档

目录结构我按常见布局补全了，实际以解压后的项目说明为准。认路的关键就一句话：前端所有请求通过代理转发到后端，后端连接数据库做鉴权和业务处理，预测调度模块以后端API形式暴露给控制器调用。

3. 本地跑通：前端与后端的完整启动顺序

3.1 环境准备：四个组件的选择和取舍

资源说明里给了明确的版本要求：Python 3.8以上，Node.js 14以上，MySQL 5.7以上可选，Redis可选。我的建议是本地开发环境按“最小可用”来配——先不装MySQL和Redis，让后端直接跑默认的SQLite，一是省事，二是排查问题的时候少两个变量。Python装3.8或3.9都行，3.10以上有些依赖包可能没跟上，装了容易遇到编译报错。Node版本尽量14以上，太老的话npm install直接卡死。

MySQL如果之前装过，倒是可以直接用上，后面Docker部署也顺手。没装过的不用特意去配，SQLite对这个项目完全够用。Redis同理——单机演示时缓存功能不启用也不影响主流程，真正做负载较高的生产环境再说。

3.2 后端启动：虚拟环境、依赖安装、初始化数据

进入项目根目录后，我习惯先建Python虚拟环境，避免依赖污染系统环境。后端目录名以实际为准，可能是backend，也可能是api、server，解压后看一眼根目录结构就清楚了。

# 进入项目根目录，创建虚拟环境 python -m venv venv # Windows激活虚拟环境 venv\Scripts\activate # Linux/Mac激活虚拟环境 source venv/bin/activate # 安装后端依赖 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 初始化数据库（首次运行时执行） python init_db.py # 启动后端服务 python run.py

说明一下：venv是Python自带的虚拟环境工具，把依赖装在项目内部，卸载时直接删文件夹，这是所有Python项目最稳妥的启动方式。requirements.txt里锁定了依赖版本，用清华源下载速度更快。init_db.py是初始化脚本，会创建数据表并写入superadmin管理员账号，第一次运行必须执行一次，但不用重复执行。run.py是启动入口，默认端口通常在5000或8000，日志里会打印访问地址。

3.3 前端启动：依赖安装、代理配置、开发服务器

前端部分资源说明里写得很清楚，直接进web目录操作即可。

cd web # 安装前端依赖，使用淘宝镜像加速 npm install --registry=https://registry.npm.taobao.org # 启动开发服务器 npm run dev

npm install这一步是前端最大的不确定因素，node_modules体积大、包数量多，网络不好容易卡住。官方源慢就换淘宝镜像，也就是命令里那个--registry参数。如果之前配置过全局镜像，可以不加这个参数。npm run dev启动的是开发服务器，默认端口8080，浏览器访问http://localhost:8080就能看到登录页。

.env.development文件里可以改启动端口和接口代理地址。默认情况下，前端通过代理把/api开头的请求转发到后端，比如http://localhost:8080/api被代理到http://localhost:5000，这样浏览器里就不会出现跨域报错。改端口时注意同时改代理目标，两边不一致的话登录会一直转圈。

用superadmin和admin123456登录，能看到全部菜单和数据。如果登录后页面报错，先看后端控制台日志——大概率是数据库没初始化，或者后端启动时连错了端口。

4. Docker部署：MySQL、Redis、前后端的容器编排

4.1 部署前检查：Docker和docker-compose是不是就绪

Docker部署的价值在于环境一致性，把这套系统装进容器后，不管换到哪台机器都是同样的运行结果。部署前先确认本机已经装了Docker Engine和docker-compose插件，在终端里跑一下docker --version和docker compose version，能看到版本号说明就绪。Windows用户装Docker Desktop时如果弹出virtualization support not detected，说明CPU虚拟化没开，要去BIOS里开启Intel VT-x或AMD-V，这是Windows下最常见的Docker翻车点。

4.2 docker-compose.yml：四个服务的完整编排

这套系统推荐用docker-compose编排，一次拉起全部服务。数据库选MySQL 8.0，缓存用Redis，后端用Python镜像，前端用Node构建后再用Nginx托管静态文件。给一份可以直接改用的compose配置：

version: "3.8" services: mysql: image: mysql:8.0 container_name: sdn-mysql environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: sdn_traffic TZ: Asia/Shanghai volumes: - ./db:/docker-entrypoint-initdb.d - mysql-data:/var/lib/mysql ports: - "3306:3306" healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s retries: 5 redis: image: redis:7-alpine container_name: sdn-redis ports: - "6379:6379" volumes: - redis-data:/data backend: build: ./backend container_name: sdn-backend environment: MYSQL_HOST: mysql MYSQL_PORT: 3306 MYSQL_DATABASE: sdn_traffic MYSQL_USER: root MYSQL_PASSWORD: root123456 REDIS_HOST: redis REDIS_PORT: 6379 ports: - "5000:5000" depends_on: - mysql - redis web: build: ./web container_name: sdn-web ports: - "80:80" depends_on: - backend volumes: mysql-data: redis-data:

参数说明：mysql服务里挂载的./db目录存放初始化SQL脚本，容器首次启动时自动执行，把RuoYi风格的表结构和默认数据建好，这个机制叫docker-entrypoint-initdb.d自动初始化，比手动登进容器执行SQL省事得多。MYSQL_DATABASE指定库名，后端连接时用同一个库名。backend服务的environment里MYSQL_HOST写成mysql而不是localhost，这是容器网络的关键——同一个compose网络内，服务之间通过服务名互相访问，不能用本机回环地址。web服务构建完成后用Nginx托管，容器内80端口映射到宿主机80，访问宿主机IP就能打开前端页面。

4.3 启动与验证：从一个命令到登录成功

# 在项目根目录执行 docker compose up -d --build # 查看容器状态 docker compose ps # 查看后端日志 docker compose logs -f backend # 查看前端日志 docker compose logs -f web

up -d --build的含义是后台启动并重新构建镜像，第一次执行会拉取MySQL和Redis的镜像，加上构建两个自定义镜像，耗时取决于网络和机器性能。docker compose ps能列出所有容器的状态，STATUS列显示Up说明运行正常，显示Restarting或Exited说明有问题。日志排查的顺序是先看mysql有没有初始化成功，再看backend有没有报数据库连接错误，最后看web能不能正常访问。后端容器健康后，浏览器访问http://localhost，能看到登录页说明这一套编排通了。

5. 避坑指南：本地启动与Docker部署的常见翻车点

5.1 npm install卡死或node-sass编译失败

现象：npm install执行到一半长时间不动，或者报node-gyp相关的错误。

原因：淘宝镜像对某些二进制包支持不完整，node-sass需要从GitHub下载编译好的二进制文件，国内网络经常失败。

解决：先删掉node_modules和package-lock.json，然后换用官方源重装，或者把node-sass替换为sass。我实际用的命令是npm install --registry=https://registry.npmmirror.com，如果还失败就设置环境变量SASS_BINARY_SITE指向国内镜像。

5.2 后端连MySQL时报Access denied for user

现象：后端启动报错，提示拒绝root用户访问数据库，但在命令行里用root能正常登录MySQL。

原因：MySQL 8.0默认的root认证插件是caching_sha2_password，而部分Python驱动连接到8.0时需要处理换行符差异，另外项目里配置的密码和MySQL实际密码不一致是更大的概率。

解决：先确认config.py或.env里的MYSQL_PASSWORD和容器环境变量一致。其次如果直接把宿主机MySQL映射到了3306端口，Docker容器里的配置会生效，把MYSQL_ROOT_PASSWORD统一修改成同一个密码再重启。

5.3 Docker Desktop启动失败：virtualization support not detected

现象：启动Docker Desktop直接弹窗提示虚拟化未检测到，点确定就退出，Docker命令全部不可用。

原因：Windows功能里没有开启Hyper-V或Windows Hypervisor Platform，或者BIOS里CPU虚拟化处于关闭状态。

解决：重启进BIOS开启Intel VT-x/AMD-V，然后在控制面板启用“适用于Linux的Windows子系统”和“虚拟机平台”两个Windows功能，重启后再启动Docker Desktop。在BIOS里找不到虚拟化选项时，检查CPU型号是否支持以及是否被超微等主板固件默认禁用。

5.4 容器能起来但页面打不开，前端一直转圈

现象：docker compose ps显示所有容器都是Up，但浏览器访问页面请求一直pending，控制台报网络错误。

原因：前端容器里的Nginx配置了代理转发，指向了localhost或者固定IP，而这个地址在容器内部根本不存在，导致API请求全部超时。

解决：把Nginx配置文件里的proxy_pass改成http://backend:5000，容器内用服务名而不是回环地址，改完重建web容器。这一条和4.2里后端环境变量用服务名是同一个原理。

5.5 操作日志里看不到任何数据，但功能正常

现象：登录、点击菜单、修改用户都没问题，但操作日志页面一直空白。

原因：日志模块依赖AOP切面或装饰器记录，如果Python后端的配置里日志开关被注释掉，或者异步写日志失败后被静默吞掉，日志表就没有数据。

解决：在管理端检查是否启用了日志记录配置，没有的话找后端配置文件里log相关参数打开，尽量让日志记录有报错提醒而不是静默失败。日志这块对毕设答辩很重要，评委通常拿它来问“系统怎么做审计的”。

6. 再进一步：把流量预测结果接到调度模块的三种验证方式

这套系统跑起来之后，真正的门道在“预测”和“调度”怎么衔接。源码里带的管理后台是壳，预测调度才是核。我自己在做类似项目时，习惯先在本地把链路走通再上控制器。

第一种方式：离线数据验证。把控制器导出的历史流量数据整理成CSV，按时间戳和链路ID两个维度组织，通过后端提供的API批量导入，然后在预测模块里跑一轮时序预测，看结果和实际流量的偏差。常见做法是用LSTM或Prophet，先用历史数据训练简单模型输出未来5分钟的各链路负载，不需要特别复杂，能看出趋势曲线就算达标。给段参考实现：

import pandas as pd from sklearn.ensemble import RandomForestRegressor def train_predictor(history_csv): """基于历史流量训练调度预测器""" df = pd.read_csv(history_csv, parse_dates=["timestamp"]) df["hour"] = df["timestamp"].dt.hour df["weekday"] = df["timestamp"].dt.weekday features = ["hour", "weekday", "value"] X = df[features].values y = df["value"].shift(-1).values[:-1] X = X[:-1] model = RandomForestRegressor(n_estimators=200, max_depth=10) model.fit(X, y) return model

这段代码用RandomForestRegressor做基线预测，n_estimators设为200防止过拟合，max_depth限制树深度。预测目标y是下一时刻的流量值，用shift(-1)构造标签，这是时序预测里最基础的监督学习做法，适合先验证数据质量。

第二种方式：调度策略闭环。预测模型输出结果后，在系统后台配置阈值策略——比如某条链路预测负载超过80%，就触发调度任务，把该链路的队列优先级降低或把业务流量切到备用路径。验证标准是看预测触发时延和调度生效之间的时间差，这个差值越小，说明系统离生产可用越近。

第三种方式：对接模拟控制器。用Mininet搭一个虚拟SDN网络，让流量发生器产生突发流量，平台预测到拥堵后通过北向接口下发流表到Ryu或Floodlight控制器。这一层涉及控制器接口协议，默认的模拟控制器在SDN场景里跑一遍效果不错。

我的习惯是：新拿到的系统，先跑一遍原始数据，再拉一次Docker编排，最后用模拟流量测试闭环，三个阶段都过了才敢说看懂了这个项目。验证时记得保留一份预测结果和实际流量的对比截图，毕设论文和答辩PPT里这块素材最值钱。这套系统的完整代码和项目说明都在下载包里，docker部署坑我已经踩过一圈，你跑的时候多留意第五章那几条，能省不少时间。希望帮到你。

本文还有配套的精品资源，点击获取