本文永久链接 – https://tonybai.com/2025/06/17/rider-elephant-arch

大家好，我是Tony Bai。

在软件架构的江湖里，关于“微服务”与“单体”的论战，几乎从未停歇。一方推崇微服务的灵活性、可扩展性和独立部署，另一方则坚守单体的简洁性、低通信开销和易于本地调试。近年来，我们甚至看到像亚马逊 Prime Video 这样重量级的玩家，也公开分享了其从微服务“回归”到某种形式的单体（或者说更粗粒度的服务）的实践，引发了业界新一轮的思考。

这不禁让我们反问：微服务与单体，真的就是非此即彼的“二元对立”吗？

最近，国外一家名为DealGate公司的一篇文章《Introducing the Rider and Elephant Software Architecture》，提出了一种他们称之为“骑手与大象”的架构模式，试图在这场看似无解的争论中，找到一条务实的中间道路。这种模式不仅在他们的实践中取得了显著成效，其背后的设计哲学和对技术选型的思考，也颇具启发意义。

“骑手与大象”：一个古老隐喻的现代架构演绎

DealGate 将其架构模式命名为“骑手与大象”，其灵感来源于心理学中的一个经典比喻：人类的思维由两部分组成——理性的“骑手”（对应我们发达的前额叶皮层，负责规划、分析和决策）和感性的、更强大的“大象”（对应我们原始的、更底层的“蜥蜴脑”或“穴居人脑”，驱动着本能和情绪）。骑手虽然可以尝试引导大象，但无法完全控制它；而如果骑手想独自前行，又会发现大象的力量是其无法比拟的。只有当骑手与大象协同合作时，才能发挥出最大的效能。

在 DealGate 的架构中，这个隐喻被巧妙地映射到了技术组件上：

• “大象 (Elephant)”：由 Go语言构建的应用。它不包含任何复杂的业务逻辑，但却承担着所有“脏活累活”——大规模的、高并发的数据处理。在 DealGate 的场景中，这可能意味着在任何时刻都有数万个 goroutine 在处理图像、PDF，抓取数千万级别的网页，并在每个网页上运行数千万次的正则表达式匹配。“大象”的核心职责是：强大、高效、能扛事儿。
• “骑手 (Rider)”：由NextJS (Node.js) 构建的应用。它承载了所有的业务逻辑、数据库访问、用户交互等。“骑手”的核心职责是：灵活、敏捷、快速响应业务变化。
• 缰绳 (Communication)：“骑手”通过 gRPC 来“引导”和控制“大象”，两者之间保持低开销、高效率的通信。

这种架构的核心思想是：将需要极致性能和高并发处理的“重计算”部分（大象），与需要快速迭代和灵活业务逻辑的“轻应用”部分（骑手）进行分离，并让它们通过高效的通信方式协同工作。

为何选择“骑手与大象”？DealGate 的实践与思考

DealGate 之所以采用这种架构，源于他们在实际业务中遇到的挑战和对现有架构模式的反思。

• 对“微服务 vs 单体”的“虚假二分法”说不：他们认为，单纯地在微服务和单体之间做选择，往往忽略了业务的复杂性和多样性。他们希望能够“have the best of both worlds”（取两者之长）。
• Node.js/NextJS 的局限性：尽管 DealGate 的主要应用是用 NextJS 编写的，但他们发现，即使 Node.js 在 I/O 和网络处理上有多线程优势，其正则表达式等 CPU 密集型操作仍然受限于单线程（JavaScript 的执行模型）。当需要在后台进行大量正则匹配，同时还要响应 Web 应用请求时，性能瓶颈就显而易见了。
• Go 语言的“大象”潜质：文章中明确指出：“Go语言非常适合这种场景，你可以轻松地扔给它数万个CPU密集型进程，它会愉快地处理掉所有这些”。这充分肯定了 Go 语言在并发处理和性能方面的核心优势。
• 对微服务通信开销的警惕：DealGate 批评了许多微服务架构使用 JSON 进行进程间通信的做法，认为其“序列化和反序列化开销是令人发指的”。他们选择 gRPC，正是为了最大限度地降低“骑手”与“大象”之间的通信成本，确保即使在需要传输大量数据（因为“大象”不包含业务逻辑，需要被视为“愚笨的工人”）的情况下，也能保持高效。

