2017 年，我正在维护一个基于 Node.js 的电子商务服务器，这时一个新的项目落到了我的肩上——一个用于车辆追踪设备的物联网平台。成千上万的设备持续传输数据，而客户期望能够实时查看这些设备报告的信息。
这个 Node.js 服务器几乎立刻就显露出了它的局限性。
设备太多，实时数据量太大，吞吐量却不足。客户端遇到了延迟。数据到达滞后。存储层挣扎得如此厉害，以至于团队每 30 天就要删除上个月的数据，以维持系统运行。而在这一切之下是一个单体架构——一个大型服务器处理所有事务，无法在不扩展整个系统的情况下，单独扩展那些陷入困境的部分。
我们需要微服务。我们需要速度。我们需要为此而构建的东西。
为什么选择 Go 语言
我是从 C++ 转向 Go 语言的，而不是从 Python、Ruby 或 JavaScript 转来的。我在结构化、编译型语言中度过了多年，在写下一行代码之前，你会仔细思考类型、内存和并发问题。Node.js 曾是一段插曲。Java 曾用了一年。而 Go 语言让人感觉像是回到了家。
2017 年的 Go 语言还很年轻。社区规模较小。生态系统较为单薄。但有谷歌在背后支持，社区增长迅速，且其性能特征正是物联网平台所需要的——编译型、支持并发、速度快。
决定很简单。更困难的问题是：如何从头构建一个 Go 语言微服务系统？
go-micro 的问题
显而易见的答案是 go-micro——当时可用的最完整的 Go 语言微服务框架。我尝试了它。它确实能工作。但感觉太过繁重。
go-micro 拥有服务发现、插件、完整的远程过程调用（RPC）系统以及针对各种功能的抽象。对于一个需要在实时物联网系统上快速行动的团队来说，这感觉就像是在一门新语言之上再学习一门新语言。认知负担是真实存在的。
我真正需要的东西更简单。有些服务需要处理来自队列的消息。有些根本不需要队列就能响应——纯粹的“发送并遗忘”模式。有些需要超文本传输协议（HTTP）。有些则需要为设备提供原始套接字连接。系统需要模块化，但不能复杂。
go-micro 可以做到所有这些。但我一直觉得我是在与框架斗争，而不是在构建产品。
所以我停止了斗争，开始构建自己的框架。
第一个版本
Keel 的第一个版本简单得几乎令人尴尬。一个主文件。一个配置文件。一种定义多个服务并在单个 Docker 容器中运行它们的方法。
核心理念：每个服务注册自身，框架根据标志启动正确的服务，并且每个服务都可以通过共享的配置和生命周期系统访问其所需的一切——超文本传输协议（HTTP）、套接字、数据库、消息传递等。
一个二进制文件
一个配置
多个服务
启动你所需的那个
就是这样。没有魔法。没有服务发现。没有插件。只是一种构建 Go 语言微服务项目的清晰方式，让你不必每次添加服务时都重新构建基础。
我用它构建的第一批服务处理了物联网设备的套接字连接。原始传输控制协议（TCP）和 Socket.IO，通过相同的生命周期系统进行管理，共享相同的配置和数据库连接。
它奏效了。所以我继续在此基础上进行构建。
从 Kafka 到 NATS
我接入 Keel 的第一个消息系统是 Kafka。这在当时是合理的——Kafka 是高容量事件流的标准，而物联网平台正在生成显著
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
