素履独行 | 元培的个人博客

当提及 ChatGPT 等生成式 AI 产品时，大家第一时间想到的是什么？对博主而言，印象最为深刻的是其流式输出效果，宛如打字机一般流畅。相信大家都注意到了，我给博客增加了 AI 摘要功能。虽然，这是一个非常“”的功能，可是在光标闪烁的一刹那，我居然产生了一种“”的莫名期待。然而，此时此刻，理性会告诉我们：ChatGPT 的流式输出并不是为了让 AI 更“”人类，它本质上是一种减少用户等待时长的优化策略。相比于人类的闪烁其词，心直口快或许更接近 AI 的真实想法。。

最近，博主为增加了协议的支持。这意味着，我们可以借助其全双工通信的特性，在一个连接请求内发送多条数据。FakeRPC 目前最大的遗憾是，建立在 HTTP 协议上而不是 TCP/IP 协议上。因此，考虑 WebSocket 协议，更多的是为了验证的可行性，以及为接下来的要支持的 TCP/IP 协议铺路。也许，你从未意识到这些概念间千丝万缕的联系，可如果我们把每一次 RPC 调用都理解为一组消息，你是不是就能更加深刻地理解 RPC 这个稍显古老的事物了呢？在编写 FakeRPC 的过程中，我使用了.NET。

在很长的一段时间里，我们的项目中一直使用这个基类来记录每个方法的日志。诚然，这个文件的存在，早已在冥冥之中暗示我，才是这座冰山下真正的墨西哥湾暖流。可惜，因为某种阴差阳错的巧合，譬如两者都使用了这个命名，这导致我过去一直以为我们使用的是。如果你是用过或者这些由出品的工具，你大概会听说过 PostSharp。不过，有趣的是，JetBrains 和 PostSharp 其实没有半毛钱的关系，两者唯一相似的地方，或许是它们都不姓微软😂。当我们谈论 PostSharp 的时候，我其实想说的是静态编织。

最近，我收到一位读者朋友的私信，问我 ELK 为什么没有下篇，道德感极强的我不得不坦诚相告，显然这一篇鸽了。这就是说，鸽子不单单会出现在吴宇森的电影里，只要你试图拖延或者逃避，你一样有鸽子可以放飞。话说回来，新冠疫情已然持续了三年，而这篇文章其实是我在新冠元年写下的。某年某月，彼时彼刻，立春过后紧接着是上元节，阳光已透过玻璃宣示着春天的到来，可在这一墙之隔的里里外外，仿佛是两个气候迥异的世界。记忆里那种每天都和消毒水、口罩打交道的日子，后来就变成了一种习以为常、甚至有一点唏嘘的常态化生活。......

一直打算写一篇关于 ASP.NET Core 集成测试 的文章，因为一旦说起单元测试这个话题，多多少少会牵动我内心深处的理想主义色彩，虽然如今已然是程序员职业生涯的第七年，可在我看来依然有太多东西在原地打转。这一路跌跌撞撞地走过来，在不同的公司里，见识到了形态各异的研发流程，接触到了貌合神离的敏捷思想，阅读过了风格迥异的框架/架构。当时间节点来到 2022 年，惊觉 诞生业已 20 周年，虽然技术一直在不断向前发展，可我个人感觉，我们并没有在工程化上取得多少感人的进步，譬如单元测试、需求管理，这些听起来丝

在上家公司工作的时候，我们有部分业务是采用事件/消息驱动的形式。虽然，当时博主还没能用上诸如 Kafka、RabbitMQ 这样的消息中间件，可数据库 + Quartz 这样一个堪称“简陋”的组合，完全不影响博主对事件/消息驱动这种思想的启蒙。后来，在实现数据库审计、数据同步 等问题的时候，更是从实践层面上加深了这一印象。再后来，博主陆陆续续地接触了 DDD，其中 领域事件 的概念，第一次让博主意识到，原来事件可以和聚合根产生某种联系。退一步讲，即使你没有接触过 DDD，你只要听说过 MediatR 或者