Go 语言：扮演“大象”的理想之选

在“骑手与大象”的架构中，Go 语言之所以被选中扮演“吃苦耐劳的大象”，并非偶然。这得益于 Go 语言的核心特性：

1. 极致的并发性能：Goroutine 和 Channel 机制，配合高效的调度器，使得 Go 能够轻松创建和管理海量的并发任务，这对于处理 DealGate 所述的“数万个 goroutine 同时处理数据”的场景至关重要。
2. 高效的执行效率：Go 语言编译为原生机器码，其性能接近 C/C++，远超解释型语言，非常适合 CPU 密集型的数据处理任务。
3. 强大的标准库：Go 的标准库提供了丰富的网络编程、文本处理（包括正则表达式）、数据编解码等功能，为构建“大象”应用提供了坚实的基础。
4. 简洁的部署：Go 应用可以编译成单个静态链接的可执行文件，部署简单，依赖少。

可以说，Go 语言的设计哲学和核心能力，使其成为承载这种“无业务逻辑、高并发、重计算”角色的理想选择。

语言选型的“二八原则”与“务实主义”

“骑手与大象”架构的另一个核心启示，在于其对不同技术栈的选择策略，体现了一种深刻的“务实主义”和对“成本效益”的考量。

文章明确反驳了“既然有更高性能的语言（如 Rust 或 Go 本身），为什么不把所有应用都用它来写？”的观点，并将其类比为“那所有应用都应该用汇编来写了”。

其核心逻辑是：

• 高级语言（如 JavaScript, Python）的优势：更安全（内存管理等）、生产力更高（表达力强、语法糖和轮子多）、开发者社群更大、单位时间开发成本相对更低。
• 高性能/底层语言（如 Go, Rust, C++）的优势：性能极致、对系统资源有更精细的控制。但通常也意味着更陡峭的学习曲线、更高的开发成本、以及（在某些情况下）更长的开发周期。

DealGate 的策略是：“在你必须快的地方快，其他一切都选择高级语言和（相对）单体的模式。” 这意味着：

• 将昂贵的、需要精细优化的高性能代码（大象）限制在最小的必要范围内（例如，只占整个业务系统的 10%）。
• 将大部分的业务逻辑、用户交互（骑手）用生产力更高、开发更快的高级语言来实现。

这种“混合编程”或“多语言架构”的思路，实际上是在性能、开发效率、人才获取成本、维护成本等多个维度之间进行权衡和优化。它提醒我们，技术选型不应盲目追求“最新最酷”或“性能极致”，而应服务于业务需求，并充分考虑团队和公司的实际情况。

文章中也提及了对“Just write Rust”（就用 Rust 写）这类口号的反思，指出大多数公司和开发者可能无法承担全员学习和使用像 Rust 这样“高门槛”语言的成本。这并非否定 Rust 的优秀，而是强调技术选型的现实约束。

小结：“没有完美的解决方案，只有明智的权衡”

“没有完美的解决方案，只有权衡取舍”。DealGate 的文章以这句经典的名言作为总结，恰如其分。

“骑手与大象”架构，正是在微服务的灵活性、分布式能力与单体的低心智负担、高开发效率之间做出的一种明智权衡。它并非适用于所有场景的“银弹”，但在类似 DealGate 这样需要处理大规模数据密集型任务，同时又需要快速迭代业务逻辑的场景下，无疑提供了一种极具价值的、务实的架构思路。

它也再次印证了一个朴素的道理：优秀的架构设计，往往不是对某种“主义”的盲从，而是对业务需求的深刻理解和对不同技术优劣的精准把握，最终在各种约束条件下找到那个“恰到好处”的平衡点。

