2024年2月

写在前面

和大家不太一样,我觉得今年的自己更加relax,没有亲戚要走,没有朋友相聚,也没有很好的哥们要去叙旧,更没有无知的相亲,甚至可以这么说没有那些闲得慌的邻居。

也可以说是从今天开始,算是可以进入自己的小世界,做自己想做的事,看看书,学习一下。

生活的精髓在于善待自己,用心感受每一刻的欢愉与宁静!

人生于世上有几个知己,多少友谊能长存,愿友谊常青!

菜单显示分类名

那么如何让菜单正常显示菜单内容呢?

1、任务拆解

  • 在页面加载就查出所有分类
  • 通过垂直菜单遍历出所有分类内容并显示

2、在页面加载就查出所有分类

即在onMounted种通过handleQueryCategory,此处可以复用分类列表中的代码,示例代码如下:

const level1 =  ref();
let categorys: any;
/**
 * 查询所有分类
 **/
const handleQueryCategory = () => {
  axios.get("/category/all").then((response) => {
    const data = response.data;
    if (data.success) {
      categorys = data.content;
      console.log("原始数组:", categorys);

      level1.value = [];
      level1.value = Tool.array2Tree(categorys, 0);
      console.log("树形结构:", level1.value);
    } else {
      message.error(data.message);
    }
  });
};

