.NetCore框架Surging系列（七）路由监听

.NetCore框架Surging系列（一）介绍
.NetCore框架Surging系列（二）HTTP
.NetCore框架Surging系列（三）HTTP本地路由发现过程
.NetCore框架Surging系列（四）RPC客户端过程
.NetCore框架Surging系列（五）路由注册
.NetCore框架Surging系列（六）路由发现

.NetCore框架Surging系列（七）路由监听

背景

在上一篇.NetCore框架Surging系列（六）路由发现中提到路由发现，此功能为发现远程服务的路由（即将Consul中路由同步下来），在Rpc时获取路由对应的服务器地址。但是该过程只会同步一次，当远程服务断线或则更改更换IP等，需要更改路由信息。故路由同步功能是保持Consul服务持续有效可用。

路由同步功能

1. 删除路由对应的无效服务地址；
2. 同步路由对应新上线的服务器节点地址；
3. 同步新上线的路由和路由地址。

整体流程

关键点

注册路由监视器

工程Surging.Core.Consul中类ConsulModule，调用方法UseConsulWatch注册路由监视器ClientWatchManager，会在Program.Run之后触发。

创建定时器Timer

ClientWatchManager构造函数中创建定时器，定时器回调时间间隔WatchInterval为surgingSettings.json

{
   //...
  "Consul": {   
    "WatchInterval": 3600, //单位秒 路由同步，刷新Consul中Key/Value 
    //...
  },
}

执行同步路由节点信息

这里尤其注意一排代码

protected override async Task ProcessImpl()
{
    RegisterWatch(this);
    //这里尤其注意一排代码 开始
    if (_allowChange!=null&&! _allowChange(_path)) return;
    //这里尤其注意一排代码 结束
    var client = await _clientCall();
    var result =await client.GetDataAsync(_path);
    if (result != null)
    {
        _action(_currentData, result);
        this.SetCurrentData(result);
    }
}

    //_allowChange方法
    /*
        tmpPath =>
        {
            var index = tmpPath.LastIndexOf("/");
            return _serviceHeartbeatManager.ExistsWhitelist(tmpPath.Substring(index + 1));
        }
    */

Rpc调用过某些接口，类DefaultAddressResolver中有一个白名单的功能 _serviceHeartbeatManager.AddWhitelist(serviceId);
在服务启动的过程中，如果没有加载完所有API，那么这里只会同步上面请求过的接口，其他接口需要访问过一次或多次后，才能访问的了，类似有个激活的过程

执行子监视器

相对于NodeMonitorWatcher，在当前服务启动之后其他服务新增了API，如果没有开启这个功能则新增的API不会被发现。开启此功能需要在
surgingSettings.json中配置EnableChildrenMonitor为true

{
   //...
  "Consul": {   
    "EnableChildrenMonitor": true,
    //...
  },
}

修改节点信息/子节点

这里管理的路由称之为路由节点，供Rpc调用使用。

//DefaultAddressResolver.cs

/// <summary>
/// 解析服务地址。
/// </summary>
/// <param name="serviceId">服务Id。</param>
/// <returns>服务地址模型。</returns>
/// 1.从字典中拿到serviceroute对象
/// 2.从字典中拿到服务描述符集合
/// 3.获取或添加serviceroute
/// 4.添加服务id到白名单
/// 5.根据服务描述符得到地址并判断地址是否是可用的（地址应该是多个）
/// 6.添加到集合中
/// 7.拿到服务命今
/// 8.根据负载分流策略拿到一个选择器
/// 9.返回addressmodel
public async ValueTask<AddressModel> Resolver(string serviceId, string item)
{
    ...
    if (descriptor == null)
    {
        var descriptors = await _serviceRouteManager.GetRoutesAsync();//这句
    }
    ...
}
        

修改路由信息

最后一步修改路由信息，供Http将请求路由path转换为路由对象ServiceRoute

//HttpMessageListener.cs

public async Task<bool> OnAuthorization(HttpContext context, HttpServerMessageSender sender,string messageId, IEnumerable<IAuthorizationFilter> filters)
{
    foreach (var filter in filters)
    {
        var path = HttpUtility.UrlDecode(GetRoutePath(context.Request.Path.ToString()));
        var serviceRoute = await _serviceRouteProvider.GetRouteByPathRegex(path);//这句       
        ...
    }
    return true;
}

总结

从上面的种种看来，整个过程比较复杂，偶尔存在抽风的感觉，请求接口会发生接口不通、有的接口通有的接口不同、有的接口第一次访问无法通等。
以上几个问题都很好解决，但是有个问题比较棘手，就是服务发布之后，无法预料接口生效的时间。解决办法是取消定时机制，结合消息队列，当服务启动通知所有的服务同步一遍路由接口。
综合来看，🤔改为服务注册发现而不用路由注册发现会更好。