我正在使用express.js。当有人尝试记录消息时，我需要能够记录某些请求数据。为此，我想创建一个帮助方法，如下所示：
function log_message(level, message){
winston.log(level, req.path + "" + message);
}
那么我会这样使用该方法。
exports.index = function(req, res){
log_message("info", "I'm here");
}
一种有趣的方法是使用新的 Domains 功能。 http://nodejs.org/api/domain.html
Domains 提供了出色的错误恢复功能，同时也可以用作“线程本地存储”的一种方式 - 用于为每个请求存储数据。
创建一些中间件，将每个请求/响应添加到一个域中。
app.use(function(req, res, next) {
var reqd = domain.create();
reqd.add(req);
reqd.add(res);
reqd._req = req; // Add request object to custom property
// TODO: hook error event on reqd (see docs)
next();
});
在log函数中，您现在可以获取当前域并提取请求对象。
function log_message(level, message) {
// Pull the request from the current domain.
var request = process.domain._req;
// TODO: log message
};
域名仍处于实验阶段，但听起来在1.0版本发布之前不会有太多变化。
类似于域名回答，现在使用 continuation-local-storage 更容易实现此操作:
https://datahero.com/blog/2014/05/22/node-js-preserving-data-across-async-callbacks/
在 DataHero 中，我们将事务 ID、用户 ID 和会话 ID 保存到所有日志消息中。您无需将请求对象一直传递下去，因此它还有助于保持模型 / 业务层的简洁。
app.use(function(req, res, next) {
var tid = uuid.v4();
var cls = require('continuation-local-storage');
var namespace = cls.createNamespace('com.storage');
var pre_ip;
if(get_ip(req))
{ ip_info= get_ip(req).clientIp;
pre_ip=ip_info
}
namespace.bindEmitter(req);
namespace.bindEmitter(res);
namespace.run(function() {
console.log(logobj);
namespace.set('tid', tid);
namespace.set('ip',ip_info);
namespace.set('logobj',logobj);
next();
});
});
并使用它：
var cls = require('continuation-local-storage');
var namespace = cls.getNamespace('com.storage');
namespace.get('ip');
log_message是如何向调用者（模块等）公开的，以及在路由之前的管道中你有什么控制权？log_message从闭包内部调用，或者利用req EventEmitter工具并将调用winston.log的操作包装在req.end的处理程序中，仅记录在请求期间进行的所有消息。这将有效地更改您的log_message成为日志消息的累加器（可能在数组中），并在请求结束时将它们全部记录下来。以下解决方案对我是可接受的。
这里有一个中间件，它将log_message方法添加到请求对象上。之后，我只需调用req.log_message来记录消息。虽然这与将req对象传递给每个日志记录调用非常相似，但它更加简洁。
function logging_middleware(req, res, next){
req.log_message = function(level, message){
winston.log(level, req.path + ":" + message);
}
next();
}
module.exports = class RequestContext {
constructor(req, res, dependencies) {
const { myService1, myService2 } = dependencies;
this.req = req;
this.res = res;
}
getMyTestHeader() {
return this.req.headers.testHeader;
}
//Registering our namespace. creating it one per app
const clsNamespace = require('cls-hooked').createNamespace('my-per-request-session');
app.use((req, res, next) => {
// binding continuation-local-storage (cls-hooked) to request and response
clsNamespace.bind(req);
clsNamespace.bind(res);
clsNamespace.run(() => {
// save here req and res to use it later in requestContext instance, it will alive during request and could be picked up from DI as other dependencies
clsNamespace.set('req', req);
clsNamespace.set('res', res);
next();
});
});
container.register({
requestContextProvider: asFunction(dependencies => ({
getCurrentContext: () => {
//retrieve res and req on each DI call "from current request"
//also, clsNamespace should be the same as we registered before, on original code it is also registered using DI container.
const req = dependencies.clsNamespace.get('req');
const res = dependencies.clsNamespace.get('res');
//and return our RequestContext (wrapper for req and res)
return new RequestContext(req, res, dependencies);
},
})),
module.exports = (dependencies) => ({
myControllerAction: async (req, res) => {
const {requestContextProvider} = dependencies;
const requestContext = requestContextProvider.getCurrentContext();
//it will return header from req!
const myHeader = requestContext.getMyTestHeader();
res.status(200).json({ myHeader });
},
});
正如您所看到的，现在我们可以在每个层级（控制器/BLL/DAL/helpers等）访问DI时都有“requestContext”。因此，它是“线程安全”的，易于测试，并且不需要将req对象传递到所有“中间”层。
同意，这不是最好和最简单的示例，但希望能对某些人有所帮助。
process.domain = reqd;对我很有用。不幸的是，我找不到文件来描述它的行为 :-/ - Timmnext()，而是调用reqd.run(next)。enter方法是由run、bind和intercept方法使用的管道，用于设置活动域。它将domain.active和process.domain设置为该域。http://nodejs.org/api/domain.html#domain_domain_enter - Ricardo Stuven