onMounted(() => {
    handleQueryCategory();
}

3、通过垂直菜单遍历出所有分类内容并显示

这块还是考察的是v -for循环遍历的知识点,示例代码如下:

<a-sub-menu v-for="item in level1" :key="item.id">
  <template v-slot:title>
    <span><user-outlined />{{item.name}}</span>
  </template>
  <a-menu-item v-for="child in item.children" :key="child.id">
    <MailOutlined /><span>{{child.name}}</span>
  </a-menu-item>
</a-sub-menu>

4、效果

写在最后

这部分的代码,是纯前端了, 代码扔太久了,只能看懂,但是自己写还是写不出来,我想这种状态,可能是很多新手,都会面临的问题吧。

有没有好的解决办法呢?

没有,在成功这条路上,
永远是没有捷径可言的。

如不适应,去练习,大量练习,直到完全适应它即可。

引言

在计算机科学和软件开发领域,正则表达式是一种强大而灵活的文本处理工具。然而,对于初学者来说,正则表达式的语法和规则可能会显得晦涩难懂。为了帮助初学者更好地理解和学习正则表达式,正则可视化工具应运而生。本文将介绍正则表达式的基本概念、语法和应用,并介绍如何利用正则可视化工具来学习和实践正则表达式。

正则表达式的基本概念

正则表达式是一种用于描述文本模式的字符串。它由普通字符(如字母、数字、标点符号)和特殊字符(如元字符和转义字符)组成。正则表达式可以用来匹配文本中的模式,并进行各种操作。

正则表达式的基本语法

正则表达式的语法由一系列的字符和特殊符号组成,用于描述匹配的规则。以下是一些常用的正则表达式语法元素:

  • 字符匹配:使用普通字符来匹配相应的字符。
  • 元字符:具有特殊含义的字符,如
    .
    匹配任意字符,
    *
    匹配前一个元素的零次或多次重复。
  • 字符类:用方括号
    []
    来指定一组可选的字符,如
    [abc]
    匹配字符a、b或c。
  • 转义字符:使用反斜杠``来转义特殊字符,如
    .
    匹配字符
    .
  • 量词:指定匹配元素的次数,如
    {n}
    匹配前一个元素恰好出现n次。

正则表达式的应用

正则表达式在文本处理中有广泛的应用,以下是一些常见的应用场景:

  • 文本搜索和匹配:使用正则表达式可以在文本中搜索和匹配特定的模式,如查找所有包含某个单词的句子。
  • 数据提取和分析:通过正则表达式可以从文本中提取出需要的数据,如从日志文件中提取出日期、时间和错误信息。
  • 格式验证和校验:正则表达式可以用于验证和校验输入的数据格式,如检查邮箱地址、手机号码或密码的合法性。
  • 文本替换和修复:使用正则表达式可以进行文本的替换和修复操作,如将所有的制表符替换为空格。
  • URL路由和路由匹配:正则表达式在URL路由和路由匹配中有广泛的应用,可以方便地进行URL的解析和匹配。

正则可视化工具的介绍和使用

正则可视化工具是一种交互式的工具,可以帮助用户可视化地理解和学习正则表达式。通过这些工具,用户可以输入正则表达式和待匹配的文本,然后工具会将匹配的结果可视化展示出来,帮助用户理解匹配的过程和结果。

正则可视化工具:

正则可视化 | 一个覆盖广泛主题工具的高效在线平台(amd794.com)

https://amd794.com/regularGraph

正则可视化工具是一种用于帮助用户理解和调试正则表达式的工具。正则表达式是一种强大的模式匹配工具,用于在文本中搜索、替换和提取特定模式的字符串。

正则可视化工具提供以下功能:

  1. 正则表达式编辑器:允许用户输入和编辑正则表达式。
  2. 文本输入框:用户可以输入需要匹配的文本。
  3. 匹配结果展示:显示正则表达式在文本中的匹配结果,通常以高亮方式展示。
  4. 错误提示:如果正则表达式存在错误,工具可以提供错误提示和建议修复。
  5. 正则表达式解释:工具可以解释正则表达式的含义和匹配规则,帮助用户理解其工作原理。
  6. 替换功能:允许用户在文本中进行替换操作,将匹配的字符串替换为指定的内容。
  7. 可视化分组:对于复杂的正则表达式,工具可以将匹配的分组可视化展示,以便用户更好地理解和调试。

正则可视化工具通常以图形界面的形式呈现,使用户可以直观地操作和观察正则表达式的匹配过程。这些工具可以帮助用户快速验证和调试正则表达式,提高开发效率。

通过使用正则可视化工具,初学者可以更加直观地理解正则表达式的语法和规则,并通过实践来加深对正则表达式的理解和掌握。

总结

正则表达式是一种强大而灵活的文本处理工具,通过简洁的语法和强大的匹配能力,可以帮助我们在文本处理中实现各种复杂的操作。然而,对于初学者来说,正则表达式的语法和规则可能会显得晦涩难懂。为了帮助初学者更好地理解和学习正则表达式,正则可视化工具成为了一种宝贵的学习资源。通过使用正则可视化工具,初学者可以可视化地理解和学习正则表达式的语法和规则,加深对正则表达式的理解和掌握。无论是在日常的文本处理任务中,还是在软件开发和数据分析等领域,正则表达式都是一个不可或缺的工具,值得我们深入学习和应用。

声明

原创文章,转载请标注。
https://www.cnblogs.com/boycelee/p/17993697
《码头工人的一千零一夜》是一位专注于技术干货分享的博主,追随博主的文章,你将深入了解业界最新的技术趋势,以及在Java开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者,都能在《码头工人的一千零一夜》找到有价值的知识和见解。

配置中心系列文章

《【架构师视角系列】Apollo配置中心之架构设计(一)》
https://www.cnblogs.com/boycelee/p/17967590
《【架构师视角系列】Apollo配置中心之Client端(二)》
https://www.cnblogs.com/boycelee/p/17978027
《【架构师视角系列】Apollo配置中心之Server端(ConfigSevice)(三)》
https://www.cnblogs.com/boycelee/p/18005318
《【架构师视角系列】QConfig配置中心系列之架构设计(一)》
https://www.cnblogs.com/boycelee/p/18013653

一、架构

基础模型

架构图

架构分层

架构分层可以分为四层,分别是客户端层、网络层、服务层以及数据层,其中客户端层包括Client模块和Admin模块,网络层包括Server模块中的EntryPoint部分和NginxLB以及Eureka,服务层仅包括Server模块。

运行规则

(1)Server将自己注册到注册中心Eureka中,

(2)当三方应用拉取配置时,Client端通过访问域名的方式,请求经过NginxLB访问到EntryPoint并从Eureka中获取到已注册的Server列表及其对应IP、端口信息,这时Client端就可以通过ip+port的形式直接访问到已注册的某个Server实例,获取到对应配置信息。

(3)当管理人员操作配置时,可以通过独立部署的Admin模块(管理平台)直接访问数据库,对配置数据进行增删查改操作。

(4)当管理人员发布配置时,Client端通过访问域名的方式,请求经过NginxLB访问到EntryPoint并从Eureka中获取到已注册的Server列表及其对应IP、端口信息,这时Admin端就可以通过ip+port的形式直接访问到所有已注册的Server实例,获取到对应配置信息。

模块划分

相对于Apollo的分层,Qconfig的分层相对更简单一些,大致分为三个模块分别是Admin模块、Client模块、Server模块。

Admin模块

提供web界面用于配置管理。但与Apollo配置中心不同的地方在于Qconfig的模块划分并没有Apollo这么明确,所有与配置操作相关的逻辑都在Admin模块中。

其中包括:

  • 应用创建、查看、修改、发布以及回滚等功能
  • 提供修改、发布配置等接口。
  • 配置变更时通知Server

Client模块

提供实时配置获取与更新。其与Apollo中的模块职责是一样的。

其中包括:

  • 客户端负责从Config Service获取应用的配置信息;
  • 监听配置变化。当配置发生更新时,Config Service会通知Client,并出发其进行配置刷新;
  • 通过ip + port的方式远程调用Config Service,以获取配置数据。

Server模块

服务于Client端,为客户端提供获取配置的接口。

其中包括:

  • 基于长轮询,提供配置更新接口;
  • 提供配置获取接口。

二、总结

(1)Apollo和QConfig都是携程集团的配置中心项目,Apollo主要在携程内部使用,而Qconfig主要去哪儿内部使用;

(2)从开源社区维护角度上,相对而言Apollo的开源工作要做得好很多;

(3)从架构设计和代码整洁这两个维度上,个人觉得QConfig要做得更优秀一些。

三、最后

《码头工人的一千零一夜》是一位专注于技术干货分享的博主,追随博主的文章,你将深入了解业界最新的技术趋势,以及在Java开发和安全领域的实用经验分享。无论你是开发人员还是对逆向工程感兴趣的爱好者,都能在《码头工人的一千零一夜》找到有价值的知识和见解。

懂得不多,做得太少。欢迎批评、指正。

操作系统 :CentOS 7.6_x64

FreeSWITCH版本 :1.10.9

日常开发中,会遇到需要在已存在的session上执行特定拨号方案的情况,今天整理下这方面的内容,我将从以下几个方面进行描述:

  • 实验环境准备

  • 基于transfer实现

  • 基于execute_extension实现

  • 基于transfer和execute_extension实现的区别

  • 基于execute_extension实现的改进

  • 提供示例代码及运行效果视频

一、实验环境准备

FreeSWITCH测试机:192.168.137.32

分机:1000

拨号方案(default.xml中添加):

<extensionname="conf_test">
    <conditionfield="destination_number"expression="^7001$">
        <actionapplication="conference"data="test1@default"/>
        <actionapplication="hangup"/>
    </condition>
</extension>

二、基于transfer实现

1、使用uuid_transfer转接到特定dialplan

uuid_transfer是一个api命令,可以将指定session转接到特定dialplan,命令格式如下:

uuid_transfer <uuid> [-bleg|-both] <dest-exten> [<dialplan>] [<context>]

完整信息可参考wiki:

https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Modules/mod_commands_1966741/#uuid_transfer

呼叫分机命令:

originate user/1000 &echo

使用示例如下:

uuid_transfer c7a95b91-3fbe-4c0c-8f5a-ff4933279558 7001 xml default

运行效果如下:

可以在会议室里面看到1000这个分机:

演示视频可从如下渠道获取:

关注微信公众号(聊聊博文,文末可扫码)后回复 2024021101 获取。

2、使用transfer转接到特定dialplan

transfer是一个app,可以在xml中使用,也可以在lua脚本中使用,这里演示下如何在lua脚本中使用实现转接特定拨号方案功能。

命令格式如下:

transfer <destination_number> [<dialplan> [<context>]]

完整信息可参考wiki:

https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Modules/mod-dptools/6586616/

在lua脚本中的使用示例如下(transTest1.lua):

local extInfo = "7001 xml default"session:execute("transfer",extInfo)

添加拨号方案:

<extensionname="testTrans">
        <conditionfield="destination_number"expression="^333$">
             <actionapplication="lua"data="transTest1.lua"/>
        </condition>
    </extension>

使用分机1000拨打333即可验证,运行效果如下:

演示视频可从如下渠道获取:

关注微信公众号(聊聊博文,文末可扫码)后回复 2024021102 获取。

三、基于execute_extension实现

execute_extension是个app,可以在xml中使用,也可以在lua脚本中使用,这里演示下如何在lua脚本中实现执行特定拨号方案的功能。

app的命令格式如下:

<actionapplication="execute_extension"data="extension [dialplan] [context]"/>

完整信息可参考wiki:

https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Modules/mod-dptools/6586595/

在lua脚本中的使用示例如下(transTest2.lua):

local extInfo = "7001 xml default"
session:execute("execute_extension",extInfo)

添加拨号方案:

<extensionname="testTrans">
        <conditionfield="destination_number"expression="^666666$">
             <actionapplication="lua"data="transTest2.lua"/>
        </condition>
</extension>

使用分机1000拨打666666即可验证,运行效果如下:

演示视频可从如下渠道获取:
关注微信公众号(聊聊博文,文末可扫码)后回复 2024021103 获取。

四、基于transfer和execute_extension的区别

这里记录下在实际使用过程中,发现的transfer和execute_extension的区别。

需要说明下,在前面提供的例子里面体现不出来transfer和execute_extension的区别,在故障恢复的场景中可以体现:

1)执行transfer时会影响故障恢复,crash前是A dialplan,recover后是B dialplan;

