Welcome to YARP - 2.2 配置功能 - 配置提供者(Configuration Providers)

目录

Welcome to YARP - 1.认识YARP并搭建反向代理服务

Welcome to YARP - 2.配置功能

Welcome to YARP - 3.负载均衡

Welcome to YARP - 4.限流

Welcome to YARP - 5.身份验证和授权

Welcome to YARP - 6.压缩、缓存

Welcome to YARP - 7.目标健康检查

Welcome to YARP - 8.分布式跟踪

哈哈哈,第一篇文章还说,只规划了8篇文章,写到配置功能的时候发现东西还是挺多的,还是拆分成小章节来说吧。目前成了10篇了—_—。写之前觉得配置功能应该没什么东西可讲,结果写着写着都想讲一嘴。然后就越写越多,大家看的时候可以选择性的跳过。

介绍

如果有同学不知道YARP是什么,YARP有哪些功能的同学请移步第一篇文章[Welcome to YARP - 1.认识YARP并搭建反向代理服务]( Welcome to YARP - 1.认识 YARP 之- 反向代理 - coding-y - 博客园 (cnblogs.com) )。接下来这篇文章主要讲解YARP的配置功能的第二小章节:配置提供程序

配置提供者(Configuration Providers)

我们之前两篇的示例中,都是通过配置文件去加载代理所需要的配置。当然,我们也可以选择以编程方式加载代理配置 。 我们可以通过提供几个实现 IProxyConfigProviderIProxyConfig 的类来做到这一点,上一篇文章中我们通过源码解读的方式,也提到过这两个接口,这里就不多说了。

结构

这个上篇文章也提到过,这里就简单带过一下吧:

IProxyConfigProvider 有一个 GetConfig() 返回 IProxyConfig 实例的方法。IProxyConfig 具有当前路由和集群的列表,以及一个用于信息过期,并通知YARP 重新加载配置的令牌IChangeToken ,这将导致 GetConfig() 会被再次调用。

内存中配置(In Memory Config)

通过 InMemoryConfigProvider 调用 LoadFromMemory 实现 IProxyConfigProvider 并启用直接在代码中指定路由和群集

services.AddReverseProxy().LoadFromMemory(routes, clusters);

若要稍后更新配置,请从服务容器解析 , InMemoryConfigProvider 并使用新的路由和集群列表进行调用 Update

httpContext.RequestServices.GetRequiredService<InMemoryConfigProvider>().Update(routes, clusters);

生命周期

启动

IProxyConfigProvider 应该在 DI 容器中注册为单一实例。在启动时,代理将解析此实例并调用 GetConfig() 。在第一次调用时,提供者可以选择:

  • 如果提供程序由于任何原因无法生成有效的代理配置,则引发异常。这将阻止应用程序启动。
  • 加载配置时同步阻止。这将阻止应用程序启动,直到有效的路由数据可用。
  • 或者,它可能选择在后台加载配置时返回空 IProxyConfig 实例。提供程序需要在配置可用时触发。 IChangeToken

原子性(Atomicity)

提供给代理的配置对象和集合应该是只读的,并且在通过GetConfig()将它们移交给代理后不会进行修改。

/// <summary>
/// 表示代理配置数据的快照。这些属性可能被多次访问,不应被修改。
/// </summary>
public interface IProxyConfig
{
    private static readonly ConditionalWeakTable<IProxyConfig, string> _revisionIdsTable = new();

    /// <summary>
    /// A unique identifier for this revision of the configuration.
    /// </summary>
    string RevisionId => _revisionIdsTable.GetValue(this, static _ => Guid.NewGuid().ToString());

    /// <summary>
    /// Routes matching requests to clusters.
    /// </summary>
    IReadOnlyList<RouteConfig> Routes { get; }

    /// <summary>
    /// Cluster information for where to proxy requests to.
    /// </summary>
    IReadOnlyList<ClusterConfig> Clusters { get; }

    /// <summary>
    /// A notification that triggers when this snapshot expires.
    /// </summary>
    IChangeToken ChangeToken { get; }
}

