Node.js HTTP服务转发gRPC服务：参数校验究竟应该放在哪里？

在Node.js中构建HTTP服务并转发请求到gRPC服务时，参数校验的位置是一个关键的设计决策。参数校验可以放在HTTP层、gRPC层，或者两者都进行校验。具体选择取决于你的应用场景和需求。以下是几种常见的做法及其优缺点：

1. 在HTTP层进行参数校验

位置：在HTTP服务接收到请求后，调用gRPC服务之前。

优点： - 快速失败：如果参数不合法，可以在HTTP层直接返回错误响应，避免不必要的gRPC调用。 - 简化gRPC服务：gRPC服务可以专注于业务逻辑，而不需要处理参数校验。 - 用户体验：可以在HTTP层返回更友好的错误信息，便于前端处理。

缺点： - 重复校验：如果gRPC服务也被其他客户端直接调用，可能需要在gRPC层再次进行校验。 - 维护成本：如果HTTP层和gRPC层的校验逻辑不一致，可能会导致问题。

实现示例：

const express = require('express');
const { validateRequest } = require('./validators');

const app = express();
app.use(express.json());

app.post('/api/resource', (req, res) => {
    const validationResult = validateRequest(req.body);
    if (!validationResult.valid) {
        return res.status(400).json({ error: validationResult.errors });
    }

    // 调用gRPC服务
    grpcClient.createResource(req.body, (err, response) => {
        if (err) {
            return res.status(500).json({ error: err.message });
        }
        res.status(200).json(response);
    });
});

app.listen(3000, () => {
    console.log('HTTP服务已启动，监听端口3000');
});

2. 在gRPC层进行参数校验

位置：在gRPC服务接收到请求后，执行业务逻辑之前。

优点： - 一致性：无论请求来自HTTP服务还是其他gRPC客户端，校验逻辑都是一致的。 - 安全性：确保所有请求都经过校验，避免绕过HTTP层的校验。

缺点： - 性能开销：每个请求都需要经过gRPC层的校验，即使参数在HTTP层已经校验过。 - 错误信息：gRPC层的错误信息可能不如HTTP层的友好，前端处理起来可能不太方便。

实现示例：

function createResource(call, callback) {
    const validationResult = validateRequest(call.request);
    if (!validationResult.valid) {
        return callback({
            code: grpc.status.INVALID_ARGUMENT,
            message: validationResult.errors.join(', ')
        });
    }

    // 执行业务逻辑
    const resource = createResourceInDB(call.request);
    callback(null, resource);
}

3. 在HTTP层和gRPC层都进行参数校验

位置：在HTTP层和gRPC层都进行参数校验。

优点： - 双重保障：确保参数在任何情况下都经过校验，避免遗漏。 - 灵活性：HTTP层可以返回更友好的错误信息，而gRPC层确保业务逻辑的安全性。

缺点： - 冗余：增加了代码的复杂性和维护成本。 - 性能开销：每个请求都需要经过两次校验，增加了处理时间。

实现示例：

// HTTP层
app.post('/api/resource', (req, res) => {
    const validationResult = validateRequest(req.body);
    if (!validationResult.valid) {
        return res.status(400).json({ error: validationResult.errors });
    }

    // 调用gRPC服务
    grpcClient.createResource(req.body, (err, response) => {
        if (err) {
            return res.status(500).json({ error: err.message });
        }
        res.status(200).json(response);
    });
});

// gRPC层
function createResource(call, callback) {
    const validationResult = validateRequest(call.request);
    if (!validationResult.valid) {
        return callback({
            code: grpc.status.INVALID_ARGUMENT,
            message: validationResult.errors.join(', ')
        });
    }

    // 执行业务逻辑
    const resource = createResourceInDB(call.request);
    callback(null, resource);
}

4. 使用中间件或共享校验逻辑

位置：将校验逻辑抽象为独立的模块，可以在HTTP层和gRPC层共享。

优点： - 代码复用：减少重复代码，提高维护性。 - 一致性：确保HTTP层和gRPC层的校验逻辑一致。

缺点： - 耦合：HTTP层和gRPC层共享校验逻辑，可能会增加模块间的耦合。

实现示例：

// 共享校验逻辑
function validateRequest(data) {
    const errors = [];
    if (!data.name) errors.push('Name is required');
    if (!data.email) errors.push('Email is required');
    return { valid: errors.length === 0, errors };
}

// HTTP层
app.post('/api/resource', (req, res) => {
    const validationResult = validateRequest(req.body);
    if (!validationResult.valid) {
        return res.status(400).json({ error: validationResult.errors });
    }

    // 调用gRPC服务
    grpcClient.createResource(req.body, (err, response) => {
        if (err) {
            return res.status(500).json({ error: err.message });
        }
        res.status(200).json(response);
    });
});

// gRPC层
function createResource(call, callback) {
    const validationResult = validateRequest(call.request);
    if (!validationResult.valid) {
        return callback({
            code: grpc.status.INVALID_ARGUMENT,
            message: validationResult.errors.join(', ')
        });
    }

    // 执行业务逻辑
    const resource = createResourceInDB(call.request);
    callback(null, resource);
}

总结

• HTTP层校验：适合需要快速失败和提供友好错误信息的场景。
• gRPC层校验：适合需要确保所有请求都经过校验的场景。
• 双重校验：适合对安全性要求极高的场景，但会增加复杂性和性能开销。
• 共享校验逻辑：适合需要代码复用和一致性的场景。

根据你的具体需求和项目复杂度，选择合适的校验策略。