一、部署环境概览:系统架构总览、部署环境要求(硬件/软件/网络)、部署流程全景图
各位同学,咱们今天正式开讲《在线学习投资系统》的部署手册。我是你们的老朋友,一个在运维坑里摸爬滚打十来年的老兵。说实话,每次接手一个新系统的部署,我第一件事不是看代码,而是先搞清楚两件事:这系统长什么样? 和 我要把它放在什么样的环境里?
嗯,今天这一章,咱们就把这两件事彻底聊透。你想想看,如果连地图都没看清就急着上路,那大概率是要翻车的。我个人习惯,在动手之前,先画一张全景图,把所有的组件、依赖、网络关系都摆到桌面上。这样心里才有底。
核心要点: 部署不是简单的“把代码扔到服务器上”。它是一个系统工程,涉及硬件选型、软件版本匹配、网络规划、安全策略等多个维度。本章就是帮你建立这个全局视角。
1.1 系统架构总览:一张图看懂所有组件
咱们这个在线学习投资系统,说白了就是一套“教你怎么管钱”的SaaS平台。它不像电商系统那么重,但涉及金融数据,对稳定性和安全性的要求可不低。我当年部署第一个金融类项目时,就因为低估了网络延迟,导致行情数据推送慢了3秒,被老板骂得狗血淋头。所以,架构设计阶段,一定要把性能瓶颈想清楚。
下面这张图,是我用SVG手绘的系统架构总览图。它清晰地展示了前端、后端、数据层、中间件以及外部接口之间的调用关系。你可以把它当作你部署工作的“作战地图”。
从这张图里,你能看到几个关键层次:
- 接入层: 用户通过Web或App访问,首先到达负载均衡器。这里我建议用Nginx,配置灵活,性能也够用。
- 应用层: 业务逻辑都在这里。我们拆成了多个微服务,比如用户服务、课程服务、支付服务。这样做的好处是,哪个服务压力大,就单独扩哪个。
- 数据层: 包括MySQL主库、Redis缓存和RabbitMQ消息队列。注意,MySQL我们用的是主从架构,读写分离。这是金融类系统的标配。
- 外部依赖: 比如实时行情接口、第三方支付网关。这些接口的稳定性不在我们控制范围内,所以一定要做好熔断和降级。
我的经验: 在画架构图时,别忘了把监控系统和日志系统也画进去。很多新手容易忽略这一点。我曾经因为没画监控,导致一个节点挂了半小时才发现,那叫一个惨。建议用Prometheus + Grafana做监控,ELK做日志收集。
1.2 部署环境要求:硬件、软件与网络
架构图看完了,咱们聊聊“地基”——部署环境。说白了,就是你的服务器得长什么样,装什么系统,网络怎么通。这部分我踩过的坑最多,咱们一个一个说。
1.2.1 硬件要求
硬件选型,核心看并发量和数据量。咱们这个系统初期预估是日均1000用户在线,峰值并发200左右。基于这个量级,我给出以下建议配置:
| 组件 | CPU | 内存 | 磁盘 | 数量 | 备注 |
|---|---|---|---|---|---|
| 负载均衡 | 4核 | 8G | 40G SSD | 2台 | 一主一备,避免单点 |
| 应用服务器 | 8核 | 16G | 100G SSD | 3台 | 初期3台,后续可水平扩展 |
| MySQL主库 | 8核 | 32G | 500G SSD | 1台 | 读写分离,主库性能要强 |
| MySQL从库 | 4核 | 16G | 500G SSD | 2台 | 分担读压力 |
| Redis集群 | 4核 | 16G | 100G SSD | 3台 | 至少3节点,保证高可用 |
| 消息队列 | 4核 | 8G | 100G SSD | 2台 | 镜像队列模式 |
⚠️ 避坑指南: 我曾经为了省钱,给MySQL从库用了机械硬盘。结果高峰期查询延迟飙到5秒,用户直接投诉。记住,所有数据库和中间件节点,必须用SSD。这是底线,没得商量。
1.2.2 软件环境
软件版本这块,我建议统一使用LTS(长期支持)版本。别追新,稳定压倒一切。以下是咱们这次部署的软件清单:
- 操作系统: CentOS 7.9 或 Ubuntu 20.04 LTS。我个人更倾向CentOS,因为生产环境里它更常见,坑也少。
- 应用运行环境: JDK 11 (LTS) + Maven 3.8。Node.js 16.x (如果前端需要本地构建)。
- 数据库: MySQL 8.0.28 + Redis 6.2.6。
- 中间件: Nginx 1.20 + RabbitMQ 3.9。
- 容器化(可选): Docker 20.10 + Docker Compose。如果你团队运维能力一般,我建议先用Docker Compose做编排,别一上来就上K8s,容易失控。
1.2.3 网络规划
网络是部署中最容易被忽视的环节。你想想看,如果应用服务器连不上数据库,那代码写得再好也没用。咱们的网络规划如下:
- 内网互通: 所有服务器必须在同一个VPC内,通过内网IP通信。千万别用公网IP连数据库,延迟高还不安全。
- 端口规划:
- 应用服务:8080 (HTTP) / 8443 (HTTPS)
- MySQL:3306(仅内网开放)
- Redis:6379(仅内网开放)
- RabbitMQ:5672(业务端口),15672(管理界面,仅运维网段开放)
- Nginx:80/443(对外暴露)
- 安全组策略: 遵循最小权限原则。比如,只有负载均衡器能访问应用服务器的8080端口,应用服务器才能访问数据库的3306端口。其他一律拒绝。
我的小技巧: 在正式部署前,先用 telnet 或 nc 命令测试一遍所有端口的连通性。别问我为什么强调这个——我曾经因为防火墙规则写错了,导致应用连不上Redis,排查了整整一个下午。最后发现是安全组里少放行了6379端口。嗯,这种低级错误,犯一次就够了。
1.3 部署流程全景图:从0到1的完整路径
好了,架构和环境都清楚了,咱们来看看整个部署流程长什么样。我把整个过程分成了7个阶段,每个阶段都有明确的输入和输出。你跟着这个流程走,基本不会出大错。
这7个阶段,咱们在后续的章节里会一个一个拆开来讲。这里我先简单说一下每个阶段的核心任务:
- 环境准备: 装系统、配网络、装Docker。这是最基础的一步,也是出错率最高的一步。我建议用自动化脚本(比如Ansible)来做,别手动一台一台配。
- 数据库部署: 搭建MySQL主从,创建数据库和用户,导入初始数据。注意,主从延迟一定要监控起来。
- 中间件部署: 部署Redis集群和RabbitMQ。记得配置持久化和高可用。
- 应用部署: 从代码仓库拉取代码,用Maven打包,然后发布到应用服务器。这里要特别注意配置文件的分离——开发、测试、生产环境的配置不能混在一起。
- 负载均衡: 配置Nginx反向代理,挂载SSL证书,设置健康检查。嗯,SSL证书别忘了续期,我见过太多因为证书过期导致服务挂掉的案例了。
- 监控部署: 部署Prometheus采集指标,Grafana展示面板。至少要把CPU、内存、磁盘、网络、数据库连接数、QPS这些核心指标监控起来。
- 验收测试与上线: 做一轮完整的冒烟测试,确认所有功能正常。然后切换DNS,正式上线。
总结一下: 部署不是一锤子买卖,而是一个持续迭代的过程。今天咱们把架构、环境和流程都理清了,相当于把地图和工具都准备好了。下一章开始,咱们就正式进入实战环节——从环境准备开始,一步步把系统跑起来。