可以看到GetConfig()加载过来的路由和集群列表都是只读的集合。

重新加载(Reload)

如果IChangeToken支持ActiveChangeCallbacks,那么一旦代理处理了初始配置,它就会使用此令牌注册回调。如果提供程序不支持回调,则HasChanged将每5分钟轮询一次。

当提供程序想要向代理提供新配置时,它应该:

  • 在后台加载该配置。
  • 路由和集群对象是不可变的,因此必须为任何新数据创建新实例。
  • 可以重用未更改路由和集群的对象,也可以创建新实例 - 将通过差异来检测更改。
  • (可选)使用 [IConfigValidator]( Interface IConfigValidator (microsoft.github.io) ) 验证配置,然后才 IChangeToken 从先前 IProxyConfig 实例发出新数据可用的信号。代理将再次调用 GetConfig() 以检索新数据。

重新加载配置与第一次加载配置时存在重要差异:

  • 新配置将与当前配置不同,并且只会更新修改的路由或集群。更新将以原子方式应用,并且仅影响新请求,而不会影响当前正在进行的请求。
  • 重新加载过程中的任何错误都将被记录和禁止。应用程序将继续使用上次已知的正确配置。
  • 如果 GetConfig() 抛出代,理将无法侦听将来的更改,因为 IChangeToken 是一次性的。

一旦验证并应用了新配置,代理将使用新的IChangeToken注册回调。请注意,如果有多个连续的重新加载信号,代理可能会跳过一些,并在准备好后立即加载下一个可用的配置。每个IProxyConfig都包含完整的配置状态,因此不会丢失任何内容。

上述描述的是刷新配置相关的内容,具体代码参考 ListenForConfigChanges(),可以结合代码一起看。

多配置源

参考前两篇文章的描述。

代码示例:

using Yarp.ReverseProxy.Configuration;
using Yarp.ReverseProxy.Model;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddReverseProxy()//添加ReverseProxy相关服务到DI
    .LoadFromMemory(GetRoutes(), GetClusters());//从内存中加载配置

var app = builder.Build();

app.MapGet("/reload", (HttpContext httpContext) =>
{
    httpContext.RequestServices.GetRequiredService<InMemoryConfigProvider>().Update(GetRoutes(), GetClusters("https://www.baidu.com"));
});

app.MapReverseProxy();

app.Run();

static RouteConfig[] GetRoutes()
{
    return new[]
    {
        new RouteConfig()
        {
            RouteId = "route" + Random.Shared.Next(),
            ClusterId = "cluster1",
            Match = new RouteMatch
            {
                Path = "{**catch-all}"
            }
        }
    };
}
static ClusterConfig[] GetClusters(string? address = null)
{
    address ??= "https://cn.bing.com";

    return new[]
    {
        new ClusterConfig()
        {
            ClusterId = "cluster1",

            Destinations = new Dictionary<string, DestinationConfig>(StringComparer.OrdinalIgnoreCase)
            {
                { "destination1", new DestinationConfig() { Address = address } }
            }
        }
    };
}

上述代码中我们通过内存去加载代理所需要的配置,而且使用了刷新配置功能,当我们访问这个站点时(http://localhost:5270)代理的是必应的站点,当我们去请求reload方法时(http://localhost:5270/reload)他会更改代理配置,从而代理百度的站点。完整代码已上传GitHub,在 YARP.ConfigurationProvider.Memory 文件夹下。

总结

这一章我们介绍并实践了配置提供者,通过内存来提供配置,通过代码来实现配置加载和更新。

当然我们还可以自定义配置提供者只要实现上述两个接口就可以。你可以实现基于 Redis 的和 数据库 的 配置提供者,感兴趣的小伙伴可以研究一下,这两种实现起来应该还是比较简单的(等有时间了,我会写个demo示例,先把规划的文章写完了再去搞这个)。

这篇文章就到这里,下一篇我们继续介绍配置过滤器(Configuration Filters)

posted @ 2023-11-02 01:54  coding-y  阅读(578)  评论(0编辑  收藏  举报