企业官网建设流程全解析

1. 项目全貌：模型服务化的“护栏工程”

上个月接到一个内部需求：把团队一直在本地跑着的 Deepseek Harness 从一个只有内网能访问的实验环境，搬到某云服务器上，并且要开放到公网给异地协作者调用。结果发现，“把服务跑起来”只是最轻松的一步，真正麻烦的是公网访问下的鉴权设计和安全体系。当时踩了一堆坑，今天把完整的部署流程、鉴权方案和排障过程整理出来，希望能帮你少走点弯路。

先说清楚这个 Deepseek Harness 到底是什么。它本质上是一个围绕 DeepSeek 模型的部署和调度框架，既负责加载模型、处理推理请求，也承担了请求路由、环境管理、调用日志这些和“模型本身没关系但又必须做”的杂活。你可以把它理解成模型和外部用户之间的一道管理走廊——模型只负责生成回答，至于谁在调用、调用了多少次、返回结果对不对、有没有超限，都由 Harness 来管。

这次部署的核心诉求有两个：第一，跨地域的团队成员需要通过公网访问服务；第二，服务不能裸奔在公网上，必须有完整的鉴权机制。说白了就是“别人能访问，但不能随便访问”。如果你也想在云服务器上把类似的大模型服务对外开放，下面这套方案可以直接参考。

2. 环境准备与基础架构设计

2.1 云服务器选型与系统初始化

先讲硬件选型。Deepseek Harness 如果在纯 CPU 模式下运行，推理速度会比较感人，所以建议尽量选择带 NVIDIA GPU 的云主机。我自己用的配置是 8 核 CPU、32GB 内存、一张 24GB 显存的显卡，跑 7B 量级的量化模型比较从容。如果只是做测试，4 核 16GB 内存加 CPU 也能跑起来，只是并发能力不要抱太大期望。

系统我选了 Ubuntu 22.04 LTS，一是 Docker 支持好，二是很多 AI 推理库对 Ubuntu 的兼容性最稳妥。购买云主机之后，第一件事就是更新系统包，然后创建普通用户，禁止 root 直接登录。很多新手习惯全程 root，后面 SSH 公网暴露就容易成为被爆破的目标，这个习惯要改。

apt update && apt upgrade -y useradd -m -s /bin/bash deploy usermod -aG sudo deploy passwd deploy

配置好跳板机或者本机的 SSH 公钥之后，修改/etc/ssh/sshd_config里的PermitRootLogin no，然后重启 SSH 服务，保证这个用户具备足够的操作权限，同时规避掉 root 的暴力破解风险。

2.2 架构设计与端口规划

服务不可能只有一个进程，我采用的是两层架构。外层是 Nginx，负责接收公网 HTTPS 请求，同时做第一道鉴权校验；内层是 Docker Compose 里的两个核心容器：harness 服务和模型推理引擎。容器之间通过内部网络通信，不直接暴露到公网。

请求链路大概是这样的：

公网用户 → HTTPS 443 → Nginx（鉴权+反向代理） → Harness 服务（业务鉴权+限流） → 模型推理引擎

端口规划要特别留意，表格我会反复提到：

很多部署翻车的根源就是端口暴露过多，比如直接把 8080 发出去，那鉴权就得完全依赖应用自身，一旦应用有漏洞就全裸奔了。所以安全组里只放行 443（80 只用于跳转），其余一概禁止公网访问。

2.3 安装基础组件

基础环境依赖 Docker 和 Docker Compose。我这边直接采用官方脚本安装 Docker，再安装 Compose 插件。

curl -fsSL https://get.docker.com | sh systemctl enable --now docker apt install docker-compose-plugin -y

国内云服务器直连 Docker Hub 经常拉取超时，建议配置镜像加速器。去云厂商的控制台找到容器镜像服务页面，复制专属加速地址，然后写入/etc/docker/daemon.json。

安装完成之后可以顺手验证一下：docker run hello-world如果顺利打印信息，说明 Docker 环境没问题。这一步虽然简单，但却是后续一切操作的地基。

3. 部署 Deepseek Harness 核心服务

3.1 模型准备与推理引擎配置

