Tony Bai » Ruby

硬核测评：哪门语言最受 AI 宠爱？13 种语言横向对比，Go 表现如何？

bigwhite — Mon, 09 Mar 2026 00:02:44 +0000

本文永久链接 – https://tonybai.com/2026/03/09/hardcore-review-13-languages-ai-favorite-go-performance

大家好，我是Tony Bai。

随着 Claude Code、Gemini Cli、Codex 等 AI 编程工具的全面普及，“让 AI 写代码”已经从极客的玩具变成了日常的生产力。随之而来的是一个触及灵魂的问题：哪种编程语言最适合交给 AI 去写？

作为 Gopher，我们一直为 Go 语言的“极简语法”、“极速编译”和“强类型安全”感到自豪。我们理所当然地认为，这种没有任何隐式魔法、像白开水一样的语言，绝对是 LLM 的最爱。

然而，现实总是比直觉更骨感。近日，Ruby 核心提交者 Yusuke Endoh（@mame）发布了一份名为 ai-coding-lang-bench 的硬核定量测评报告。他使用 Claude Code（Opus 4.6 模型）对 13 种主流编程语言进行了系统性横向对比。

在这场涵盖了动态语言、静态语言和函数式语言的混战中，Go 语言的表现究竟如何？ 是力压群雄，还是黯然失色？那些备受人类推崇的静态类型系统，在 AI 面前是否成了累赘？

本文和大家一起阅读和拆解这份报告，为你揭晓 AI 时代的语言偏好图谱。

实验设计：让 AI 写一个 Mini-Git

在评价这份报告之前，我们先来看看它的实验设计，这是目前业内少见的、针对 AI Agent 的工程化能力的量化评估。

任务目标：让 Claude Code (Opus 4.6) 从零开始实现一个 mini-git（简化版的 Git）。这是一个极具代表性的任务，它包含了文件 I/O、哈希计算、数据结构操作以及命令行接口，足以考验模型对语言生态的综合运用能力。

测试被巧妙地分为两个阶段，模拟了真实的软件生命周期：

v1 (新项目构建)：实现基础的 init, add, commit 和 log。
v2 (特性扩展)：在 v1 的基础上，增加 status, diff, checkout, reset, rm, show 等复杂指令。

提示词（Prompt）极其极简：“阅读 SPEC-v1.txt，实现它，并确保 test-v1.sh 测试通过。”这种设计最大程度地减少了人类指令的干预，纯粹考验 AI 代理在闭环环境下的自主编码、调试和测试能力。

参赛选手（13种语言/15种配置）：

动态语言：Python, Ruby, JavaScript, Perl, Lua
动态+类型检查器：Python/mypy, Ruby/Steep
静态语言：TypeScript, Go, Rust, C, Java
函数式语言：Scheme (动态), OCaml (静态), Haskell (静态)

每种语言配置运行 20 次，以消除 LLM 生成的随机性带来的误差，并统计其耗时（Time）、成本（Cost，即 Token 消耗）和代码行数（LOC）。

核心发现：动态语言逆袭，Go 位居第二梯队

如果仅看总耗时和总成本（v1 + v2），测试结果呈现出了令人瞩目的阶梯式分布。

第一梯队：Ruby, Python, JavaScript 的绝对统治

在这场 AI 编程竞速中，Ruby（73.1s）、Python（74.6s）和 JavaScript（81.1s）组成了无可争议的第一阵营。

它们不仅生成速度最快、消耗 API 成本最低（均在 $0.40 以下），而且在 20 次测试中表现出了极高的稳定性（标准差极小）。

对于 AI 来说，生成这三种语言的代码就像呼吸一样自然。它们无需繁琐的项目初始化配置（如 Cargo.toml 或 package.json），可以做到“建个文件直接跑”，这种极简的工作流在 v1 阶段（新项目构建）优势极大。

第二梯队：被“强类型”拖慢脚步的 Go 与 Java

现在，来回答大家最关心的问题：Go 表现如何？

答案是：位居第二梯队。Go 的总耗时为 101.6s，平均成本 $0.50。中规中矩。Go 虽然在语法上非常克制，但依然落后于 Python 和 JS 等动态语言。与之类似，Java（115.4s）也因为繁琐的语法结构和强类型约束，留在了这一梯队。

尽管如此，Go 在整个 20 次测试中没有出现一次失败（0 次 fail），这证明了 Go 的编译器在防止 AI 产生“幻觉 Bug”方面，发挥了极其可靠的安全网作用。

“后进生”阵营：Rust 与 C 的挣扎

备受人类极客推崇的 Rust（113.7s，且有 2 次失败）和底层的 C（155.8s）在测试中显得步履维艰。

尤为值得注意的是，在总共 600 次的独立运行中，只有 Rust (2次) 和 Haskell (1次) 出现了测试失败（未能最终跑通 Shell 脚本）的情况。这两门语言都以其极高的心智负担和“编译器教你做人”的严格程度而闻名。

这也是将Rust列入“后进生”阵营的主要原因。如果用《飞驰人生》的拉力赛来比喻，Rust 相当于在40站的赛季中，有两站没能完赛！

深度剖析：为什么 AI 更偏爱动态语言？

在传统的工程视角中，“静态类型防止低级 Bug”、“动态语言难以维护”是金科玉律。但在 LLM 驱动的 Agent 开发流中，这个逻辑为何失效了？作者 Yusuke Endoh 提出了几个关键的解释维度。

训练数据的“虹吸效应”

LLM 的能力直接取决于训练语料的规模和质量。Python、JavaScript 和 Ruby 是过去十几年 Web 开发的绝对主流。GitHub 上海量的这三种语言的开源代码、StackOverflow 上的问答，为 Claude Code 提供了极其丰富的“预训练肌肉记忆”。

当 AI 需要实现一个功能时，它在 Python 的隐空间（Latent Space）中寻找最优解的路径，远比在 Haskell 甚至 Rust 中要清晰、笔直得多。

静态类型的“双刃剑”与重构阻力

静态类型系统的初衷是约束人类，防止我们在重构时犯错。但在 AI 的“ Prompt -> 生成 -> 测试报错 -> 思考 -> 再生成”的迭代循环中，严格的类型检查反而成了巨大的“摩擦力”。

编译成本与调试死锁：在 Rust 或 C 中，当 AI 生成的代码出现类型不匹配时，它需要花费大量的 Token 去阅读复杂的编译器报错信息。有时，为了解决一个简单的借用检查器（Borrow Checker）报错，AI 可能会陷入漫长的、无休止的“试错-编译失败”死循环。
重构牵一发而动全身：在 v2 特性扩展阶段，往往需要修改现有的数据结构。对于 Python，AI 只需要在字典里加个 key；而对于 Rust 或 Java，这可能意味着需要重构一系列的 Struct、更新类型签名、甚至修改与之相关的无数个函数的参数声明。这种“爆炸半径”极大地增加了耗时。

“附加类型检查”的巨大损耗

报告中一个非常有意思的对照组是：原生动态语言 vs 附加类型检查器的动态语言。

Python (74.6s) vs Python/mypy (125.3s) —— 变慢了 1.6~1.7 倍。
Ruby (73.1s) vs Ruby/Steep (186.6s) —— 变慢了 2.0~3.2 倍！

这证明了，迫使 AI 在动态语言中编写严谨的类型注解（Type Annotations），是一项极其昂贵的任务。模型需要耗费额外的算力去推导类型、生成类型声明文件，并且在类型检查器报错时，还要去修复那些在纯动态模式下可能根本不影响运行的“伪 Bug”。

代码量（LOC）的迷思：越短越好吗？

我们通常认为，写得越少，跑得越快。但数据打破了这个迷思。

Haskell 和 OCaml 生成的最终代码行数（224行和 216行）是所有语言中最少的，甚至少于 Python 和 Ruby。然而，它们在生成时间上的表现却排在倒数（Haskell 耗时最长，达 174s）。

这表明，对于 AI 来说，函数式语言那种高度抽象、信息密度极大的代码，生成和推理的成本远高于像 Python、Go 那种稍微啰嗦但逻辑平铺直叙的“大白话”代码。浓缩的未必是精华，对于 LLM 来说，高度浓缩往往意味着更高的生成熵和更高的试错概率。

行业启示：我们需要重新思考 AI 时代的技术栈选型

面对这份详实的基准测试报告，无论你是 CTO 还是普通开发者，都必须开始重新审视未来的技术选型逻辑。

动态语言是快速原型的“绝对王者”

如果你正在启动一个新项目，或者需要用 AI Agent 快速验证一个业务流程，Python 和 TypeScript 是首选（报告中 JavaScript 表现优于 TS，但在实际工程中 TS 的综合权衡更佳）。

不要迷信“大型项目必须一开始就上强类型编译语言”。在需求快速变化的初期，让 AI 用动态语言狂飙突进，是获取业务反馈最高效的手段。

性能王者们的困境：Go 与 Rust 在 AI 时代掉队了吗？

看到测评数据，很多 Gopher 可能会感到失落：难道注重工程严谨性和系统级性能的静态语言，真的在 AI 时代掉队了吗？

结论并非如此悲观。我们需要明确一点：Agent 测评的速度，不等于软件最终运行的速度。

业务试错 vs 基础设施：AI Agent 目前最擅长、也最快速能完成的，是写“胶水逻辑”和“业务 CRUD”。在这些领域，Python 确实快。但当你的系统涉及到高并发、内存精细控制、或者需要打包为轻量级容器部署时，人类依然需要 Go。
容错的底线：在这场 600 次的庞大测试中，只有 Rust 和 Haskell 出现了最终测试失败，而 Go 保持了完美的 100% 成功率。这恰恰说明，Go 在“极度灵活（易幻觉）”与“极度严格（难生成）”之间，找到了一个非常微妙的平衡点。它可能不是 AI 写得最快的，但它一定是 AI 写出来最让人放心的系统级语言。

我们不应期待 AI Agent 能够像写 Python 脚本一样，如德芙般丝滑地生成出一个复杂的 Go 并发系统。但在 AI 给出的初稿之上，Go 语言极佳的可读性和统一的规范，将为人类工程师的最终审查（Code Review）节省巨大的精力。

小结：下一个十年的编程语言，长什么样？

ai-coding-lang-bench 给我们上了生动的一课。它揭示了当前 LLM 的偏好：它们喜欢有海量训练数据的、灵活的、不需要应对死板编译器的语言。

但我们必须认识到，这只是一份基于 2026 年初模型（Claude Opus 4.6）的快照。未来的 AI 编程语言形态，可能会朝着两个方向演进：

AI Native 语言的诞生：抛弃目前设计给人类阅读的语法，出现一种专门为了降低 LLM 生成 Token 成本、且天然抗幻觉的机器中间语言。
现有静态语言的“Agent 友好化”编译模式：Go 和 Rust 可能会进化出一种特殊的编译模式。在这个模式下，编译器不仅是冷冰冰地报错，还能以结构化的、对 LLM 更友好的方式提供“修复建议”，从而大幅缩短 Agent 修复编译错误的反馈回路。

无论如何，浪潮已经来临。在 AI 主导代码生成的新时代，我们评价一门编程语言的标准，正在从“它对人类大脑是否友好”，悄然转变为“它对大模型推理是否友好”。

而在这场新赛道上，动态语言们，已经抢跑了。

本文核心数据与图表均来源于 GitHub 项目 mame/ai-coding-lang-bench。

你的 AI 编程初体验

看完这个排名，你是感到意外，还是早已感同身受？在你日常使用 AI 编程时，你觉得它写哪种语言最让你省心？你是否也曾为了修一个 AI 写的编译错误而陷入“死循环”？

欢迎在评论区分享你的“AI 协作”红黑榜！

“语言的严格性正在变成 AI 的摩擦力？在 AI 时代，掌握一套能驱动 Agent 自动化、自修复的‘工作流’比死磕语法更重要。我的新专栏 《AI原生开发工作流实战》 将教你如何利用 Claude Code 结合 Spec 驱动开发，构建真正高产出的‘软件工厂’。”

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

告别懵圈：实战派 Gopher 的类型理论入门

bigwhite — Thu, 30 Oct 2025 00:04:05 +0000

本文永久链接 – https://tonybai.com/2025/10/30/type-theory-intro-for-gopher

大家好，我是Tony Bai。

你是否曾有过这样的经历：在浏览一个关于 Go 泛型或接口设计的 GitHub issue 或技术提案时，评论区里的大佬们突然开始讨论 “Sum Type”、“Product Type”、“Parametric Polymorphism” 或是 “Higher-Kinded Types”。一瞬间，你感觉自己仿佛闯入了一个学术研讨会，这些看似熟悉又陌生的词汇让你一头雾水，只想默默关掉页面。

作为一名务实的 Gopher，我们习惯于用具体的代码和设计模式来思考问题。我们关心的是接口的解耦能力、struct 的组合性、goroutine 的并发效率。这些学院派的类型理论术语，似乎离我们的日常工作很遥远。

然而，事实并非如此。这些术语并非象牙塔里的空谈，它们是计算机科学家们经过几十年沉淀，用来精确描述和分类编程语言核心特性的“通用语言”。理解它们，就像给一位经验丰富的工匠配上了一套精准的图纸和测量工具。它能让你：

更深刻地理解 Go 的设计哲学：为什么 Go 的接口如此强大？为什么 Go 1.18之前长期以来没有泛型？为什么 int 和 int32 不能直接相加？这些背后都有类型理论的影子。
更清晰地沟通技术方案：当你能用“Product Type”来描述 struct，用“Sum Type”的思想来解释接口的用途时，你的技术沟通会变得更加精确和高效。
看懂高阶的技术讨论：无论是 Go 语言的未来演进，还是与其他语言（如 Rust, Haskell, Scala）的对比，这些术语都是绕不开的基石。

本文的灵感来源于阅读Simon Thompson教授所著《Type Theory & Functional Programming》一书时的感悟，但我们的目标并非成为类型理论的研究者。恰恰相反，我们的目标是做一个“翻译者”，将这些核心的理论概念，用我们最熟悉的 Go 语言特性和代码示例进行“转码”，彻底拉通学术殿堂与工程实践之间的鸿沟。

准备好了吗？让我们一起告别懵圈，开启这段实战派 Gopher 的类型理论入门之旅。

地基与框架 —— 到底什么是“类型系统”？

在深入具体的类型之前，我们首先需要建立一个宏观的框架。一个编程语言的类型系统 (Type System)，从学术角度来说，是一套规则集合，它为程序中的每个值（value）、变量（variable）和表达式（expression）都关联一个“类型”属性。

它的核心目的非常单纯且强大：在程序造成危害（比如运行时崩溃）之前，通过检查类型的合法性来预防错误。正如 Go 的领军人物 Rob Pike 所言：类型系统旨在“让非法的状态无法表示”。

为了系统性地理解它，我们可以从以下几个关键维度来对其进行分类和审视。

类型检查的时机：编译时 vs. 运行时 (Static vs. Dynamic)

这是对类型系统最基本、最重要的划分。

静态类型 (Statically Typed)

定义：类型检查在编译时完成。编译器会像一位严谨的图书管理员，在程序运行前，通读你的全部代码，检查每一个变量的赋值、每一次函数调用，确保类型在所有地方都严格匹配。如果发现问题，程序将无法通过编译。

优点：
* 早期错误发现：绝大多数类型相关的 bug 在开发阶段就被扼杀在摇篮里。
* 更高的性能：编译器确切地知道每个变量的类型和内存布局，可以生成高度优化的机器码。运行时无需再花费时间去检查类型。
* 更好的工具支持和可维护性：类型本身就是最可靠的文档。IDE 能提供精准的自动补全、代码导航和安全的重构。

Go 是一门不折不扣的静态类型语言。 它的编译器是你的第一道防线。

package main

func main() {
    var i int
    // 下面这行代码会导致编译失败，而不是运行时错误
    i = "hello"
}

// go build -> ./main.go:6:4: cannot use "hello" (type untyped string) as type int in assignment

动态类型 (Dynamically Typed)

定义：类型检查发生在运行时。变量本身没有固定的类型，它可以随时指向任何类型的值。只有当代码执行到某一行，需要对一个值进行特定操作时，解释器才会检查这个值的类型是否支持该操作。

代表语言：Python, JavaScript, Ruby。

Go 中的“动态”一面：虽然 Go 语言本身是静态的，但它通过 interface{} (自 Go 1.18 起的别名 any) 提供了一种强大的机制来处理不确定的类型，这在行为上模拟了动态类型的灵活性。

一个接口值可以看作一个“箱子”，它包含了两部分信息：值的动态类型（dynamic type）和动态值（dynamic value）。

package main
import "fmt"

func main() {
    // data 的静态类型是 any，它可以持有任何类型的值
    var data any

    data = "hello, world" // 编译通过，data 的动态类型是 string
    printValue(data)

    data = 42 // 编译通过，data 的动态类型是 int
    printValue(data)

    data = true // 编译通过，data 的动态类型是 bool
    printValue(data)
}

func printValue(v any) {
    // 使用类型断言(type assertion)或类型选择(type switch)在运行时检查动态类型
    switch val := v.(type) {
    case string:
        fmt.Printf("It's a string: %s\n", val)
    case int:
        fmt.Printf("It's an integer: %d\n", val)
    default:
        fmt.Printf("It's some other type: %T\n", val)
    }
}

这种机制是 Go 实现通用数据结构和处理 JSON 等非结构化数据的基石，但代价是放弃了部分编译时的类型安全，并将检查推迟到了运行时。

类型的严格程度：强类型 vs. 弱类型 (Strong vs. Weak)

这个维度的划分标准在学术界略有争议，但通常用来描述一门语言对于不同类型间隐式转换的容忍度。

强类型 (Strongly Typed)

定义：语言严格限制不同类型之间的隐式转换。当一个操作需要特定类型时，你必须提供该类型的值。如果类型不匹配，要么编译失败，要么运行时报错，语言本身不会“自作主张”地进行不安全的转换。

Go 的类型系统是出了名的“强硬”。

package main

import "strconv"

func main() {
    var a int = 10
    var b float64 = 5.5

    // 编译错误：不同数值类型之间不能直接运算
    // c := a + b // invalid operation: a + b (mismatched types int and float64)

    // 必须进行显式类型转换
    c := float64(a) + b // 正确

    var i int32 = 100
    var j int64 = 200

    // 即使是不同位数的整型，也必须显式转换
    // k := i + j // invalid operation: i + j (mismatched types int32 and int64)
}

这种严格性杜绝了许多在 C/C++ 或 JavaScript 中常见的、因隐式转换导致的难以察觉的 bug，让代码行为更加可预测。

弱类型 (Weakly Typed)

定义：语言倾向于在操作中自动进行类型转换，以“尽力”让程序继续运行。

代表语言：JavaScript 是典型代表，’5′ + 1 会得到字符串 ’51′，而 ’5′ – 1 会得到数字 4。这种灵活性有时很方便，但也是 bug 的温床。

类型的等价性判断：名义类型 vs. 结构类型 (Nominal vs. Structural)

这是判断“类型 A 和类型 B 是否相同（或兼容）”的规则，也是理解 Go 接口的关键。

名义类型 (Nominal Typing)

定义：类型是否等价，取决于它们的名称。即使两个类型拥有完全相同的底层结构和字段，只要它们的类型名称不同，它们就是两个完全不同的、不兼容的类型。

Go 的核心类型（structs, named basic types）遵循名义类型系统。

package main
import "fmt"

type UserID int
type ProductID int

type Point struct {
    X, Y int
}

type Vector struct {
    X, Y int
}

func main() {
    var uid UserID = 123
    var pid ProductID = 123

    // 编译错误：尽管底层都是 int，但类型名称不同
    // if uid == pid { ... } // invalid operation: uid == pid (mismatched types UserID and ProductID)

    p := Point{1, 2}
    v := Vector{1, 2}

    // 编译错误：尽管结构完全相同，但类型名称不同
    // if p == v { ... } // invalid operation: p == v (mismatched types Point and Vector)
}

名义类型提供了非常强的意图保证。UserID 就是 UserID，它承载的业务含义与 ProductID 完全不同，编译器强制你区分它们，从而避免了将用户 ID 误用为产品 ID 的逻辑错误。

结构类型 (Structural Typing)

定义：类型是否兼容，取决于它们的结构或“形状”（它们有哪些字段、哪些方法）。只要结构满足要求，类型就是兼容的，这与它们的名称无关。这通常被称为“鸭子类型”（Duck Typing）——“如果它走起来像鸭子，叫起来也像鸭子，那么它就是一只鸭子。”

Go 的体现：Go 的 interface 系统是纯粹的结构类型系统。

package main
import "fmt"

// 定义一个“会叫的”接口
type Quacker interface {
    Quack() string
}

// Duck 类型，它有一个 Quack 方法
type Duck struct{}
func (d Duck) Quack() string {
    return "Quack!"
}

// Person 类型，它也有一个 Quack 方法
type Person struct{}
func (p Person) Quack() string {
    return "I'm quacking like a duck!"
}

// 这个函数只关心传入的值是否满足 Quacker 接口的“结构”
func MakeItQuack(q Quacker) {
    fmt.Println(q.Quack())
}

func main() {
    var d Duck
    var p Person

    // Duck 和 Person 都没有显式声明 "implements Quacker"
    // 但因为它们都有 Quack() string 方法，所以它们都满足 Quacker 接口
    MakeItQuack(d) // 输出: Quack!
    MakeItQuack(p) // 输出: I'm quacking like a duck!
}

Go 的这一设计堪称神来之笔：在一个整体为名义类型的静态语言中，通过接口开辟了一块结构类型的区域，从而在不牺牲类型安全的前提下，获得了动态语言般的灵活性和强大的解耦能力。你可以在不修改第三方库代码的情况下，让自己的类型去实现它的接口。

Go 类型系统的定位

综合以上维度，我们可以给 Go 的类型系统下一个精准的定义：

Go 是一门静态、强类型的语言。它主要采用名义类型系统来保证代码的严谨性和意图明确性，同时通过接口这一特性，创造性地引入了结构类型系统，以实现灵活、非侵入式的多态。

现在，我们已经搭建好了理解类型系统的宏观框架。接下来，让我们深入到类型的“原子世界”，看看那些让 Gopher 们“懵圈”的术语，在 Go 中究竟是什么模样。

