保康进销存与智慧餐厅共机部署及维护总结

整理日期：2026年10月16日。服务器：192.168.1.211。本文用于交付说明和日常维护，详细步骤见部署过程、部署结果及运维手册。

一本次部署结论

一台服务器承载进销存和智慧餐厅前厅，两套系统分别使用独立的Nginx服务、MySQL实例和Redis实例。隔离的是服务入口、端口、配置和数据目录；不能把同一服务器理解为可以共用或覆盖全部运行环境。

目前已收到组件隔离成功的证据，但没有收到所有最终业务及重启验收结果。本文不代表两套业务已经全部验收通过，也没有在整理时重新连接服务器检查。

二两套系统的部署关系

项目	进销存	智慧餐厅前厅
网页入口	http://192.168.1.211:8000/；供应商端9000	http://192.168.1.211:4200/dist/#/login
Nginx服务	nginx	zhct-nginx
Nginx程序	/usr/sbin/nginx	/usr/local/nginx/sbin/nginx
Nginx配置	/etc/nginx/nginx.conf	/usr/local/nginx/conf/nginx.conf及vhost目录
MySQL服务	mysqld，MySQL8.0.46	mysql，MySQL5.6.51
MySQL端口	3306	3307
MySQL配置	/etc/my.cnf及/etc/my.cnf.d/	/etc/zhct-mysql56.cnf
MySQL数据目录	/var/lib/mysql	/usr/local/mysql/var
MySQL Socket	/var/lib/mysql/mysql.sock	/tmp/zhct-mysql56.sock
Redis服务	redis	zhct-redis
Redis端口	6379	127.0.0.1:6380
Redis配置	/etc/redis.conf	/etc/zhct-redis.conf
Redis数据目录	/var/lib/redis	/var/lib/zhct-redis
后端运行方式	Supervisor管理Java	php-fpm及php-fpm7.4

进销存后端配置端口：portal8670、merchant8682、admin8600；最终监听与功能需要实测。智慧餐厅AI API仅监听127.0.0.1:81，经主站/aizhct/转发。LNMP默认页仅本机18080，不是业务入口。

食安192.168.5.45属于外部依赖，不能随本次网站地址或数据库端口批量替换。

三本次实际部署和故障恢复

1 业务包与目录

文件或对象	部署位置或用途
zhct_229.tgz	前厅store，/workspace/wwwroot/zhct_local/project
aizhct_117.tgz	AI API，/workspace/wwwroot/aizhct_local/project
store_25.tgz	AI前端，目标主站public/store；最终发布待验
static.zip	独立图片资源，主站public/static/upload
zhct_bkzx	前厅实际商户及主数据库
aizhct_bkzx	AI实际商户及数据库

目录中的local是部署路径命名，不要求将商户改成local。229包已有前端构建产物，不需要为了部署现成版本再次构建。制作新版本仍需重新构建对应前端，保留现场配置并检查数据库迁移。

主数据库导入后显示256张表，AI数据库163张表。表数量只能证明导入结果，不证明229所需迁移完整。

2 共机环境冲突

服务器原来已有进销存。本次执行LNMP安装器后，安装器新增的/etc/systemd/system/nginx.service优先于原发行版服务，导致nginx服务改为启动我们的程序；其默认站点也监听80。

安装日志还明确显示原MySQL8.0.46被卸载，另装MySQL5.6；进销存Redis认证与新配置不匹配。后端因此出现数据库认证异常、Redis invalid password、业务端口未监听，网页接口返回502。

此前按空服务器前提执行安装，没有充分保护已有业务，这是本次部署方法需要修正的核心问题。仅放开20.03环境包的版本检查，不构成24.03共机兼容性验证。

3 隔离和恢复

Nginx：恢复进销存nginx服务；我们的服务独立为zhct-nginx，网站4200、AI本机81；默认页改为本机18080。
MySQL：备份原数据，恢复同版本MySQL8.0到3306；我们的MySQL5.6独立配置、数据目录和Socket，迁到3307。
Redis：备份当前6379数据后，新建我们使用的6380实例；进销存保留6379并按其原配置核对密码。6380为空实例，旧队列尚需核对，不视为迁移完成。
登录：前厅曾因Redis NOAUTH和MySQL1045失败，修复后出现已登录业务页面。隔离后所有连接仍需重新验证。
图片：图片包独立解压；浏览器请求127.0.0.1曾命中Windows本机IIS，需使用带4200的网站资源地址。

4 重启后的访问问题

重启后Nginx已启动、/workspace挂载正常，本机4200返回200；Windows电脑能ping服务器，但4200和8000均超时。现场iptables规则只允许已建立连接、ICMP、loopback、SSH22，其后REJECT拒绝网页请求。

已给出仅对批准局域网放行4200/8000/9000并持久化的命令，但未收到最终执行和再次重启验证结果。firewalld未运行，不代表iptables不存在规则。

四下次日常维护怎么做

1 先检查再操作

以下在服务器SSH会话中执行：