在此之前，我曾写过一篇博客，《Envoy 集成 Jaeger 实现分布式链路跟踪》，主要分享了 ASP.NET Core 应用如何结合 Envoy 和 Jeager 来实现分布式链路跟踪，其核心思想是生成一个全局唯一的x-request-id，并在不同的微服务或者子系统中传播该信息。进而，可以使得相关的信息像一条线上的珠子一样串联起来。在此基础上，社区主导并产生了 OpenTracing 规范，在这个 规范 中，一个 Trace，即调用链，是由多个 Span 组成的有向无环图，而每个 Span 则可以含有多

本文内容定义 Protobuf实现上传实现下载现实挺骨感本文小结几天前，某人同我抱怨，说是某接口无法正常工作，坦白地讲，这只是程序员生命里再枯燥不过的日常，因为无论“好”或者“不好”，他们都要努力回应来自灵魂深处的那声“为什么”。所以，善待程序员的方式之一，就是不要总问他“为什么”，因为他已经听了太多的“为什么”。经过一番攀谈交心，我了解到是模型绑定出了问题。原来，他需要实现一个导出/下载功能，因为他不确定能否通过 Envoy 代理来自 gRPC 的文件流，故而，他选择了传统的 Web API，结果不曾想

“这是最好的时代，这是最坏的时代”，英国作家查尔斯·狄更斯在两百多年前写下的这句话，如果从辩证的角度来看，它或许可以适用于任何一个时代。我们生活在一个怎样的时代呢？我想，或许是一个矛盾的时代。因为，有时它让你对未来有无限的期待，有时它又会让你陷入无尽的绝望，特别是当集体和个人的命运形成强烈反差的时候，当实用主义、精致利己主义开始盛行的时候，我们偶尔会感慨罗曼蒂克的消亡、怀念从前慢、追忆芳华，可下一秒就被卷入到同时间赛跑的庸庸碌碌当中。生活节奏越来越快，人们越来越追求实时、速度、效率，选择当下的同时，意味着选

本文内容从 HTTP/2 说起gRPC 中的流式传输客户端流服务器端流双向流本文小结最近一直在研究 gRPC 的 ServerReflection，顾名思义，这是 gRPC 里提供的反射接口，当你需要获取某个接口的描述信息，或者是希望动态调用 gRPC 的时候，这一切就会变得非常有用，如果你经常使用 gRPC UI 这款工具来调试 gRPC 接口，那么，你一定会注意到一件事情，即它要求服务端必须支持 ServerReflection API，而这一点在 ASP.NET Core 中已经得到支持，对此感兴趣

本文内容楔子gRPCSignalRKafka本文小结据我所知，软件行业，向来是充满着鄙视链的，人们时常会因为语言、框架、范式、架构等等问题而争执不休。不必说 PHP 到底是不是世界上最好的语言，不必说原生与 Web 到底哪一个真正代表着未来，更不必说前端与后端到底哪一个更有技术含量，单单一个 C++ 的版本，1998 与 2011 之间仿佛隔了一个世纪。我真傻，我单知道人们会因为 GCC 和 VC++ 而分庭抗礼多年，却不知道人们还会因为大括号换行、Tab 还是空格、CRLF 还是 CR……诸如此类的问题

本文内容Protobuf 里的 Any 类型在 .NET 中使用 Any 类型本文小结我发现，人们非常喜欢在一件事情上反复横跳。譬如，以编程语言为例，人们喜欢静态的、强类型语言的严谨和安全，可难免会羡慕动态的、弱类型语言的自由和灵活。于是，在过去的这些年里，我们注意到，.NET 的世界里出现了 dynamic 类型，JavaScript 的世界里出现了 TypeScript，甚至连 Python 都开始支持类型标注。这种动与静、强与弱的角逐，隐隐然有种太极圆转、轮回不绝的感觉。果然，“城外的人想冲进去，城