类型的“和”与“积” —— Go 世界的 Sum & Product Type

在类型理论中，最基本的两种类型组合方式是“积”与“和”。它们就像算术中的乘法和加法，是构建更复杂类型的基础。

Product Type (积类型)：A and B

学术定义：一个积类型（Product Type）的值由多个其他类型的值同时组成。如果一个类型 P 是类型 A 和类型 B 的积类型，那么 P 的一个值会同时包含一个 A 类型的值和一个 B 类型的值。

这听起来很熟悉，对吗？

Go 的实现：struct

struct 是 Go 对积类型的直接且完美的实现。

// Person 类型是 string 和 int 的积类型
type Person struct {
    Name string // 包含一个 string
    Age  int    // 和一个 int
}

// p1 这个值同时持有一个 string "Alice" 和一个 int 30
var p1 Person = Person{Name: "Alice", Age: 30}

学术上，积类型最简单的形式是元组 (Tuple)，例如 (string, int)。Go 不支持原生的元组语法，但 struct 在功能上是更强大的、带命名字段的元组。你甚至可以通过多返回值来模拟元组的使用：

func getPerson() (string, int) {
    return "Bob", 42
}

// name 和 age 在这里就像一个临时的元组
name, age := getPerson()

所以，下次当你在讨论中听到 Product Type，你就可以自信地在脑海里将它替换为：“哦，就是 struct 这种东西。”

Sum Type (和类型)：A or B

学术定义：一个和类型（Sum Type），也叫可辨识联合 (Discriminated Union) 或变体 (Variant)，它的值在任意时刻只能是几种可能性中的一种。如果一个类型 S 是类型 A 和类型 B 的和类型，那么 S 的一个值要么是一个 A 类型的值，要么是一个 B 类型的值，绝不可能同时是两者。

很多现代语言，如 Rust、Swift、Haskell，都有原生语法来支持和类型：

// Rust 中的 enum 就是一个和类型
enum Result {
    Ok(T),    // 要么是成功，里面包含一个 T 类型的值
    Err(E),   // 要么是失败，里面包含一个 E 类型的值
}

Go 语言没有提供上述那样的原生和类型语法。这是 Go 设计者在语言复杂性上做出的一个明确权衡。但是，Go 开发者每天都在使用和类型的思想，只是我们用的是另一种工具——接口。

一个接口类型定义了一个方法的集合。任何实现了这些方法的类型，都可以被看作是这个接口类型集合中的一员。因此，一个接口类型的变量，可以持有任何一个满足其要求的具体类型的值。这正是“A 或 B 或 C…”的核心思想。

让我们用一个经典的例子来具象化这个概念：一个图形应用需要处理不同的形状。

package main
import "math"

// Shape 接口定义了一个“和类型”，它可以是任何能计算面积的东西。
// 它可以是 Circle，或者是 Rectangle，或者是未来我们定义的任何其他形状。
type Shape interface {
    Area() float64
}

// --- 可能性 1: Circle ---
type Circle struct {
    Radius float64
}
func (c Circle) Area() float64 {
    return math.Pi * c.Radius * c.Radius
}

// --- 可能性 2: Rectangle ---
type Rectangle struct {
    Width, Height float64
}
func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

// 这个函数接受一个 Shape 类型的值。
// 它不关心这个值到底是 Circle 还是 Rectangle，只关心它能调用 Area() 方法。
func PrintArea(s Shape) {
    // 这时，变量 s 的值可能是 Circle 或 Rectangle 之一
    fmt.Printf("Area of %T is %0.2f\n", s, s.Area())
}

func main() {
    c := Circle{Radius: 5}
    r := Rectangle{Width: 4, Height: 3}

    PrintArea(c) // 输出: Area of main.Circle is 78.54
    PrintArea(r) // 输出: Area of main.Rectangle is 12.00
}

在这个例子里，Shape 接口扮演了和类型的角色。一个 Shape 变量的值，在任何时刻，要么是一个 Circle，要么是一个 Rectangle。

如何“辨识”具体的类型？—— type switch

和类型的一个关键特性是“可辨识”（Discriminated）。这意味着我们必须有办法知道当前的值到底是哪个具体的类型。在 Go 中，我们使用 type switch 来实现这一点。

func PrintShapeDetails(s Shape) {
    fmt.Printf("Shape details for %T:\n", s)
    switch shape := s.(type) {
    case Circle:
        // 在这个 case 分支里，编译器知道 shape 的类型是 Circle
        fmt.Printf("  It's a circle with radius %.2f\n", shape.Radius)
    case Rectangle:
        // 在这个 case 分支里，编译器知道 shape 的类型是 Rectangle
        fmt.Printf("  It's a rectangle with width %.2f and height %.2f\n", shape.Width, shape.Height)
    default:
        fmt.Println("  It's an unknown shape.")
    }
}

type switch 是处理和类型值时的“模式匹配”，它安全地拆开接口这个“箱子”，并根据里面的动态类型执行相应的逻辑。

模拟的代价：开放性与编译时检查的缺失

Go 的接口模拟与原生和类型有一个本质区别：接口是开放的，而原生和类型通常是封闭的。

封闭性 (Sealed/Closed)：在 Rust 的例子中，Result只能是 Ok(T)中的T 或 Err(E)中的E，编译器知道所有可能性。如果你在 match（类似 switch）时漏掉了一种情况，编译器会报错。
开放性 (Open)：在 Go 的例子中，任何包、任何地方都可以定义一个新的类型（比如 Triangle），只要它实现了 Area() 方法，它就可以被赋值给 Shape 变量。这意味着编译器永远无法保证你的 type switch 处理了所有情况，因此 default 分支变得至关重要。

为了在 Go 中模拟一个更“封闭”的和类型，有时会使用一种技巧：在接口中定义一个私有方法。

type Shape interface {
    Area() float64
    isShape() // 私有方法
}

由于私有方法 isShape 只能在同一个包内被实现，这实际上就将 Shape 接口的实现者限制在了当前包内，从而模拟了一个封闭的和类型。这在 Go 标准库中（例如 net/url.go 中的 addr 接口）时有应用。

所以，下次当你看到 Sum Type 这个术语，你的脑海中应该浮现出这样的映射：

“哦，这是指一个值在多个类型中‘非此即彼’的概念。Go 没有原生支持它，但我们通过 interface 和 type switch 的组合，在工程实践中出色地模拟了它的核心思想。”

抽象的力量 —— Go 中的函数与多态

类型系统不仅用于组合数据，更强大的能力在于抽象行为。这主要涉及到函数类型和多态。

函数类型 (Function Types)

学术定义：从类型 A 到类型 B 的一个映射，记作 A -> B。在函数式编程和类型理论中，函数本身就是一种可以被传递、存储和返回的值，即“一等公民”。

Go 的实现：Go 完全支持一等公民函数。我们可以定义函数类型，这在 Go 代码中非常常见。

package main
import "fmt"

// 定义一个函数类型 Operator，它接受两个 int，返回一个 int
type Operator func(int, int) int

func add(a, b int) int {
    return a + b
}

func multiply(a, b int) int {
    return a * b
}

// calculate 函数接受一个 Operator 类型的函数作为参数
func calculate(a, b int, op Operator) {
    result := op(a, b)
    fmt.Printf("Result is: %d\n", result)
}

func main() {
    calculate(10, 5, add)      // 输出: Result is: 15
    calculate(10, 5, multiply) // 输出: Result is: 50
}

HTTP 中间件、策略模式等诸多设计模式在 Go 中都大量利用了函数类型。

多态 (Polymorphism)

“Polymorphism”源于希腊语，意为“多种形态”。在编程中，它指代一段代码可以处理不同类型的值的能力。类型理论通常将其分为几种。

参数多态 (Parametric Polymorphism)

学术定义：编写的代码其逻辑对于操作的值的具体类型是通用的、不相关的。函数或数据结构可以被一个或多个类型参数化。例如，一个反转列表的函数，其逻辑（交换头尾元素）与列表里存的是整数、字符串还是用户自定义结构完全无关。

Go 的实现：泛型 (Generics, Go 1.18+)

在 Go 1.18 之前，Gopher 们只能通过 interface{} 和反射来模拟参数多态，但这牺牲了类型安全和性能。泛型的引入，为 Go 提供了实现参数多态的“正统”方式。

package main
import "fmt"

// 这个函数的逻辑对任何类型 T 都是一样的
// T 是一个类型参数
func Reverse[T any](s []T) {
    for i, j := 0, len(s)-1; i < j; i, j = i+1, j-1 {
        s[i], s[j] = s[j], s[i]
    }
}

func main() {
    intSlice := []int{1, 2, 3, 4}
    Reverse(intSlice)
    fmt.Println(intSlice) // 输出: [4 3 2 1]

    stringSlice := []string{"a", "b", "c"}
    Reverse(stringSlice)
    fmt.Println(stringSlice) // 输出: [c b a]
}

当你听到 Parametric Polymorphism，你就可以直接联想到 Go 的泛型。

子类型多态 (Subtype Polymorphism)

学术定义：一个函数或操作可以作用于某个类型 T，同时也能作用于 T 的所有子类型。例如，一个处理 Animal 的函数，应该也能处理 Dog 和 Cat，因为 Dog 和 Cat 都是 Animal 的子类型。

Go 的实现：接口 (Interfaces)

我们又回到了接口！在 Go 的世界里，子类型的概念正是通过接口来实现的。如果类型 T 实现了接口 I，那么 T 就可以被看作是 I 的一个“子类型”。

更准确地说，Go 实现的是结构化子类型 (Structural Subtyping)。

package main
import (
    "bytes"
    "fmt"
    "io"
    "os"
)

// 这个函数接受任何满足 io.Reader 接口的类型
// os.File 是 io.Reader 的一个“子类型”
// bytes.Buffer 也是 io.Reader 的一个“子类型”
func ReadAndPrint(r io.Reader) {
    data, err := io.ReadAll(r)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data))
}

func main() {
    // 从文件读取
    file, _ := os.Open("test.txt")
    defer file.Close()
    ReadAndPrint(file)

    // 从内存中的 buffer 读取
    buffer := bytes.NewBufferString("Hello from buffer!")
    ReadAndPrint(buffer)
}

ReadAndPrint 函数体现了子类型多态：它被编写用来处理 io.Reader 这一通用类型，但实际上它可以无缝处理 os.File、bytes.Buffer 以及任何其他未来可能出现的、满足 io.Reader 结构的类型。

Ad-hoc 多态 (Ad-hoc Polymorphism)

学术定义：也称为重载 (Overloading)。同一个函数名可以有多个不同的实现，具体调用哪个实现取决于参数的类型。例如，add(int, int) 和 add(string, string) 是两个不同的函数。

Go 不支持函数重载。Go 的哲学是“显式优于隐式”，函数签名（包括函数名、参数类型和返回值类型）是唯一的。

理论的边界 —— Go 类型系统“做不到”的事

理解一门语言，不仅要知道它能做什么，也要知道它的边界在哪里，以及为什么会有这些边界。这通常是设计者在“表达力”与“简洁性”之间做出权衡的结果。

依赖类型 (Dependent Types)

学术定义：一种高级的类型系统特性，允许类型依赖于值。这意味着类型可以由程序中的常规变量来参数化。

经典例子：定义一个“长度为 n 的向量”类型 Vector(n)。这样，Vector(3) 和 Vector(4) 就是两个完全不同的类型。编译器可以静态地保证你不会把一个长度为 3 的向量赋值给一个长度为 4 的向量变量，或者保证矩阵乘法的维度匹配。

// 伪代码，Go 并不支持
func dotProduct(n: int, v1: Vector(n), v2: Vector(n)) -> float64 {
    // ...
}

var vec3 Vector(3)
var vec4 Vector(4)
dotProduct(3, vec3, vec4) // 编译错误！vec4 的长度不是 3

Go完全不支持依赖类型。Go 的类型系统在编译时工作，而像 n 这样的值通常在运行时才知道。将运行时信息混入编译时类型检查会极大地增加语言和编译器的复杂性。Go 选择了简洁，将这类检查（如切片长度）的责任交给了程序员，通过 len() 函数和运行时 panic 来保障。

值得一提的是，Go 的数组类型 [N]T 具有依赖类型的“影子”。例如，[3]int 和 [4]int 是不同的类型，因为它们的类型定义依赖于值 3 和 4。但这并非真正的依赖类型，因为数组的长度 N 必须是一个编译时常量，而不能是一个运行时变量。这个限制正是 Go 的数组与依赖类型的本质区别，也是 Go 在追求更强类型安全与保持语言简洁性之间做出的一种工程权衡。

高阶类型 (Higher-Kinded Types, HKTs)

这是一个在函数式编程和高级类型系统讨论中频繁出现的术语，也是理解 Go 泛型设计边界的关键所在。乍一听可能有些吓人，但我们可以通过类比来轻松理解它。

通俗解释：类型的“阶”

想象一下我们熟悉的函数：

一阶函数：操作“值”。例如，func add(a, b int) int 接受 int 值，返回 int 值。
高阶函数：操作“函数”。例如，func apply(f func(int) int, v int) int 接受一个函数 f 作为参数。

现在，我们把这个概念“提升”到类型层面：

一阶类型 (或称普通类型)：就是一个具体的类型，比如 int, string, struct{}。在类型理论中，它们的“种类”(Kind) 被记为 *。
高阶类型 (Higher-Kinded Types)：不是一个完整的类型，而是一个“类型的模板”或“类型构造器”(Type Constructor)。它接受一个或多个普通类型作为参数，然后“构造”出一个新的普通类型。
- []T 就是一个类型构造器。[] 本身不是类型，你必须给它一个类型（如 int），才能得到一个完整的类型 []int。它的“种类”可以记为 * -> * (接受一个类型，返回一个类型)。
- 同理，map[K]V 也是一个类型构造器，它的“种类”是 * -> * -> * (接受两个类型，返回一个类型)。
- chan T 也是 * -> *。

高阶类型系统，就是指一门语言的泛型系统能够对类型构造器本身进行抽象的能力。换句话说，泛型参数不仅可以是 T（代表一个普通类型），还可以是 F（代表一个类型构造器，如 [] 或 chan）。

Go 的现状：不支持高阶类型

Go 的泛型系统被设计为只处理一阶类型。这意味着 Go 的类型参数 [T any] 只能代表一个完整的类型。

T 可以是 int。
T 也可以是 []int。
但 T 不能是 [] 本身。

让我们通过一个经典的 Map 函数的例子来具体说明这一点。我们的目标是写一个通用的 Map 函数，它能将一个容器里的所有元素通过一个函数进行转换，并返回一个包含新元素的同类容器。

Go 能做到的：为每种容器编写独立的泛型函数

由于 Go 不支持 HKTs，我们必须为 slice、channel 或其他任何我们想支持的容器类型，分别编写一个泛型 Map 函数。

// 为 slice 实现的 Map
func SliceMap[T, U any](s []T, f func(T) U) []U {
    result := make([]U, len(s))
    for i, v := range s {
        result[i] = f(v)
    }
    return result
}

// 为 channel 实现的 Map (简化版)
func ChanMap[T, U any](ch <-chan T, f func(T) U) <-chan U {
    result := make(chan U)
    go func() {
        defer close(result)
        for v := range ch {
            result <- f(v)
        }
    }()
    return result
}

注意，SliceMap 和 ChanMap 的核心逻辑思想是一致的，但因为容器的操作方式（创建、遍历、添加元素）不同，且 Go 无法抽象“容器”这个概念，我们不得不重复编写。

Go 做不到的：一个统一所有容器的 Map 函数（伪代码）

如果 Go 支持高阶类型，我们就可以梦想编写一个 UniversalMap 函数。下面的代码使用了 Go 的语法风格，但它在 Go 中是完全无法编译的，它仅仅是为了展示 HKTs 的思想。

// ----------------------------------------------------
// !! 警告：以下是 HKTs 思想的伪代码，无法在 Go 中编译 !!
// ----------------------------------------------------

// 这里的 type F[T] any 是一种虚构的语法，
// 意在声明“F 是一个接受单一类型参数的类型构造器”。
func UniversalMap[type F[T] any, T, U any](container F[T], f func(T) U) F[U] {
    // 这段函数体在 Go 中是无法实现的，因为：
    // 1. 如何创建一个 F[U] 类型的新容器？make(F[U]) 语法无效。
    // 2. 如何遍历一个抽象的 F[T] 容器？range 关键字只认识内置类型。
    // 3. 如何向 F[U] 中添加一个元素？是 append 还是 <- 发送？

    panic("This is pseudo-code demonstrating what HKTs would enable.")
}

func main() {
    ints := []int{1, 2, 3}
    intChan := make(chan int)

    // 在一个支持 HKTs 的理想世界里，我们可以这样调用：
    // strings := UniversalMap(ints, func(i int) string { ... })      // 期望返回 []string
    // stringChan := UniversalMap(intChan, func(i int) string { ... }) // 期望返回 chan string
}

这段伪代码清晰地揭示了 Go 泛型的边界：

语法限制：Go 没有定义 [type F[T] any] 这样的语法来表示“一个类型构造器”作为类型参数。
实现限制：即使语法允许，Go 缺乏一个通用的接口来描述“容器”的基本操作（如 map, flatMap 等）。支持 HKTs 的语言（如 Haskell, Scala）通常会提供一套名为 Functor, Monad 的“类型类”或“特质”(traits) 来定义这些通用操作，程序员可以为自己的容器类型（比如自定义的 Tree[T]）实现这些接口。

为什么 Go 选择不支持 HKTs？

这是一个深思熟虑的设计决策。Go 语言的核心哲学之一是简洁性和可读性。高阶类型的概念虽然强大，但它引入了更高层次的抽象，极大地增加了语言的复杂性和程序员的心智负担。对于 Go 团队来说，为 slice 和 chan 等几种常见类型编写独立的泛型函数，这种适度的代码重复，相比于引入整个 HKTs 体系所带来的复杂性，是一个更值得接受的权衡。

所以，当你听到 Higher-Kinded Types，你可以这样理解：“它是一种更强大的泛型，可以对像 []T 中的 [] 这样的‘类型模板’本身进行参数化，但 Go 为了保持简洁而没有支持它。因此在 Go 中，我们需要为不同的容器类型（如 slice, channel）编写各自的泛型工具函数。”

小结：从“懵圈”到“通透”

我们从令人困惑的 GitHub issue 讨论出发，踏上了一段连接类型理论与 Go 语言实践的旅程。现在，让我们回顾一下我们的“翻译”成果，将那些抽象的术语牢牢地锚定在 Go 的具体实现上：

类型系统框架：我们确立了 Go 的定位——一个静态、强类型的系统，它以名义类型为基础保证代码的严谨性，同时通过接口这一卓越设计，巧妙地融合了结构类型的灵活性。
Product Type (积类型)：这个概念不再神秘，它就是我们日常工作中构建复合数据的基石——struct。
Sum Type (和类型)：我们揭示了 Go 是如何通过接口和type switch 这一组合拳，优雅地模拟出和类型的核心思想（“A 或 B”）。我们最熟悉的 error 接口，便是这一思想在 Go 生态中最无处不在的体现。
Parametric Polymorphism (参数多态)：我们看到，Go 1.18+ 的泛型为其提供了原生的、类型安全的支持，让我们得以编写出与具体类型无关的通用算法和数据结构。
Subtype Polymorphism (子类型多态)：这再次指向了 Go 接口的强大之处。它基于结构化子类型，构建了一个非侵入式、高度解耦的多态模型，这是 Go 强大组合能力的核心源泉。
理论的边界 (Dependent Types & HKTs)：我们不仅理解了这些高级特性是什么，更重要的是，通过具体的伪代码示例，我们清晰地看到了 Go 泛型的局限性——它只能参数化完整的类型，而无法抽象类型构造器（如 [] 或 chan）。我们明白了，这些“做不到”并非语言的缺陷，而是 Go 团队在追求简洁性、可读性和工程实用性方面做出的深思熟虑的设计权衡。

掌握这些术语，并不仅仅是为了在技术讨论中显得“专业”。更重要的是，它为我们提供了一个更深刻、更系统的视角来审视我们每天使用的工具。它解释了 Go 为什么是现在这个样子，它的优势在哪里，它的取舍又在哪里。

希望这篇文章能成为你工具箱里的一件利器。当你下一次再遇到那些“学院派”术语时，你将不再“懵圈”，而是能够会心一笑，轻松地将它们映射到你熟悉的 Go 世界中，从而更加自信地去创造、去构建、去解决实际的工程问题。

毕竟，对于实战派 Gopher 而言，任何理论的最终价值，都在于它能否帮助我们写出更好、更稳健、更易于维护的代码。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

Martin Fowler最新洞察：LLM 不止是“更高”的抽象，它正在改变编程的“本质”！

bigwhite — Wed, 25 Jun 2025 23:02:07 +0000

本文永久链接 – https://tonybai.com/2025/06/26/non-deterministic-abstraction

大家好，我是Tony Bai。

在软件开发领域，Martin Fowler 的名字几乎等同于思想的灯塔。他的每一篇文章、每一次演讲，都能为我们揭示行业发展的深层脉络。最近，Fowler 大师又发布了一篇简短但引人深思的博文——《LLMs bring new nature of abstraction》，再次精准地捕捉到了一个正在发生的、可能颠覆我们认知和工作方式的巨大变革。

Fowler 认为，大型语言模型（LLM）的出现，对软件开发的影响，堪比从汇编语言到首批高级编程语言（HLLs）的飞跃。但关键在于，LLM 带来的不仅仅是又一个“更高层次”的抽象，它正在从根本上改变编程的“本质”——迫使我们思考，用“非确定性工具”进行编程究竟意味着什么。

在这篇文章中，我们就来简单解读一下。

从“确定性”的阶梯到“非确定性”的岔路

回顾编程语言的发展史，我们一直在追求更高层次的抽象，以提升生产力、降低复杂度：

