简介这是一份面向云从业者与计算机专业人员的在线购物系统部署实践资源围绕JDShop项目在云服务器与Linux环境下的完整落地展开适合具备基础Web开发知识、希望掌握真实项目上云流程的学习者参考。资源包共175个文件约4.59MB以31个php业务脚本、17个css样式文件、8个js交互脚本及1个sql数据库脚本为核心辅以78个png与37个jpg界面素材另含少量txt与md说明文档覆盖前端展示、后端逻辑与数据库初始化等模块。目前已有190人学习。通过该资源读者可获取JDShop的完整源码结构与数据库建表脚本理解includes目录下数据库配置文件的组织方式并借助样式与脚本文件梳理购物车、订单、商品详情等页面的实现逻辑为在云服务器上完成环境准备、代码上传、数据库导入与安全配置等环节提供可复用的项目素材与排错参考。1. JDShop 上云一个在线购物系统从裸机到云原生的最小闭环很多团队做在线购物系统第一版都是「一台服务器 一个数据库 一个前端包」硬扛JDShop 这类项目也不例外。等到要上云问题就来了本地跑得好好的一上云就出现会话丢失、图片 404、下单超时。这不是代码写错了而是部署形态变了——本地是单进程共享内存云上是多实例 独立存储 负载均衡任何依赖「本机状态」的逻辑都会翻车。这篇笔记讲的就是 JDShop 在线购物系统云上部署的完整路径从镜像构建、数据库外置、会话共享到反向代理和健康检查每一步都给可复现的命令和参数。适合正在把单体电商项目往云上搬的后端和运维同学也适合想搞懂「云上部署到底和本地差在哪」的开发者。读完你能拿到一套能直接照着跑的最小闭环而不是一堆概念。2. 部署前必须想清楚的三个架构决策2.1 为什么 JDShop 不能直接 scp 上云就跑本地开发时JDShop 通常是一个 Spring Boot 或 Node 进程连本机 MySQL图片存本地upload/目录Session 存在 JVM 内存里。这套东西在单机上是自洽的但云上部署的第一原则是「实例无状态」。一旦你开了两个副本做负载均衡用户第一次请求打到实例 ASession 存在 A 的内存里第二次请求被转发到实例 BB 不认识这个 Session用户就被踢回登录页。图片同理A 实例上传的图片存在 A 的磁盘B 实例读不到前端就是一片 404。所以上云前必须先做三个决策Session 存哪里、文件存哪里、数据库连哪里。这三个问题的答案决定了后面所有配置。常见做法是 Session 外置到 Redis文件外置到对象存储数据库用云数据库或自建主从。下面逐个说清楚选型理由和落地方式。2.2 会话外置Redis 还是粘性会话粘性会话Sticky Session是最省事的方案在负载均衡上开启会话保持同一个用户的请求永远打到同一台后端。但它有两个硬伤一是实例扩容或重启时那台机器上的用户会话全丢二是流量倾斜热门用户集中在一台机器上负载均衡形同虚设。JDShop 这种有购物车和登录态的系统会话丢失直接等于用户重新登录体验很差。Redis 方案是把 Session 序列化后存到 Redis所有实例共享。Spring Boot 下引入spring-session-data-redis依赖配置几行就生效。代价是多了一次网络往返但内网 Redis 延迟通常在 1ms 以内对电商场景完全可接受。我一般会选 Redis并且给 Session 设置 30 分钟过期和业务侧的登录态保持一致。2.3 文件外置对象存储的接入方式JDShop 的商品图片、用户头像这类文件本地存upload/目录在云上必然出问题。对象存储是标准答案但接入方式有两种一种是应用直接调 SDK 上传返回 URL 存数据库另一种是挂载对象存储到本地目录应用无感知。前者更可控后者改动小但依赖 FUSE 挂载的稳定性。我倾向第一种。以阿里云 OSS 或腾讯云 COS 为例在 JDShop 的上传接口里替换掉FileOutputStream改成 SDK 的putObject返回的 URL 直接写进商品表。这样应用实例完全无状态扩容时不需要同步任何文件。下面是一个最小改动示例// 替换本地文件写入为对象存储上传 Value(${oss.endpoint}) private String endpoint; Value(${oss.bucket}) private String bucket; public String uploadImage(MultipartFile file) throws IOException { // 构造 OSS 客户端实际项目建议做成单例 Bean OSS ossClient new OSSClientBuilder().build(endpoint, accessKeyId, accessKeySecret); // 用 UUID 做对象名避免同名覆盖 String objectName jdshop/images/ UUID.randomUUID() .jpg; // 上传流不落地本地磁盘 ossClient.putObject(bucket, objectName, file.getInputStream()); ossClient.shutdown(); // 返回可公网访问的 URL存进商品表 return https:// bucket . endpoint / objectName; }这段代码的关键改动是把file.getInputStream()直接喂给对象存储不再经过本地磁盘。参数上endpoint填区域地址bucket填存储桶名objectName用 UUID 避免并发上传同名覆盖。注意OSSClient不要每次请求都新建生产环境应该做成单例 Bean 并配置连接池否则高并发下会频繁创建连接。2.4 数据库连接云数据库的白名单与连接池JDShop 的数据库上云最容易被忽略的是白名单和连接池。云数据库默认只允许同 VPC 内网访问你的应用实例必须和数据库在同一个 VPC否则连不上。连接池方面本地开发可能用默认配置云上必须显式设置maximumPoolSize因为云数据库有最大连接数限制连接池开太大反而会把数据库打满。以 HikariCP 为例典型配置是maximumPoolSize20、minimumIdle5、connectionTimeout30000。这个 20 不是拍脑袋是按「单实例 QPS × 平均查询耗时」估算的。如果单实例 100 QPS平均查询 50ms理论上需要 5 个连接留 4 倍余量就是 20。超过这个数要么加实例要么优化慢查询而不是继续加连接。3. 从镜像构建到反向代理的完整落地步骤3.1 用 Dockerfile 把 JDShop 打成可移植镜像云上部署的第一步是把 JDShop 打成镜像。很多人直接docker commit或者把 jar 包 scp 上去这两种做法都不可复现。正确做法是写 Dockerfile用多阶段构建减小镜像体积。下面是一个 Spring Boot 版 JDShop 的 Dockerfile# 第一阶段构建用 Maven 镜像编译 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build # 先拷 pom利用 Docker 层缓存依赖不变时不重复下载 COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests -B # 第二阶段运行只带 JRE镜像更小 FROM eclipse-temurin:17-jre WORKDIR /app # 从构建阶段拷 jar COPY --frombuilder /build/target/*.jar app.jar # 暴露应用端口 EXPOSE 8080 # 启动命令堆内存按容器限制的 75% 设置 ENTRYPOINT [java, -XX:MaxRAMPercentage75.0, -jar, app.jar]这个 Dockerfile 的核心是两阶段构建阶段用 Maven 镜像运行阶段只用 JRE最终镜像能控制在 200MB 左右。-XX:MaxRAMPercentage75.0让 JVM 自动按容器内存限制的 75% 设堆避免容器被 OOM Kill。注意COPY pom.xml和RUN mvn dependency:go-offline要放在COPY src之前这样改代码不会触发依赖重新下载构建速度快很多。3.2 环境变量注入别把密码写进镜像镜像里绝对不能有数据库密码、Redis 密码、对象存储密钥。这些通过环境变量注入云平台的容器服务都支持。JDShop 的application.yml里用占位符spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useSSLfalseserverTimezoneAsia/Shanghai username: ${DB_USER} password: ${DB_PASSWORD} redis: host: ${REDIS_HOST} port: ${REDIS_PORT} password: ${REDIS_PASSWORD}部署时在云平台控制台或 CI 流水线里设置这些变量。这样做的好处是同一个镜像可以部署到测试、预发、生产三套环境只换环境变量不用重新构建。注意serverTimezoneAsia/Shanghai要显式设置否则 MySQL 驱动可能按 UTC 解析时间导致订单时间差 8 小时这个坑我踩过。3.3 Nginx 反向代理与健康检查配置JDShop 前面通常挂一个 Nginx 做反向代理负责 TLS 终止、静态资源缓存和请求转发。云上部署时Nginx 可以单独跑一个容器也可以直接用云平台的负载均衡。如果自建 Nginx配置里要加健康检查路径让负载均衡知道实例是否存活upstream jdshop_backend { server 10.0.0.10:8080 max_fails3 fail_timeout30s; server 10.0.0.11:8080 max_fails3 fail_timeout30s; } server { listen 443 ssl; server_name shop.example.com; location / { proxy_pass http://jdshop_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 传递真实协议避免应用生成 http 链接 proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_read_timeout 30s; } # 健康检查端点不转发到后端 location /health { return 200 ok; add_header Content-Type text/plain; } }max_fails3 fail_timeout30s表示 30 秒内失败 3 次就把这台后端摘掉30 秒后再试。proxy_read_timeout 30s要大于应用的最长响应时间JDShop 的下单接口如果涉及库存扣减和订单写入可能超过 10 秒设太短会导致 504。健康检查路径/health直接返回 200不经过后端这样即使应用卡死Nginx 本身还能响应负载均衡的探测。3.4 数据库初始化与数据迁移JDShop 上云时数据库通常要新建实例并导入初始数据。步骤是先在云数据库控制台创建实例和账号拿到内网地址然后用mysqldump从本地导出再导入云数据库。注意导出时要加--single-transaction避免锁表导入时先建库再导数据# 本地导出--single-transaction 保证一致性且不锁表 mysqldump -u root -p --single-transaction --routines --triggers jdshop jdshop_dump.sql # 导入云数据库先建库 mysql -h ${DB_HOST} -u ${DB_USER} -p -e CREATE DATABASE jdshop DEFAULT CHARSET utf8mb4; mysql -h ${DB_HOST} -u ${DB_USER} -p jdshop jdshop_dump.sql--routines --triggers把存储过程和触发器一起导出JDShop 如果有这些对象漏掉会导致功能异常。utf8mb4字符集要显式指定否则 emoji 和部分生僻字会乱码。导入完成后用SELECT COUNT(*)核对几张核心表的行数确认数据完整。4. 云上部署最容易翻车的五个坑4.1 现象用户登录后刷新页面就退出登录原因Session 存在应用实例内存里负载均衡把请求分发到了另一台实例。这是云上部署最经典的翻车场景本地单机永远复现不了。解决引入spring-session-data-redis把 Session 外置到 Redis。配置spring.session.store-typeredis并确保所有实例连同一个 Redis。验证方法是登录后连续刷新多次观察是否稳定保持登录态。4.2 现象商品图片上传成功但前端显示 404原因图片存在实例 A 的本地磁盘前端请求被转发到实例 BB 的磁盘上没有这个文件。或者容器重启后本地磁盘被清空。解决文件上传改为对象存储返回公网可访问的 URL。如果暂时不能改代码至少要把upload/目录挂载到共享存储如 NAS但这是过渡方案长期还是走对象存储。4.3 现象下单接口偶发超时日志显示数据库连接等待原因连接池maximumPoolSize设得太大超过云数据库的最大连接数新连接被数据库拒绝或者设得太小高并发时请求排队。解决先查云数据库的最大连接数再按「单实例 QPS × 平均查询耗时 × 余量系数」估算连接池大小。同时开启慢查询日志排查是否有全表扫描。连接池不是越大越好超过数据库承载能力反而会雪崩。4.4 现象容器频繁重启日志显示 OOMKilled原因JVM 堆内存按物理机内存设置没有考虑容器限制。比如容器限制 2GBJVM 默认堆可能设到 4GB一启动就被 Kill。解决启动参数加-XX:MaxRAMPercentage75.0让 JVM 按容器内存限制自动算堆。同时检查是否有内存泄漏用jmap导出堆转储分析。注意MaxRAMPercentage在 JDK 10 以上才支持老版本要用-Xmx显式指定。4.5 现象部署后接口返回时间比本地慢很多原因应用和数据库不在同一区域跨区域访问延迟高或者没走内网走了公网。解决确保应用实例和数据库在同一个 VPC 和可用区用内网地址连接。云数据库的外网地址延迟通常是内网的 10 倍以上。另外检查是否开启了 SSL内网连接可以关掉 SSL 减少握手开销。5. 用健康检查探针和灰度发布把上线风险压到最低JDShop 上云后最怕的是「一发布全挂」。我现在的习惯是给容器配两个探针livenessProbe和readinessProbe。前者判断进程是否活着失败就重启容器后者判断应用是否准备好接收流量失败就从负载均衡摘掉。这两个探针的配置直接决定发布时的平滑程度。livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 30 periodSeconds: 5 failureThreshold: 2initialDelaySeconds要给足Spring Boot 启动加上数据库连接池初始化60 秒是保守值。readinessProbe的/health/ready端点应该检查数据库和 Redis 连接是否正常只有都通了才返回 200。这样新实例启动时不会立刻接流量避免「还没连上数据库就被打挂」。灰度发布方面云平台一般支持按比例分流。我的做法是先放 10% 流量到新版本观察 5 分钟重点看错误率和响应时间。如果错误率超过 1% 或 P99 超过 2 秒立即回滚。验证方法是用curl循环打接口统计成功率和延迟# 循环请求 100 次统计成功率和平均延迟 for i in $(seq 1 100); do curl -o /dev/null -s -w %{http_code} %{time_total}\n https://shop.example.com/api/products done | awk {sum$2; if($1200) ok} END {print 成功率:, ok/NR*100%, 平均延迟:, sum/NRs}这段脚本输出成功率和平均延迟灰度期间每 30 秒跑一次数据稳定再扩大流量。注意time_total包含网络传输时间如果延迟突然从 200ms 跳到 2s大概率是新版本有慢查询或锁竞争。最后说一个我自己的教训早期上云时我图省事把数据库密码写在了application.yml里一起打进镜像结果镜像被推到公共仓库密码泄露。后来改成环境变量注入并且给镜像仓库加了访问控制。云上部署没有后悔药每一步都要假设「这个配置会被人看到」。希望帮到你。本文还有配套的精品资源点击获取