2)转dialplan时,使用 execute_extension 这个app则不会影响故障恢复,crash前是A dialplan,recover后还是A dialplan;

1、准备拨号方案及lua脚本

A dialplan的内容:

<extensionname="dp_testA1">
  <conditionfield="destination_number"expression="^7771$">
    <actionapplication="answer"/>
    <actionapplication="lua"data="apply_extension_test1.lua" />
    <actionapplication="sleep"data="60000"/>
    <actionapplication="hangup" />
  </condition>
</extension>


<extensionname="dp_testA2">
  <conditionfield="destination_number"expression="^7772$">
    <actionapplication="answer"/>
    <actionapplication="lua"data="apply_extension_test2.lua" />
    <actionapplication="sleep"data="60000"/>
    <actionapplication="hangup" />
  </condition>

</extension>

B dialplan的内容:

<extensionname="dp_testB">
    <conditionfield="destination_number"expression="^8001$">
        <actionapplication="playback"data="local_stream://moh"/>
        <actionapplication="hangup"/>
    </condition>
</extension>

apply_extension_test1.lua的内容:

apply_extension_test2.lua的内容:

完整代码及相关文件可从如下渠道获取:

关注微信公众号(聊聊博文,文末可扫码)后回复 20240211 获取。

2、配置fs的故障恢复