汇编语言 vs. 机器指令： 汇编让我们用助记符替代了 0 和 1，但仍需关注特定机器的寄存器和指令集。
高级语言 (HLLs) vs. 汇编： Fortran、COBOL 等早期 HLLs 让我们能用语句、条件、循环来思考，而不用关心数据如何在寄存器间移动。Fowler 回忆道，他用 Fortran IV 编程时，虽然有诸多限制（如 IF 没有 ELSE，整数变量名必须以 I-N 开头），但这已经是巨大的进步。
现代语言、框架、DSL vs. 早期 HLLs： Ruby、Go、Python 等现代语言，以及各种框架和领域特定语言（DSL），进一步提升了抽象层次。我们现在可以本能地将函数作为数据传递，使用丰富的库和模式，而不用从头编写大量底层代码。

Fowler 指出，尽管这些发展极大地提升了抽象层次和生产力，但它们并没有从根本上改变“编程的性质”。我们仍然是在与机器进行一种“确定性”的对话：给定相同的输入和代码，我们期望得到相同的输出。错误（Bug）也是可复现的。

然而，LLM 的介入，打破了这一基本假设。

Fowler 写道：“用提示词与机器对话，其差异之大，犹如 Ruby 之于 Fortran，Fortran 之于汇编”。

更重要的是，这不仅仅是抽象层次的巨大飞跃。当 Fowler 用 Fortran 写一个函数，他可以编译一百次，结果中的 Bug 依然是那个 Bug。但 LLM 引入的是一种“非确定性”的抽象 (non-deterministic abstraction)。

这意味着，即使我们把精心设计的 Prompt 存储在 Git 中，也不能保证每次运行都会得到完全相同的行为。正如他的同事 Birgitta Böckeler 精辟总结的那样：

我们并非仅仅在抽象层级上“向上”移动，我们同时也在“横向”移入非确定性的领域。

Fowler 文章中的配图非常形象地展示了这一点：传统的编程语言、编译器、字节码是一条清晰的、自上而下的抽象路径；而模型/DSL、代码生成器、低代码、框架是其上的不同抽象层次。自然语言（通过 LLM）则像一条从旁边切入的、直接通往“半结构化/接近人类思维”的道路，这条路本身就带有模糊和不确定性。

“非确定性”编程时代的挑战与启示

这种“非确定性”的本质，对我们 Gopher，乃至所有软件开发者，都带来了前所未有的挑战和需要重新思考的问题：

版本控制与可复现性： 当 Prompt 不能保证结果一致时，我们如何管理和版本化我们的“AI辅助代码”？如何确保开发、测试、生产环境的一致性，或者至少是可接受的差异性？仅仅版本化 Prompt 可能不够，我们还需要版本化模型、参数（如 temperature）甚至是一些关键的种子（seed）吗？
测试与调试： 如何测试一个输出不完全固定的“组件”？传统的单元测试、集成测试方法是否依然有效？我们可能需要引入新的测试策略，例如基于属性的测试、对输出结果的统计验证、或者更侧重于行为和意图的验证。当 LLM 生成的代码出现问题，调试的难度是否会指数级增加？
可靠性与契约： 在一个包含非确定性AI组件的系统中，如何定义和保证整体的可靠性？服务间的“契约”又该如何描述和强制执行？
思维模式的转变： 我们习惯了对代码的精确控制，追求逻辑的严密和行为的可预测。现在，我们可能需要学会与“模糊”和“概率”共存，从“指令下达者”转变为“意图沟通者”和“结果筛选者”。

这对我们 Gopher 意味着什么？

Go 语言以其明确性、强类型、简洁的并发模型以及相对可预测的行为，深受开发者喜爱。当我们尝试将 LLM 融入 Go 的生态和开发流程时，这些“非确定性”的特性会带来新的思考：

AI 生成 Go 代码： 当我们使用 LLM 生成 Go 代码片段、单元测试，甚至整个模块时，如何确保生成的代码符合 Go 的最佳实践、是高效且安全的？如何对生成的代码进行有效的审查和集成？
用 Go 构建与 LLM 交互的工具/Agent： 如果我们用 Go 开发与 LLM 交互的后端服务或智能体（Agent），我们需要在架构设计上充分考虑 LLM 的非确定性，设计更鲁棒的错误处理、重试机制，以及对 LLM 输出结果的验证和筛选逻辑。
利用 LLM 理解复杂 Go 系统： LLM 或许能帮助我们理解遗留的复杂 Go 代码库，但其解释的准确性和一致性也需要我们审慎评估。

Fowler 在文末表达了他对这一变革的兴奋之情：“这种改变是戏剧性的，也让我颇为兴奋。我相信我会为一些失去的东西感到悲伤，但我们也将获得一些我们中很少有人能理解的东西。”

小结：拥抱不确定，探索新大陆

Martin Fowler 的这篇文章，为我们揭示了 LLM 时代编程范式可能发生的深刻转变。它不再仅仅是工具的进化，更是与机器协作方式的本质性变革。

作为 Gopher，作为软件工程师，我们需要开始认真思考这种“非确定性”带来的影响，积极探索与之共存、甚至利用其特性创造价值的新方法。这无疑是一个充满挑战但也充满机遇的新大陆。

你如何看待 Fowler 的这个观点？你认为 LLM 带来的“非确定性”会对你的日常开发工作产生哪些具体影响？欢迎在评论区分享你的看法！

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

成为那个拿锤子的人

bigwhite — Sun, 03 Nov 2024 13:49:18 +0000

本文永久链接 – https://tonybai.com/2024/11/03/become-the-one-with-the-hammer

“当你有一个锤子时，每件事看起来都像一个钉子”，这句来自心理学家亚伯拉罕·马斯洛(没错！就是提出五层需求理论的那个马斯洛)的名言揭示了人们在掌握一种技能或工具时，很容易将其视作通用解决方案的倾向，在技术领域，这种倾向尤为明显。

同时这句话也常被用来描述人们对工具的过度依赖和思维的局限性。

在程序员圈子中，“语言战争(programming language war)”是一个永不过时的话题，而马斯洛的“锤子”观点在每一种新语言兴起并掀起波澜时，总会被用作“讥讽”该语言拥趸的“思想武器”，细数当前的主流语言，莫不如此：

上世纪90年代初，随着图形用户界面(GUI)和大型软件开发而兴起的C++语言；
上世纪90年代末至2000年初期，随着互联网的普及和企业应用程序需求增加而大火儿的Java语言；
从2001年开始，特别是在微软.NET框架推出之后逐渐成为Windows应用开发新霸主的C#语言；
2004年以后，随着Ruby on Rails框架的推出，而在Web应用开发领域变成网红且语法优雅的Ruby语言；
2009年以后，刚发布就赢得TIOBE编程语言排行榜年度最佳语言，并在之后引领云原生时代的Go语言；
2010年诞生，从2016年开始连续8年霸榜Stackoverflow最受欢迎编程语言、打出“用Rust重写一切”的Rust语言。

这些语言都有自己的高光时刻，语言拥趸们举起大锤到处砸钉子，伴随而来的是来自其他语言阵营的讥讽。以我最熟悉的Go为例，在Go 1.5版本实现自举并实现GC延迟大幅度下降后，Go社区迎来了快速发展。Go也开始飘了！Gopher们乃至Go团队开始了在各个领域积(四)极(处)探(出)索(击)，除了云原生基础设施和服务、Cli和Web这几个主流领域之外，Go还进军了GUI、游戏、移动开发以及嵌入式系统等领域，这让Go语言一度也面临过与目前Rust相似的境遇和挑战，遭遇了一些质疑和嘲讽：

然而，这真的是一种糟糕的状态吗？手握大锤找钉子真的有错吗？让我们将视野从狭小的编程语言领域拓展到更广阔的其他领域。

我们先来看看汽车领域，如果说内燃机驱动技术和机械变速箱技术属于上一代成熟技术的话，那么基于锂电池和电动机的新能源驱动技术就是这个领域的“新锤子”，它也一直在被以丰田为代表的传统主机厂诟病。但以特斯拉为代表的的新能源车企是如何使用这柄锤子的呢？下面是特斯拉的产品发布历史：

2008年 Roadster：特斯拉的首款量产电动车
2012年 Model S：高档电动轿车，获得广泛好评，具有长续航和高性能，奠定了特斯拉在豪华车市场的地位。
2015年 Model X：一款豪华电动SUV，以独特的鹰翼门设计和高度的安全性著称。
2017年 Model 3：面向大众市场的紧凑型电动车，成为全球销量最高的电动车之一。
2020年 Model Y：一款电动跨界SUV，基于Model 3平台，迅速赢得市场。
2021年 Cybertruck：特斯拉的电动皮卡
2022年 Tesla Semi：电动重型卡车，专注于运输行业的可持续性。

哦，没错！就像编程界一样，一旦他们拿到这柄锤子，也会到处找钉子：从轿车、SUV、皮卡到电动重卡，甚至国内一些新能源主机厂已经发布了几款概念版电动飞行汽车：

我们再来看看四轴或多轴无人机领域，随着大疆等厂商拿到这把锤子后，无人机的应用范围得到了极大的拓展。从最初的航拍工具和玩具，逐渐演变为物流配送的利器，甚至展望未来，它们有可能成为飞行汽车的一部分。此外，一些军工企业也开始将无人机用于战场，成为一种武器。

如今，大语言模型正成为新时代的”锤子”，从自然语言处理到代码生成，从内容创作到自动驾驶决策辅助，从寻找新蛋白质到新药研发等，正在重塑各个领域的工作方式。

到这里，我们看到每一种新技术的诞生，都像一把新锤子，重塑着所在领域的版图。它们不是简单的工具替换，而是带来了全新的思维方式和解决方案。现在，你还担心拿着锤子找钉子会遭到他人的“讥讽”吗？

在不断演变的科技世界，真正驱动变革的往往就是那些“拿锤子”的人。他们不只是拥有先进技术的工具，更重要的是，他们拥有通过这些工具改变世界的意愿。因此，找到并精通一项核心技术，就像获得了一把改变世界的锤子。这不是局限，而是机遇。重要的不是担心把所有问题都看成钉子，而是要深入理解你的”锤子”，保持开放的心态，发现新的应用场景，勇于尝试用锤子去创新性解决问题。

由此可见，本文开头处马斯洛的那句话在今天有了新的意义：成为那个拿锤子的人，意味着你有能力参与改变世界的进程。拥抱你手中的锤子吧，这是你的幸运！我们要做的就是善用这份幸运，创造更大的价值。

作为程序员，我们需要挑选一柄锤子并握在手中，而Go是一个很好的候选。如果你觉得拥抱Go这柄锤子，那我推荐大家关注极客时间的“Go语言第一课”，这是一个很好的起点，帮助你入门Go语言并深入理解Go语言的精髓。

同时，我的书籍《Go语言精进之路》也将为你提供更深入的知识和实用技巧。

让我们一起在这条道路上不断探索，提升自我，以更好地应对未来的挑战！

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite
Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

htmx：Gopher走向全栈的完美搭档？

bigwhite — Fri, 20 Sep 2024 11:44:51 +0000

本文永久链接 – https://tonybai.com/2024/09/20/htmx-gopher-perfect-partner-for-full-stack

在传统的Web开发领域，前端和后端开发通常被明确划分。前端主要负责用户界面的交互和视觉呈现，运用HTML、CSS和JavaScript等技术；后端则专注于服务器逻辑、数据库管理和核心功能实现，常用Go、Java、PHP、Ruby等语言。

然而，随着技术的不断演进和开发流程的优化，全栈开发逐渐成为一种趋势。全栈开发者能够在项目的不同阶段灵活转换角色，有效降低沟通成本和缩短开发周期。他们对系统的整体架构和工作原理有更深入的理解，从而能更高效地解决问题。此外，全栈技能也使得开发者在就业市场上更具竞争力，能够承担更多样化的职责。

尽管如此，对于许多专注后端的工程师（包括众多Gopher）来说，前端开发仍然是一个不小的挑战。它不仅要求熟悉JavaScript等语言，还需要理解复杂的前端框架和工具链。这使得不少后端开发者在面对全栈开发时感到力不从心。

幸运的是，技术的进步为我们提供了更简单、高效的开发途径。Go语言以其简洁和高效著称，而htmx库则通过HTML属性实现丰富的前端交互。将两者结合，开发者可以在无需深入学习JavaScript的情况下，轻松实现全栈开发。这种组合不仅能够显著提升开发效率，还能充分利用服务器端渲染（SSR）的优势，在性能和用户体验方面取得显著提升。

那么，htmx是否真的是Gopher走向全栈的完美搭档呢？在本文中，我们就将探讨一下这个问题，介绍一下htmx的核心理念和工作原理，并结合代码示例和使用场景，详细分析Go和htmx如何协同工作。至于Go+htmx究竟有多能打，相信在本文最后，你会得出自己的评价！

1. htmx：为简化前端开发而生

传统的前端开发通常依赖于JavaScript框架，例如React、Vue或Angular。这些框架虽然功能强大，但往往伴随着高昂的学习成本和复杂的开发流程。对于那些主要从事后端开发的程序员来说，学习和掌握这些框架不仅需要花费大量时间，还需要深入理解前端生态系统中的各种概念和工具链。这种学习曲线和开发复杂性成为了许多后端开发者的阻碍，同时也成为了阻碍Go开发者迈向全栈的绊脚石。

htmx的诞生正是为了简化前端开发，特别是对于那些不愿意或没有时间深入学习JavaScript的开发者。

htmx的核心理念是通过扩展HTML，使其具备更强大的功能，从而减少对JavaScript的依赖。它遵循了”HTML优先”的设计原则，允许开发者直接在HTML元素中添加特殊的属性来定义与服务器交互的行为，比如动态加载、表单处理、局部刷新等，从而实现动态交互，而无需编写任何JavaScript代码。可以说，htmx的出现为后端开发者(包括Gopher)提供了一种新的选择，使得Web应用的开发变得更加直观和简便。

不过，htmx自身却是一个轻量级的JavaScript库，这与Go的设计哲学有些“异曲同工”，即简单留给大家，复杂留给自己。作为js库，它提供了一组简洁而强大的API，通过设置HTML属性，开发者就可以实现多种交互功能。以下是htmx的一些核心特性：

请求类型（hx-get、hx-post、hx-put和hx-delete）

通过指定请求类型，htmx可以在用户触发事件时向服务器发送请求，并处理响应。

目标更新（hx-target）

支持指定服务器响应数据要插入的DOM元素，支持部分页面更新而无需刷新整个页面。

触发条件（hx-trigger）

支持定义请求触发的条件，例如点击、鼠标悬停、表单提交等事件。

交换方式（hx-swap）

支持定义响应内容插入DOM的方式，可以选择替换、插入、删除等操作。

这些API的设计目标是让开发者能够通过声明式的方式来实现前端逻辑，而不必依赖JavaScript代码，以简化开发过程。

由于几乎无需后端开发者写JavaScript，HTMX很容易被认为是SSR（服务器端渲染）的一种实现。它们看似很相似，但它们的思路并不完全一致。SSR的渲染过程是在服务器上完成的，服务器生成整个HTML页面的内容，并将其发送给客户端。客户端接收到完整的HTML直接展示给用户。这也使得SSR通常可以提供更快的初始加载体验，因为用户可以立即看到页面内容，而不必等待JavaScript加载和执行。此外，由于HTML内容在服务器上渲染，搜索引擎更容易抓取和索引内容。

而HTMX的大部分渲染也是在服务端完成的，但它支持在客户端通过AJAX请求动态更新页面的某些部分，而不需要重新加载整个页面，只是它是通过简单的HTML属性(外加自身js)实现这些功能的，而无需用户手工写JavaScript实现。HTMX还使得页面能够更具交互性，用户可以在不离开当前页面的情况下与应用程序进行交互。

因此，htmx可以视为一种结合SSR和局部CSR(客户端渲染)的技术，它让你通过服务器端渲染HTML，同时在客户端实现灵活的动态交互功能。这使得开发者能够在SSR提供的性能优势和SEO友好性基础上，提升用户体验而不必依赖完整的客户端框架。

虽然保留了CSR，但与传统的JavaScript框架（如 React、Vue、Angular）相比，htmx非常轻量，体积非常小，以撰写本文时的最新2.0.2版本htmx为例，它的js包大小如下，压缩版才10几k：

此外，传统框架虽然功能强大，但往往需要复杂的配置和较高的学习成本，尤其对于习惯后端开发的开发者来说，更是如此。而使用HTMX，只需掌握HTML和少量的htmx API即可开始开发，适合后端开发者快速上手。

说了这么多htmx的优点，那基于htmx的开发究竟是怎样的呢？下面我们就以htmx的几个核心特性为例，看看如何基于htmx开发简单web应用。

2. htmx的基本用法

在前面我们了解了htmx的几个核心特性，包括请求类型、目标更新等。下面我们就针对这些核心特性，举几个例子，大家初步了解一下基于htmx的开发web应用的流程。

我们先从请求类型开始，了解一下基于htmx如何向后端发起POST/GET/PUT/DELETE等请求。

2.1 示例1：请求类型

在这第一个示例中，我们使用Go语言创建一个简单的服务器，并使用htmx在前端实现不同类型的请求。下面是我们定义的html模板，其中包含了htmx的自定义属性：

// go-htmx/demo1/index.html




    
    
    HTMX Go Example
    
    


    HTMX Request Types Demo

在这个HTML模板文件中包含了四个按钮，每个按钮对应一种http请求类型（GET、POST、PUT、DELETE），具体的实现方式是每个按钮都使用了相应的htmx属性（hx-get、hx-post、hx-put、hx-delete）来指定请求类型和目标URL。此外，所有按钮都使用了hx-target来设置服务器的响应将被显示的元素id。以get请求button为例，响应的值将被放到id为get-result的span中。

对应的Go后端程序就非常简单了，下面是代码摘录：

// go-htmx/demo1/main.go

package main

import (
    "fmt"
    "net/http"
    "os"
    "path/filepath"
)

func main() {
    http.HandleFunc("/", handleIndex)
    http.HandleFunc("/api/get", handleGet)
    http.HandleFunc("/api/post", handlePost)
    http.HandleFunc("/api/put", handlePut)
    http.HandleFunc("/api/delete", handleDelete)

    fmt.Println("Server is running on http://localhost:8080")
    http.ListenAndServe(":8080", nil)
}

func handleIndex(w http.ResponseWriter, r *http.Request) {
    currentDir, _ := os.Getwd()
    filePath := filepath.Join(currentDir, "index.html")
    http.ServeFile(w, r, filePath)
}

func handleGet(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Received a GET request")
}

func handlePost(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Received a POST request")
}

func handlePut(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Received a PUT request")
}

func handleDelete(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Received a DELETE request")
}

运行该server后，用浏览器打开localhost:8080，我们将看到下面页面：

逐一点击各个Button，htmx会将从服务器收到的响应内容放入对应的span中：

2.2 示例2：触发条件

在这个示例2中，我们将基于htmx实现对各种触发条件的响应与处理，htmx提供了hx-trigger属性来应对这些不同的事件触发，包括点击、鼠标悬停和表单提交等。我们看下面html模板代码：

// go-htmx/demo2/index.html




    
    
    HTMX Trigger Demo
    
    


    HTMX Trigger Demo

    
        Click Trigger
        
        
    

    
        Hover Trigger
        
            Hover over me
        
        
    

    
        Form Submit Trigger
        
            
            
        
        
    

    
        Custom Delay Trigger

通过模板代码，我们可以看到hx-trigger 的多种用法：

点击触发（Click Trigger）：使用 hx-trigger=”click”，当按钮被点击时触发请求。
悬停触发（Hover Trigger）：使用 hx-trigger=”mouseenter”，当鼠标悬停在元素上时触发请求。
表单提交触发（Form Submit Trigger）：使用 hx-trigger=”submit”，当表单提交时触发请求。
自定义延迟触发（Custom Delay Trigger）：使用 hx-trigger=”keyup changed delay:500ms”，在输入框中输入时，等待500毫秒后触发请求。这对于实现搜索建议等功能很有用。

下面是该示例的后端go代码，逻辑非常简单，针对每个事件调用，简单返回一个字符串：

// go-htmx/demo2/main.go

... ...

func main() {
    http.HandleFunc("/", handleIndex)
    http.HandleFunc("/api/click", handleClick)
    http.HandleFunc("/api/hover", handleHover)
    http.HandleFunc("/api/submit", handleSubmit)
    http.HandleFunc("/api/search", handleSearch)

    fmt.Println("Server is running on http://localhost:8080")
    http.ListenAndServe(":8080", nil)
}

func handleIndex(w http.ResponseWriter, r *http.Request) {
    currentDir, _ := os.Getwd()
    filePath := filepath.Join(currentDir, "index.html")
    http.ServeFile(w, r, filePath)
}

func handleClick(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Button was clicked!")
}

func handleHover(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "You hovered over the element!")
}

func handleSubmit(w http.ResponseWriter, r *http.Request) {
    message := r.FormValue("message")
    fmt.Fprintf(w, "Form submitted with message: %s", message)
}

func handleSearch(w http.ResponseWriter, r *http.Request) {
    query := r.URL.Query().Get("search")
    fmt.Fprintf(w, "Searching for: %s", query)
}

运行该server后，用浏览器打开localhost:8080，我们将看到下面页面：

接下来，我们可以尝试点击按钮、悬停在元素上、提交表单和在搜索框中输入，看看每个操作如何触发HTMX 请求并更新页面的相应部分，下面是触发后的结果：

2.3 示例3：交换方式

在示例3中，我们将展示如何使用htmx的hx-swap属性实现不同的内容更新方式，包括替换、插入和删除操作，其中还包含多种替换方式。下面是html模板：

// go-htmx/demo3/index.html




    
    
    HTMX Swap Demo - All Attributes
    
    


    HTMX Swap Demo - All Attributes

    
        innerHTML (Default)
        
        
            This is the original content. The entire inner HTML will be replaced.
        
    

    
        outerHTML
        
        
            This entire div will be replaced, including its container.
        
    

    
        textContent
        
        
            This text will be replaced, but HTML tags will be treated as plain text.
        
    

    
        beforebegin
        
        
            New content will be inserted before this div.
        
    

    
        afterbegin
        
        
            New content will be inserted at the beginning of this div, before this paragraph.
        
    

    
        beforeend
        
        
            New content will be inserted at the end of this div, after this paragraph.
        
    

    
        afterend
        
        
            New content will be inserted after this div.
        
    

    
        delete
        
        
            This content will be deleted when the button is clicked.