有人说，程序员最讨厌两件事情，一件是写文档，一件是别人不写文档，这充分展现了人类双标的本质，所谓的“严于律人”、“宽于律己”就是在说这件事情。虽然这种听来有点自私的想法，是生物自然选择的结果，可一旦人类的大脑皮层在进化过程中产生了“理性”，就会试图去纠正这种来自动物世界的阴暗面。所以，人类双标的本质，大概还是因为这个行为本身就有种超越规则、凌驾于众人之上的感觉，毕竟每个人生来就习惯这种使用特权的感觉。回到写文档这个话题，时下流行的微服务架构，最为显著的一个特点是：仓库多、服务多、接口多，此时，接口文档的重要

Hi，大家好，我是飞鸿踏雪，欢迎大家关注我的博客。近来，博主经历了一次服务器迁移，本以为有 Docker-Compose 加持，一切应该会非常顺利，没想到最终还是在证书上栽了跟头，因为它的证书是和IP地址绑定的。对，你没听错，这个世界上还真就有这么别扭的设定，尤其是你折腾了一整天，发现你需要到一个 CA 服务器上去申请证书的时候，那种绝望你晓得吧？数字证书、HTTPS、SSL/TLS、加密……无数的词汇在脑海中席卷而来，这都是些啥啊？为了解答这些困惑，经历了写字、画图、查资料的无数次轮回，终于在周末两天淅淅

在构建以 gRPC 为核心的微服务架构的过程中，博主曾经写过一篇名为 ASP.NET Core gRPC 打通前端世界的尝试 的文章，主要是希望打通 gRPC 和 前端这样两个异次元世界，因为无论我们构建出怎样高大上的微服务架构，最终落地的时候，我们还是要面对当下前后端分离的浪潮。所以，在那篇文章中，博主向大家介绍过 gRPC-Web 、gRPC-Gateway 、封装 API 、编写中间件 这样四种方案。我个人当时更喜欢编写中间件这种方案，甚至后来博主进一步实现了 gRPC 的 “扫描” 功能。当时，博主

AOP，即：面向切面编程，关于这个概念，博主其实写过好几篇博客啦！从这个概念，我们可以引申出诸如代理模式、动态代理、装饰器模式、过滤器、拦截器等等相互关联的概念。从实现方式上而言，微软官方的 .NET Remoting 提供了真实代理和透明代理的支持，我们熟悉的 WebService 和 WCF 均和这项技术息息相关，作为最早的分布式 RPC 解决方案，其本身更是与客户端的动态代理密不可分。或许，各位曾经接触过 Unity、Castle、AspectCore、PostSharp 等等这些支持 AOP 特性的

在构建以 gRPC 为核心的微服务架构的过程中，得益于 Envoy 对 gRPC 的“一等公民”支持，我们可以在过滤器中对gRPC服务进行转码，进而可以像调用 Web API 一样去调用一个 gRPC 服务。通常情况下， RPC 会作为微服务间内部通信的信使，例如，Dubbo、Thrift、gRPC、WCF 等等更多是应用在对内通信上。所以，一旦我们通过 Envoy 将这些 gRPC 服务暴露出来，其性质就会从对内通信变为对外通信。我们知道，对内和对外的接口，无论是安全性还是规范性，都有着相当大的区别。博主

在构建微服务架构的过程中，我们会接触到服务划分、服务编写以及服务治理这一系列问题。其中，服务治理是工作量最密集的一个环节，无论是服务发现、配置中心、故障转移、负载均衡、健康检查……等等，这一切的一切，本质上都是为了更好地对服务进行管理，尤其是当我们面对数量越来越庞大、结构越来越复杂的集群化环境的时候，我们需要一种科学、合理的管理手段。博主在上一家公司工作的时候，每次一出现线上故障，研发都要第一时间对问题进行排查和处理，而当时的运维团队，对于微服务的监控止步于内存和CPU，无法系统而全面的掌握微服务的运行情况