1)开启fs启动时恢复

文件:vars.xml

添加的内容:

<X-PRE-PROCESScmd="set"data="api_on_startup=fsctl recover"/>

2) 开启profile相关开关

文件:internal.xml  external.xml

添加内容:

<paramname="track-calls"value="true"/>

3、使用transfer进行呼叫测试

1)使用originate发起呼叫

命令如下:

originate user/1000 7771 xml default

2)根据语音提示进行按键;

3)执行crash操作

fsctl crash

4) 启动fs进行故障恢复;

5) 观察恢复效果。

恢复后执行的是8001这个dialplan的内容。

演示视频可从如下渠道获取:
关注微信公众号(聊聊博文,文末可扫码)后回复 2024021104 获取。

4、使用execute_extension进行呼叫测试

1)使用originate发起呼叫

命令如下:

originate user/1000 7772 xml default

2)根据语音提示进行按键;

3)执行crash操作

fsctl crash

4) 启动fs进行故障恢复;

5) 观察恢复效果。

恢复后执行的是7772这个dialplan的内容。

演示视频可从如下渠道获取:
关注微信公众号(聊聊博文,文末可扫码)后回复 2024021105 获取。

五、基于execute_extension实现的改进

如果故障恢复后需要走原来的拨号方案,则execute_extension是更好的选择,可以结合故障恢复的标志进行改进。

