在测试环境或本地开发环境里，直接调用真实Jira接口并不是一件省心的事。权限申请流程繁琐、测试数据写入后难以清理、网络策略限制集群内访问外部服务，这些问题都会拖慢联调和自动化测试的进度。用一个Node.js写的Mock服务把Jira的核心接口模拟出来，再部署到K8s集群里，团队就能拿到一套完全可控、随时重置的“假Jira”。本文完整讲解实现思路和落地步骤。
一、梳理Jira接口协议，确定Mock范围
做Mock之前先要明确模拟哪些接口。Jira的REST API以/rest/api/2为前缀，最常用的包括：根据Key获取Issue的GET /rest/api/2/issue/:issueKey、创建Issue的POST /rest/api/2/issue、搜索的POST /rest/api/2/search（JQL查询）、添加评论的POST /rest/api/2/issue/:issueKey/comment以及工作流状态流转的POST /rest/api/2/issue/:issueKey/transitions。这五类接口覆盖了绝大部分自动化测试和联调场景。
Mock的关键在于响应结构必须和真实Jira一致，否则上层代码在解析字段时会直接报错。建议先在真实环境用Postman或curl把每个接口的响应JSON抓下来，保存为模板文件。尤其是Issue对象里嵌套的fields结构，包含status、assignee、issuetype等复杂嵌套对象，这些字段的结构层级一定要原样保留，值可以替换成模拟数据。
另一个容易被忽略的点是错误响应。真实Jira在Issue不存在时返回404，响应体中有errorMessages和errors两个字段。如果Mock服务只返回一个简单的字符串，依赖错误码做重试的业务代码就会行为异常。所以Mock层要完整模拟Jira的错误协议，包括400参数校验失败、401未认证、404不存在等。
二、用Express实现Mock服务核心逻辑
服务端框架选Express就够了，轻量且生态成熟。数据存储采用内存Map加JSON文件的组合：内存Map保证读写性能，JSON文件用于持久化，服务重启后数据不丢失。下面是核心实现骨架：
const express = require('express');
const fs = require('fs');
const app = express();
app.use(express.json());
// 数据存储：issueKey 到 issue 对象的映射
let issues = new Map();
// 从文件恢复数据
if (fs.existsSync('./data/issues.json')) {
const arr = JSON.parse(fs.readFileSync('./data/issues.json', 'utf8'));
arr.forEach(item => issues.set(item.key, item));
}
function persist() {
fs.writeFileSync('./data/issues.json',
JSON.stringify([...issues.values()], null, 2));
}
// 获取单个Issue
app.get('/rest/api/2/issue/:issueKey', (req, res) => {
const issue = issues.get(req.params.issueKey);
if (!issue) {
return res.status(404).json({
errorMessages: ['Issue does not exist or you do not have permission to see it.'],
errors: {}
});
}
res.json(issue);
});
// 创建Issue
let seq = 100;
app.post('/rest/api/2/issue', (req, res) => {
const { fields } = req.body;
if (!fields || !fields.summary) {
return res.status(400).json({
errorMessages: [],
errors: { summary: 'Summary is required' }
});
}
const key = 'MOCK-' + (++seq);
const issue = {
id: String(seq),
key,
fields: {
summary: fields.summary,
issuetype: { name: fields.issuetype ? fields.issuetype.name : 'Task' },
status: { name: 'To Do' },
assignee: null,
created: new Date().toISOString()
}
};
issues.set(key, issue);
persist();
res.status(201).json({ id: issue.id, key, self: 'http://mock-jira/rest/api/2/issue/' + key });
});
// JQL搜索（简化版：只支持 key = XXX 和 summary ~ 关键字）
app.post('/rest/api/2/search', (req, res) => {
const { jql, maxResults = 50 } = req.body || {};
let result = [...issues.values()];
if (jql) {
const keyMatch = jql.match(/key\s*=\s*(\w+-\d+)/);
if (keyMatch) result = result.filter(i => i.key === keyMatch[1]);
const sumMatch = jql.match(/summary\s*~\s*"?([^"]+)"?/);
if (sumMatch) {
result = result.filter(i => i.fields.summary.includes(sumMatch[1]));
}
}
res.json({
startAt: 0,
maxResults,
total: result.length,
issues: result.slice(0, maxResults)
});
});
// 状态流转
app.post('/rest/api/2/issue/:issueKey/transitions', (req, res) => {
const issue = issues.get(req.params.issueKey);
if (!issue) return res.status(404).json({ errorMessages: ['Issue not found'], errors: {} });
const target = req.body.transition;
const map = { 11: 'In Progress', 21: 'Done', 31: 'To Do' };
if (target && map[target.id]) {
issue.fields.status = { name: map[target.id] };
persist();
}
res.json({});
});
app.listen(3000, () => console.log('Mock Jira listening on 3000'));除了基本增删改查，还建议加两个实用功能。第一是响应延迟注入，通过环境变量MOCK_DELAY给所有响应加固定延迟，用来测试上层代码的超时和重试逻辑。第二是错误注入接口，比如POST /mock/admin/fail?rate=0.3，让Mock服务按30%的概率随机返回500，模拟真实网络抖动。这两个能力对混沌测试特别有价值。
数据重置也很重要。测试跑完之后需要一键清空所有模拟数据，可以暴露一个POST /mock/admin/reset接口，清空内存Map并重写JSON文件，让每次测试都从干净的初始状态开始，避免数据累积导致的测试结果不可重复。
三、容器化并部署到K8s集群
服务写好之后，先打包成Docker镜像。Node.js镜像推荐用node:20-alpine作为基础镜像，体积小、拉取快。注意JSON数据文件要挂载出来，不能写死在镜像层里：
FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm install --production COPY . . EXPOSE 3000 CMD ["node", "server.js"]
K8s部署的关键点是数据持久化和健康检查。如果只跑单实例，可以用一个挂载PVC或者hostPath的Deployment；如果要多副本，内存Map就不适用了，最简单的办法是引入Redis作为共享存储，或者干脆限制Mock服务为单实例并合理设置资源。下面是单实例部署清单：
apiVersion: apps/v1
kind: Deployment
metadata:
name: mock-jira
spec:
replicas: 1
selector:
matchLabels:
app: mock-jira
template:
metadata:
labels:
app: mock-jira
spec:
containers:
- name: mock-jira
image: your-registry/mock-jira:1.0.0
ports:
- containerPort: 3000
readinessProbe:
httpGet:
path: /mock/health
port: 3000
initialDelaySeconds: 5
volumeMounts:
- name: data
mountPath: /app/data
volumes:
- name: data
emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
name: mock-jira
spec:
selector:
app: mock-jira
ports:
- port: 80
targetPort: 3000部署完成后，集群内其他服务通过http://mock-jira/rest/api/2/...这个稳定的服务地址访问Mock接口。如果外部也需要访问，可以再补一个Ingress规则。健康检查接口/mock/health要单独实现，直接返回200即可，不要依赖业务数据，这样Pod重启时 readiness 探针能快速通过。
四、进阶优化与踩坑建议
第一，配置热更新。Mock的响应模板、延迟参数、错误率等配置如果硬编码在代码里，每次调整都要重新构建镜像，非常低效。建议把这些配置放到ConfigMap中，挂载为JSON文件，配合fs.watch监听文件变化，实现改配置秒级生效而不用重启Pod。
第二，JQL解析的坑。Jira的JQL语法很复杂，支持AND、OR、ORDER BY等操作符，完整实现成本很高。实践中建议只覆盖团队实际用到的查询模式，通常key =、project =、status =和summary ~这几种就够了。千万不要试图引入完整的语法解析器，投入产出比太低。
第三，认证模拟。有些上层代码依赖Jira返回的认证头或者用户信息接口，可以在Mock层实现GET /rest/api/2/myself返回一个固定的虚拟用户，并且在中间件里对带Basic Auth的请求做宽松校验——无论什么凭证都放行，这样上层代码的认证逻辑能正常走通，又不会因为Mock环境没有真实账号而卡住。
整体而言，这套方案的核心价值在于把外部依赖收敛为集群内部一个可控的服务，测试数据随时可造、随时可清，联调不再受制于真实Jira的权限和网络。实现成本大概一两天，但对自动化测试稳定性的提升非常明显，值得在团队内推广落地。