背景

我们的新项目有个比较复杂的全区全服交易行系统，其中搜索和推荐是高实时性全区服多维度排序的，并且要支持比较复杂的标签交集查询和属性范围查询的自由组合。 当有订单发生变化时，它不仅仅会影响全服状态下搜索和推荐条件的结果变化，也会同时影响商品维度的聚合，交易行层面的数据聚合。

前言

我们项目组前段时间排查和分析压测环境下的某些业务模块大量索引结构的内存问题。通用的工具比如 jemalloc+jeperf 或者 tcmalloc+gperf 的组合过于底层，一方面开启跟踪开销较高，另一方面也是会产生过多噪音数据影响判断。所以我针对我们的智能指针（包含 std::shared_ptr 和我最近写了个非线程安全的版本的 strong_rc_ptr ， 这个后面有空再分享）和STL容器实现了allocator来帮助动态的手动插桩来分析问题。 最终的效果是可以通过一键替换类型申明的Allocator来插入动态控制和插桩统计的能力，这里分享一下手夯标准STL allocator的一些实现细节，方便其他小伙伴如果需要做类似的实现来参考。

背景

这篇分享拖更了好久了。问题起源于去年我们项目组接入 opentelemetry-cpp 的时候，在进程优雅退出的时候偶现超时，虽然可以直接kill进程没啥影响但是退出不“优雅”的话总归会破坏发布流程，增加人工介入的成本。这里记录一下问题可能其他的组件有类似的用法也会有相似的问题。

前言

近期发现项目组使用新版本的 opentelemetry-cpp 的时候偶现崩溃。崩溃的位置在STL的 std::future 析构的地方，而这个 std::future 由 std::async创建。 比较违反直觉，这里记录分享一下分析和解决过程方面其他碰到的小伙伴们。

背景

早先社区报过 opentelemetry-cpp 在GCC 14中编译不通过的问题。最近我也是先升级我们项目组的工具链，主要也是把GCC升级到GCC 14，这时候发现有些第三方工具构建失败。 这里记录一下以防后续其他人碰到参考。

前言

xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。

主要功能特点：

• 跨平台（java 11 or upper）
• Excel => protobuf/msgpack/lua/javascript/json/xml
• 完整支持协议结构，包括嵌套结构和数组嵌套
• 同时支持protobuf proto v2 和 proto v3
• 支持导出proto枚举值到lua/javascript代码和json/xml数据
• 支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能）
• 支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 DataTable 加载代码
• 支持别名表，用于给数据内容使用一个易读的名字
• 支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效
• 支持通过protobuf协议插件控制部分输出
• 支持自动合表，把多个Excel数据表合并成一个输出文件
• 支持公式
• 支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map
• 支持空数据压缩（裁剪）或保留定长数组
• 支持基于正则表达式分词的字段名映射转换规则
• 支持设置数据版本号
• Lua输出支持全局导出或导出为 require 模块或导出为 module 模块。
• Javascript输出支持全局导出或导出为 nodejs 模块或导出为 AMD 模块。
• 提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux）
• 提供GUI批量转换工具（支持Windows、macOS、Linux）
• CLI/GUI批量转换工具支持include来实现配置复用

xresloader 包含了多个组件，其中最主要的部分分别是。

前言

opentelemetry-cpp 在标准上报协议OTLP里是支持使用 gRPC 作为传输协议的。但是，当 gRPC 被作为静态库同时链接进多个动态库时，在一些平台上会有一些问题。这是 gRPC 本身的一些实现方式导致的。 一直拖到今天才来比较完整得写这个问题的具体成因和解决方案，实际上也有一些其他库有相似实现的也会有相同的问题，所以分享出来看看有没有其他同学也可能碰到可以参考一下。

前言

xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。

主要功能特点：