这里进行简单的示例,捕获该session是故障恢复的呼叫,代码如下(apply_extension_test22.lua):

完整代码及相关文件可从如下渠道获取:
关注微信公众号(聊聊博文,文末可扫码)后回复 20240211 获取。

配套的拨号方案如下:

<extensionname="dp_testA3">
  <conditionfield="destination_number"expression="^7773$">
    <actionapplication="answer"/>
    <actionapplication="lua"data="apply_extension_test22.lua" />
    <actionapplication="sleep"data="60000"/>
    <actionapplication="hangup" />
  </condition>

</extension>

配套呼叫命令如下:

originate user/1000 7773 xml default

运行效果如下:

六、资源下载

本文涉及资源可从如下渠道获取:

关注微信公众号(聊聊博文,文末可扫码)后回复 20240211 获取。

好,就这么多了,别忘了点赞哈!

原文 | Máňa,Natalia Kondratyeva

翻译 | 郑子铭

修改 HttpClient 日志记录

自定义(甚至简单地关闭)HttpClientFactory 日志记录是长期请求的功能之一 (
dotnet/runtime#77312
)。

旧日志记录概述

HttpClientFactory 添加的默认(“旧”)日志记录非常详细,每个请求发出 8 条日志消息:

  1. 使用请求 URI 启动通知 — 在通过委托处理程序管道传播之前;
  2. 请求标头 - 在处理程序管道之前;
  3. 使用请求 URI 启动通知 — 在处理程序管道之后;
  4. 请求标头——处理程序管道之后;
  5. 在通过委托处理程序管道将响应传播回之前,停止通知已用时间;
  6. 响应头——在传播回响应之前;
  7. 停止通知并显示经过的时间——在传播回响应之后;
  8. 响应标头 - 将响应传播回来之后。

这可以用下图来说明。在此图和下图中,* 和 [...] 表示日志记录事件(在默认实现中,日志消息被写入 ILogger),--> 表示通过应用程序层和传输层的数据流。

  Request -->
*   [Start notification]    // "Start processing HTTP request ..." (1)
*   [Request headers]       // "Request Headers: ..." (2)
      --> Additional Handler #1 -->
        --> .... -->
          --> Additional Handler #N -->
*           [Start notification]    // "Sending HTTP request ..." (3)
*           [Request headers]       // "Request Headers: ..." (4)
                --> Primary Handler -->
                      --------Transport--layer------->
                                          // Server sends response
                      <-------Transport--layer--------
                <-- Primary Handler <--
*           [Stop notification]    // "Received HTTP response ..." (5)
*           [Response headers]     // "Response Headers: ..." (6)
          <-- Additional Handler #N <--
        <-- .... <--
      <-- Additional Handler #1 <--
*   [Stop notification]    // "End processing HTTP request ..." (7)
*   [Response headers]     // "Response Headers: ..." (8)
  Response <--

默认 HttpClientFactory 日志记录的控制台输出如下所示:

var client = _httpClientFactory.CreateClient();
await client.GetAsync("https://httpbin.org/get");
info: System.Net.Http.HttpClient.test.LogicalHandler[100]
      Start processing HTTP request GET https://httpbin.org/get
trce: System.Net.Http.HttpClient.test.LogicalHandler[102]
      Request Headers:
      ....
info: System.Net.Http.HttpClient.test.ClientHandler[100]
      Sending HTTP request GET https://httpbin.org/get
trce: System.Net.Http.HttpClient.test.ClientHandler[102]
      Request Headers:
      ....
info: System.Net.Http.HttpClient.test.ClientHandler[101]
      Received HTTP response headers after 581.2898ms - 200
trce: System.Net.Http.HttpClient.test.ClientHandler[103]
      Response Headers:
      ....
info: System.Net.Http.HttpClient.test.LogicalHandler[101]
      End processing HTTP request after 618.9736ms - 200
