.NET Core API网关Ocelot(十五)【请求Id和关联Id,中间件注入和重写】

待我称王封你为后i 2021-07-05 00:00 652阅读 0赞

Ocelot支持一个客户端以头的形式发送`requestid`。 如果设置了，一旦中间件管道中可用，Ocelot便会使用这个`requestid`进行日志记录。 Ocelot也会使用指定头将`requireid`转发给下游服务。

如果在日志配置中你设置`IncludeScopes`为`true`,你还可以在日志中获取asp.net core的请求id。

为了是用`requestid`,有两种选择。

全局

在`ocelot.json`的`GlobalConfiguration`配置块中如下设置。这样所有进入`Ocelot`的请求都会起作用。

"GlobalConfiguration": { 
      "RequestIdKey": "OcRequestId"
    }

我建议使用`GlobalConfiguration`，除非你真的需要它是指定`Route`的。

Route

如果你想覆盖全局设置，在`ocelot.json`的特定`Route`中添加如下设置。

"RequestIdKey": "OcRequestId"

一旦Ocelot识别出与`Route`对象匹配的请求，它将根据`Route`的配置来设置`requestid`。

这可能会导致一下困惑。如果你在`GlobalConfiguration`中设置了`requestid`，可能在`Route`被匹配前是一个，匹配后是另一个，因为`requestid`的`key`会变。这是因为设计如此，而且这是我目前能想到的最好的解决方案了。在这种情况下`OcelotLogger`会在日志中记录当前`requestid`和上一个`requestid`。

下面的例子是`debug`级别下一个正常请求的日志记录。

dbug: Ocelot.Errors.Middleware.ExceptionHandlerMiddleware[0]
          requestId: asdf, previousRequestId: no previous request id, message: ocelot pipeline started,
    dbug: Ocelot.DownstreamRouteFinder.Middleware.DownstreamRouteFinderMiddleware[0]
          requestId: asdf, previousRequestId: no previous request id, message: upstream url path is { upstreamUrlPath},
    dbug: Ocelot.DownstreamRouteFinder.Middleware.DownstreamRouteFinderMiddleware[0]
          requestId: asdf, previousRequestId: no previous request id, message: downstream template is { downstreamRoute.Data.Route.DownstreamPath},
    dbug: Ocelot.RateLimit.Middleware.ClientRateLimitMiddleware[0]
          requestId: asdf, previousRequestId: no previous request id, message: EndpointRateLimiting is not enabled for Ocelot.Values.PathTemplate,
    dbug: Ocelot.Authorisation.Middleware.AuthorisationMiddleware[0]
          requestId: 1234, previousRequestId: asdf, message: /posts/{ postId} route does not require user to be authorised,
    dbug: Ocelot.DownstreamUrlCreator.Middleware.DownstreamUrlCreatorMiddleware[0]
          requestId: 1234, previousRequestId: asdf, message: downstream url is { downstreamUrl.Data.Value},
    dbug: Ocelot.Request.Middleware.HttpRequestBuilderMiddleware[0]
          requestId: 1234, previousRequestId: asdf, message: setting upstream request,
    dbug: Ocelot.Requester.Middleware.HttpRequesterMiddleware[0]
          requestId: 1234, previousRequestId: asdf, message: setting http response message,
    dbug: Ocelot.Responder.Middleware.ResponderMiddleware[0]
          requestId: 1234, previousRequestId: asdf, message: no pipeline errors, setting and returning completed response,
    dbug: Ocelot.Errors.Middleware.ExceptionHandlerMiddleware[0]
          requestId: 1234, previousRequestId: asdf, message: ocelot pipeline finished,

--------------------

## 中间件注入和重写 ##

警告！请谨慎使用。 如果您在中间件管道中看到任何异常或奇怪的行为，并且正在使用以下任何一种行为。删除它们，然后重试！

当在`Startup.cs`中配置`Ocelot`的时候，可以添加或覆盖中间件。如下所示：

var configuration = new OcelotPipelineConfiguration
    { 
        PreErrorResponderMiddleware = async (ctx, next) =>
        { 
            await next.Invoke();
        }
    };
    app.UseOcelot(configuration);

在上面的例子中，提供的函数将在第一个`Ocelot`中间件之前运行。 这允许用户在Ocelot管道运行之前和之后提供他们想要的任何行为。 这意味着你可以打破一切，你开心就好！

用户可以针对以下内容设置功能。

`PreErrorResponderMiddleware` \- 上面已经解释过了.  
`PreAuthenticationMiddleware` \- 这个允许用户执行预认证逻辑，然后再调用 Ocelot的认证中间件。  
`AuthenticationMiddleware` \- 可以重写Ocelot的认证中间件。  
`PreAuthorisationMiddleware` \- 这个允许用户执行预授权逻辑，然后再调用 Ocelot的授权中间件。  
`AuthorisationMiddleware` \- 可以重写Ocelot的授权中间件。  
`PreQueryStringBuilderMiddleware` \- 这允许用户在传递给Ocelot请求创建器之前在http请求上处理查询字符串。

很明显，您只能在调用`app.UseOcelot()`之前添加中间件，而不能在它之后，因为`Ocelot`不会调用下一个中间件。