目前来看除夕夜写年终总结确实是一个不错的时间节点，一方面正好是完整的一个农历年，另一方面来说当是守岁。 工作 今年工作上有一些调整，先是年中的时候参与到智能体的一个项目中接着又是产品线调整进入一个新的业务。目前国内智能体平台普通在易用性上都不太行，又由于是“新技术”（或者说新产品）在稳定性上面相对于主流开源平台还是有不小差距的，比较典型的两个问题，一个是在开发上线过程中模型被修改竟然无法定位到具体原因，另一个则是开发过程中经常发现之前调试或已上线功能不可用。对于国内这些智能体开发平台来说真正可用还需要一定时间。 另外就是对于新业务和新团队，一方面有很多业务知识需要补充，又是需要高频学习的阶段；另一方面是管理的混乱，只从技术角度去说的话一方面是系统没有经过良好的设计，只是一味实现需求，至于对既有业务系统影响以及后续扩展和可维护性上面存在比较大的欠缺。 学习 今年最大的遗憾就是没有按期完成小论文，先是和导师沟通在国庆把初稿投出去，然后中间实验不是很顺利一直拖到了元旦，再然后是元旦期间又因为在论文内容和公式推导细节上进展缓慢。在终于把初稿投出去后就是和编辑那边相互卷了，审稿人无论是一轮还是二轮给的意见都很专业也不太好回复。网上看了相关讨论说是可以向编辑申请延期，但我始终觉着如果一件事情不能在今天完成那么明天也将完不成，所以宁愿在春节期间修改也没有向编辑申请延期。当然编辑在最后一个工作日也友善地发邮件过来询问是否有困难和已经开始修改稿件，在回邮件中礼貌地表达感谢并表示由于春节原因可能有一些影响但会赶在 DDL 之前完成相关补充实验和论文修改。 关于学习这方面只能说但愿顺利吧。 技术 Rust! Rust! Rust! 如果说去年是学习Rust的一年那么今年应该说是实践的一年。目前在工作之外的一些代码都尽可能地用Rust来写了，同时针对工作上的一些代码也会思考如果用Rust该如何实现，从代码量上来说 Rust 相关代码算是稳步增长。 LaTeX 暂且把 LaTeX 勉强归为技术这块。其实一直都有想法好好学习下 LaTeX，但毕竟工作中基本没有用到，就算是写文档 Word 也可以说覆盖了 99% 的场景。今年以来由于要完成论文终于强迫自己好好学了下 LaTeX的语法，同时为了更好地掌握相关语法和排版一些手册和笔记也迫使自己使用 LaTeX 来完成。其实真的花点心思熟练下一些常用的 Package，LaTeX 还是很好掌握的而且制作出来的 PDF 排版相比使用 Word 生成的在视觉方面强出不少，当然 TikZ 另当别论。 Gleam 如果说让我选一门编程语言作为下一门语言的话，我想那么一定是 Erlang，但不得不说其学习门槛过于陡峭。好在现在有了 Gleam，作为一门运行在 Erlang 虚拟机上的静态类型语言，它既有 Rust 的安全感，又有 Elixir 的高并发能力，同时语法也没有那么怪异。目前 Gleam 的问题是还比较小众，即便是相对 Elixir 来说也过于小众了，但好的方面是 Gleam 在 2024 年就发布了 1.0 版本并且有一个完善工具链（LSP 插件、包管理器、格式化工具）、有稳定的发布周期和积极活跃的社区。 Java 本来不太想写 Java 这块的，但考虑到今年发布了 JDK 25 还是稍微说两句，现在 Java 迭代越来越快的同时带来的特性也越加丰富，同时也在积极现代化，吸收其他语言特性，这一方面蚕食 Scala 的，另一方面也给 Kotlin 带来挑战。最后说一句对于项目上已经切换到 JDK 21 的系统来说建议尽快切换到 JDK 25，其带来的 Scoped Values 和 结构化并发 解决了虚拟线程下 ThreadLocal 变量不可靠的问题，使得现代并发编程变得更安全高效且更易维护。