trce: System.Net.Http.HttpClient.test.LogicalHandler[103]
      Response Headers:
      ....

请注意,为了查看跟踪级别消息,您需要在全局日志记录配置文件中或通过
SetMinimumLevel(LogLevel.Trace)
选择加入该消息。但即使只考虑信息性消息,“旧”日志记录每个请求仍然有 4 条消息。

要删除默认(或之前添加的)日志记录,您可以使用新的
RemoveAllLoggers()
扩展方法。它与上面“
为所有客户端设置默认值
”部分中描述的ConfigureHttpClientDefaults API 结合起来特别强大。这样,您可以在一行中删除所有客户端的“旧”日志记录:

services.ConfigureHttpClientDefaults(b => b.RemoveAllLoggers()); // remove HttpClientFactory default logging for all clients

如果您需要恢复“旧”日志记录,例如对于特定客户端,您可以使用
AddDefaultLogger()
来执行此操作。

添加自定义日志记录

除了能够删除“旧”日志记录之外,新的 HttpClientFactory API 还允许您完全自定义日志记录。您可以指定当 HttpClient 启动请求、接收响应或引发异常时记录的内容和方式。

如果您选择这样做,您可以同时添加多个自定义记录器 - 例如,控制台和 ETW 记录器,或
“包装”和“不包装”
记录器。由于其附加性质,您可能需要事先显式删除默认的“旧”日志记录。

要添加自定义日志记录,您需要实现
IHttpClientLogger
接口,然后使用
AddLogger
将自定义记录器添加到客户端。请注意,日志记录实现不应引发任何异常,否则可能会中断请求执行。

登记:

services.AddSingleton<SimpleConsoleLogger>(); // register the logger in DI

services.AddHttpClient("foo") // add a client
    .RemoveAllLoggers() // remove previous logging
    .AddLogger<SimpleConsoleLogger>(); // add the custom logger

示例记录器实现:

// outputs one line per request to console
public class SimpleConsoleLogger : IHttpClientLogger
{
    public object? LogRequestStart(HttpRequestMessage request) => null;

    public void LogRequestStop(object? ctx, HttpRequestMessage request, HttpResponseMessage response, TimeSpan elapsed)
        => Console.WriteLine($"{request.Method} {request.RequestUri?.AbsoluteUri} - {(int)response.StatusCode} {response.StatusCode} in {elapsed.TotalMilliseconds}ms");

    public void LogRequestFailed(object? ctx, HttpRequestMessage request, HttpResponseMessage? response, Exception e, TimeSpan elapsed)
        => Console.WriteLine($"{request.Method} {request.RequestUri?.AbsoluteUri} - Exception {e.GetType().FullName}: {e.Message}");
}

示例输出:

var client = _httpClientFactory.CreateClient("foo");
await client.GetAsync("https://httpbin.org/get");
await client.PostAsync("https://httpbin.org/post", new ByteArrayContent(new byte[] { 42 }));
await client.GetAsync("http://httpbin.org/status/500");
await client.GetAsync("http://localhost:1234");
GET https://httpbin.org/get - 200 OK in 393.2039ms
POST https://httpbin.org/post - 200 OK in 95.524ms
GET https://httpbin.org/status/500 - 500 InternalServerError in 99.5025ms
GET http://localhost:1234/ - Exception System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it. (localhost:1234)

请求上下文对象

上下文对象可用于将
LogRequestStart
调用与相应的
LogRequestStop
调用相匹配,以将数据从一个调用传递到另一个调用。 Context 对象由 LogRequestStart 生成,然后传递回 LogRequestStop。这可以是属性包或保存必要数据的任何其他对象。

如果不需要上下文对象,实现可以从 LogRequestStart 返回 null。

以下示例显示了如何使用上下文对象来传递自定义请求标识符。

public class RequestIdLogger : IHttpClientLogger
{
    private readonly ILogger _log;

    public RequestIdLogger(ILogger<RequestIdLogger> log)
    {
        _log = log;
    }