这个示例略复杂，它涵盖了hx-swap的所有属性：

innerHTML（默认）：替换目标元素的内部HTML。
outerHTML：用响应替换整个目标元素。
textContent：替换目标元素的文本内容，不解析HTML。
beforebegin：在目标元素之前插入响应。
afterbegin：在目标元素的第一个子元素之前插入响应。
beforeend：在目标元素的最后一个子元素之后插入响应。
afterend：在目标元素之后插入响应。
delete：删除目标元素，忽略响应内容。

为了配合这个演示，我们编写了一个简单的go后端程序：

// go-htmx/demo3/main.go
... ...

func main() {
    http.HandleFunc("/", handleIndex)
    http.HandleFunc("/api/swap/inner", handleInner)
    http.HandleFunc("/api/swap/outer", handleOuter)
    http.HandleFunc("/api/swap/text", handleText)
    http.HandleFunc("/api/swap/before", handleBefore)
    http.HandleFunc("/api/swap/afterbegin", handleAfterBegin)
    http.HandleFunc("/api/swap/beforeend", handleBeforeEnd)
    http.HandleFunc("/api/swap/after", handleAfter)
    http.HandleFunc("/api/swap/delete", handleDelete)

    fmt.Println("Server is running on http://localhost:8080")
    http.ListenAndServe(":8080", nil)
}

func handleIndex(w http.ResponseWriter, r *http.Request) {
    currentDir, _ := os.Getwd()
    filePath := filepath.Join(currentDir, "index.html")
    http.ServeFile(w, r, filePath)
}

func handleInner(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This content replaced the inner HTML at %s", time.Now().Format(time.RFC1123))
}

func handleOuter(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This div replaced the entire outer HTML at %s", time.Now().Format(time.RFC1123))
}

func handleText(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This replaced the text content at %s. HTML tags are not parsed.", time.Now().Format(time.RFC1123))
}

func handleBefore(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This content was inserted before the target div at %s", time.Now().Format(time.RFC1123))
}

func handleAfterBegin(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This content was inserted at the beginning of the target div at %s", time.Now().Format(time.RFC1123))
}

func handleBeforeEnd(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This content was inserted at the end of the target div at %s", time.Now().Format(time.RFC1123))
}

func handleAfter(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "This content was inserted after the target div at %s", time.Now().Format(time.RFC1123))
}

func handleDelete(w http.ResponseWriter, r *http.Request) {
    // For delete, we don't need to send any content back
    w.WriteHeader(http.StatusOK)
}

运行该server后，用浏览器打开localhost:8080，你应该能看到一个包含八个不同部分的页面，每个部分演示了hx-swap的一种属性。你可以点击每个部分的按钮，观察内容如何以不同的方式更新或变化。这个综合示例展示了hx-swap的强大功能和灵活性，让你可以精确控制如何更新页面的不同部分。下面是你可以看到的效果呈现：

以上就是htmx核心属性的用法，基于这些核心属性，我们可以实现更多更为复杂和高级的场景功能。在下一节，我们会举两个复杂一些的示例，供大家参考。

3. 高级用法

3.1 基于token的身份认证

在使用HTMX作为前端与后端进行交互时，通常会涉及到用户身份认证及鉴权，其中一个常见场景是通过前端获取的Token（如JWT）去访问后端的受保护的API。下面我们看看使用HTMX该如何实现这一常见功能。

下面是网站首页的html模板，包含用户登录的Form：

// go-htmx/demo4/index.html




    
    
    HTMX Auth Example - Login
    
    


    HTMX Auth Example - Login
    
        Username:
        


        Password:

这个代码片段结合了HTMX和JavaScript，处理登录表单的提交，以及登录成功后将令牌（Token）存储到浏览器的本地存储中，并在登录成功后重定向到dashboard页面。

这段代码监听了HTMX的htmx:afterRequest事件。此事件在HTMX请求完成（即请求已经发出并接收到响应）后触发，event.detail.elt表示触发事件的元素。代码检查该元素的id是否为login-form，确认这次请求来自登录表单。如果是其他表单或元素触发的请求，它将忽略。如果服务器的身份验证成功，它以json格式返回token和重定向地址，前端会解析响应，并将Token存储到本地存储，然后自动跳转到登录后的dashboard页面。

下面是dashboard页面的html模板：

// go-htmx/demo4/dashboard.html




    
    
    HTMX Auth Example - Dashboard
    
    


    Welcome to Your Dashboard

这段代码最值得关注的地方就是在后续发出的Request中自动加入之前获取到的token。这里是使用了htmx:configRequest事件实现的。监听HTMX的htmx:configRequest事件，该事件在HTMX发出请求之前触发，它允许你修改即将发出的请求。这里的configRequest的处理逻辑是：如果Token存在，将它添加到即将发出的请求的Authorization头中，并格式化为标准的Bearer Token形式（即 “Authorization: Bearer your_token_here”）。这样，后端在处理请求时可以从请求头中提取出Token，用于验证用户身份。

整个示例的后端go程序如下：

// go-htmx/demo4/main.go
package main

import (
    "encoding/json"
    "fmt"
    "html/template"
    "net/http"
    "strings"
    "sync"

    "github.com/google/uuid"
)

var (
    tokens   = make(map[string]bool)
    tokensMu sync.Mutex
)

type LoginResponse struct {
    Success  bool   `json:"success"`
    Token    string `json:"token,omitempty"`
    Message  string `json:"message"`
    Redirect string `json:"redirect,omitempty"`
}

func main() {
    http.HandleFunc("/", indexHandler)
    http.HandleFunc("/login", loginHandler)
    http.HandleFunc("/dashboard", dashboardHandler)
    http.HandleFunc("/protected", protectedHandler)
    fmt.Println("Server is running on http://localhost:8080")
    http.ListenAndServe(":8080", nil)
}

func indexHandler(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path != "/" {
        http.NotFound(w, r)
        return
    }
    http.ServeFile(w, r, "index.html")
}

func loginHandler(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
        return
    }

    username := r.FormValue("username")
    password := r.FormValue("password")

    response := LoginResponse{}

    if username == "admin" && password == "password" {
        token := uuid.New().String()

        tokensMu.Lock()
        tokens[token] = true
        tokensMu.Unlock()

        response.Success = true
        response.Token = token
        response.Message = "Login successful"
        response.Redirect = "/dashboard"
    } else {
        response.Success = false
        response.Message = "Login failed. Please check your credentials and try again."
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(response)
}

func dashboardHandler(w http.ResponseWriter, r *http.Request) {
    tmpl, err := template.ParseFiles("dashboard.html")
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    tmpl.Execute(w, nil)
}

func protectedHandler(w http.ResponseWriter, r *http.Request) {
    authHeader := r.Header.Get("Authorization")
    if authHeader == "" || !strings.HasPrefix(authHeader, "Bearer ") {
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }

    token := strings.TrimPrefix(authHeader, "Bearer ")

    tokensMu.Lock()
    valid := tokens[token]
    tokensMu.Unlock()

    if !valid {
        http.Error(w, "Invalid token", http.StatusUnauthorized)
        return
    }

    fmt.Fprintf(w, `
        Protected Content
        This is sensitive information only for authenticated users.
        Your token: %s
    `, token)
}

注：这里仅是示例，因此只是用了一个uuid作为token，没有使用通用的jwt。

运行程序，登录并在Dashboard中点击访问protected data，我们会看到下面图中呈现的效果：

下面我们再来看一个略复杂一些的示例，这次我们基于htmx来实现SSE(Server-Sent Event)，即服务端事件。

3.2 SSE

Server-Sent Events (SSE) 是一种轻量级的实时通信技术，允许服务器通过HTTP协议持续向客户端推送更新数据。与WebSocket不同，SSE是单向通信，服务器可以推送数据到客户端，但客户端无法通过同一连接向服务器发送数据。这种机制非常适合需要频繁更新数据但对双向通信要求不高的场景，如股票价格、新闻推送、社交媒体通知等。

htmx对SSE的支持是通过扩展包实现的，下面就是本示例的index.html模板代码：

// go-htmx/demo5/index.html




    
    
    HTMX SSE Notifications
    
    


    实时通知

这个代码片段通过HTMX和Server-Sent Events (SSE) 实现了实时通知的功能。它会动态将服务器端发送的通知添加到页面的通知列表中。具体来说：

hx-ext=”sse”：启用了HTMX的SSE扩展，用于处理 Server-Sent Events（服务器发送事件），使得浏览器可以保持与服务器的长连接，实时接收更新。
sse-connect=”/events”：指定了SSE连接的URL。浏览器会向/events这个路径发起SSE连接，服务器可以通过这个连接持续向客户端推送消息。
sse-swap=”message”：指示HTMX在收到SSE消息时触发事件处理，消息内容将使用JavaScript进行处理而不是自动更新HTML。
htmx.on(“htmx:sseMessage”, function(event))：监听HTMX的htmx:sseMessage事件，每当服务器通过SSE推送新消息时，该事件会触发。event.detail.message包含从服务器接收到的消息内容。
var ul = document.getElementById(“notifications”);：获取页面上ID为notifications的\

下面是示例对应的Go后端程序：

// go-htmx/demo5/main.go

func main() {
    http.HandleFunc("/", serveHTML)
    http.HandleFunc("/events", handleSSE)

    fmt.Println("Server starting on http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

func serveHTML(w http.ResponseWriter, r *http.Request) {
    http.ServeFile(w, r, "index.html")
}

func handleSSE(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "Streaming unsupported!", http.StatusInternalServerError)
        return
    }

    notificationCount := 1

    for {
        notification := fmt.Sprintf("新通知 #%d: %s", notificationCount, time.Now().Format("15:04:05"))
        fmt.Fprintf(w, "data: %s\n\n", notification)
        flusher.Flush()

        notificationCount++
        time.Sleep(3 * time.Second)

        if r.Context().Err() != nil {
            return
        }
    }
}

运行程序，打开浏览器访问localhost:8080，在加载的页面中会自动建立sse连接，页面上的通知消息区便会如下面这样每3秒一变化：

不过这个示例的程序有个“瑕疵”，那就是如果将htmx的版本从1.9.6换作最新的2.0.2，那么示例就将不工作了，翻看了一下htmx文档，应该是sseMessage这个htmx扩展属性被删除了。

如果要让示例更具通用性，可以将index.html换成下面的代码：

// go-htmx/demo6/index.html



    
    
    HTMX SSE Notifications
    
    


    实时通知
    
        等待通知...

当然这个代码更多使用js来实现事件的处理。

4. 小结

本文探讨了Go与htmx这一全栈组合的简洁优势。对于后端开发者而言，这一组合提供了一种无需深入掌握前端技术即可开发现代Web应用的高效途径。

然而，从两个高级示例中可以看出，JavaScript代码仍难以完全避免，虽然数量不多，但在稍复杂的场景下依然不可或缺。

因此，htmx目前更多被中小型团队或个人开发者所青睐。这类开发者通常没有专职的前端人员，但希望快速构建并部署功能完善的Web应用。

综上所述，在我这个对前端开发了解甚少的Go开发者看来，Go与htmx的组合的确降低了开发门槛，同时提供了性能和SEO优势，使其成为现代Web开发中值得推荐的技术栈之一。不过，对于复杂的Web应用，开发者可能需要结合htmx和JavaScript，或更可能直接采用vue、react或angular等框架。

目前Go社区对htmx的支持也越来越多，比如html模板引擎templ可以用于生成htmx模板，当然也有专有的htmx框架，比如：ghtmx、pagoda、go-htmx等。

本文涉及的源码可以在这里下载。

5. 参考资料

htmx.org – https://htmx.org/
htmx sucks – https://htmx.org/essays/htmx-sucks/
《HYPERMEDIA SYSTEMS》 – https://hypermedia.systems/book/contents/

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite
Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

通过实例理解API网关的主要功能特性

bigwhite — Sun, 03 Dec 2023 09:35:56 +0000

本文永久链接 – https://tonybai.com/2023/12/03/understand-api-gateway-main-functional-features-by-example

在当今的技术领域中，“下云”的概念正逐渐抬头，像David Heinemeier Hansson(37signals公司的联合创始人, Ruby on Rails的Creator)就直接将公司所有的业务都从公有云搬迁到了自建的数据中心中。虽说大多数企业不会这么“极端”，但随着企业对云原生架构采用的广泛与深入，不可避免地面临着对云服务的依赖。云服务在过去的几年中被广泛应用于构建灵活、可扩展的应用程序和基础设施，为企业提供了许多便利和创新机会。然而，随着业务规模的增长和数据量的增加，云服务的成本也随之上升。企业开始意识到，对云服务的依赖已经成为一个值得重新评估的议题。云服务的开销可能占据了企业可用的预算的相当大部分。为了保持竞争力并更好地控制成本，企业需要寻找方法来减少对云服务的依赖，寻找更经济的解决方案，同时确保仍能获得所需的性能、安全性和可扩展性。

在这样的背景下，我们的关注点是选择一款适宜的API网关，从主流功能特性的角度来评估候选者的支持。API网关作为现代云原生应用架构中的关键组件，扮演着连接前端应用和后端服务的中间层，负责管理、控制和保护API的访问。它的功能特性对于确保API的安全性、可靠性和可扩展性至关重要。

尽管API网关并不是一个新鲜事物了，但对于那些长期依赖于云供应商的服务的人来说，它似乎变得有些“陌生”。因此，本文旨在帮助我们重新理解API网关的主要特性，并获得对API网关选型的能力，以便在停止使用云供应商服务之前，找到一个合适的替代品^_^。

1. API网关回顾

API网关是现代应用架构中的关键组件之一，它的存在简化了应用程序的架构，并为客户端提供一个单一的访问入口，并进行相关的控制、优化和管理。API网关可以帮助企业实现微服务架构、提高系统的可扩展性和安全性，并提供更好的开发者体验和用户体验。

1.1 API网关的演化

随着互联网的快速发展和企业对API的需求不断增长，API网关作为一种关键的中间层技术逐渐崭露头角并经历了一系列的演进和发展。这里将API网关的演进历史粗略分为以下几个阶段:

API网关之前的早期阶段

在互联网发展的早期阶段，大多数应用程序都是以单体应用的形式存在。后来随着应用规模的扩大和业务复杂性的增加，单体应用的架构变得不够灵活和可扩展，面向服务架构（Service-Oriented Architecture，SOA）逐渐兴起，企业开始将应用程序拆分成一组独立的服务。这个时期，每个服务都是独立对外暴露API，客户端也是通过这些API直接访问服务，但这会导致一些安全性、运维和扩展性的问题。之后，企业也开始意识到需要一种中间层来管理和控制这种客户端到服务的通信行为，并确保服务的可靠性和安全性，于是开始有了API网关的概念。

API网关的兴起

早期的API网关，其主要功能就是单纯的路由和转发。API网关将请求从客户端转发到后端服务，并将后端服务的响应返回给客户端。在这个阶段，API网关的功能非常简单，主要用于解决客户端和后端服务之间的通信问题。

API网关的成熟

随着微服务架构的兴起和API应用的不断发展，企业开始将应用程序进一步拆分成更小的、独立部署的微服务。每个对外暴露的微服务都有自己的API，并通过API网关进行统一管理和访问。API网关在微服务架构中的作用变得更加重要，它的功能也逐渐丰富起来了。

在这一阶段，它不仅负责路由和转发请求，API网关还增加了安全和治理的功能，可以满足几个不同领域的微服务需求。比如：API网关可以通过身份认证、授权、访问控制等功能来保护API的安全；通过基于重试、超时、熔断的容错机制等来对API的访问进行治理；通过日志记录、基于指标收集以及Tracing等对API的访问进行观测与监控；支持实时的服务发现等。

API网关(图来自网络)

API网关的云原生化

随着云原生技术的发展，如容器化和服务网格（Service Mesh）等，API网关也在不断演进和适应新的环境。在云原生环境中，API网关实现了与容器编排系统（如Kubernetes）和服务网格集成，其自身也可以作为一个云原生服务来部署，以实现更高的可伸缩性、弹性和自动化。同时，新的技术和标准也不断涌现，如GraphQL和gRPC等，API网关也增加了对这些新技术的集成和支持。

1.2 API网关的主要功能特性

从上面的演化历史我们看到：API网关的演进使其从最初简单的请求转发角色，逐渐成为整个API管理和微服务架构中的关键组件。它不仅扮演着API管理层与后端服务层之间的适配器，也是云原生架构中不可或缺的基础设施，使微服务管理更加智能化和自动化。下面是现代API网关承担的主要功能特性，我们后续也会基于这些特性进行示例说明：

请求转发和路由
身份认证和授权
流量控制和限速
高可用与容错处理
监控和可观测性

2. 那些主流的API网关

下面是来自CNCF Landscape中的主流API网关集合(截至2023.11月)，图中展示了关于各个网关的一些细节，包括star数量和背后开发的公司或组织：

主流的API网关还有各大公有云提供商的实现，比如：Amazon的API Gateway、Google Cloud的API Gateway以及上图中的Azure API Management等，但它们不在我们选择范围之内；虽然被CNCF收录，但多数API网关受到的关注并不高，超过1k star的不到30%，这些不是很受关注或dev不是那么active的项目也无法在生产环境担当关键角色；而像APISIX、Kong这两个受关注很高的网关，它们是建构在Nginx之上实现的，技术栈与我们不契合；而像EMISSARY INGRESS、Gloo等则是完全云原生化或者说是Kubernetes Native的，无法在无Kubernetes的基于VM或裸金属的环境下部署和运行。

好吧，剩下的只有几个Go实现的API Gateway了，在它们之中，我们选择用Tyk API网关来作为后续API功能演示的示例。

注：这并不代表Tyk API网关就要比其他Go实现的API Gateway优秀，只是它的资料比较齐全，适合在本文中作演示罢了。

3. API网关主要功能特性示例(Tyk API网关版本)

3.1 Tyk API网关简介

记得在至少5年前就知道Tyk API网关的存在，印象中它是使用Go语言开发的早期的那批API网关之一。Tyk从最初的纯开源项目，到如今由背后商业公司支持，以Open Core模式开源的网关，一直保持了active dev的状态。经过多年的演进，它已经一款功能强大的开源兼商业API管理和网关解决方案，提供了全面的功能和工具，帮助开发者有效地管理、保护和监控API。同时，Tyk API网关支持多种安装部署方式，即可以单一程序的方式放在物理机或VM上运行，也可以支持容器部署，通过docker-compose拉起，亦可以通过Kubernetes Operator将其部署在Kubernetes中，这也让Tyk API网关具备了在各大公有云上平滑迁移的能力。

关于Tyk API网关开源版本的功能详情，可以点击左边超链接到其官网查阅，这里不赘述。

3.2 安装Tyk API网关

下面我们就来安装一下Tyk API网关，我们直接在VM上安装，VM上的环境是CentOS 7.9。Tyk API提供了很多中安装方法，这里使用CentOS的yum包管理工具安装Tyk API网关，大体步骤如下(演示均以root权限操作)。

3.2.1 创建tyk gateway软件源

默认的yum repo中是不包含tyk gateway的，我们需要在/etc/yum.repos.d下面创建一个新的源，即新建一个tyk_tyk-gateway.repo文件，其内容如下：

[tyk_tyk-gateway]
name=tyk_tyk-gateway
baseurl=https://packagecloud.io/tyk/tyk-gateway/el/7/$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/tyk/tyk-gateway/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

[tyk_tyk-gateway-source]
name=tyk_tyk-gateway-source
baseurl=https://packagecloud.io/tyk/tyk-gateway/el/7/SRPMS
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/tyk/tyk-gateway/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

接下来我们执行下面命令来创建tyk_tyk-gateway这个repo的YUM缓存：

$yum -q makecache -y --disablerepo='*' --enablerepo='tyk_tyk-gateway'
导入 GPG key 0x5FB83118:
 用户ID     : "https://packagecloud.io/tyk/tyk-gateway (https://packagecloud.io/docs#gpg_signing) "
 指纹       : 9179 6215 a875 8c40 ab57 5f03 87be 71bd 5fb8 3118
 来自       : https://packagecloud.io/tyk/tyk-gateway/gpgkey

repo配置和缓存完毕后，我们就可以安装Tyk API Gateway了：

$yum install -y tyk-gateway

安装后的tky-gateway将以一个systemd daemon服务的形式存在于主机上，程序意外退出或虚机重启后，该服务也会被systemd自动拉起。通过systemctl status命令可以查看服务的运行状态：

# systemctl status tyk-gateway
● tyk-gateway.service - Tyk API Gateway
   Loaded: loaded (/usr/lib/systemd/system/tyk-gateway.service; enabled; vendor preset: disabled)
   Active: active (running) since 日 2023-11-19 20:22:44 CST; 12min ago
 Main PID: 29306 (tyk)
    Tasks: 13
   Memory: 19.6M
   CGroup: /system.slice/tyk-gateway.service
           └─29306 /opt/tyk-gateway/tyk --conf /opt/tyk-gateway/tyk.conf

11月 19 20:34:54 iZ2ze18rmx2avqb5xgb4omZ tyk[29306]: time="Nov 19 20:34:54" level=error msg="Connection to Redis faile...b-sub
11月 19 20:35:04 iZ2ze18rmx2avqb5xgb4omZ tyk[29306]: time="Nov 19 20:35:04" level=error msg="cannot set key in pollerC...ured"
11月 19 20:35:04 iZ2ze18rmx2avqb5xgb4omZ tyk[29306]: time="Nov 19 20:35:04" level=error msg="Redis health check failed...=main
Hint: Some lines were ellipsized, use -l to show in full.

3.2.2 安装redis

我们看到tyk-gateway已经成功启动，但从其服务日志来看，它在连接redis时报错了！tyk gateway默认将数据存储在redis中，为了让tyk gateway正常运行，我们还需要安装redis！这里我们使用容器的方式安装和运行一个redis服务：

$docker pull redis:6.2.14-alpine3.18
$docker run -d --name my-redis -p 6379:6379 redis:6.2.14-alpine3.18
e5d1ec8d5f5c09023d1a4dd7d31d293b2d7147f1d9a01cff8eff077c93a9dab7