今天是 除夕, 决定花时间写一下 2024 年总结, 既是对过去一年工作的回顾，也是对自我的不断完善. 2023 年因各种因素没有做年终总结, 后续还是要严格敦促自己. 工作 今年工作重心上有一些调整, 除了继续延续 23 年研发项目外更多地处理一些研发外围的工作, 既有 研发流程 又有 总结汇报 类的工作. 从研发角度考虑，流程应当尽可能服务于研发工作, 使研发更顺畅工作更顺利否则就会形成 枷锁 和 镣铐, 不仅徒有形式同时还加重一线人员负担. 另外就是对于 口号 和 方法论 颇有感触, 在具体实施过程中存在定位问题和解决问题四象限, 如果能做到定位问题的同时解决问题这个维度是最优的, 但往往迫于人员能力和时间要求一线同学只能靠蛮力硬推, 这样长期下来技术债越堆越高最终成为万年屎山. 而方法论则是大前提抑或是最为重要或最不重要 的一环, 对于路径明确的问题方法论已内化在各个环节之中, 对于没有很好的解决思路或是完全陌生的领域方法论就会显得尤为重要. 回头来说从一线抽出部分精力后终于有时间做一些基础架构和全局整体相关的事情, 下半年原计划做两场以上技术分享，但因年底汇报和一些紧急需求最终搁浅; 另一个就是项目上需针对性地进行性能优化, 初期给了一些优化方案但实施起来研发同学优化的并不是很到位问题也较多, 最终以封装二方包的形式给了一套较为可靠的解决方案, 从而尽可能解放一线人员的心智负担, 提升代码质量. 学习 今年在模式识别遇到了一些问题, 主要是平时工作太忙没课程顾得上期末这段时间也没有较大段的时间可以集中精力, 毫无疑问地挂科了. 不过万幸补考顺利通过也算收获了迄今为止唯一一次挂科, 不知是算学习生涯上的完整还是不完整. 读书 首先值得介绍的是今年阅读了三本关于 DuckDB 相关的书籍 DuckDB in Action, DuckDB: Up and Running 和 Getting Started with DuckDB. DuckDB 是一个主要面向嵌入式系统的 OLAP 开源列式数据库, 简而言之就是补齐 SQLite 在数据分析方面的生态位.

上一篇文章介绍了 CloudFlare 开源的网络框架 Pingora, 此篇文章我们使用该框架从零到一实作一个应用网关. 目前大规模应用的网关主要分为三大类, 一类是以传统 C 语言开发的 Nginx 为基础并通过 Lua 进行扩展的网关, 诸如 OpenResty, Kong 等便是如此; 一类则在诞生之初便完全为云原生提供解决方案的代理, 诸如 Envoy, Linkerd2 和 Cilium (严格说来 Cilium 划分在网关代理类并不合适); 最后一类便是和应用深度绑定的应用网关, 如 Spring Cloud Gateway. 从今天的视角看 Spring Cloud 微服务的模式与云原生存在较大的竞合, 同时 微服务, 注册中心 等概念被 Kubernetes 的不同 Service 通过类 DNS 模式一一种优雅的方式解决, 这也导致了 Spring Cloud Gateway 模块在 Kubernetes 集群内尴尬的境地. 开发中经常面对一种场景是微服务部署到 Kubernetes 内本地无法调试的问题和多应用集群内应用间相互调用的问题. 我们这里通过 Pingora 构建的应用网关主要便是为解决此特定场景下请求转发与应用鉴权的工作, 同时在此基础上可做进一步扩展. 首先声明一个 Gateway 结构体作为网关的主体, 后续有需要时可通过扩展该结构体以绑定资源, 实现一些高级功能. #[derive(Debug, Default)] pub struct Gateway { } 在定义完 Gateway 后, 考虑到 TCP 连接特性我们再定义一个 Host 元组结构体以反映不同服务对应的 IP 和 Port:

CloudFlare 在 2022 年中时曾发布过一篇博文 How we built Pingora, the proxy that connects Cloudflare to the Internet 介绍了其为了解决 Nginx 在实际应用场景下的诸多困境从头设计并使用 Rust 开发了一个名为 Pingora 的 代理, 并在文章中介绍将会开源该系统. 但后续针对 Pingora 便再无其他消息, 开源计划看起来也是遥遥无期, 个人也一直担心是否会像 Servo 一样胎死腹中. 但昨天 CloudFlare 在 Github 上开源了该系统相关代码 cloudflare/pingora, 同时也发布了一篇博文 Open sourcing Pingora: our Rust framework for building programmable network services 介绍了 Pingora 开发相关的工作. 在开发 Pingora 之初, 与所有其他公司一样 CloudFlare 也考虑过通过付费以便 Nginx 背后的公司可以为其进行定制化开发和迁移到其他诸如 Envoy 等第三方代理系统, 但经长期考虑最终还是选择自行构建一个全新的代理系统, 该系统设计目标主要是 快速, 高效 和 安全. 在不舍弃 高效 和 快速 的前提下追求尽可能 安全 的目标, CloudFlare 自然地选择了 Rust 语言开发 Pingora.