    private static readonly Action<ILogger, Guid, string?, Exception?> _requestStart =
        LoggerMessage.Define<Guid, string?>(
            LogLevel.Information,
            EventIds.RequestStart,
            "Request Id={RequestId} ({Host}) started");

    private static readonly Action<ILogger, Guid, double, Exception?> _requestStop =
        LoggerMessage.Define<Guid, double>(
            LogLevel.Information,
            EventIds.RequestStop,
            "Request Id={RequestId} succeeded in {elapsed}ms");

    private static readonly Action<ILogger, Guid, Exception?> _requestFailed =
        LoggerMessage.Define<Guid>(
            LogLevel.Error,
            EventIds.RequestFailed,
            "Request Id={RequestId} FAILED");

    public object? LogRequestStart(HttpRequestMessage request)
    {
        var ctx = new Context(Guid.NewGuid());
        _requestStart(_log, ctx.RequestId, request.RequestUri?.Host, null);
        return ctx;
    }

    public void LogRequestStop(object? ctx, HttpRequestMessage request, HttpResponseMessage response, TimeSpan elapsed)
        => _requestStop(_log, ((Context)ctx!).RequestId, elapsed.TotalMilliseconds, null);

    public void LogRequestFailed(object? ctx, HttpRequestMessage request, HttpResponseMessage? response, Exception e, TimeSpan elapsed)
        => _requestFailed(_log, ((Context)ctx!).RequestId, null);

    public static class EventIds
    {
        public static readonly EventId RequestStart = new(1, "RequestStart");
        public static readonly EventId RequestStop = new(2, "RequestStop");
        public static readonly EventId RequestFailed = new(3, "RequestFailed");
    }

    record Context(Guid RequestId);
}
info: RequestIdLogger[1]
      Request Id=d0d63b84-cd67-4d21-ae9a-b63d26dfde50 (httpbin.org) started
info: RequestIdLogger[2]
      Request Id=d0d63b84-cd67-4d21-ae9a-b63d26dfde50 succeeded in 530.1664ms
info: RequestIdLogger[1]
      Request Id=09403213-dd3a-4101-88e8-db8ab19e1eeb (httpbin.org) started
info: RequestIdLogger[2]
      Request Id=09403213-dd3a-4101-88e8-db8ab19e1eeb succeeded in 83.2484ms
info: RequestIdLogger[1]
      Request Id=254e49bd-f640-4c56-b62f-5de678eca129 (httpbin.org) started
info: RequestIdLogger[2]
      Request Id=254e49bd-f640-4c56-b62f-5de678eca129 succeeded in 162.7776ms
info: RequestIdLogger[1]
      Request Id=e25ccb08-b97e-400d-b42b-b09d6c42adec (localhost) started
fail: RequestIdLogger[3]
      Request Id=e25ccb08-b97e-400d-b42b-b09d6c42adec FAILED

避免从内容流中读取

例如,如果您打算阅读和记录请求和响应内容,请注意,它可能会对最终用户体验产生不利的副作用并导致错误。例如,请求内容可能在发送之前被消耗,或者巨大的响应内容可能最终被缓冲在内存中。此外,在 .NET 7 之前,访问标头不是线程安全的,可能会导致错误和意外行为。

谨慎使用异步日志记录

我们期望同步 IHttpClientLogger 接口适用于绝大多数自定义日志记录用例。出于性能原因,建议不要在日志记录中使用异步。但是,如果严格要求日志记录中的异步访问,您可以实现异步版本 IHttpClientAsyncLogger。它派生自
IHttpClientLogger
,因此可以使用相同的 AddLogger API 进行注册。

请注意,在这种情况下,还应该实现日志记录方法的同步对应项,特别是如果该实现是面向 .NET Standard 或 .NET 5+ 的库的一部分。同步对应项是从同步 HttpClient.Send 方法调用的;即使 .NET Standard 表面不包含它们,.NET Standard 库也可以在 .NET 5+ 应用程序中使用,因此最终用户可以访问同步 HttpClient.Send 方法。

包装和不包装记录仪

当您添加记录器时,您可以显式设置wrapHandlersPipeline参数来指定记录器是否将被

  • 包装处理程序管道(添加到管道的顶部,对应于上面
    旧日志记录概述
    部分中的 1、2、7 和 8 号消息)
  Request -->