拉取并运行redis后，我们通过redis-cli验证一下与redis server的连接：

# docker run -it --rm redis:6.2.14-alpine3.18  redis-cli -h 192.168.0.24
192.168.0.24:6379>

我们看到可以正常连接！但此时Tyk Gateway仍然无法与redis正常连接，我们还需要对Tyk Gateway做一些配置调整！

3.2.3 配置Tyk Gateway

yum默认将Tyk Gateway安装到/opt/tyk-gateway下面，这个路径下的文件布局如下：

$tree -F -L 2 .
.
├── apps/
│   └── app_sample.json
├── coprocess/
│   ├── api.h
│   ├── bindings/
│   ├── coprocess_common.pb.go
│   ├── coprocess_mini_request_object.pb.go
│   ├── coprocess_object_grpc.pb.go
│   ├── coprocess_object.pb.go
│   ├── coprocess_response_object.pb.go
│   ├── coprocess_return_overrides.pb.go
│   ├── coprocess_session_state.pb.go
│   ├── coprocess_test.go
│   ├── dispatcher.go
│   ├── grpc/
│   ├── lua/
│   ├── proto/
│   ├── python/
│   └── README.md
├── event_handlers/
│   └── sample/
├── install/
│   ├── before_install.sh*
│   ├── data/
│   ├── init_local.sh
│   ├── inits/
│   ├── post_install.sh*
│   ├── post_remove.sh*
│   ├── post_trans.sh
│   └── setup.sh*
├── middleware/
│   ├── ottoAuthExample.js
│   ├── sampleMiddleware.js
│   ├── samplePostProcessMiddleware.js
│   ├── samplePreProcessMiddleware.js
│   ├── testPostVirtual.js
│   ├── testVirtual.js
│   └── waf.js
├── policies/
│   └── policies.json
├── templates/
│   ├── breaker_webhook.json
│   ├── default_webhook.json
│   ├── error.json
│   ├── monitor_template.json
│   └── playground/
├── tyk*
└── tyk.conf

其中tyk.conf就是tyk gateway的配置文件，我们先看看其默认的内容：

$cat /opt/tyk-gateway/tyk.conf
{
  "listen_address": "",
  "listen_port": 8080,
  "secret": "xxxxxx",
  "template_path": "/opt/tyk-gateway/templates",
  "use_db_app_configs": false,
  "app_path": "/opt/tyk-gateway/apps",
  "middleware_path": "/opt/tyk-gateway/middleware",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379,
    "username": "",
    "password": "",
    "database": 0,
    "optimisation_max_idle": 2000,
    "optimisation_max_active": 4000
  },
  "enable_analytics": false,
  "analytics_config": {
    "type": "",
    "ignored_ips": []
  },
  "dns_cache": {
    "enabled": false,
    "ttl": 3600,
    "check_interval": 60
  },
  "allow_master_keys": false,
  "policies": {
    "policy_source": "file"
  },
  "hash_keys": true,
  "hash_key_function": "murmur64",
  "suppress_redis_signal_reload": false,
  "force_global_session_lifetime": false,
  "max_idle_connections_per_host": 500
}

我们看到：storage下面存储了redis的配置信息，我们需要将redis的host配置修改为我们的VM地址：

    "host": "192.168.0.24",

然后重启Tyk Gateway服务：

$systemctl daemon-reload
$systemctl restart tyk-gateway

之后，我们再查看tyk gateway的运行状态：

systemctl status tyk-gateway
● tyk-gateway.service - Tyk API Gateway
   Loaded: loaded (/usr/lib/systemd/system/tyk-gateway.service; enabled; vendor preset: disabled)
   Active: active (running) since 一 2023-11-20 06:54:07 CST; 41s ago
 Main PID: 20827 (tyk)
    Tasks: 15
   Memory: 24.8M
   CGroup: /system.slice/tyk-gateway.service
           └─20827 /opt/tyk-gateway/tyk --conf /opt/tyk-gateway/tyk.conf

11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Loading API configurations...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Tracking hostname" api_nam...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Initialising Tyk REST API ...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="API bind on custom port:0"...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Checking security policy: ...fault
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="API Loaded" api_id=1 api_n...ip=--
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Loading uptime tests..." p...k-mgr
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Initialised API Definition...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=warning msg="All APIs are protected ...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="API reload complete" prefix=main
Hint: Some lines were ellipsized, use -l to show in full.

从服务日志来看，现在Tyk Gateway可以正常连接redis并提供服务了！我们也可以通过下面的命令验证网关的运行状态：

$curl localhost:8080/hello
{"status":"pass","version":"5.2.1","description":"Tyk GW","details":{"redis":{"status":"pass","componentType":"datastore","time":"2023-11-20T06:58:57+08:00"}}}

“/hello”是Tyk Gateway的内置路由，由Tyk网关自己提供服务。

到这里Tyk Gateway的安装和简单配置就结束了，接下来，我们就来看看API Gateway的主要功能特性，并借助Tyk Gateway来展示一下这些功能特性。

注：查看Tyk Gateway的运行日志，可以使用journalctl -u tyk-gateway -f命令实时follow最新日志输出。

3.3 功能特性：请求转发与路由

请求转发和路由是API Gateway的主要功能特性之一，API Gateway可以根据请求的路径、方法、查询参数等信息将请求转发到相应的后端服务，其内核与反向代理类似，不同之处在于API Gateway增加了“API”这层抽象，更加专注于构建、管理和增强API。

下面我们来看看Tyk如何配置API路由，我们首先创建一个新API。

3.3.1 创建一个新API

Tyk开源版支持两种创建API的方式，一种是通过调用Tyk的控制类API，一种则是通过传统的配置文件，放入特定目录下。无论哪种方式添加完API，最终都要通过Tyk Gateway热加载(hot reload)或重启才能生效。

注：Tyk Gateway的商业版本提供Dashboard，可以以图形化的方式管理API，并且商业版本的API定义会放在Postgres或MongoDB中，我们这里用开源版本，只能手工管理了，并且API定义只能放在文件中。

下面，我们就来在Tyk上创建一个新的API路由，该路由示例的示意图如下：

在未添加新API之前，我们使用curl访问一下该API路径：

$curl localhost:8080/api/v1/no-authn
Not Found

Tyk Gateway由于找不到API路由，返回Not Found。接下来，我们采用调用tyk gateway API的方式来添加路由：

$curl -v -H "x-tyk-authorization: {tyk gateway secret}" \
  -s \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "name": "no-authn-v1",
    "slug": "no-authn-v1",
    "api_id": "no-authn-v1",
    "org_id": "1",
    "use_keyless": true,
    "auth": {
      "auth_header_name": "Authorization"
    },
    "definition": {
      "location": "header",
      "key": "x-api-version"
    },
    "version_data": {
      "not_versioned": true,
      "versions": {
        "Default": {
          "name": "Default",
          "use_extended_paths": true
        }
      }
    },
    "proxy": {
      "listen_path": "/api/v1/no-authn",
      "target_url": "http://localhost:18081/",
      "strip_listen_path": true
    },
    "active": true
}' http://localhost:8080/tyk/apis | python -mjson.tool 

* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> POST /tyk/apis HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8080
> Accept: */*
> x-tyk-authorization: {tyk gateway secret}
> Content-Type: application/json
> Content-Length: 797
>
} [data not shown]
* upload completely sent off: 797 out of 797 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Wed, 22 Nov 2023 05:38:40 GMT
< Content-Length: 53
<
{ [data not shown]
* Connection #0 to host localhost left intact
{
    "action": "added",
    "key": "no-authn-v1",
    "status": "ok"
}

从curl返回结果我们看到：API已经被成功添加。这时tyk gateway的安装目录/opt/tyk-gateway的子目录apps下会新增一个名为no-authn-v1.json的配置文件，这个文件内容较多，有300行，这里就不贴出来了，这个文件就是新增的no-authn API的定义文件。

不过此刻，Tyk Gateway还需热加载后才能为新的API提供服务，调用下面API可以触发Tyk Gateway的热加载：

$curl -H "x-tyk-authorization: {tyk gateway secret}" -s http://localhost:8080/tyk/reload/group | python -mjson.tool
{
    "message": "",
    "status": "ok"
}

注：即便触发热加载成功，但如果body中的json格式错，比如多了一个结尾逗号，Tyk Gateway是不会报错的！

API路由创建完毕并生效后，我们再来访问一下API：

$ curl localhost:8080/api/v1/no-authn
{
    "error": "There was a problem proxying the request"
}

我们看到：Tyk Gateway返回的已经不是“Not Found”了！现在我们创建一下no-authn这个API服务，考虑到适配更多后续示例，这里建立这样一个http server：

// api-gateway-examples/httpserver

func main() {
    // 解析命令行参数
    port := flag.Int("p", 8080, "Port number")
    apiVersion := flag.String("v", "v1", "API version")
    apiName := flag.String("n", "example", "API name")
    flag.Parse()                                         

    // 注册处理程序
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Println(*r)
        fmt.Fprintf(w, "Welcome api: localhost:%d/%s/%s\n", *port, *apiVersion, *apiName)
    })                                                                                     

    // 启动HTTP服务器
    addr := fmt.Sprintf(":%d", *port)
    log.Printf("Server listening on port %d\n", *port)
    log.Fatal(http.ListenAndServe(addr, nil))
}

我们启动一个该http server的实例：

$go run main.go -p 18081 -v v1 -n no-authn
2023/11/22 22:02:42 Server listening on port 18081

现在我们再通过tyk gateway调用一下no-authn这个API：

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn

我们看到这次路由通了！no-authn API返回了期望的结果！

3.3.2 负载均衡

如果no-authn API存在多个服务实例，Tyk Gateway也可以将请求流量负载均衡到多个no-authn服务实例上去，下图是Tyk Gateway进行请求流量负载均衡的示意图：

要实现负责均衡，我们需要调整no-authn API的定义，这次我们直接修改/opt/tyk-gateway/apps/no-authn-v1.json，变更的配置主要有三项：

// /opt/tyk-gateway/apps/no-authn-v1.json

  "proxy": {
    "preserve_host_header": false,
    "listen_path": "/api/v1/no-authn",
    "target_url": "",                  // (1) 改为""
    "disable_strip_slash": false,
    "strip_listen_path": true,
    "enable_load_balancing": true,     // (2) 改为true
    "target_list": [                   // (3) 填写no-authn服务实例列表
      "http://localhost:18081/",
      "http://localhost:18082/",
      "http://localhost:18083/"
    ],

修改完配置后，调用Tyk的控制类API使之生效，然后我们启动三个no-authn的API实例：

$go run main.go -p 18081 -v v1 -n no-authn
$go run main.go -p 18082 -v v1 -n no-authn
$go run main.go -p 18083 -v v1 -n no-authn

接下来，我们多次调用curl访问no-authn API：

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18083/v1/no-authn

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18083/v1/no-authn

我们看到：Tyk Gateway在no-authn API的各个实例之间做了等权重的轮询。如果我们停掉实例3，再来访问该API，我们将得到下面结果：

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Bad Request

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Bad Request

注：Tyk Gateway商业版通过Dashboard支持配置带权重的RR负载均衡算法。

我们看到：实例3已经下线，但Tyk Gateway并不会跳过该已经下线的实例，这在生产环境会给客户端带来不一致的响应。

3.3.3 服务实例存活检测(uptime test)

Tyk Gateway在开启负载均衡的时候，也提供了对后端服务实例的存活检测机制，当某个服务实例down了后，负载均衡机制会绕过该实例将请求发到下一个处于存活状态的实例；而当down机实例恢复后，Tyk Gateway也能及时检测到服务实例上线，并将其加入流量负载调度。

支持存活检测(uptime test)的API定义配置如下：

// /opt/tyk-gateway/apps/no-authn-v1.json

"uptime_tests": {
    "disable": false,
    "poller_group":"",
    "check_list": [
      {
        "url": "http://localhost:18081/"
      },
      {
        "url": "http://localhost:18082/"
      },
      {
        "url": "http://localhost:18083/"
      }
    ],
    "config": {
      "enable_uptime_analytics": true,
      "failure_trigger_sample_size": 3,
      "time_wait": 300,
      "checker_pool_size": 50,
      "expire_utime_after": 0,
      "service_discovery": {
        "use_discovery_service": false,
        "query_endpoint": "",
        "use_nested_query": false,
        "parent_data_path": "",
        "data_path": "",
        "port_data_path": "",
        "target_path": "",
        "use_target_list": false,
        "cache_disabled": false,
        "cache_timeout": 0,
        "endpoint_returns_list": false
      },
      "recheck_wait": 0
    }
}

"proxy": {
    ... ...
    "enable_load_balancing": true,
    "target_list": [
      "http://localhost:18081/",
      "http://localhost:18082/",
      "http://localhost:18083/"
    ],
    "check_host_against_uptime_tests": true,
    ... ...
}

我们新增了uptime_tests的配置，uptime_tests的check_list中的url的值要与proxy中target_list中的值完全一样，这样Tyk Gateway才能将二者对应上。另外proxy的check_host_against_uptime_tests要设置为true。

这样配置并生效后，等我们将服务实例3停掉后，后续到no-authn的请求就只会转发到实例1和实例2了。而当恢复实例3运行后，Tyk Gateway又会将流量分担到实例3上。

3.3.4 动态负载均衡

上面负载均衡示例中target_list中的目标实例的IP和端口的手工配置的，而在云原生时代，我们经常会基于容器承载API服务实例，当容器因故退出，并重新启动一个新容器时，IP可能会发生变化，这样上述的手工配置就无法满足要求，这就对API Gateway提出了与服务发现组件集成的要求：通过服务发现组件动态获取服务实例的访问列表，进而实现动态负载均衡。

Tyk Gateway内置了主流服务发现组件(比如Etcd、Consul、ZooKeeper等)的对接能力，鉴于环境所限，这里就不举例了，大家可以在Tyk Gateway的服务发现示例文档页面找到与不同服务发现组件对接时的配置示例。

3.3.5 IP访问限制

针对每个API，API网关还提供IP访问限制的特性，比如Tyk Gateway就提供了IP白名单和IP黑名单功能，通常二选一开启一种限制即可。

以白名单为例，即凡是在白名单中的IP才被允许访问该API。下面是白名单配置样例：

// /opt/tyk-gateway/apps/no-authn-v1.json

  "enable_ip_whitelisting": true,
  "allowed_ips": ["12.12.12.12", "12.12.12.13", "12.12.12.14"],

生效后，当我们访问no-authn API时，会得到下面错误：

$curl localhost:8080/api/v1/no-authn
{
    "error": "access from this IP has been disallowed"
}

如果开启的是黑名单，那么凡是在黑名单中的IP都被禁止访问该API，下面是黑名单配置样例：

// /opt/tyk-gateway/apps/no-authn-v1.json

  "enable_ip_blacklisting": true,
  "blacklisted_ips": ["12.12.12.12", "12.12.12.13", "12.12.12.14", "127.0.0.1"],

生效后，当我们访问no-authn API时，会得到如下结果：

$curl 127.0.0.1:8080/api/v1/no-authn
{
    "error": "access from this IP has been disallowed"
}

到目前为止，我们的API网关和定义的API都处于“裸奔”状态，因为没有对客户端进行身份认证，任何客户端都可以访问到我们的API，显然这不是我们期望的，接下来，我们就来看看API网关的一个重要功能特性：身份认证与授权。

3.4 功能特性：身份认证和授权

在《通过实例理解Go Web身份认证的几种方式》一文中，我们提到过：建立全局的安全通道是任何身份认证方式的前提。

3.4.1 建立安全通道，卸载TLS证书

Tyk Gateway支持在Gateway层面统一配置TLS证书，同时也起到在Gateway卸载TLS证书的作用：

这次我们要在tyk.conf中进行配置，才能在Gateway层面生效。这里我们借用《通过实例理解Go Web身份认证的几种方式》一文中生成的几个证书(大家可以在https://github.com/bigwhite/experiments/tree/master/authn-examples/tls-authn/make_certs下载)，并将它们放到/opt/tyk-gateway/certs/下面：

$ls /opt/tyk-gateway/certs/
server-cert.pem  server-key.pem

然后，我们在/opt/tyk-gateway/tyk.conf文件中增加下面配置：

// /opt/tyk-gateway/tyk.conf 

  "http_server_options": {
    "use_ssl": true,
    "certificates": [
      {
        "domain_name": "server.com",
        "cert_file": "./certs/server-cert.pem",
        "key_file": "./certs/server-key.pem"
      }
    ]
  }

之后，重启tyk gateway服务，使得tyk.conf的配置修改生效。

注：在/etc/hosts中设置server.com为127.0.0.1。

现在我们用之前的http方式访问一下no-authn的API：

$curl server.com:8080/api/v1/no-authn
Client sent an HTTP request to an HTTPS server.

由于全局启用了HTTPS，采用http方式的请求将被拒绝。我们换成https方式访问：

// 不验证服务端证书
$curl -k https://server.com:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn

// 验证服务端的自签证书
$curl --cacert ./inter-cert.pem https://server.com:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn

3.4.2 Mutual TLS双向认证

在《通过实例理解Go Web身份认证的几种方式》一文中，我们介绍的第一种身份认证方式就是TLS双向认证，那么Tyk Gateway对MTLS的支持如何呢？Tyk官方文档提到它既支持client mTLS，也支持upstream mTLS。

我们更关心的是client mTLS，即客户端在与Gateway建连后，Gateway会使用Client CA验证客户端的证书！我最初认为这个Client CA的配置是在tyk.conf中，但找了许久，也没有发现配置Client CA的地方。

在no-authn API的定义文件(no-authn-v1.json)中，我们做如下配置改动：

  "use_mutual_tls_auth": true,
  "client_certificates": [
      "/opt/tyk-gateway/certs/inter-cert.pem"
  ],

但使用下面命令访问API时报错：

$curl --key ./client-key.pem --cert ./client-cert.pem --cacert ./inter-cert.pem https://server.com:8080/api/v1/no-authn
{
    "error": "Certificate with SHA256 bc8717c0f2ea5a0b81813abb3ec42ef8f9bf60da251b87243627d65fb0e3887b not allowed"
}

如果将”client_certificates”的配置中的inter-cert.pem改为client-cert.pem，则是可以的，但个人感觉这很奇怪，不符合逻辑，将tyk gateway的文档、issue甚至代码翻了又翻，也没找到合理的配置client CA的位置。

Tyk Gateway支持多种身份认证方式，下面我们来看一种使用较为广泛的方式：JWT Auth。

主要JWT身份认证方式的原理和详情，可以参考我之前的文章《通过实例理解Go Web身份认证的几种方式》。

3.4.3 JWT Token Auth

下面是我为这个示例做的一个示意图：

这是我们日常开发中经常遇到的场景，即通过portal用用户名和密码登录后便可以拿到一个jwt token，然后后续的访问功能API的请求仅携带该jwt token即可。API Gateway对于portal/login API不做任何身份认证；而对后续的功能API请求，通过共享的secret(也称为static secret)对请求中携带的jwt token进行签名验证。

portal/login API由于不进行authn，这样其配置与前面的no-authn API几乎一致，只是API名称、路径和target_list有不同：

// apps/portal-login-v1.json

{
  "name": "portal-login-v1",
  "slug": "portal-login-v1",
  "listen_port": 0,
  "protocol": "",
  "enable_proxy_protocol": false,
  "api_id": "portal-login-v1",
  "org_id": "1",
  "use_keyless": true,
  ... ...
  "proxy": {
    "preserve_host_header": false,
    "listen_path": "/api/v1/portal/login",
    "target_url": "",
    "disable_strip_slash": false,
    "strip_listen_path": true,
    "enable_load_balancing": true,
    "target_list": [
      "http://localhost:28084"
    ],
    "check_host_against_uptime_tests": true,
  ... ...
}

对应的portal login API也不复杂：

// api-gateway-examples/portal-login/main.go

package main

import (
    "log"
    "net/http"
    "time"

    "github.com/golang-jwt/jwt/v5"
)

func main() {
    // 创建一个基本的HTTP服务器
    mux := http.NewServeMux()

    username := "admin"
    password := "123456"
    key := "iamtonybai"

    // for uptime test
    mux.HandleFunc("/health", func(w http.ResponseWriter, req *http.Request) {
        w.WriteHeader(http.StatusOK)
    })

    // login handler
    mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
        // 从请求头中获取Basic Auth认证信息
        user, pass, ok := req.BasicAuth()
        if !ok {
            // 认证失败
            w.WriteHeader(http.StatusUnauthorized)
            return
        }

        // 验证用户名密码
        if user == username && pass == password {
            // 认证成功，生成token
            token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
                "username": username,
                "iat":      jwt.NewNumericDate(time.Now()),
            })
            signedToken, _ := token.SignedString([]byte(key))
            w.Write([]byte(signedToken))
        } else {
            // 认证失败
            http.Error(w, "Invalid username or password", http.StatusUnauthorized)
        }
    })

    // 监听28084端口
    err := http.ListenAndServe(":28084", mux)
    if err != nil {
        log.Fatal(err)
    }
}

运行该login API服务后，我们用curl命令获取一下jwt token：

$curl -u 'admin:123456' -k https://server.com:8080/api/v1/portal/login
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MDA3NTEyODEsInVzZXJuYW1lIjoiYWRtaW4ifQ.-wC8uPsLHDxSXcEMxIxJ8O2l3aWtWtWKvhtmuHmgIMA

现在我们再来建立protected API：

// apps/protected-v1.json

{
  "name": "protected-v1",
  "slug": "protected-v1",
  "listen_port": 0,
  "protocol": "",
  "enable_proxy_protocol": false,
  "api_id": "protected-v1",
  "org_id": "1",
  "use_keyless": false,    // 设置为false, gateway才会进行jwt的验证
  ... ...
  "enable_jwt": true,      // 开启jwt
  "use_standard_auth": false,
  "use_go_plugin_auth": false,
  "enable_coprocess_auth": false,
  "custom_plugin_auth_enabled": false,
  "jwt_signing_method": "hmac",        // 设置alg为hs256
  "jwt_source": "aWFtdG9ueWJhaQ==",    // 设置共享secret: base64("iamtonybai")
  "jwt_identity_base_field": "username", // 设置代表请求中的用户身份的字段，这里我们用username
  "jwt_client_base_field": "",
  "jwt_policy_field_name": "",
  "jwt_default_policies": [
     "5e189590801287e42a6cf5ce"        // 设置security policy，这个似乎是jwt auth必须的
  ],
  "jwt_issued_at_validation_skew": 0,
  "jwt_expires_at_validation_skew": 0,
  "jwt_not_before_validation_skew": 0,
  "jwt_skip_kid": false,
  ... ...
  "version_data": {
    "not_versioned": true,
    "default_version": "",
    "versions": {
      "Default": {
        "name": "Default",
        "expires": "",
        "paths": {
          "ignored": null,
          "white_list": null,
          "black_list": null
        },
        "use_extended_paths": true,
        "extended_paths": {
          "persist_graphql": null
        },
        "global_headers": {
          "username": "$tyk_context.jwt_claims_username" // 设置转发到upstream的请求中的header字段username
        },
        "global_headers_remove": null,
        "global_response_headers": null,
        "global_response_headers_remove": null,
        "ignore_endpoint_case": false,
        "global_size_limit": 0,
        "override_target": ""
      }
    }
  },
  ... ...
  "enable_context_vars": true, // 开启上下文变量
  "config_data": null,
  "config_data_disabled": false,
  "tag_headers": ["username"], // 设置header
  ... ...
}

这个配置就相对复杂许多，也是翻阅了很长时间资料才验证通过的配置。JWT Auth必须有关联的policy设置，我们在tyk gateway开源版中要想设置policy，需要现在tyk.conf中做如下设置：

// /opt/tyk-gateway/tyk.conf

  "policies": {
    "policy_source": "file",
    "policy_record_name": "./policies/policies.json"
  },

而policies/policies.json的内容如下：

// /opt/tyk-gateway/policies/policies.json
{
    "5e189590801287e42a6cf5ce": {
        "rate": 1000,
        "per": 1,
        "quota_max": 100,
        "quota_renewal_rate": 60,
        "access_rights": {
            "protected-v1": {
                "api_name": "protected-v1",
                "api_id": "protected-v1",
                "versions": [
                    "Default"
                ]
            }
        },
        "org_id": "1",
        "hmac_enabled": false
    }
}

上述设置完毕并重启tyk gateway生效后，且protected api服务也已经启动时，我们访问一下该API服务：

$curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MDA3NTEyODEsInVzZXJuYW1lIjoiYWRtaW4ifQ.-wC8uPsLHDxSXcEMxIxJ8O2l3aWtWtWKvhtmuHmgIMA" -k https://server.com:8080/api/v1/protected
invoke protected api ok

我们看到curl发出的请求成功通过了Gateway的验证！并且通过protected API输出的请求信息来看，Gateway成功解析出username，并将其作为Header中的字段传递给了protected API服务实例：

http.Request{Method:"GET", URL:(*url.URL)(0xc0002f6240), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{"Accept":[]string{"*/*"}, "Accept-Encoding":[]string{"gzip"}, "Authorization":[]string{"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MDA3NTEyODEsInVzZXJuYW1lIjoiYWRtaW4ifQ.-wC8uPsLHDxSXcEMxIxJ8O2l3aWtWtWKvhtmuHmgIMA"}, "User-Agent":[]string{"curl/7.29.0"}, "Username":[]string{"admin"}, "X-Forwarded-For":[]string{"127.0.0.1"}}, Body:http.noBody{}, GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"localhost:28085", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"[::1]:55583", RequestURI:"/", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc0002e34f0)}