Deepseek Harness 本身不负责推理，它背后需要一个真正跑模型的推理引擎。这次部署中我选用的是 vLLM 方案，吞吐量比原生 Transformers 管线快得多，而且自带分页注意力机制，长文本输入时不至于内存暴涨。

模型文件我用的是 DeepSeek 的量化版本，具体来说是 4-bit 量化后的 GGUF 格式。为什么要强调量化？24GB 显存跑 7B 全精度会直接爆显存，而 4-bit 量化之后显存占用降到 8GB 左右，给并发请求留下了充足空间。

模型文件不要直接放在系统盘，因为我这台系统盘只有 80GB，模型和日志加起来很容易把它打满。我单独挂载了一块数据盘，格式化为 ext4 后挂载到/data，模型放在/data/models，日志放在/data/logs。

启动推理引擎之前，需要先验证显存驱动没问题。执行nvidia-smi看到显卡信息后，再启动 vLLM 容器：

docker run -d --name infer-engine \ --gpus all \ -v /data/models:/models \ -v /data/logs:/logs \ -p 127.0.0.1:11434:11434 \ your-registry/vllm-image \ --model /models/deepseek-7b-q4.gguf

这里有个很关键的细节：-p 127.0.0.1:11434:11434意味着推理引擎只监听本机，Docker 内的端口不会映射到公网。即使云服务器安全组放行所有端口，外部也访问不到它。这种“只在本机回环地址上监听”的方式，比单纯依赖防火墙更安全。

3.2 编写 Docker Compose 编排

为了让服务可以一键启停，我写了一个docker-compose.yml，核心服务一共三个：harness、推理引擎、Redis。

version: "3.8" services: harness: image: your-registry/deepseek-harness:latest container_name: harness environment: - MODEL_ENDPOINT=http://infer-engine:11434 - REDIS_ADDR=redis:6379 - API_SECRET_KEY=${HARNESS_SECRET_KEY} volumes: - /data/logs:/app/logs networks: - inner-net depends_on: - infer-engine - redis restart: unless-stopped infer-engine: image: your-registry/vllm-image:latest container_name: infer-engine runtime: nvidia environment: - CUDA_VISIBLE_DEVICES=0 volumes: - /data/models:/models networks: - inner-net restart: unless-stopped redis: image: redis:7-alpine container_name: harness-redis command: redis-server --appendonly yes volumes: - /data/redis:/data networks: - inner-net restart: unless-stopped networks: inner-net: driver: bridge

