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

最新推荐文章于 2024-09-14 09:03:47 发布

.NET跨平台

最新推荐文章于 2024-09-14 09:03:47 发布

阅读量2.2k

点赞数

分类专栏： NET Core API网关Ocelot

原文链接：https://blog.csdn.net/WuLex

版权

NET Core API网关Ocelot 专栏收录该内容

22 篇文章 12 订阅

订阅专栏

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不会调用下一个中间件。