#年终总结
#总结
#读书
#技术负责人 今天是 除夕, 决定花时间写一下 2024 年总结, 既是对过去一年工作的回顾，也是对自我的不断完善. 2023 年因各种因素没有做年终总结, 后续还是要严格敦促自己.
工作 今年工作重心上有一些调整, 除了继续延续 23 年研发项目外更多地处理一些研发外围的工作, 既有 研发流程 又有 总结汇报 类的工作. 从研发角度考虑，流程应当尽可能服务于研发工作, 使研发更顺畅工作更顺利否则就会形成 枷锁 和 镣铐, 不仅徒有形式同时还加重一线人员负担. 另外就是对于 口号 和 方法论 颇有感触, 在具体实施过程中存在 定位问题 和 解决问题 四象限, 如果能做到 定位问题 的同时 解决问题 这个维度是最优的, 但往往迫于人员能力和时间要求一线同学只能靠蛮力 硬推, 这样长期下来 技术债 越堆越高最终成为万年屎山. 而 方法论 则是大前提抑或是 最为重要 和 最为不重要 的一环, 对于路径明确的问题方法论已内化在各个环节之中了, 对于没有很好的解决思路或是完全陌生的领域方法论就会显得尤为重要.
回头来说从一线抽出部分精力后终于有时间做一些基础架构和全局整体相关的事情, 下半年原计划做两场以上技术分享，但因年底汇报和一些紧急需求最终搁浅; 另一个就是项目上需针对性地进行性能优化, 初期给了一些优化方案但实施起来研发同学优化的并不是很到位问题也较多, 最终提供 二方包 的形式给了一套较为可靠的解决方案, 尽可能解放一线人员的心智负担, 同时提升代码质量.
学习 今年在 模式识别 遇到了一些问题, 主要是平时工作太忙没有听课期末也没有时间复习, 毫无疑问地挂科了. 不过万幸补考顺利通过也算收获了迄今为止唯一一次挂科, 不知是算完整还是不完整.
#Rust
#Pingora
#Proxy
#Gateway 上一篇文章介绍了 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:
#Rust
#Pingora
#Proxy 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.
#Rust
#Closure 闭包 是在以函数作为一等公民等编程语言中实现词法绑定等一种技术, 闭包 和 匿名函数 在一些语境下经常互为替换, 但严格来说 匿名函数 也即字面意义上等没有被赋予名称等函数, 而 闭包 实际上是函数的一个实例, 相对于常规函数, 闭包 可以捕捉环境上下文环境中的自由变量, 从一般定义来说即:
f(x) = g(x) + h(y)
这里函数 f(x) 可以表示为关于 x 和 y 的函数, 而函数 f 中无 y 的信息(相对的是 f(x, y)), 即 y 是自由变量. 除了本文介绍的 Rust 外其他诸如 Swift, Go, Erlang, JavaScript, Python 等都有 闭包.
前一篇文章介绍了 DHCP 协议定义以及相关信令之间的流转, 本文主要通过 Rust 从头实现一个 DHCP 协议客户端.
环境准备
首先需要安装 Rust, 目前 Rust 官方主要提供 Rustup 这一工具管理 Rust 各版本. 如果是 Windows 可直接下载 Rustup-init.exe 运行即可, 如果是 Linux 或 macOS 则可在 Shell 中运行一下命令快速安装:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Rustup 在安装 Rust 同时也会同时安装 Cargo 这一构建和包管理工具, 相对于 C/C++ 而言极大地减轻依赖和构建管理的心智负担.
在安装完 Rust 和 Cargo 后由于涉及到网络报文, 因此还建议安装 Wireshark(Linux 环境下使用 tcpdump 亦可)以便后续对报文进行分析.
IDE 可以选择 VS Code 或 JetBrains 新发布的 RustRover, 如果选择 VS Code 的话为了进行调试还需同时安装 CodeLLDB 插件.