• 跨平台（java 11 or upper）
• Excel => protobuf/msgpack/lua/javascript/json/xml
• 完整支持协议结构，包括嵌套结构和数组嵌套
• 同时支持protobuf proto v2 和 proto v3
• 支持导出proto枚举值到lua/javascript代码和json/xml数据
• 支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能）
• 支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 DataTable 加载代码
• 支持别名表，用于给数据内容使用一个易读的名字
• 支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效
• 支持通过protobuf协议插件控制部分输出
• 支持自动合表，把多个Excel数据表合并成一个输出文件
• 支持公式
• 支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map
• 支持空数据压缩（裁剪）或保留定长数组
• 支持基于正则表达式分词的字段名映射转换规则
• 支持设置数据版本号
• Lua输出支持全局导出或导出为 require 模块或导出为 module 模块。
• Javascript输出支持全局导出或导出为 nodejs 模块或导出为 AMD 模块。
• 提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux）
• 提供GUI批量转换工具（支持Windows、macOS、Linux）
• CLI/GUI批量转换工具支持include来实现配置复用

xresloader 包含了多个组件，其中最主要的部分分别是。

前言

近期的 protobuf v22和 gRPC v1.55 版本在构建流程层面引入了一些比较大的变化。 最初我关注到这个问题是在我参与的一个社区项目 opentelemetry-cpp 的issue中（ https://github.com/open-telemetry/opentelemetry-cpp/issues/2095 ）。 直到后来，我们在自己的构建系统 cmake-toolset 对 protobuf 和 gRPC 也进行了升级。所以顺带给社区的项目也提交了一些相关的Patch，在这里分享一下可能其他同学也会碰到。

前言

年初的时候我们项目组的构建系统( cmake-toolset )里把 protobuf 升级到了 v20/v3.20 版本, gRPC 也升级到了 v1.54 版本。然而这两个版本在Linux的ELF ABI和MacOS的Macho ABI下都出现了一些符号未定义的问题（当然也包含Android和iOS）。 这些问题也不仅限于 protobuf v20/v3.20 和 gRPC v1.54，后续的版本有些修复了，有些没有。在官方完全修复之前，我们自己打了一些patch去修复这些问题。

前言

xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。

主要功能特点：

• 跨平台（java 11 or upper）
• Excel => protobuf/msgpack/lua/javascript/json/xml
• 完整支持协议结构，包括嵌套结构和数组嵌套
• 同时支持protobuf proto v2 和 proto v3
• 支持导出proto枚举值到lua/javascript代码和json/xml数据
• 支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能）
• 支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 DataTable 加载代码
• 支持别名表，用于给数据内容使用一个易读的名字
• 支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效
• 支持通过protobuf协议插件控制部分输出
• 支持自动合表，把多个Excel数据表合并成一个输出文件
• 支持公式
• 支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map
• 支持空数据压缩（裁剪）或保留定长数组
• 支持基于正则表达式分词的字段名映射转换规则
• 支持设置数据版本号
• Lua输出支持全局导出或导出为 require 模块或导出为 module 模块。
• Javascript输出支持全局导出或导出为 nodejs 模块或导出为 AMD 模块。
• 提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux）
• 提供GUI批量转换工具（支持Windows、macOS、Linux）
• CLI/GUI批量转换工具支持include来实现配置复用

xresloader 包含了多个组件，其中最主要的部分分别是。

前言

我们终于在年初的时候最后完成了整体服务器框架对C++20协程的支持和接入。虽然之前陆陆续续抽时间改造一些组件，让它支持C++20协程，期间也记录了一些早期的设计思路和踩的坑（包括 《libcopp接入C++20 Coroutine和一些过渡期的设计》和《libcopp对C++20协程的接入和接口设计》），其中不乏一些C++20协程使用上可能打破我们常规思路细节和编译器的BUG。而且这些都是各个组件的改造，并没有最后整合到一起。

背景

Opentelemetry-cpp 是可观测领域，opentelemetry (CNCF基金会孵化项目)的C++ SDK接入层。 opentelemetry 里面主要是分链路跟踪(Trace)、指标(Metrics)、日志(Logs)三大块。 同时 opentelemetry 有一个标准规范文档 opentelemetry-specification ，而SDK实现主要就是来对这个标准规范文档的特定语言实现。 由于日志(Logs)这一块一直处于Experimental阶段，所以很长时间以来 C++ SDK接入层 都没有及时更新跟进规范的变化。

前言

前段时间集成一些公司内组件的时候发现它依赖 nghttp2 。正好之前一直有给我的构建工具(cmake-toolset)里的构建 curl 的流程加 HTTP/2 和 HTTP/3 的计划。 所以这波一次性搞定了。

构建工具 cmake-toolset 和 curl