如果不携带Authorization头字段或jwt的token是错误的，那么结果将如下所示：

$ curl -k https://server.com:8080/api/v1/protected
{
    "error": "Authorization field missing"
}

$ curl -k -H "Authorization: Bearer xxx" https://server.com:8080/api/v1/protected
{
    "error": "Key not authorized"
}

一旦通过API Gateway的身份认证，上游的API服务就会拿到客户端身份，有了唯一身份后，就可以进行授权操作了，其实policy设置本身也是一种授权访问控制。Tyk Gateway自身也支持RBAC等模型，也支持与OPA(open policy agent)等的集成，但更多是在商业版的tyk dashboard下完成的，这里也就不重点说明了。

下面的Gateway的几个主要功能特性由于试验环境受限以及文章篇幅考量，我不会像上述例子这么细致的说明了，只会简单说明一下。

3.5 功能特性：流量控制与限速

Tyk Gateway内置提供了强大的流量控制功能，可以通过全局级别和API级别的限速来管理请求流量。此外，Tyk Gateway 还支持请求配额（request quota）来限制每个用户或应用程序在一个时间周期内的请求次数。

流量不仅和请求速度和数量有关系，与请求的大小也有关系，Tyk Gateway还支持在全局层面和API层面设置Request的size limit，以避免超大包对网关运行造成不良影响。

3.6 功能特性：高可用与容错处理

在许多情况下，我们要为客户确保服务水平(service level)，比如：最大往返时间、最大响应时延等。Tyk Gateway提供了一系列功能，可帮助我们确保网关的高可用运行和SLA服务水平。

Tyk支持健康检查，这对于确定Tyk Gateway的状态极为重要，没有健康检查，就很难知道网关的实际运行状态如何。

Tyk Gateway还内置了断路器(circuit breaker)，这个断路器是基于比例的，因此如果y个请求中的x请求都失败了，断路器就会跳闸，例如，如果x = 10，y = 100，则阈值百分比为10%。当失败比例到达10%时，断路器就会切断流量，同时跳闸还会触发一个事件，我们可以记录和处理该事件。

当upstream的服务响应迟迟不归时，Tyk Gateway还可以设置强制超时，可以确保服务始终在给定时间内响应。这在高可用性系统中非常重要，因为在这种系统中，响应性能至关重要，这样才能干净利落地处理错误。

3.7 功能特性：监控与可观测性

微服务时代，可观测性对运维以及系统高可用的重要性不言而喻。Tyk Gateway在多年的演化过程中，也逐渐增加了对可观测的支持，

可观测主要分三大块：

Tyk Gateway支持设置输出日志的级别(log level)，默认是info级别。Tyk输出的是结构化日志，这使得它可以很好的与其他日志收集查询系统集成，Tyk支持与主流的日志收集工具对接，包括：logstash、sentry、Graylog、Syslog等。

metrics

度量数据是反映网关系统健康状况、错误计数和类型、IT基础设施（服务器、虚拟机、容器、数据库和其他后端组件）及其他流程的硬件资源数据的重要参考。运维团队可以通过使用监控工具来利用实时度量的数据，识别运行趋势、在系统故障时设置警报、确定问题的根本原因并缓解问题。

Tyk Gateway内置了对主流metrics采集方案Prometheus+Grafana的支持，可以在网关层面以及对API进行实时度量数据采集和展示。

tracing

Tyk Gateway从5.2版本开始支持了与服务Tracing界的标准：OpenTelemetry的集成，这样你可以使用多种支持OpenTelemetry的Tracing后端，比如Jaeger、Datadog等。Tracing可在Gateway层面开启，也可以延展到API层面。

4. 小结

本文对已经相对成熟的API网关技术做了回顾，对API网关的演进阶段、主流特性以及当前市面上的主流API网关进行了简要说明，并以Go实现的Tyk Gateway社区开源版为例，以示例方式对API网关的主要功能做了介绍。

总体而言，Tyk Gateway是一款功能强大，社区相对活跃并有商业公司支持的产品，文档很丰富，但从实际使用层面，这些文档对Tyk社区版本的使用者来说并不友好，指导性不足(更多用商业版的Dashboard说明，与配置文件难于对应)，就像本文例子中那样，为了搞定JWT认证，笔者着实花了不少时间查阅资料，甚至阅读源码。

Tyk Gateway的配置设计平坦，没有层次和逻辑，感觉是随着时间随意“堆砌”上去的。并且配置文件更新时，如果出现格式问题，Tyk Gateway并不报错，让人难于确定配置是否真正生效了，只能用Tyk Gateway的控制API去查询结果来验证，非常繁琐低效。

本文涉及的源码可以在这里下载，文中涉及的一些tyk gateway api和security policy的配置也可以在其中查看。

5. 参考资料

Leaving the Cloud – https://37signals.com/podcast/leaving-the-cloud/
The Past, Present, and Future of API Gateways – https://www.infoq.com/articles/past-present-future-api-gateways/
How moving from AWS to Bare-Metal saved us 230,000/yr – https://blog.oneuptime.com/moving-from-aws-to-bare-metal/
A Comprehensive Guide to API Gateways, Kubernetes Gateways, and Service Meshes – https://navendu.me/posts/gateway-and-mesh/
Use API gateways in microservices – https://learn.microsoft.com/en-us/azure/architecture/microservices/design/gateway
The Tyk API Gateway and Postman – https://blog.postman.com/the-tyk-api-gateway-and-postman/
Getting Started with Tyk API Gateway with Keycloak – https://javascript.plainenglish.io/getting-started-to-tyk-api-gateway-with-keycloak-16307435584a
Observing your API traffic with Tyk, Elasticsearch & Kibana – https://medium.com/@asoorm/observing-your-api-metrics-with-tyk-elasticsearch-kibana-74e8fd946c39
Set up JWT token in tyk gateway – https://community.tyk.io/t/set-up-jwt-token-in-tyk-gateway/6572/9

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite
Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go是一门面向对象编程语言吗

bigwhite — Sun, 12 Mar 2023 12:58:07 +0000

本文永久链接 – https://tonybai.com/2023/03/12/is-go-object-oriented

Go语言已经开源13年了，在近期TIOBE发布的2023年3月份的编程语言排行榜中，Go再次冲入前十，相较于Go在2022年底的排名提升了2个位次：

《Go语言第一课》专栏中关于Go在这两年开始飞起的“预言”也正在逐步成为现实^_^，大家学习Go的热情也在快速提升，《Go语言第一课》专栏的学习的人数年后也快速增加，快突破2w了。

很多专栏的订阅者都是第一次接触Go，他们中的很多是来自像Java, Ruby这样的OO(面向对象)语言阵营的，他们学习Go之后的第一个问题便是：Go是一门OO语言吗？在这篇博文中，我们就来探讨一下。

一. 溯源

在公认的Go语言“圣经”《Go程序设计语言》一书中，有这样一幅Go语言与其主要的先祖编程语言的亲缘关系图：

从图中我们可以清晰看到Go语言的“继承脉络”：

从C语言那里借鉴了表达式语法、控制语句、基本数据类型、值参数传递、指针等；
从Oberon-2语言那里借鉴了package、包导入和声明的语法，而Object Oberon提供了方法声明的语法。
从Alef语言以及Newsqueak语言中借鉴了基于CSP的并发语法。

我们看到，从Go先祖溯源的情况来看，Go并没有从纯面向对象语言比如Simula、SmallTalk等那里取经。

Go诞生于2007年，开源于2009年，那正是面向对象语言和OO范式大行其道的时期。不过Go设计者们觉得经典OO的继承体系对程序设计与扩展似乎并无太多好处，还带来了较多的限制，因此在正式版本中并没有支持经典意义上的OO语法，即基于类和对象实现的封装、继承和多态这三大OO主流特性。

但这是否说明Go不是一门OO语言呢？也不是！带有面向对象机制的Object Oberon也是Go的先祖语言之一，虽然Object Oberon的OO语法又与我们今天常见的语法有较大差异。

就此问题，我还特意咨询了ChatGPT^_^，得到的答复如下：

ChatGPT认为：Go支持面向对象，提供了对面向对象范式基本概念的支持，但支持的手段却并不是类与对象。

那么针对这个问题Go官方是否有回应呢？有的，我们来看一下。

二. 官方声音

Go官方在FAQ中就Go是否是OO语言做了简略回应：

Is Go an object-oriented language?

Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).

Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.

粗略翻译过来就是：

Go是一种面向对象的语言吗？

是，也不是。虽然Go有类型和方法，并且允许面向对象的编程风格，但却没有类型层次。Go中的“接口”概念提供了一种不同的OO实现方案，我们认为这种方案更易于使用，而且在某些方面更加通用。还有一些可以将类型嵌入到其他类型中以提供类似子类但又不等同于子类的机制。此外，Go中的方法比C++或Java中的方法更通用：Go可以为任何数据类型定义方法，甚至是内置类型，如普通的、“未装箱的”整数。Go的方法并不局限于结构体（类）。

此外，由于去掉了类型层次，Go中的“对象”比C++或Java等语言更轻巧。

“是，也不是”！我们看到Go官方给出了一个“对两方都无害”的中庸的回答。那么Go社区是怎么认为的呢？我们来看看Go社区的一些典型代表的观点。

三. 社区声音

Jaana Dogan和Steve Francia都是前Go核心团队成员，他们在加入Go团队之前对“Go是否是OO语言”这一问题也都有自己的观点论述。

Jaana Dogan在《The Go type system for newcomers》一文中给出的观点是：Go is considered as an object-oriented language even though it lacks type hierarchy，即“Go被认为是一种面向对象的语言，即使它缺少类型层次结构”。

而更早一些的是Steve Francia在2014年发表的文章《Is Go an Object Oriented language?》中的结论观点：Go，没有对象或继承的面向对象编程，也可称为“无对象”的OO编程模型。

两者表达的遣词不同，但含义却异曲同工，即Go支持面向对象编程，但却不是通过提供经典的类、对象以及类型层次来实现的。

那么Go究竟是以何种方式实现对OOP的支持的呢？我们继续看！

四. Go的“无对象”OO编程

经典OO的三大特性是封装、继承与多态，这里我们看看Go中是如何对应的。

1. 封装

封装就是把数据以及操作数据的方法“打包”到一个抽象数据类型中，这个类型封装隐藏了实现的细节，所有数据仅能通过导出的方法来访问和操作。这个抽象数据类型的实例被称为对象。经典OO语言，如Java、C++等都是通过类(class)来表达封装的概念，通过类的实例来映射对象的。熟悉Java的童鞋一定记得《Java编程思想》一书的第二章的标题：“一切都是对象”。在Java中所有属性、方法都定义在一个个的class中。

Go语言没有class，那么封装的概念又是如何体现的呢？来自OO语言的初学者进入Go世界后，都喜欢“对号入座”，即Go中什么语法元素与class最接近！于是他们找到了struct类型。

Go中的struct类型中提供了对真实世界聚合抽象的能力，struct的定义中可以包含一组字段(field)，如果从OO角度来看，你也可以将这些字段视为属性，同时，我们也可以为struct类型定义方法(method)，下面例子中我们定义了一个名为Point的struct类型，它拥有一个导出方法Length：

type Point struct {
    x, y float64
}

func (p Point) Length() float64 {
    return math.Sqrt(p.x * p.x + p.y * p.y)
}

我们看到，从语法形式上来看，与经典OO声明类的方法不同，Go方法声明并不需要放在声明struct类型的大括号中。Length方法与Point类型建立联系的纽带是一个被称为receiver参数的语法元素。

那么，struct是否就是对应经典OO中的类呢? 是，也不是！从数据聚合抽象来看，似乎是这样, struct类型可以拥有多个异构类型的、代表不同抽象能力的字段(比如整数类型int可以用来抽象一个真实世界物体的长度，string类型字段可以用来抽象真实世界物体的名字等)。

但从拥有方法的角度，不仅是struct类型，Go中除了内置类型的所有其他具名类型都可以拥有自己的方法，哪怕是一个底层类型为int的新类型MyInt：

type MyInt int

func(a MyInt)Add(b int) MyInt {
    return a + MyInt(b)
}

2. 继承

就像前面说的，Go设计者在Go诞生伊始就重新评估了对经典OO的语法概念的支持，最终放弃了对诸如类、对象以及类继承层次体系的支持。也就是说：在Go中体现封装概念的类型之间都是“路人”，没有亲爹和儿子的关系的“牵绊”。

谈到OO中的继承，大家更多想到的是子类继承了父类的属性与方法实现。Go虽然没有像Java extends关键字那样的显式继承语法，但Go也另辟蹊径地对“继承”提供了支持。这种支持方式就是类型嵌入(type embedding)，看一个例子：

type P struct {
    A int
    b string
}

func (P) M1() {
}

func (P) M2() {
}

type Q struct {
    c [5]int
    D float64
}

func (Q) M3() {
}

func (Q) M4() {
}

type T struct {
    P
    Q
    E int
}

func main() {
    var t T
    t.M1()
    t.M2()
    t.M3()
    t.M4()
    println(t.A, t.D, t.E)
}

我们看到类型T通过嵌入P、Q两个类型，“继承”了P、Q的导出方法(M1~M4)和导出字段(A、D)。

关于类型嵌入的具体语法说明，大家可以温习一下《十分钟入门Go语言》或《Go语言第一课》专栏。

不过实际Go中的这种“继承”机制并非经典OO中的继承，其外围类型(T)与嵌入的类型(P、Q)之间没有任何“亲缘”关系。P、Q的导出字段和导出方法只是被提升为T的字段和方法罢了，其本质是一种组合，是组合中的代理（delegate）模式的一种实现。T只是一个代理（delegate），对外它提供了它可以代理的所有方法，如例子中的M1~M4方法。当外界发起对T的M1方法的调用后，T将该调用委派给它内部的P实例来实际执行M1方法。

以经典OO理论话术去理解就是T与P、Q的关系不是is-a，而是has-a的关系。

3. 多态

经典OO中的多态是尤指运行时多态，指的是调用方法时，会根据调用方法的实际对象的类型来调用不同类型的方法实现。

下面是一个C++中典型多态的例子：

#include 

class P {
        public:
                virtual void M() = 0;
};

class C1: public P {
        public:
                void M();
};

void C1::M() {
        std::cout << "c1.M()\n";
}

class C2: public P {
        public:
                void M();
};

void C2::M() {
        std::cout << "c2.M()\n";
}

int main() {
        C1 c1;
        C2 c2;
        P *p = &c1;
        p->M(); // c1.M()
        p = &c2;
        p->M(); // c2.M()
}

这段代码比较清晰，一个父类P和两个子类C1和C2。父类P有一个虚拟成员函数M，两个子类C1和C2分别重写了M成员函数。在main中，我们声明父类P的指针，然后将C1和C2的对象实例分别赋值给p并调用M成员函数，从结果来看，在运行时p实际调用的函数会根据其指向的对象实例的实际类型而分别调用C1和C2的M。

显然，经典OO的多态实现依托的是类型的层次关系。那么对应没有了类型层次体系的Go来说，它又是如何实现多态的呢？Go使用接口来解锁多态！

和经典OO语言相比，Go更强调行为聚合与一致性，而非数据。因此Go提供了对类似duck typing的支持，即基于行为集合的类型适配，但相较于ruby等动态语言，Go的静态类型机制还可以保证应用duck typing时的类型安全。

Go的接口类型本质就是一组方法集合(行为集合)，一个类型如果实现了某个接口类型中的所有方法，那么就可以作为动态类型赋值给接口类型。通过该接口类型变量的调用某一方法，实际调用的就是其动态类型的方法实现。看下面例子：

type MyInterface interface {
    M1()
    M2()
    M3()
}

type P struct {
}

func (P) M1() {}
func (P) M2() {}
func (P) M3() {}

type Q int
func (Q) M1() {}
func (Q) M2() {}
func (Q) M3() {}

func main() {
    var p P
    var q Q
    var i MyInterface = p
    i.M1() // P.M1
    i.M2() // P.M2
    i.M3() // P.M3

    i = q
    i.M1() // Q.M1
    i.M2() // Q.M2
    i.M3() // Q.M3
}

Go这种无需类型继承层次体系、低耦合方式的多态实现，是不是用起来更轻量、更容易些呢！

五. Gopher的“OO思维”

到这里，来自经典OO语言阵营的小伙伴们是不是已经找到了当初在入门Go语言时“感觉到别扭”的原因了呢！这种“别扭”就在于Go对于OO支持的方式与经典OO语言的差别：秉持着经典OO思维的小伙伴一上来就要建立的继承层次体系，但Go没有，也不需要。

要转变为正宗的Gopher的OO思维其实也不难，那就是“prefer接口，prefer组合，将习惯了的is-a思维改为has-a思维”。

六. 小结

是时候给出一些结论性的观点了：

Go支持OO，只是用的不是经典OO的语法和带层次的类型体系；
Go支持OO，只是用起来需要换种思维；
在Go中玩转OO的思维方式是：“优先接口、优先组合”。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

2023年的Rust与Go[译]

bigwhite — Wed, 22 Feb 2023 13:49:14 +0000

本文永久链接 – https://tonybai.com/2023/02/22/rust-vs-go-in-2023

本文译自《Rust vs Go in 2023》。

注：从2022年下半年开始，我们研发团队的产品研发不再局限于云端，车端也是将来的一个重要方向。于是我除了继续对Go语言保持常规的高度关注之外，也逐步开始留意Rust语言的发展。

Rust和Go哪个更好？Go还是Rust？在2023年，你应该为你的下一个项目选择哪种语言，为什么？两者在性能、简单性、安全性、功能、规模和并发性等方面如何比较？它们的共同点是什么，它们有哪些根本性的不同？让我们在这个友好而公平的Rust和Go的比较中找到答案。

Rust和Go都很棒

首先，我必须要说的是，Go和Rust都是绝对优秀的编程语言。它们都是现代的、强大的、被广泛采用的编程语言，并且都提供出色的性能。

你可能读过一些说Go比Rust好的文章，或者相反。但这真的没有意义；每一种编程语言都代表了一系列的权衡和取舍。每种语言都有自己的优化重点，所以你对语言的选择应该由适合你的东西和你想用它解决的问题决定。

在这篇文章中，我将尝试告诉你何时使用Go是理想选择以及何时使用Rust更佳。我也会试着介绍一下这两种语言的本质（如果你愿意的话，就是Go和Rust的道）。

虽然它们在语法和风格上有很大不同，但Rust和Go都是构建软件的一流工具。接下来，让我们仔细看看这两种语言。

Go和Rust的相似之处

Rust和Go有很多共同点，这也是你经常听到它们一起被提及的原因之一。两种语言的共同目标是什么呢？