如果说，我们一定要找出一个词来形容这纷繁复杂的世界，我希望它会是熵。有人说，熵增定律是宇宙中最绝望的定律，所谓熵，即是指事物混乱或者无序的程度。在一个孤立系统下，熵是不断在增加的，当熵达到最大值时，系统就会出现严重混乱，直至最终走向死亡。从某种意义上来讲，它揭示了事物结构衰退的必然性，甚至于我们的人生，本来就是一场对抗熵增的旅程。熵增的不可逆性，正如时光无法倒流一般，古人说，“覆水难收”正是这个道理。同样地，当我们开始讨论微服务的划分/编写/治理的时候，当我们使用服务网格来定义微服务架构的时候……我们是否有

本文内容走近 EnvoyEnvoy配置文件侦听器(Listeners)过滤器(Filters)集群(Clusters)负载均衡(Load Assignment)管理(Admin)服务编排本文小结参考文档第一次接触到Envoy，其实是在微软的示例项目 eShopOnContainers 。当时，博主并没有对它做深入的探索，直到最近，需要在一个项目中用到Envoy，终于决定花点时间来学习一下相关内容。所以，接下来这几篇博客，大体上会记录我学习Envoy的过程。考虑到Envoy的配置项特别多，在写作过程中难免会

本文内容gRPC-WebgRPC-Gateway封装 Web API编写中间件本文小结在构建以 gRPC 为核心的微服务架构的过程中，我们逐渐接触到了 gRPC 的过滤器、健康检查、重试等方面的内容。虽然， Protocol Buffers 搭配 HTTP/2 ，在整个传输层上带来了显著的性能提升，可当这套微服务方案面对前后端分离的浪潮时，我们能明显地有点“水土不服”。其实，如果单单是以 Protocol Buffers 来作为 HTTP 通信的载体，通过 protobuf.js 就可以实现前端的二进制化

引言在软件开发过程中，数据库永远都是绕不开的一个话题。有时候，我们甚至会因此而获得一个名字——“CURD Boy”。虽然不过是朴实无华的“增删查改”，可隐隐然早已分出了无数的流派。在这些不同的流派中，有的人坚持“我手写我心”，认为手写SQL才是真正的王道，没有读过/写过成百上千行的存储过程，便不足以谈论程序员的人生。而有的人喜欢ORM的清晰、整洁，认为数据库和面向对象存在着天然抗阻，ORM更有利于推进DDD和微服务的落地。相信大家都听说过Java里的SSH框架，从Hibernate到Mybatis再到Sp

本文内容引言基于 gRPC RetryPolicy基于 HttpClientFactory基于 gRPC 拦截器基于 CallInvoker本文小结在上一篇 博客 中，我们一起探索和实现了gRPC的健康检查。从服务治理的角度来看，健康检查保证的是被调用的服务“健康”或者“可用”。可即使如此，我们依然会遇到，因为网络不稳定等原因而造成的服务调用失败的情形，就如同我们赖以生存的这个真实世界，本身就充满了各种不确定的因素一样，“世间唯一不变的只有变化本身”。不管是面对不稳定的服务，还是面对不确定的人生，任何时候

最近，博主偶然间在 博客园 看到一篇文章：ASP.NET Core 扩展库之 Http 请求模拟，它里面介绍了一种利用 HttpMessageHandler 来实现 Http 请求模拟的方案。在日常工作中，我们总是不可避免地要和第三方的服务或者接口打交道，尤其是当我们需要面对“联调”这样一件事情的时候。通常，我们可以通过类似 YAPI 这样的工具来对尚在开发中的接口进行模拟。可是，因为这种方式会让我们的测试代码依赖于一个外部工具，所以，从严格意义上讲，它其实应该属于“集成测试”的范畴。在接触前端开发的过程中