首先，curl 是支持多种第三方库作为 HTTP/2 和 HTTP/3（QUIC）算法库的。比如 nghttp3+ngtcp2，或者微软家 msquic，或者Google家 quiche。 其中HTTP/3只能选一个，互相是冲突的。而Google的quiche官方仅有对bazel构建系统的支持，而我的cmake-toolset是cmake生态的。 这里选用 nghttp3+ngtcp2 的组合，主要是为了和其他的模块共享依赖。

背景

传说中的下一代 iptables 的 nftables 已经出来了好长时间了。现在主流发行版的内核也都已经更新到了对 nftables 支持足够好的版本。 在2年多前我也初步体验过了 nftables ，当时写了个 《nftables初体验》 。并且开始使用 nftables 来实现对家里软路由的管理。 而去年的时候，我也尝试用 nftables 实现了双拨（详见: 《折腾一下nftables下的双拨》）并且可以搭配TPROXY透明代理使用。

前言

前段时间有人在 opentelemetry-cpp 提出了api组件在动态库中单例无法工作的 issue ，( https://github.com/open-telemetry/opentelemetry-cpp/issues/1520 ) 。

opentelemetry 是可观测性领域的开源项目，目标是统一链路跟踪、数据指标和日志的服务、上报、协议和接口规范，目前属于 CNCF基金会 孵化项目。而 opentelemetry-cpp 则是 opentelemetry 中对标准规范SDK的C++实现。

前言

xresloader 是一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript、UE-Csv、UE-Json等数据格式的工具。 并且整个工具链还包含了基于模板引起生成读表代码的 xres-code-generator ，方便产品/策划使用的 GUI批量执行工具 - xresconv-gui 和方便CI集成和程序使用的 命令行批量执行工具 - xresconv-cli。

前言

最近新项目重新评估了一下protobuf的C/C++ -> Lua binding 方案。之前，使用最广泛的 Lua binding 方案应该是 云风 的 pbc 。但是这个库已经是作者弃坑好多年的状态了。我之前使用 pbc 的时候刚碰上 protobuf 3.0 刚出来，当时打了patch来适配 protobuf 3.0 ，还修复了一些其他问题。这个Patch有些推给了上游，有些因为和上游的某些机制冲突没有推。我了解到的很多其他项目也或多或少的打了自己的Patch，大多数也没往上游推。基本上 pbc 已经处于一个失维的状态，所以这次新项目就干脆来寻求更好，或者说仍然有良好活跃度的解决方案。于是就看向了 upb 。

前言

最近开的坑有点多。有点忙不过来了所以好久没写Blog了。这个C++20的协程接入一直在改造计划中，但是一直没抽出时间来正式实施。 在之前，我写过一个初版的C++20协程接入 《libcopp接入C++20 Coroutine和一些过渡期的设计》 。当时主要是考虑到 Rust也有和C++类似的历史包袱问题，所以参考了一些Rust协程改造过程中的设计。 但是后来尝试在项目中使用的时候发现还是有一些问题。首先C++20的协程并不是零开销抽象，所以强行用Rust的模式反而带来了一定开销和理解上的难度。其次原先的设计中 generator 是按类型去实现外部接入的。但是实际接入SDK的过程中我们有相当一部分类型相同但是接入流程不同的情况，再加上现在各大编译器也都已经让C++20协程的特性脱离 experimental 阶段了，有一些细节有所变化。所以干脆根据我们实际的使用场景，重新设计了下组织结构。

前言

一直以来，我都维护了完整的 GCC 工具链构建工具 和 LLVM,Clang,libc++,libc++abi工具链构建工具 。 一方面是为了测试和体验新版本编译器的功能和利用一些更现代化的工具检查代码中的风险，另一方面也是为了给我得很多开源仓库做多版本适配。 其中所有的编译期依赖项（不包括 tar,awk等可执行程序的工具）都是自己构建的，这样也能管理好某些新版本组件需要的新版本依赖项，并且做到跨发行版兼容。同时很多发行版自带的 LLVM+Clang 套件都缺斤少两，有的缺少 clang-analyzer ，有的缺少 clang-format ，也有的缺少 libc++ 和 libc++abi 或者缺少sanitizer组件。我也是根据自己的需要编译并输出了大多数开发工具，甚至还有一些开发库以便二次开发（比如用libclang写工具来复用libcang的AST功能）。