systemctl --failed --no-pager
systemctl is-active nginx zhct-nginx mysqld mysql redis zhct-redis php-fpm php-fpm7.4 supervisor
systemctl is-enabled nginx zhct-nginx mysqld mysql redis zhct-redis php-fpm php-fpm7.4 supervisor
findmnt -T /workspace
ss -lntp | grep -E ':(4200|8000|9000|3306|3307|6379|6380|8670|8682)[[:space:]]'

active只表示服务状态，enabled只表示开机策略；两者都不等于业务验收通过。继续从电脑分别登录两套系统，检查核心业务、图片、AI接口和后台任务。

2 只管理对应服务

修改Nginx配置先检查，成功后再重载：

# 进销存
/usr/sbin/nginx -t && systemctl reload nginx
# 智慧餐厅
/usr/local/nginx/sbin/nginx -t && systemctl reload zhct-nginx

故障需要重启时，只操作所属服务：进销存Nginx用nginx，前厅用zhct-nginx；MySQL8用mysqld，MySQL5.6用mysql；6379用redis，6380用zhct-redis。

进销存Java由Supervisor管理：

/usr/local/python3.9/bin/supervisorctl -c /etc/supervisor/supervisord.conf status

确认依赖和维护窗口后，才对hcgj-portal-1或hcgj-merchant-1单独重启；不要重复java -jar，不restart all。不要使用lnmp start/stop/restart或killall nginx管理共享服务器。

3 更新和备份

更新前备份代码、商户配置及数据库；校验包版本、SHA256、包根目录和SQL迁移。普通更新不使用reset-database，不运行旧环境安装器，不覆盖另一系统配置。

两套数据库分别用匹配版本的工具备份。物理目录拷贝需要停目标实例或一致性快照，不能复制运行中的目录冒充完整备份。恢复前保护新增业务数据，先在隔离环境验证。

当前历史恢复备份：

内容	位置	说明
原MySQL8数据	/home/workspace/mysql8-recovery-20261014-190015/mysql	252MB，不等于完整业务恢复已验证
Redis数据与配置	/home/workspace/redis-recovery-20261014-192908	244KB，是LNMP安装之后的快照，不是安装前原状态

备份应另做加密异机保存；当前同机副本无法抵御整机损坏。不要把数据库、密钥或口令复制到普通文档包。

4 遇到故障先分层定位

现象	优先检查
本机200、电脑超时	端口监听、iptables、网络访问网段
接口502	Nginx upstream、目标端口、后端启动日志
Java RUNNING却无接口端口	MySQL/Redis依赖和Java启动异常
MySQL1045	连接实例3306或3307、业务账号和密码
Redis认证失败	6379或6380及对应密码，不关闭认证
图片缺失	完整URL、static文件、权限、ossHost是否带4200
重启后异常	挂载、启动依赖、自启动、防火墙持久化

Windows本机只执行ssh/scp/Test-NetConnection/curl.exe；Linux systemctl/iptables等必须在登录服务器后执行。密码输入不回显正常，导入SQL结束返回Shell正常。

五下次在已有进销存的服务器部署

1. 先盘点已有业务。核对系统、端口、服务、软件版本、数据目录、Supervisor及防火墙，不能因服务器新采购就假定没有部署。 2. 先备份并明确恢复。记录两系统负责人、维护窗口、原数据库版本、原程序包、配置及可恢复备份。 3. 提前冻结资源。进销存保留原端口和数据；前厅从第一天使用4200、3307、6380和独立服务，AI入口本机81；若有其他占用先重新分配。 4. 选择隔离方案。优先独立虚拟机；同机时使用经过验证的容器栈或独立前缀组件。本次旧20.03一键包不能原样作为24.03共机安装器。 5. 审查所有安装动作。不得卸载对方MySQL，不重写同名服务或原配置，不操作已有数据库目录；安装器内部脚本也要审查。 6. 部署代码和数据。校验产物，先暂存再发布；仅初始化本系统新空库，保留bkzx商户配置，补齐独立图片和AI前端。 7. 两套业务同时验收。先留进销存基线，部署后对比；验证登录、数据读写、主要业务、AI、图片上传、队列及定时任务。 8. 最后验收重启。保存端口放行规则，检查服务enable、/workspace挂载依赖及应用等待机制，在维护窗口重启，再从远程电脑复验两套业务。

六交付前仍需确认

前厅主库及ai_zhct连接3307的最终证据；AI配置和前厅Redis6380已有截图，不能代替全部连接验证。
进销存hcgj_prod业务数据可读、原账号可用；6379认证匹配、8670/8682监听和登录成功。
图片使用正确资源地址并HTTP200，AI API和store25前端可用。
旧Redis队列迁移或处置、消费者及Cron实际运行；不能直接FLUSHALL。
网页防火墙规则已经执行、保存且重启后有效；重启后所有服务和业务重新通过。

本次组件隔离已取得成功证据，以上业务和重启验收尚未全部闭环。后续结果应回填《部署结果》验收表，而不是把当前总结当作验收签字。