或许，在微服务与单体的喧嚣争论之外，我们更应该学习这种“骑手与大象”的智慧——在正确的地方，用正确的方式，做正确的事情。

参考文献：
Introducing the Rider and Elephant Software Architecture – https://d-gate.io/blog/rider-and-elephant-architecture

聊一聊，也帮个忙：

• 你如何看待 DealGate 提出的“骑手与大象”架构模式？它是否对你的项目有所启发？
• 在你的工作中，是否也遇到过类似的“微服务 vs 单体”或“高性能 vs 高生产力”的选型困境？你是如何权衡的？
• Go 语言在你心目中，更适合扮演“骑手”还是“大象”的角色？或者两者皆可，取决于具体场景？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章提供了一个有价值的视角，也请转发给你身边的开发者和架构师朋友们，一起探讨更务实的架构之道！

精进有道，更上层楼

极客时间《Go语言进阶课》上架刚好一个月，受到了各位读者的热烈欢迎和反馈。在这里感谢大家的支持。目前我们已经完成了课程模块一『语法强化篇』的 13 讲，为你系统突破 Go 语言的语法认知瓶颈，打下坚实基础。

现在，我们即将进入模块二『设计先行篇』，这不仅包括 API 设计，更涵盖了项目布局、包设计、并发设计、接口设计、错误处理设计等构建高质量 Go 代码的关键要素。

这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”，真正驾驭 Go 语言，编写出更优雅、
更高效、更可靠的生产级代码！

扫描下方二维码，立即开启你的 Go 语言进阶之旅！

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

本文永久链接 – https://tonybai.com/2025/05/29/xiter-declined

大家好，我是Tony Bai。

随着 Go 1.22 中 range over func 实验性特性的引入，以及在 Go 1.23 中该特性的最终落地（#61405），Go 社区对迭代器（Iterators）的讨论达到了新的高度。在这一背景下，一项旨在提供标准迭代器适配器（Adapters）的提案 x/exp/xiter (Issue #61898) 应运而生，曾被寄予厚望，期望能为 Go 开发者带来一套便捷、统一的迭代器操作工具集。然而，经过社区的广泛讨论和官方团队的审慎评估，该提案最终被标记为“婉拒并撤回 (declined as retracted)”。本文将对 x/exp/xiter 提案的核心内容做个简单解读，说说社区围绕它的主要争论点，以及最终导致其搁浅的关键因素，并简单谈谈这一决策对 Go 语言生态的潜在影响与启示。

x/exp/xiter：构想与核心功能

x/exp/xiter 提案由 Russ Cox (rsc) 发起，旨在 golang.org/x/exp/xiter 包中定义一系列迭代器适配器。这些适配器主要服务于 Go 1.23 中引入的 range over func 特性，提供诸如数据转换 (Map)、过滤 (Filter)、聚合 (Reduce)、连接 (Concat)、并行处理 (Zip) 等常用功能。

其核心目标是：

• 提供标准化的迭代器操作工具： 帮助开发者以更声明式的方式处理序列数据。
• 探索迭代器在 Go 中的惯用法： 将其置于 x/exp 目录下，意在收集社区反馈，探讨这些适配器如何融入现有的 Go 代码风格，以及是否最终适合进入标准库 iter 包。

提案中包含了一系列具体的函数定义，例如：

• Concat / Concat2: 连接多个序列。
• Filter / Filter2: 根据条件过滤序列元素。
• Map / Map2: 对序列中的每个元素应用一个函数。
• Reduce / Reduce2: 将序列中的元素聚合成单个值。
• Zip / Zip2: 并行迭代两个序列。
• Limit / Limit2: 限制序列的长度。
• Equal / Equal2 (及 EqualFunc 版本): 比较两个序列是否相等。
• Merge / Merge2 (及 MergeFunc 版本): 合并两个有序序列。

值得注意的是，许多函数都提供了针对 iter.Seq[V]（单值序列）和 iter.Seq2[K, V]（键值对序列）的两个版本，这导致了 API 数量上的成倍增加。