Rust是一种低级静态类型的多范式编程语言，专注于安全和性能。 – Gints Dreimanis

Go是一种开源的编程语言，可以轻松构建简单、可靠、高效的软件。 – go.dev

内存安全

Go和Rust都属于现代编程语言，它们的首要任务是内存安全。经过几十年对C和C++等旧语言的使用，我们可以清楚地看到，导致错误和安全漏洞的最大原因之一是不安全地或不正确地访问内存。

Rust和Go以不同的方式处理这个问题，但它们的目标都是在管理内存方面比其他语言更聪明、更安全，并帮助你写出正确和高性能的程序。

快速、紧凑的可执行文件

Go和Rust都是编译型语言，这意味着你的程序被直接翻译成可执行的机器码，因此你可以以单一二进制文件形式来部署你的程序；与Python和Ruby等解释型语言不同，你不需要将解释器和大量的库和依赖关系与你的程序一起分发，这是一个很大的优点。这也使得Rust和Go的程序与解释型语言相比都非常快。

通用语言

Rust和Go都是强大的、可扩展的通用编程语言，你可以用它们来开发各种现代软件，从网络应用到分布式微服务，或者从嵌入式微控制器到移动应用程序。

两者都有优秀的标准库、繁荣的第三方生态系统以及巨大的商业支持和庞大的用户基础。它们都已经存在了很多年，并将在未来几年内继续被广泛使用。今天学习Go或Rust将是对你时间和精力的合理投资。

务实的编程风格

Go和Rust都不是以函数式编程为主的语言（例如像Scala或Elixir），也不是完全面向对象的语言（像Java和C#）。相反，虽然Go和Rust都有与函数式和面向对象编程相关的特性，但它们是务实的语言，旨在以最合适的方式解决问题，而不是强迫你采用特定的做事方式。

如果你喜欢函数式编程风格，你会在Rust中发现更多对这种风格的支持，因为Rust在语法特性数量上要比Go更多。

我们可以讨论什么是“面向对象”语言，但可以说C++、Java或C#用户所期望的面向对象编程风格在Go或Rust中都不存在。 – Jack Mott

规模化的开发

Rust和Go都有一些有用的特性，使它们适合于大规模的编程，不管是指大型团队，还是大型代码库，或者两者兼具。

例如，C语言的程序员们多年来一直在争论将括号放在哪里，以及代码应该用制表符还是空格缩进，而Rust和Go通过使用标准的格式化工具（Go为gofmt，Rust为rustfmt）使用规范的风格自动重写你的代码，完全消除了这些问题。

这并不是说这种特殊的风格本身有多好：而是Rust和Go的程序员都喜欢这种标准化。

gofmt的风格是没有人喜欢的，但gofmt却是所有人的最爱。 – Rob Pike

两种语言的另一个高分领域是构建管道(pipeline)。两种语言都有优秀的、内置的、高性能的标准构建和依赖管理工具；不再需要与复杂的第三方构建系统搏斗，也不再需要每隔几年就学习一个新的系统。

对于早期职业生涯以Java和Ruby为背景的我而言，构建Go和Rust代码感觉就像从我的肩上卸下了一个不可能的重担。当我在谷歌工作时，遇到用Go编写的服务是一种解脱，因为我知道它很容易构建和运行。Rust也是如此，尽管我只在较小规模的Rust项目上工作过。我希望可无限配置的构建系统的时代已经过去了，所有语言都会有自己专门的构建工具，开箱即可使用。- 山姆-罗斯

Rust还是Go？

综上可知，这两种语言都设计得很好、很强大，那么你可能会想知道那些关于两门语言的“圣战”究竟是怎么回事（我也是）。为什么人们对“Go vs.Rust”如此大惊小怪，在社交媒体上大打出手，并且写长篇博文说只有傻瓜才会使用Rust，或者Go不是真正的编程语言，或者其他什么。

这可能会让他们感觉好些，但这并不能完全帮助你，因为你正试图决定在你的项目中使用哪种语言，或者你应该学习哪种语言来推动你的编程生涯。一个明智的人不会根据谁喊得声最大来做出重要的选择。

现在让我们继续我们成熟的讨论，看看在某些领域，一个有理智的人可能更喜欢哪一种语言。

Go与Rust的性能对比

我们已经说过，Go和Rust都能生产出高性能的程序，因为它们被编译成了本地机器代码，而不必通过解释器或虚拟机。

然而，Rust的性能尤其突出。它可以与C和C++相媲美，这两种语言通常被认为是性能最高的编译语言，但与这些老语言不同的是，Rust还提供了内存安全和并发安全，并且基本上不会给执行速度上带去没有任何开销。Rust还允许你创建复杂的抽象，而不需要在运行时付出任何性能上的代价。

相比之下，尽管Go程序的性能也非常好，但Go主要是为开发速度（包括编译）而设计的，而不是执行速度。Go程序员更倾向于清晰的代码而不是快速的代码。

Go编译器也不会花很多时间去尝试生成最有效的机器代码；它更关心的是快速编译大量代码。所以Rust通常会在运行时基准测试中击败Go。

Rust的运行时性能也是一致和可预测的，因为它不使用垃圾收集。Go的垃圾收集器非常高效，并且经过优化，使其“STW(停止世界)”的停顿时间尽可能短（每一个新的Go版本都会越来越短）。但是垃圾收集不可避免地在程序的行为方式中引入了一些不可预测的因素，这在某些应用中可能是一个严重的问题，例如嵌入式系统。

因为Rust旨在让程序员完全控制底层硬件，所以有可能将Rust程序优化到相当接近机器的最大理论性能。这使得Rust在执行速度胜过所有其他考虑因素的领域是一个很好的选择，比如游戏编程、操作系统内核、网络浏览器组件和实时控制系统。

简单性

如果没有人能够弄清楚如何使用一种编程语言，那么这种语言有多快也无所谓。Go语言是为了应对C++等语言不断增长的复杂性而特意设计的；它的语法非常少，关键字也非常少，事实上，功能特性也很少。

这意味着学习Go语言不需要很长时间，就可以用它来编写有用的程序。

Go是非常容易学习的。我知道这是一个经常被吹捧的好处，但我真的很惊讶于我能够如此迅速地提高工作效率。多亏了这个语言、文档和工具，我在两天后就写出了有趣的、可提交的代码。 – 一个Rust程序员对Go的早期印象

这里的关键词是简单性。当然，简单并不等同于容易，但是小而简单的语言比大而复杂的语言更容易学习。Go语言没有提供那么多不同的方法来做一件事情，所以所有写得好的Go代码往往看起来都一样。快速学习一个不熟悉的服务并理解它在做什么很容易。

fmt.Println("Gopher's Diner Breakfast Menu")
for dish, price := range menu {
    fmt.Println(dish, price)
}

在我的代码俱乐部视频系列中，我正是这样做的：从GitHub上半随机地挑选Go项目，并与一群Go初学者一起探索它们，看看我们能理解多少的代码。结果总是比我们预期的要多。

虽然核心语言很小，但Go的标准库却非常强大。这意味着你的学习曲线也需要包括你需要的标准库的部分，而不仅仅是Go语法。

另一方面，将功能从语言中转移到标准库中，意味着你可以只专注于学习与你现在相关的库。

Go也是为大规模的软件开发而设计的，支持有大型代码库的大型团队。在这种情况下，新的开发人员能够尽快上手是非常重要的。出于这个原因，Go社区十分看重：简单、明显、常规、直接的程序。

使用Go，你可以快速完成工作。Go是我所使用过的生产力最高的语言之一。它的口号是：今天解决实际问题。 – 马蒂亚斯-恩德勒

特性

Rust比其他几种编程语言支持更多的复杂语法特性，因此，你可以用它实现更多。 – devathon

Rust是专门设计用来帮助程序员用最少的代码做最多的事情，它包括很多强大而有用的功能特性。例如，Rust的match功能可以让你以十分简洁地方式写出灵活的、富有表现力的逻辑：

fn is_prime(n: u64) -> bool {
    match n {
        0...1 => false,
        _ => !(2..n).any(|d| n % d == 0),
    }
}

因为Rust做了很多事情，这意味着有很多东西需要学习，特别是在开始的时候。但这没关系：在C++或Java中也有很多东西要学，而且你不会得到Rust的高级特性，比如内存安全。

批评Rust是一种复杂的语言忽略了一点：它被设计成具有表现力，这意味着有很多功能，而在许多情况下，这正是你想要的编程语言。

当然，Rust有一个学习曲线，但一旦你开始使用它，你就会好起来。

对于那些准备接受更复杂的语法和语义（以及可能更高的可读性成本）以换取最大可能的性能的程序员来说，Rust将与C++和D语言争夺思想份额。 – 戴夫-切尼

虽然Rust采用了Go的一些特性，而Go也在采用Rust的一些特性（尤其是泛型），但可以说Rust的特性很重，而Go的特性相对较轻。

并发

大多数语言都对并发编程（同时做多件事情）有某种形式的支持，但Go从一开始就是为这项工作而设计的。Go不使用操作系统的线程，而是提供了一个轻量级的替代方案：goroutine。

每个goroutine是一个独立执行的Go函数，Go调度器会将其映射到其控制下的一个操作系统线程中。这意味着调度器可以非常有效地管理大量并发的goroutine，只使用有限的操作系统线程。

因此，你可以在一个程序中运行数百万个并发的goroutine，而不会产生严重的性能问题。这使得Go成为高规模并发应用程序的完美选择，如网络服务器和微服务。

Go还具有快速、安全、高效的功能特性，可以使用channel让goroutines进行通信和共享数据。Go的并发支持感觉设计得很好，使用起来也很愉快。

一般来说，对并发程序进行推断是很难的，而且在任何语言中建立可靠、正确的并发程序都是一个挑战。但由于它从一开始就内置于语言中，而不是事后才想到的，Go中的并发编程是最简单、最完整的。

Go语言可以很容易地建立一个很好的多因素的应用程序，充分利用并发性，同时作为一组微服务进行部署。Rust也可以做这些事情，但可以说它更难。在某些方面，Rust对防止与内存有关的安全漏洞的痴迷意味着程序员必须不遗余力地执行那些在其他语言（包括Go）中会更简单的任务。 – Sonya Koptyev

相比之下，Rust中的并发故事是非常新的，而且还在稳定中，但它正处于非常积极的开发中，所以请关注这个领域。例如，Rust的rayon库提供了一种非常优雅和轻量级的方式来将顺序计算转化为并行计算。

拥有goroutines和使用channel的轻量级语法真的很好。这真的显示了语法的力量，这些小细节使并发编程比其他语言感觉好得多 – 一个Rust程序员对Go的早期印象

虽然在Rust中实现并发程序可能不那么简单，但还是有可能的，而且这些程序可以利用Rust的安全保证。

一个很好的例子是标准库的Mutex类：在Go中，你可以忘记在访问某些东西之前获得一个Mutex锁，但Rust不会让你这样做。

Go专注于将并发性作为一个一等公民的概念。这并不是说你不能在Rust中找到Go的面向actor的并发性，但这是留给程序员的一个练习。 – Dave Cheney

安全

我们在前面看到，Go和Rust都以不同的方式来防止一大类与内存管理有关的常见编程错误。但是Rust尤其努力确保你不会做一些你不想做的不安全的事情。

Rust的编译器非常严格和学究派，它检查你使用的每个变量和你引用的每个内存地址。它避免了可能的数据竞争条件，并告知你未定义的行为。并发和内存安全问题在Rust的安全子集中根本不可能发生。 – 为什么是Rust？

这将使Rust编程成为与几乎所有其他语言不同的体验，而且一开始可能是一种挑战。但对很多人来说，这种辛苦是值得的。

对我来说，Rust的关键优势是一种感觉，即编译器是我的后盾，不会让它可能检测到的任何错误通过（说真的，有时感觉就像魔法一样）。 – Grzegorz Nosek

包括Go在内的许多语言都有帮助程序员避免错误的设施，但Rust将这一点提高到了一个新的水平，因此可能不正确的程序甚至不会被编译。

有了Rust，库程序员有很多工具来防止他/她的用户犯错。Rust让我们有能力说，我们拥有一块特定的数据；其他东西不可能声称拥有，所以我们知道没有其他东西能够修改它。我想不出以前有什么时候我被赋予过这么多工具来防止意外的误用。这是一种奇妙的感觉。 – 山姆-罗斯

“与借用检查器(borrow checker)斗争”是Rust程序员新手的常见综合症，但在大多数情况下，它所发现的问题是你的代码中真正的bug（或至少是潜在的bug）。它可能会迫使你从根本上重构你的程序，以避免遇到这些问题；而当正确性和可靠性是你的首要任务时，这是件好事。

一个不改变你编程方式的语言有什么意义呢？当你用其他语言工作时，Rust所教授的关于安全的课程也是有用的。

如果你选择了Rust，通常你需要该语言提供的保证：针对空指针和数据竞争的安全，可预测的运行时行为，以及对硬件的完全控制。如果你不需要这些功能，Rust可能是你下一个项目的糟糕选择。这是因为这些保证是有代价的：入门时间。你需要戒掉坏习惯，学习新概念。有可能的是，当你开始的时候，你会经常和借用检查器斗争。 – Matthias Endler

你觉得Rust的编程模型有多大的挑战性，可能取决于你以前有哪些其他语言的经验。Python或Ruby程序员可能会发现它的限制性；其他人会很高兴。

如果你是一个花了几周的时间来追寻内存安全漏洞的C/C++程序员，你会非常欣赏Rust。”与借用检查器斗争”变成了”编译器可以检测到这个？酷！” -Grzegorz Nosek

规模化

今天的服务器程序由数千万行代码组成，由数百甚至数千名程序员进行构建，而且每天都在更新。Go的设计和开发是为了使在这种环境中工作更有成效。Go的设计考虑包括严格的依赖性管理，随着系统的发展，软件架构的适应性，以及组件之间的健壮性。 – Rob Pike

当你一个人或在小团队中处理问题时，选择简单的语言还是功能丰富的语言是一个偏好的问题。但是当软件越来越大，越来越复杂，团队越来越大时，差异就开始显现出来了。

对于大型应用程序和分布式系统来说，执行速度不如开发速度重要：像Go这样刻意简化的语言可以减少新开发人员的启动时间，并使他们更容易处理大型代码库的工作。

有了Go，作为初级开发者更容易提高工作效率，而作为中级开发者则更难引入会导致后续问题的脆弱抽象。由于这些原因，Rust在企业软件开发方面不如Go有说服力。 – Loris Cro

当涉及到大型的软件开发时，清晰的比聪明的好。Go的局限性实际上使它比Rust等更复杂和强大的语言更适合企业和大机构。

Rust和Go的不同点

虽然Rust和Go都是流行的、现代的、广泛使用的语言，但它们并不是真正的竞争对手，因为它们故意针对的是完全不同的使用情况。

Go的整个编程方法与Rust的完全不同，每一种语言都适合一些人，同时也会刺激另一些人。这完全没问题，如果Rust和Go都能以或多或少相同的方式做同样的事情，我们就不会真的需要两种不同的语言。

那么，我们是否可以通过发现Rust和Go所采取的截然不同的方法来了解它们各自的本性呢？让我们拭目以待。

垃圾回收

“要不要垃圾回收”是一个没有正确答案的问题。垃圾回收，以及一般的自动内存管理，使得开发可靠、高效的程序变得快速和容易，对于一些人来说，这至关重要。

但也有人说，垃圾回收及其性能开销和停顿，使程序在运行时表现得不可预测，并引入了不可接受的延迟。争论还在继续。

Go是一种与Rust非常不同的语言。虽然两者都可以被模糊地描述为系统语言或C语言的替代品，但它们有不同的目标和应用、语言设计的风格以及优先级。垃圾回收是一个真正巨大的区别。Go中的GC使语言更简单，更小，更容易推理。在Rust中没有GC会让它变得非常快（尤其是当你需要保证延迟，而不仅仅是高吞吐量的时候），并且可以实现Go中不可能实现的功能和编程模式（或者至少是在不牺牲性能的情况下）。 – PingCAP

接近机器

计算机编程的历史是一个越来越复杂的抽象的故事，它让程序员在解决问题时不用太担心底层机器的实际运作。

这使得程序更容易编写，也许更容易移植。但是对于许多程序来说，对硬件的访问以及对程序执行方式的精确控制更为重要。

Rust的目标是让程序员“更接近机器”，有更多的控制权，但Go抽象了架构细节，让程序员更接近问题。

两种语言都有不同的适用范围。Go在编写微服务和典型的”DevOps”任务方面表现出色，但它不是一种系统编程语言。Rust对于那些看重并发性、安全性和性能的任务中更强；但它的学习曲线比Go更陡峭。 – Matthias Endler

必须运行更快

许多人同意，对于大多数程序来说，性能不如可读性重要。但当性能确实重要时，它真的很重要。Rust做了一些设计上的权衡，以达到尽可能好的执行速度。

相比之下，Go更关注简单性，它愿意为此牺牲一些（运行时）性能。但是Go的构建速度是无可匹敌的，这对于大型代码库来说是非常重要的。

Rust比Go快。在基准测试中，Rust更快，在某些情况下，甚至是数量级的快。但在你选择用Rust写所有东西之前，考虑一下Go在许多基准测试中并不落后于它，而且它仍然比Java、C#、JavaScript、Python等快得多。如果你需要的是顶级的性能，那么选择这两种语言中的任何一种，你都会在游戏中领先。如果你正在构建一个处理高负载的网络服务，你希望能够在纵向和横向上进行扩展，那么这两种语言都会非常适合你。- 安德鲁-拉德

正确性

另一方面，如果一个程序不需要正常工作的话，它可以任意地快。大多数代码不是为长期而写的，但有些程序能在生产中运行多长时间往往是令人惊讶的：在某些情况下，可以保持几十年。

在这种情况下，值得在开发中多花一点时间，以确保程序的正确性、可靠性，并在未来不需要大量的维护。

Go和Rust都旨在帮助你编写正确的程序，但方式不同。例如，Go提供了一个极好的内置测试框架，而Rust则专注于使用其借用检查器消除运行时的错误。

我认为。Go适用于明天必须交付的代码，而Rust适用于必须在未来五年内保持运行不动的代码。 – Grzegorz Nosek

虽然Go和Rust对于任何严肃的项目来说都是很好的选择，但是让自己尽可能地了解每种语言及其特点是一个好主意。

归根结底，别人怎么想并不重要：只有你能决定哪种语言适合你和你的团队。

如果你想加快开发速度，也许是因为你有许多不同的服务需要编写，或者你有一个庞大的开发团队，那么Go是你的首选语言。Go把并发性作为第一等公民给你，并且不容忍不安全的内存访问（Rust也是如此），但不强迫你管理每一个细节。Go是快速和强大的，但它避免了使开发者陷入困境，而是专注于简单性和统一性。如果在另一方面，拧出每一盎司的性能是必要的，那么Rust应该是你的选择。 – 安德鲁-拉德

结论

我希望这篇文章能让你相信Rust和Go都值得你认真考虑。如果可能的话，你应该争取在这两种语言中至少获得一定程度的经验，因为它们对你的任何技术职业都会有极大的帮助，甚至如果你仅把编程作为一种业余爱好的话。

如果你只有时间投资学习一门语言，在你将Go和Rust用于各种不同类型的大小程序之前，不要做出最终决定。

而编程语言的知识实际上只是成为一名成功的软件工程师的一小部分。到目前为止，你需要的最重要的技能是设计、工程、架构、沟通和协作。如果你在这些方面表现出色，无论你选择哪种语言，你都会成为一名优秀的软件工程师。学习愉快!

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Prometheus采不到数据了！居然是Prometheus client包的锅

bigwhite — Wed, 15 Jun 2022 14:25:07 +0000

本文永久链接 – https://tonybai.com/2022/06/15/prometheus-can-not-pick-up-data-because-of-the-prometheus-client-package

在基于eBPF的新一代观测设施尚未成熟之前，我们采用了业界成熟的Prometheus+Grafana方案采集节点与应用度量指标(metrics)信息。众所周知，这样的方案是一种对应用有侵入的方案，即需要在应用内部嵌入采集度量信息及与Prometheus通信的client包。

Prometheus官方提供并维护了主流语言的client包，包括Go、Java、Python、Ruby、Rust等，如下图：

Prometheus的go client端使用起来也不算复杂，总共分两步：

把你要获取的度量指标注册(Register)到Prometheus的Registry中；
建立起一个HTTP Server，暴露度量指标采集端口即可。

Prometheus采用拉模型(pull)收集时序度量数据，数据拉取行为是由Prometheus服务端来决定的，比如可以设定Prometheus拉取各个采集点的时间周期。一般来说，这个技术栈已经很成熟，配置完启动后，马上就能看到效果。这个技术栈也很稳定，我们使用后一直运行良好，直到本周压测时遇到一个问题：Prometheus采不到数据了！

从最初的数据由连续的线变成“断断续续”的点，见下图：

到后来干脆就无法采到任何数据了：

之前Prometheus跑的好好的，为什么现在却采不到数据了呢？这次与之前的不同之处在于我们的压测用例情景下，每个服务节点都要建立百万以上的连接，而之前仅仅是10w左右的量级。

好在我们部署了在线Continuous Profiling工具，可以查看一下压测那段时间的资源占用，如下图：

上面是一个alloc object的火焰图，我们看到Prometheus client的Registry.Gather方法占了50%的内存分配开销，这是很不正常的。继续沿着Gather函数的火焰图看，我们看到底端居然是readdir。我们应用注册的度量指标也没有哪个采集时需要readdir啊！

要想解决这个问题只有翻Prometheus client源码了！

我们使用的是prometheus client端的默认defaultRegistry。从源码中可以看到：这个defaultRegistry在初始化时，默认注册了两个collector:

// registry.go
func init() {
    MustRegister(NewProcessCollector(ProcessCollectorOpts{}))
    MustRegister(NewGoCollector())
}

我们发现：第一个processCollector会采集如下度量指标数据：

// process_collector.go
func (c *processCollector) Describe(ch chan<- *Desc) {
    ch <- c.cpuTotal
    ch <- c.openFDs
    ch <- c.maxFDs
    ch <- c.vsize
    ch <- c.maxVsize
    ch <- c.rss
    ch <- c.startTime
}