gRPC是微软在.NET Core 及其后续版本中主推的 RPC 框架，它使用 Google 的 Protocol Buffers 作为序列化协议，使用 HTTP/2 作为通信协议，具有跨语言、高性能、双向流式调用等优点。考虑到，接下来要参与的是，一个以gRPC为核心而构建的微服务项目。因此，博主准备调研一下gRPC的相关内容，而首当其冲的，则是从 .NET Core 3.1 开始就有的拦截器，它类似于ASP.NET Core中的过滤器和中间件，体现了一种面向切面编程(AOP)的思想，非常适合在RPC服务调

gRPC微服务健康检查Consul各位朋友，大家好，欢迎大家关注我的博客。在上一篇 博客 中，博主和大家分享了gRPC的拦截器在日志记录方面的简单应用，今天我们继续来探索gRPC在构建微服务架构方面的可能性。其实，从博主个人的理解而言，不管我们的微服务架构是采用RPC方式还是采用RESTful方式，我们最终要面对的问题本质上都是一样的，博主这里将其归纳为：服务划分、服务编写 和 服务治理。首先，服务划分决定了每一个服务的上下文边界以及服务颗粒度大小，如果按照领域驱动设计(DDD)的思想来描述微服务，.

本文内容分库分表多租户架构多数据库单数据库本文小结各位朋友，大家好，我是 Payne，欢迎大家关注我的博客，我的博客地址是：https://blog.yuanpei.me。最近这段时间，我一直在学习 ABP vNext 框架，在整个学习过程中，我基本就是在“文档”和“源码”间来回横跳。我个人推荐大家，多去阅读一点优秀的代码，因为阅读 ABP vNext 的源代码简直就是一种享受，它可以暂时让你摆脱如泥沼一般的业务代码。言归正传，ABP vNext 是一个支持多租户架构的框架，在了解了其多租户的实现原理以后

本文内容核心流程核心部件CorsPolicyCorsService再论CORS简单请求复杂请求本文小结本文是 #源代码探案系列# 第三篇，今天这篇博客，我们来一起解读下 ASP.NET Core 中的 CORS 中间件，熟悉这个中间件的的小伙伴们，想必都已经猜出本文的主题：跨域。这确实是一个老生常谈的话题，可我并不认为，大家愿意去深入探究这个问题，因为博主曾经发现，每当工作中遇到跨域问题的时候，更多的是直接重写跨域相关的 HTTP 头。博主曾经写过一篇关于跨域的博客：《聊聊前端跨域的爱恨情仇》，当时是完全

在上一篇文章中，博主带领大家一起深入了解 ConcurrencyLimiter 这个中间件，正当我得意洋洋地向 Catcher Wong 大佬吹嘘这一点小收获时，大佬一脸嫌弃地说，一个单机版的方案有什么好得意的啊。大佬言下之意，显然是指，这个中间件在分布式环境中毫无用武之地。其实，你只需要稍微想一下，就能想明白这个问题。毕竟，它只是通过SeamphoreSlim控制线程数量而已，一旦放到分布式环境中，这个并发控制就被大大地削弱。所以，在今天这篇文章中，博主会带领大家一起“探案” ASP.NET Core 中

本文内容揭秘 QueuePolicy揭秘 StackPolicy揭秘 Middleware本文小结打算开一个新的专栏——源代码探案系列，目的是通过源代码来探索更广阔的技术世界。因为我越来越意识到，我可能缺乏一个结构化的知识体系，虽然处在一个碎片化的时代，从外界接收了大量的信息，可这些碎片化的信息，到底能不能转化为自身可用的知识，其实是需要去认真思考一番。尤其是当我注意到，许多人工作多年，在经历过从“生手”到“熟练工”这种蜕变以后，居然还是会害怕原理性内容的考察。我承认，程序员这个职业更像是一个“手艺人”，