以下是一个简单的设想用法示例：

package main

import (
    "fmt"
    "iter"
    // 假设 xiter 包已存在且包含提案中的函数
    // "golang.org/x/exp/xiter"
)

// 假设的 Filter 函数
func Filter[V any](f func(V) bool, seq iter.Seq[V]) iter.Seq[V] {
    return func(yield func(V) bool) {
        for v := range seq {
            if f(v) && !yield(v) {
                return
            }
        }
    }
}

// 假设的 Map 函数
func Map[In, Out any](f func(In) Out, seq iter.Seq[In]) iter.Seq[Out] {
    return func(yield func(Out) bool) {
        for in := range seq {
            if !yield(f(in)) {
                return
            }
        }
    }
}

func main() {
    numbers := func(yield func(int) bool) {
        for i := 1; i <= 5; i++ {
            if !yield(i) {
                return
            }
        }
    }

    // 设想：筛选偶数，然后平方
    evenSquares := Map(
        func(n int) int { return n * n },
        Filter(
            func(n int) bool { return n%2 == 0 },
            numbers,
        ),
    )

    for sq := range evenSquares {
        fmt.Println(sq) // 预期输出: 4, 16
    }
}

社区热议：挑战与权衡

x/exp/xiter 提案引发了社区成员的广泛讨论，焦点集中在 API 设计、易用性、与 Go 语言既有哲学的契合度等多个方面。

API 设计与易用性

• 链式调用 vs. 嵌套函数调用: 一些开发者指出，与 Java Streams 或 C# LINQ 那样的流畅链式调用（seq.Map(…).Filter(…)）相比，Go 中基于顶层函数的嵌套调用（Filter(Map(seq, …))）在可读性和编写顺序上存在不足。然而，实现链式调用需要泛型方法，而 Russ Cox指出泛型方法在 Go 中面临巨大的实现挑战（动态代码生成、性能问题、接口检查复杂性等），因此短期内不太可能实现。
• 函数参数顺序: 关于 Filter, Map, Reduce 等函数中，回调函数 f 与序列 seq 的参数顺序，社区存在不同看法。
  • benhoyt认为回调函数应置于末尾，以符合 Go 标准库中如 sort.Slice 等多数函数的习惯，便于使用内联函数字面量。
  • aarzilli 和 Russ Cox 则倾向于将回调函数置于首位（如 Map(f, seq)），理由是这更利于函数组合时的阅读顺序（从内到外或从后往前阅读），并且与 Lisp, Python, Haskell 等语言的类似库保持一致。Russ Cox 最终在提案更新中将 Reduce 的函数参数也移至首位。
• 匿名函数冗余: DeedleFake等人指出，在没有更简洁的匿名函数语法（如 #21498 提案）的情况下，使用这些适配器时，匿名函数的类型签名显得冗余和笨拙，降低了代码的简洁性。

Seq vs. Seq2 的双重性

提案中大量函数针对 iter.Seq[V] 和 iter.Seq2[K, V] 提供了两个版本（例如 Map 和 Map2），这直接导致了 API 接口数量的翻倍。虽然 Russ Cox 认为这只是“重复而非复杂性”，因为学习了 Foo 形式后，Foo2 形式只是一个简单的规则，但仍有社区成员担忧这会使包显得臃肿，影响开发者体验，并随着未来可能增加更多适配器而使问题恶化。

Zip 的语义之争

提案中的 Zip 函数设计为当一个序列耗尽后，仍会继续迭代另一个序列，并在 Zipped 结构体中通过 Ok1/Ok2 标志位标示元素是否存在。这与 Python 等语言中 zip 在最短序列结束时即停止的行为不同，更类似于 zip_longest。社区开发者就此展开讨论，认为应提供传统意义上的 Zip（返回 Seq2[V1, V2] 并在短序列结束时停止）和行为类似 zip_longest 的版本（如 ZipAll 或将提案中的 Zip 重命名为 ZipLongest）。