*   [LogRequestStart()]                // wrapHandlersPipeline=TRUE
      --> Additional Handlers #1..N -->    // handlers pipeline
          --> Primary Handler -->
                --------Transport--layer--------
          <-- Primary Handler <--
      <-- Additional Handlers #N..1 <--    // handlers pipeline
*   [LogRequestStop()]                 // wrapHandlersPipeline=TRUE
  Response <--
  • 或者,不包装处理程序管道(添加到底部,对应于上面
    旧日志记录概述
    部分中的第 3、4、5 和 6 号消息)。
  Request -->
    --> Additional Handlers #1..N --> // handlers pipeline
*     [LogRequestStart()]             // wrapHandlersPipeline=FALSE
          --> Primary Handler -->
                --------Transport--layer--------
          <-- Primary Handler <--
*     [LogRequestStop()]              // wrapHandlersPipeline=FALSE
    <-- Additional Handlers #N..1 <-- // handlers pipeline
  Response <--

默认情况下,记录器添加为不包装。

在将重试处理程序添加到管道的情况下(例如 Polly 或某些重试的自定义实现),包装和不包装管道之间的区别最为显着。在这种情况下,包装记录器(位于顶部)将记录有关单个成功请求的消息,记录的经过时间将是从用户发起请求到收到响应的总时间。非包装记录器(位于底部)将记录每次重试迭代,第一个可能记录异常或不成功的状态代码,最后一个记录成功。每种情况下消耗的时间都是纯粹在主处理程序中花费的时间(实际在网络上发送请求的处理程序,例如 HttpClientHandler)。

这可以用下图来说明:

  • 包装案例 (wrapHandlersPipeline=TRUE)
  Request -->
*   [LogRequestStart()]
        --> Additional Handlers #1..(N-1) -->
            --> Retry Handler -->
              --> //1
                  --> Primary Handler -->
                  <-- "503 Service Unavailable" <--
              --> //2
                  --> Primary Handler ->
                  <-- "503 Service Unavailable" <--
              --> //3
                  --> Primary Handler -->
                  <-- "200 OK" <--
            <-- Retry Handler <--
        <-- Additional Handlers #(N-1)..1 <--
*   [LogRequestStop()]
  Response <--
info: Example.CustomLogger.Wrapping[1]
      GET https://consoto.com/
info: Example.CustomLogger.Wrapping[2]
      200 OK - 809.2135ms
  • 不包装案例 (wrapHandlersPipeline=FALSE)
  Request -->
    --> Additional Handlers #1..(N-1) -->
        --> Retry Handler -->
          --> //1
*           [LogRequestStart()]
                --> Primary Handler -->
                <-- "503 Service Unavailable" <--
*           [LogRequestStop()]
          --> //2
*           [LogRequestStart()]
                --> Primary Handler -->
                <-- "503 Service Unavailable" <--
*           [LogRequestStop()]
          --> //3
*           [LogRequestStart()]
                --> Primary Handler -->
                <-- "200 OK" <--
*           [LogRequestStop()]
        <-- Retry Handler <--
    <-- Additional Handlers #(N-1)..1 <--
  Response <--
info: Example.CustomLogger.NotWrapping[1]
      GET https://consoto.com/
info: Example.CustomLogger.NotWrapping[2]
      503 Service Unavailable - 98.613ms
info: Example.CustomLogger.NotWrapping[1]
      GET https://consoto.com/
info: Example.CustomLogger.NotWrapping[2]
      503 Service Unavailable - 96.1932ms
info: Example.CustomLogger.NotWrapping[1]
      GET https://consoto.com/
info: Example.CustomLogger.NotWrapping[2]
      200 OK - 579.2133ms

原文链接

.NET 8 Networking Improvements

知识共享许可协议

本作品采用
知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议
进行许可。

欢迎转载、使用、重新发布,但务必保留文章署名 郑子铭 (包含链接:
http://www.cnblogs.com/MingsonZheng/
),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。

如有任何疑问,请与我联系 (
MingsonZheng@outlook.com
)