在采集openFDs时，processCollector遍历了/proc/{pid}下面的fd目录：

// process_collector_other.go
func (c *processCollector) processCollect(ch chan<- Metric) {
    pid, err := c.pidFn()
    if err != nil {
        c.reportError(ch, nil, err)
        return
    }

    p, err := procfs.NewProc(pid)
    if err != nil {
        c.reportError(ch, nil, err)
        return
    }

    if stat, err := p.Stat(); err == nil {
        ch <- MustNewConstMetric(c.cpuTotal, CounterValue, stat.CPUTime())
        ch <- MustNewConstMetric(c.vsize, GaugeValue, float64(stat.VirtualMemory()))
        ch <- MustNewConstMetric(c.rss, GaugeValue, float64(stat.ResidentMemory()))
        if startTime, err := stat.StartTime(); err == nil {
            ch <- MustNewConstMetric(c.startTime, GaugeValue, startTime)
        } else {
            c.reportError(ch, c.startTime, err)
        }
    } else {
        c.reportError(ch, nil, err)
    }

    if fds, err := p.FileDescriptorsLen(); err == nil { // 这里获取openFDs
        ch <- MustNewConstMetric(c.openFDs, GaugeValue, float64(fds))
    } else {
        c.reportError(ch, c.openFDs, err)
    }

    if limits, err := p.Limits(); err == nil {
        ch <- MustNewConstMetric(c.maxFDs, GaugeValue, float64(limits.OpenFiles))
        ch <- MustNewConstMetric(c.maxVsize, GaugeValue, float64(limits.AddressSpace))
    } else {
        c.reportError(ch, nil, err)
    }
}

采集openFDS时，processCollector调用了FileDescriptorsLen方法，在FileDescriptorsLen方法调用的fileDescriptors方法中，我们找到了对Readdirnames的调用，见下面源码片段：

// github.com/prometheus/procfs/proc.go

// FileDescriptorsLen returns the number of currently open file descriptors of
// a process.
func (p Proc) FileDescriptorsLen() (int, error) {
    fds, err := p.fileDescriptors()
    if err != nil {
        return 0, err
    }

    return len(fds), nil
}  

func (p Proc) fileDescriptors() ([]string, error) {
    d, err := os.Open(p.path("fd"))
    if err != nil {
        return nil, err
    }
    defer d.Close()

    names, err := d.Readdirnames(-1) // 在这里遍历目录中的文件
    if err != nil {
        return nil, fmt.Errorf("could not read %q: %w", d.Name(), err)
    }

    return names, nil
}

通常情况下，读取/proc/{pid}/fd目录是没有问题的，但当我们的程序上连接着100w+的连接时，意味着fd目录下有100w+的文件，逐一遍历这些文件将带来很大的开销。这就是导致Prometheus在超时时间(通常是10几秒)内无法及时采集到数据的原因。

那么如何解决这个问题呢？

临时解决方法是将registry.go文件的init函数中的MustRegister(NewProcessCollector(ProcessCollectorOpts{}))这一行注释掉！这个进程度量指标信息对我们用处不大。不过这样做的不足是我们自己需要维护一份prometheus golang client包，需要用到go mod replace，十分不便，并且不便于prometheus golang client包的版本升级。

一劳永逸的解决方法是：不使用默认Registry，而是使用NewRegistry函数新建一个Registry。这样我们抛开默认注册的那些度量指标，并可以自行定义我们要注册的度量指标。需要时，我们也可以将ProcessCollector加进来，这个根据不同Go程序的需要而定。

按这个方案修改后，那些熟悉的连续曲线就又重现在眼前了！

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2022年，Gopher部落全面改版，将持续分享Go语言与Go应用领域的知识、技巧与实践，并增加诸多互动形式。欢迎大家加入！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
博客：tonybai.com
github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

手把手教你使用ANTLR和Go实现一门DSL语言（第一部分）：设计DSL语法与文法

bigwhite — Mon, 23 May 2022 21:38:36 +0000

本文永久链接 – https://tonybai.com/2022/05/24/an-example-of-implement-dsl-using-antlr-and-go-part1

在《使用ANTLR和Go实现DSL入门》一文中，我们了解了DSL与通用编程语言(GPL)的差异、DSL解析器生成工具选择以及ANTLR文法的简要书写规则，并和大家一起完成了一个CSV解析器的例子。看完上述文章后，你是不是有了打造属于自己的DSL的冲动了呢！

那么究竟该如何设计和实现一门自己的DSL呢？在这个系列文章中，我将“手把手”地和大家一起看看设计和实现一门DSL(这里主要指外部DSL)的全流程。

结合Martin Fowler在《领域特定语言》一书中的建议，我将设计与实现一门外部DSL的过程分为如下几个步骤：

图：外部DSL设计与实现的步骤

本文是系列文章的第一篇，在这一篇中，我将先来说说前三个步骤，即为某一特定领域设计一门DSL的语法(syntax)、并编写可以解析该DSL的ANTLR文法(grammar)，生成该DSL语法的解析器并验证ANTLR文法的正确性。

到这里有朋友可能会问：“一会儿文法，一会儿又语法，它们到底有啥区别？”，别急！在设计这门DSL语法之前，我先来和大家一起简单理解一下文法与语法的区别。

一. 文法(grammar)和语法(syntax)

图：文法与语法的比较

如上图所示，语法是面向使用该编程语言的应用开发者的，就像Go语法面向的是Gopher；而文法则是面向这门编程语言的编译器或解释器(Interpreter)的核心开发者的。

我们通常用自然语言描述编程语言的语法，这样的文档一般被称为该编程语言的语言规范(language specification)，比如用于描述Go语法的Go语言规范。

但自然语言通常是不精确的，有时带有歧义。为了给出更为精确的语法描述，编程语言规范通常也会有采用某种形式语言(比如：EBNF)表示的关于这门语言语法所对应的文法，比如在Go语言规范中，我们就能看到用EBNF所描述的文法：

SourceFile       = PackageClause ";" { ImportDecl ";" } { TopLevelDecl ";" } .
PackageClause    = "package" PackageName .
PackageName      = identifier .
ImportDecl       = "import" ( ImportSpec | "(" { ImportSpec ";" } ")" ) .
ImportSpec       = [ "." | PackageName ] ImportPath .
ImportPath       = string_lit .
... ...

通常应用开发人员是不会关心这些夹带在语言规范文档中的文法描述的，只有当规范中的说明有歧义时，开发人员才会根据文法中的产生式规则去推导语法的合规形式的，当然了这一推导过程是比较“痛苦”的。

到这里，结合我们在《使用ANTLR和Go实现DSL入门》一文中的说明，我们进一步明确了文法就是一组规则，这组规则告诉我们如何将文本流转换为语法树。如果转换失败，说明文本流中存在不符合编程语言语法的地方。

此外，用于描述一门编程语言语法的文法可以不止一种，每种形式语言工具都有自己的表示形式，比如针对Go语言语法，我们可以使用EBNF给出形式化的文法，也可以使用ANTLR专用的形式化文法。

到这里，你对文法与语法的概念是不是更深刻一些了呢！不过这时可能会有朋友站出来提问：设计一门编程语言或DSL，是先设计语法还是先设计文法呢？

在语言设计伊始，语法和文法设计的边界其实并非那么清晰。讨论语法是为了确定文法做准备，而一旦确定了一版文法，语法的使用形式又被进一步精确了。在编程语言/DSL设计过程中，语法与文法是交替螺旋上升的。简单的DSL语言，可能一轮迭代就完成了全部设计。复杂的通用编程语言可能要反复针对语法讨论多次，确定下来后，才会编写出新一版本的文法，依次反复迭代。

不过通常来说我们会先确定一版语言的语法，写出一些采用此版语言语法的样例源文件，供后续文法以及生成的解析器(Parser)验证使用。回顾Go语言的历史，我们会发现Go语言创世团队当初也是这么做的。Robert Griesemer、Rob Pike和Ken Thompson这三位大佬在Google总部的一间会议室里首先进行了一场有关Go具体设计的会议。会后的第二天，Robert Griesemer发出了一封题为“prog lang discussion”的电邮，这封电邮便成为了这门新语言的第一版设计稿，三位大佬在这门语言的一些基础语法特性与形式上达成了初步一致：

Date: Sun, 23 Sep 2007 23:33:41 -0700
From: "Robert Griesemer" 
To: "Rob 'Commander' Pike" , ken@google.com
Subject: prog lang discussion
...
*** General:
Starting point: C, fix some obvious flaws, remove crud, add a few missing features
  - no includes, instead: import
  - no macros (do we need something instead?)
  - ideally only one file instead of a .h and .c file, module interface
should be extracted automatically
  - statements: like in C, though should fix 'switch' statement
  - expressions: like in C, though with caveats (do we need ',' expressions?)
  - essentially strongly typed, but probably w/ support for runtime types
  - want arrays with bounds checking on always (except perhaps in 'unsafe mode'-see section on GC)
  - mechanism to hook up GC (I think that most code can live w/ GC, but for a true systems
    programming language there should be mode w/ full control over memory allocation)
  - support for interfaces (differentiate between concrete, or implementation types, and abstract,
    or interface types)
  - support for nested and anonymous functions/closures (don't pay if not used)
  - a simple compiler should be able to generate decent code
  - the various language mechanisms should result in predictable code
...

基于这版设计，2008年初，Unix之父Ken Thompson实现了第一版Go编译器(文法相关)，用于验证之前的语法设计。

好了，在理解了文法与语法的区别后，接下来，我们就来为某一特定领域创建一门DSL语言，我们先来介绍一下这门DSL的背景与语法设计。

注：以上提到的对文法与语法的理解仅限于计算机编程语言领域，并不一定适合自然语言领域(自然语言领域也有文法与语法的概念)。

二. 为《后天》中的气象学家设计一门DSL

注：下面只是一个虚构的领域例子，大家无需在其合理性、可行性、科学性与严谨性上产生质疑:)。

如果你看过灾难片专业户罗兰·艾默里奇指导的美国灾难题材电影《后天》，你肯定会对电影里发生的威胁人类文明的灾难情节记忆犹新。不过《后天》里的情节其实离我们并不“遥远”，尤其是进入二十一世纪以来，极端异常天气在全球各个地区屡屡发生：两极高温冰川消融、北美陆地飓风以及我国2021年华北地区的极端降水等等。各国的气象学家、地球物理科学家们都在努力破解这些极端天气背后的原因，并预测全球气候的走势。他们在全球设置了诸多气象数据的采集装置，就像《后天》中部署在大西洋上的浮标那样，7×24小时地监视着“地球的生命体征”。

像浮标这样的采集装置内置采集程序，按照设定的规则定期向中心上报数据或发送异常事件信息。不过浮标一般都是无人值守的，一旦投放，便很难维护。一旦要进行程序升级，比如更新采集数据与上报事件的规则，就比较麻烦了。

如果我们为像浮标这样的采集装置设计一门DSL，让这些装置内置某种DSL引擎，这样变更采集和报警规则只需给装置远程传送一个极小数据量的规则文件即可完成升级，采集装置将按照新规则上报数据和事件。

好了，领域背景介绍完了，下面我们就来为气象学家们分忧，帮助他们设计一门DSL语言，用于“指挥”像浮标这样的数据收集装置按照气象学家们设定的规则上报数据与事件。

三. DSL语言的语法样例

我们先来构思一下这门DSL的语法。什么样的DSL是好DSL？没有固定的评价标准。

自然语言 vs. 编程语言

有人说DSL是给领域专家用的，应该更贴近自然语言一些，但实际情况是DSL更多还是开发人员/测试人员去写，或有开发经验的领域专家使用。所以在《领域特定语言》一书的第二章末尾，Martin Fowler给出关于DSL的特别警示：不要试图让DSL读起来像自然语言。牢记，DSL是一种程序设计语言。

使用DSL更像是在编程，而不是写小说。同自然语言相比，像DSL这样的程序设计语言的目标是简洁、清晰与精确。

一门大的DSL vs. 多门小的DSL

DSL正如其名，是领域相关的。绝大多数DSL都是非常简单、非常小的“编程语言”，比如一个算术表达式求值语言，再比如DSL一书中格兰特小姐的控制器状态机等。

但DSL始终存在演化成庞然大物-一门图灵完备的通用编程语言的风险，这个是要极力避免的。那么怎么识别这种风险呢？Martin Fowler告诉我们：如果一个系统整体都是用一门DSL实现的，那么这门DSL就成为了事实上的通用编程语言了。更佳的作法是切分领域，为不同领域构建不同的DSL，而不要构建一门DSL用于所有领域。

好了，到这里我们先了解一下虚构例子的领域需求，我们需要为这样的一个无人值守的海洋浮标设备设计一门DSL，DSL可用于描述采集设备数据采集与上报的规则。

科学家们对设备的采集能力描述如下：

可通过传感器周期性(默认间隔一分钟)获取所在坐标位置的大气温度、水温、水流速、盐度、….等物理指标；
可对传感器实时获取到的各种物理指标信息进行一元运算(向下取整、向上取整、绝对值)、算术运算(加减乘除取模)、关系运算(大于、小于…)、逻辑运算(与、或) ，构造混合这些运算的条件，当条件为真时，上报指定的物理指标信息；
可结合采集设备缓存的历史时刻数据(缓存能力有限，最大300分钟，即300条数据)进行综合条件判定，这里将其定义为窗口计算，判定策略包括：都不满足、全部满足和至少一项满足。

面对这样的需求，我们怎么定义DSL的语法呢？外部DSL的语法设计往往会受到设计者对以往的编程语言的使用经验的影响。很多开发人员都会从自己熟悉的编程语言的语法中“借鉴”一些语法元素来构成自己的DSL。下面是我设计的一组语法样例：

r0001: Each { || $speed > 30 } => ("speed", "temperature", "salinity");

r0002: None { |,30| $temperature > 5 } => ("speed", "temperature", "salinity");

r0003: None { |3,| $temperature > 10 } => ("speed", "temperature", "salinity");

r0004: Any { |11,30| ($speed < 5) and ($temperature < 2) and (roundUp($salinity) < 600) } => ("speed", "temperature", "salinity");

r0005: Each { |,| (($speed < 5) and (($temperature + 1) < 10)) or ((roundDown($speed) <= 10) and (roundUp($salinity) >= 500))} => ();

到这里，一些童鞋会惊讶到DSL的简单，没错！就像前面所说的，DSL就应该简单、清晰和表意精确。

下面我来对上面的语法样例做个简单说明：

一条规则占用一行，以ruleID开头，以分号结尾；
ruleID与rule body之间通过冒号分隔；
rule body借鉴了Ruby语言中的迭代器语法：

#!/usr/bin/ruby

a = [1,2,3,4,5]
b = Array.new
b = a.collect{ |x| x <= 4 }
puts b

输出：

true
true
true
true
false

在上面ruby的这种迭代器语法中，collect迭代器会将迭代数组a中每个元素，并针对每个元素进行x <= 4的求值，求值结果存储在b中对应的元素位置上。我借鉴了这种形式的语法，形成支持窗口计算和表达式求值的语法。以下面语法为例：

r0001: Each { |1,5| $speed > 30 } => ("speed", "temperature", "salinity");

这个规则的含义是：当窗口数据，从第1项到第5项数据中的speed指标都大于30时，输出并上报当前最新的speed、temperature和salinity指标数据。

Each是对窗口满足策略的判定，Each表示窗口数据中每一项都符合后面的条件表达式；其他两个判定词是None和Any，None表示窗口数据中没有一项满足后面的条件表达式；Any表示窗口数据中有一项满足后面的条件表达式即可。

Each后面的大括号中放置了窗口范围以及条件表达式。

两个竖线表示要参与求值的窗口数据，窗口表示的标准形式为|low, high|，low和high是下标值(下标从1开始)，表示的窗口范围为：[low, high]。当省略low时，比如：|, high|表示的窗口范围为|1, high|；当low与high相同时，比如：|n, n|表示只有下标为n这一个元素参与后续求值；当省略high时，比如：|low, |表示窗口范围为|low, max|，其中max为默认设置的窗口的大小；当low与high都省略，但保留逗号时，比如：|,|，表示窗口中所有数据；当low与high都省略，逗号也省略时，比如：||，则表示|1,1|，即窗口中最新的那条数据。这种设计也部分借鉴了Go的切片下标的语法。

窗口后面条件表达式的求值结果要么为true，要么为false。其支持的运算符可以参考r0005规则。物理指标用$+指标名字表示，比如$speed。

当整个规则求值结果为真时，输出窗口中最新数据的speed、temperature和salinity这三个指标。如果最后输出指标的元组为空，则代表输出所有指标。

好了，大致确定了DSL语法后，我们就来根据语法样例编写对应ANTLR文法。

四. 为DSL编写ANTLR文法

在之前的文章中，我们也提到过，ANTLR文法规则存储在以.g4为后缀的文件中，文件名要与文件内的grammar关键字后面的名字保持一致，比如我们的文件名为Tdat.g4，那么该文件中grammar后面也必须是Tdat：

// the grammar for tdat RuleEngine
grammar Tdat;

注意：如果生成的解析器的目标语言为Go，那么ANTLR文法文件名必须要大写，否则生成的一些重要的结构无法被导出。

每个ANTLR文法文件都需要一个起始语法解析规则(parser rule)，在Tdat.g4中，我们的起始规则为prog：

// the first parser rule, also the first rule of RuleEngine grammar
// prog is a sequence of rule lines.

prog
    : ruleLine+
    ;

正如prog规则的注释那样，一个采集装置的完整规则文件是由一组(至少包含一条)规则行（ruleLine)组成。而每个ruleLine的组成模式也非常固定：

ruleLine
    : ruleID ':' enumerableFunc '{' windowsRange conditionExpr '}' '=>' result ';'
    ;

大家可以对照着前面语法样例来理解ruleLine这个规则。接下来我们自顶向下(从左向右)的将各个组成部分的规则逐一定义就好了。先来看ruleID这个最简单的规则：

ruleID就是以字母开头，由数字与数字组成的文本：

ruleID
    : ID
    ;

// the first char of ID must be a letter
ID
    : ID_LETTER (ID_LETTER | DIGIT)*
    ;

fragment
ID_LETTER
    : 'a'..'z'|'A'..'Z'|'_'  // [a-zA-Z_]
    ;

fragment
DIGIT
    : [0-9]  // match single digit
    ;

像ID这样的词法规则，大家其实无需自己去从头编写，《ANTLR 4权威指南》或antlr/grammar-v4中有大量样例可供参考。

enumerableFunc就是窗口判定策略，这里直接将Each、None和Any定为语言的关键字了：

enumerableFunc
    : 'Each'
    | 'None'
    | 'Any'
    ;

windowsRange是窗口规则，它有两个候选产生式：

windowsRange
    : '|' INT? '|'          #WindowsWithSingleOrZeroIndex
    | '|' INT? ',' INT? '|' #WindowsWithLowAndHighIndex
    ;

为了便于后续解析，这里用#为每个产生式起了一个名字，这样后续ANTLR在基于Tdat.g4生成Parser代码时，就会单独针对每个名字生成一对EnterXXX和ExitXXX(以listener模式下为例)，便于我们解析。当然这里你还可以拆分的更细碎一些以进一步减少在处理Parser规则时自己写代码做判断的工作量。

conditionExpr是这里最复杂的parser规则，它的求值结果永远是true或false，因此我将其产生式规则定义如下：

conditionExpr
    : conditionExpr logicalOp conditionExpr
    | '(' conditionExpr ')'
    | primaryExpr comparisonOp primaryExpr
    ;

我们看到：conditionExpr规则有三个候选产生式，它可以是带括号的自身，支持自身通过逻辑操作符(and和or)的运算，也可以是经由比较操作符计算(比如>、<等)的普通表达式(primaryExpr)。

而普通表达式(primaryExpr)同样可以是带括号的自身，可以是经由算术运算符(比如：加减乘除等)计算的普通表达式，可以是单一的指标(METRIC)，可以是经由一元内置函数(比如：roundUp、abs等)计算的普通表达式，当然也可以仅仅是一个字面值(literal)。literal字面值支持整型、浮点(非科学记数法表示形式)和字符串(双引号括起的文本)：

primaryExpr
    : '(' primaryExpr ')'                  #BracketExprInPrimaryExpr
    | primaryExpr arithmeticOp primaryExpr #ArithmeticExprInPrimaryExpr
    | METRIC                               #MetricInPrimaryExpr
    | builtin '(' primaryExpr ')'          #BuildinExprInPrimaryExpr
    | literal                              #RightLiteralInPrimaryExpr
    ;

arithmeticOp
    : '+'
    | '-'
    | '*'
    | '/'
    | '%'
    ;

builtin
    : 'roundUp'
    | 'roundDown'
    | 'abs'
    ;

logicalOp
    : 'or'
    | 'and'
    ;

comparisonOp
    : '<'
    | '>'
    | '<='
    | '>='
    | '=='
    | '!='
    ;

METRIC
    : '$' ID // match $speed
    ;

INT
    : DIGIT+
    ;

FLOAT
    : DIGIT+ '.' DIGIT* // match 1. 39. 3.14159 etc...
    | '.' DIGIT+        // match .1 .14159
    ;

STRING
    : '"' (ESC|.)*? '"'
    ;

result规则定义了声明输出指标的形式，它是一个小括号表示的元组，指标间用逗号分隔，如果元组为空，则表示输出所有指标。

result
    : '(' STRING (',' STRING)* ')' # ResultWithElements
    | '(' ')'                      # ResultWithoutElements
    ;

好了，到这里针对这门DSL的ANTLR文法也编写完了。

五. 小结

在这一篇中，我们了解了开发一门DSL的基本流程，我们以一门为气象科学家打造的DSL为示例，和大家一起为该DSL设计了语法样例，并用ANTLR4的文法规则定义了这门DSL。

那么这个文法是否能被ANTLR正确解析并生成目标代码？通过这个文法能否正确识别出前面我们给出的语法样例呢？在下一篇“文法验证”中我将给大家揭晓答案。

本文中涉及的代码可以在这里下载 – https://github.com/bigwhite/experiments/tree/master/antlr/tdat 。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。