标准库的边界与 Go 的哲学

• “Go 风格”与“过度抽象”: 一些开发者对引入这类高度函数式的适配器表示担忧，认为它们可能与 Go 语言简洁、直接、偏向过程式循环的既有风格不符，可能导致“过度抽象”。Russ Cox 也承认存在这类担忧，并指出提案的初衷是补充而非取代传统的 for 循环。
• x/exp 的定位: Russ Cox强调，x/exp 仓库并非随意尝试新事物的试验场，而是存放那些被认为是标准库潜在候选者的地方，因为即使是 x/exp 中的包，也需要长期支持。
• DSL (领域特定语言) 的可能性: 有开发者提出了借鉴 jq 或 C# LINQ 的思路，通过 DSL 来解决迭代器链式操作的易用性问题。但 Russ Cox 认为这不符合 Go 当前的目标，且可能带来性能和复杂性问题。

最终的抉择：为何搁置？

在 Go 1.23 发布一段时间后，经过充分的讨论和实践反馈，Russ Cox 和 Austin Clements 代表提案审查小组，宣布将此提案标记为“婉拒并撤回 (declined as retracted)”。

主要原因可以归纳为：

1. 缺乏广泛共识与“过度抽象”的担忧: 官方团队认为，对于将这些适配器加入标准库并鼓励其广泛使用，社区并未形成足够强的共识。许多情况下，直接使用 for 循环可能更为清晰和符合 Go 的惯用法，而这些适配器可能导致“过度抽象”。
2. 实际使用体验与语法限制: 许多开发者在实际使用迭代器后发现，由于当前 Go 语言匿名函数语法的冗余以及缺乏流畅的链式调用机制，这些适配器的使用体验并不理想，甚至不如手写循环或自定义辅助函数来得直接。
3. 为第三方库发展留出空间: 官方认为，与其在标准库中提供一套可能不完美或引发争议的工具集，不如将这部分探索和创新留给社区和第三方库。撤回官方提案可以为第三方迭代器工具库的涌现和发展创造更有利的环境。
4. 迭代器特性尚年轻: Go 中的迭代器特性相对较新，社区和官方都需要更多时间来积累使用经验，观察哪些模式和辅助函数真正被广泛需要和接受。未来可能会基于更充分的数据和实践，提出更具针对性的小型提案。

展望与启示

x/exp/xiter 提案的搁浅，并不意味着 Go 语言在迭代器支持上的停滞。相反，它反映了 Go 团队在语言发展上一贯的审慎和务实态度。

对 Go 开发者而言，这意味着：

• range over func 依然强大: Go 1.23 提供的原生迭代器机制是核心，开发者可以充分利用它来构建高效、灵活的数据处理逻辑。
• 自定义与第三方库是当前主流: 对于迭代器的转换、过滤、聚合等操作，目前主要依赖开发者自行编写辅助函数，或选用社区中涌现的第三方迭代器工具库（如 deedles.dev/xiter, github.com/bobg/seqs, github.com/jub0bs/iterutil 等在讨论中被提及的个人项目）。
• 关注语言本身的演进: 诸如更简洁的匿名函数语法 (#21498) 等相关语言特性的提案，如果未来能被接受，可能会极大地改善函数式编程风格在 Go 中的体验，并可能为官方再次考虑标准化迭代器工具铺平道路。
• Go 的哲学不变: 清晰、简洁、可读性以及避免不必要的复杂性，仍然是 Go 语言设计的核心考量。任何新特性或库的引入，都将在此框架下被严格审视。

x/exp/xiter 的讨论过程本身就是一次宝贵的社区实践，它汇集了众多 Go 开发者的智慧与经验，即便提案未被接纳，其间的深入思考和论证也为 Go 语言迭代器生态的未来发展指明了方向，并留下了丰富的参考。我们期待看到 Go 社区在迭代器领域持续探索，涌现出更多符合 Go 风格且能切实解决开发者痛点的优秀工具与实践。

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