注意 harness 里我留了API_SECRET_KEY环境变量，这个值不要直接写在 yml 文件里，而是通过.env文件注入，`.env 文件需要加入 .gitignore，防止误上传。

3.3 配置 Nginx 反向代理与 HTTPS

Nginx 在云主机上直接以系统服务方式运行，不走 Docker 容器，这样排查网络问题时更直观。

首先安装 Nginx 和 Certbot：

apt install nginx certbot python3-certbot-nginx -y

然后申请证书。我这个域名提前解析到了云主机的公网 IP 上，所以直接用 Nginx 插件申请：

certbot --nginx -d your-domain.com

申请完成之后，再修改 Nginx 配置，核心反向代理配置如下：

server { listen 443 ssl http2; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

到这里，基础链路已经通了：用户通过 HTTPS 访问域名，Nginx 转发给本机 8080 端口上的 Harness 服务。但此刻公网还是“裸奔”的，后面这一步是重头戏。

4. 公网访问的鉴权体系设计

4.1 鉴权模型选择：API Key 还是 JWT

公网服务常见的鉴权方案有三种。

第一种是纯 API Key，客户端在请求头里带一个固定密钥，服务端比对一致就放行。优点是实现简单，缺点是密钥一旦泄露就形同虚设，而且无法控制哪些人可以调用。

第二种是 JWT 令牌，用户先登录换取短期 Token，后续请求带着 Token 访问。优点是令牌有生命周期，而且可以携带用户身份信息，缺点是需要在应用层维护签发和校验逻辑。

第三种是我这次实际采用的混合方案：API Key 用于身份识别，请求签名用于内容校验，IP 白名单用于边界限制。相当于三道门，即使某一层被绕过，其他层仍然有效。

这套混合方案的实现思路是：客户端每次请求时，把 API Key、时间戳、请求体内容一起做 HMAC-SHA256 签名，服务端用存储中的密钥计算出同样签名，两边一致才放行。时间戳超过两分钟直接拒绝，这样即使请求被截获，攻击者也很难重放。

4.2 实现鉴权中间件

我不打算把鉴权逻辑散落在各个业务接口里，而是在 Harness 服务的最外层封装一层中间件，所有请求都必须先经过鉴权过滤器。

这个中间件如果用 Python 写，核心逻辑大概长这样：

import hashlib import hmac import time SECRET_KEY = "your-secret-key" def verify_signature(api_key: str, timestamp: str, body: str, sign: str) -> bool: # 防重放限制 if abs(int(time.time()) - int(timestamp)) > 120: return False message = f"{api_key}{timestamp}{body}" expected = hmac.new(SECRET_KEY.encode(), message.encode(), hashlib.sha256).hexdigest() return hmac.compare_digest(expected, sign)

关键点是用了hmac.compare_digest而不是直接字符串比较。直接比较存在时序攻击的风险，攻击者通过响应时间差异可以逐步猜出正确签名，compare_digest会在常数时间内完成比较，在安全上多了一层保障。

API Key 的管理单独做了一张表，记录 key、所属用户名、创建时间、状态、最后调用时间。后台管理人员在创建密钥时，可以选择只允许该密钥访问某些特定模型接口，也可以设置过期时间，到期自动失效。

4.3 在 Nginx 层做第一道拦截

虽然应用层已经做了鉴权，但我还是习惯在 Nginx 层再加一道封锁，不是为了替代应用鉴权，而是为了将无效请求尽早拦截，降低应用层的无效计算压力。

这里使用了 Nginx 的auth_request模块。它允许你在请求转发给 Harness 之前，先向一个独立的鉴权服务发子请求，根据返回状态码决定放行还是拒绝。

location /api/ { auth_request /auth ; auth_request_set $auth_status $upstream_status; proxy_pass http://127.0.0.1:8080; } location = /auth { internal; proxy_pass http://127.0.0.1:8081/auth; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; }

这个独立鉴权服务部署在 8081 端口，只处理鉴权请求，不做任何业务。如果子请求返回 200，则继续向下游转发；如果返回 401 或 403，Nginx 直接拒绝客户端请求。这样做的优点是，以后想换鉴权算法，只需要改这个子服务，不需要动 Harness 主服务。

4.4 限流与并发控制

公网服务一旦开放，就一定会遇到恶意刷接口或者程序调用失控的情况。限流是必须做的。我用的方案是 Redis 令牌桶。

思路并不复杂：为每个 API Key 维护一个令牌桶，桶中初始有 N 个令牌，每处理一个请求消耗一个令牌，同时以固定速率向桶中添加令牌。如果桶已空，请求直接返回 429。

在 Harness 中接入 Redis 之后，核心逻辑如下：

import redis r = redis.Redis(host='redis', port=6379, decode_responses=True) def check_rate_limit(api_key: str) -> bool: key = f"ratelimit:{api_key}" current = r.get(key) if current is None: r.setex(key, 60, 10) # 限流窗口 60 秒，桶容量 10 return True if int(current) <= 0: return False r.decr(key) return True

部署初期可以把桶容量调高一些，观察正常调用峰值，再逐步收紧。我曾经见过团队一上来就把桶容量设置为 1，结果自己测试时频繁被限流，半天都排查不到原因，最后发现是限流配置太粗暴。

4.5 管理接口独立鉴权

除了普通 API 接口，Harness 还有一些管理接口，比如查看日志、更新模型配置、新建 API Key。这些接口绝对不能走同一套鉴权。

我在 Nginx 层把/admin/路径单独隔离出来，必须使用不同于普通 API Key 的管理员密钥，同时还要满足源 IP 白名单。管理员密钥每次请求都会校验，并且签发后只能绑定一个固定的 IP 地址，不绑定就拒绝访问。

这样一来，即使普通 API Key 泄露，攻击者也只能调用模型生成接口，无法接触系统管理和用户数据。管理面和数据面分离，是生产环境必须坚持的一条底线。

5. 安全加固与常见问题排查

5.1 云服务器安全组与防火墙加固

安全组是云服务器最外层的保护罩。我这次把安全组规则压缩到了最少：

同时云主机内部也启用 UFW 防火墙，安全组和安全组一致的口径，双重保障：

ufw default deny incoming ufw default allow outgoing ufw allow 443/tcp ufw allow 80/tcp ufw allow from 你的办公网IP to any port 22 ufw enable

SSH 服务还改到了非标准端口，并禁用密码登录。第一次部署完云主机后，我检查过/var/log/auth.log，结果总是有来自不同 IP 的 SSH 爆破尝试，所以这个习惯千万别偷懒。

5.2 常见部署问题速查表

几轮实操下来，我整理了最容易踩的坑，全部列进表格里：

5.3 日志与监控

鉴权服务、Nginx、Harness 三层的日志一定要分开，否则排查问题时你会陷入混沌。我统一把日志写到/data/logs下，按天分目录：

/data/logs/nginx/ /data/logs/harness/ /data/logs/infer-engine/

同时在 Harness 启动参数里开启访问日志，每条请求都记录用户标识、API Key 前缀、来源 IP、请求路径、耗时、状态码。一旦出现安全问题，这些日志就是最重要的追踪依据。

另外我还写了一个简单的健康检查脚本，每分钟调用一次/health接口，如果连续三次响应超时，就通过短信和邮件告警。这个接口不需要鉴权，但天然也暴露在公网，所以我给它的响应体故意不包含任何版本号、进程路径、依赖库信息，只返回一个 200 状态码，越少的信息越安全。

6. 上线后的运维小技巧

6.1 HTTPS 证书自动续期

Let‘s Encrypt 证书有效期只有三个月，必须设置自动续期。certbot renew本身支持定时任务，但直接执行默认命令对 Nginx 重启时机不够友好，我写了一个续期脚本：

#!/bin/bash certbot renew --quiet --deploy-hook "nginx -s reload"

然后把它加到 cron：

0 4 * * 1 /opt/scripts/renew_cert.sh >> /var/log/renew-cert.log 2>&1

每周一凌晨四点检查一次，到期前自动续期并平滑重载 Nginx。证书文件更新不会导致服务中断，但如果不执行 reload，新证书不会生效。

6.2 模型平滑升级与回滚

升级模型肯定不能直接杀掉容器，否则正在处理中的请求会全部中断。我用了一套双副本策略：先把新模型部署到推理引擎 B 容器中，预热完成后，把 Nginx 的上游从引擎 A 切换到引擎 B，确认稳定后，再下线引擎 A。整个过程请求有秒级抖动，但不会中断。

回滚同样平滑：只需要再把 Nginx 改回引擎 A 即可。如果 Harness 服务本身升级，我首先在测试环境把所有鉴权流程走一遍，特别要确认新版本没有改变签名数据拼接格式。这类兼容性问题最隐蔽，表面看起来一切正常，但线上请求全部 401。

6.3 成本控制与接口预警

模型服务跑在云服务器上，每一秒都在产生费用。我给自己设了三个预警线：首先是每日请求量，如果超过前一天峰值的 200% 就触发告警；其次是平均推理耗时，如果耗时持续高于设定阈值，可能说明模型被大量长文本请求挤压，需要扩容或限流；最后是带宽峰值，如果某个 API Key 持续大流量调用，可能是程序失控，需要主动排查调用日志。

还有一个容易被忽略的点：模型被反复调用也会产生大量 token 消耗。配置一个 token 计数的中转层，把每个请求的输入输出 token 数都统计下来，按用户维度汇总日报。这样做既能优化成本，也能发现潜在的不合理调用模式。

这次部署下来，我个人的体会是：部署大模型服务本身并不难，真正体现工程能力的是鉴权架构和安全边界的设计。所有环节都围绕一个核心原则——服务可以对外开放，但每一步都要有明确的身份确认和行为审计。如果你想在云服务器上开放自己的模型能力，上面这套流程可以直接复用，尤其在鉴权这一层，宁可多设几道门槛，也别心存侥幸。