Peter Bourgon谈使用Go和“Go kit”构建微服务

Bourgon：去年，我在 SoundCloud 的核心基础设施团队里工作。 我们很早就是微服务框架的使用者了， 并在内部构建了一个叫做 Bazooka 的类 Heroku 平台，用来容器化和运行我们的服务，其中大部分是用 Go 语言编写的。

对产品团队而言，Go 是一个很棒的工具：它能快速上手、容易维护、和易于重构。对于运维而言，同样如此：用 Go 编写的服务相对其它语言（Ruby，Scala，Clojure，Node）而言，同一时间在商业运营上对资源的占用要少一个数量级，甚至更多。

但是，随着时间的推移，作为一个工程组织，我们分工越来越精细，团队越来越多的选择了 Scala。尽管我们选择 Scala 并不是因为语言的缘故，但是，从任何角度来看 Scala 都是一个很不错的语言。我是一名 Go 语言爱好者，所以我承认对此我有些偏见，但是我认为对于微服务而言，它可以说是一种完美的语言，尤其是在较大组织里。所以，当我我看到我们逐渐转向 Scala 这种巨变时，我感到很悲伤。

我询问了周围一圈，得到的答复是，选择 Scala 或者更确切的说 JVM 仅仅是因为他们对微服务管道（microservice plumbing）有着更好的支持。我的意思是很大程度上是无趣但相当重要的工作，比如连接池、安全性校核、从错误中优雅的恢复、管理度量和 instrumentation、路由日记等等。SoundCloud 选择了 Twitter 的 Finagle 栈；还有其他的。虽然所有的这一切 Go 语言都可以实现，但是它也确实如此的繁琐，以及针对以上问题没有能够解决的最佳实践方案。所以不久，惯性就偏向了 JVM 一侧。

因此，我决定做点什么！Go kit 是我尝试用 Go 语言为编写微服务提供一套规范化、最佳实践、和可用的组件。包含了我们认为合理的组件——断路器、速率限制器、日记记录和 instrumentation 包、和针对流行服务发现平台的适配器——可以逐个或者批量使用。如果 Go kit 获得了成功，那么任何规模的工程组织在选择了 Go 作为他们业务逻辑时都会感到自信。

Bourgon：对于这个问题，我想从两方面来回答。

首先，毫无疑问在很多方面 Go 标准库都是一个金标准，在这方面 Go kit 没有想过要去取代它。相反，我们围绕它搭建了一些脚手架，以迎接面对微服务所遇到的大规模挑战。

例如，如果你想编写一种服务，比如用户服务，它是通过 HTTP 进行的服务，你完全可以用简单的 net/http.Server 来编写。当然，GitHub 上有好多这么做的项目，也许对环境、需求等做了稍微不同的假设，并且这些服务在单独运行时都运行的很好。

但是，当你有一个系统，它是由很多种这样的服务组成时，或许甚至是由不在同一地方工作的开发者或者团队编写时，你就不可避免的要在一些辅助问题上徘徊，比如：不同的管理错误的方法、不同的后台日志记录格式、处理恶意客户的不同理念。

当达到一定的规模后，这些差异就会成为真正的问题。结果就是能够系统地推论你要构建的庞大的、解耦的、分布式系统变得非常重要。但是，Go kit 给你提供了这样的组件、和共同的基础。

其次，Go kit 的贡献者都来自不同的组织，有着不同的背景，并且都从事过或参与微服务架构很长一段时间。因此，Go kit 有着一套如何更恰当的编写微服务的久经沙场的信念和最佳的实践。

对于那些刚开始接触微服务的个人和小团队，或者是那些第一次向微服务迁移的较大组织，也许长期以来他们没有操作一定规模微服务的学院知识，但是 Go kit 提供了一些指导方案。我已经分享了我能够想到的和犯过的有关微服务方面的错误，并尽力确保用户在使用 Go kit 时不会犯同样的错误。

Bourgon：Go kit 的目标是使 Go 语言成为现代企业业务逻辑微服务上的一种可行的选择。这是我给自己制定的一个长期目标。我的意思是像 SoundCloud、Spotify、Hailo、37Signals、Bit.ly、Imgur、Secret 等这些公司包括 Netflix 和 Twitter 这样的大型组织，这些通常都是消费者导向、技术驱动的公司，受激励而成长。这些激励措施驱使它们要承担一定的技术风险，当这些风险转变成好的结果时，它们也为软件行业奠定了基调。 现在许多我们认为理所当然的想法 ——像不可变的基础设施、或者开发 / 运维、或者函数式反应编程——往往都是在这样的现代企业一开始以实验而开展的。我想给 Go 一次成为这种成功案例的机会。

也就是说，Go kit 被设计成恰到好处的按比例缩小。如果你是一名黑客, 致力于自己项目，Go kit 将给你提供一个非常好的引导体验。如果你们是一个小的团队，已经建立了一些自己的服务，Go kit 可以加入而不引起大的变更和中断。

Bourgon：的确，Go 正快速成为云基础设施语言。我想其中很多跟工具链有关； 毫不夸大地说在单个 Go 语言里，拥有这样一种编译器，可以为各种现代化平台生成体积小的、静态链接的、本地可编译的执行文件是一件美妙的事情。仅仅是 Go 的这种单体属性让其在很多基础设施工具面前有着很大的吸引力。

除此之外，我认为 Go 实际上是编写多线程（即并发性）网络服务器语言的首选，它让编写多线程网络服务器不再是一种剧痛。正因为这种原因，我是为数不多的一些从 C ++ 转了过来开发者。Go 处理并发性的方法——事实上，它被完全内置到语言内，但花费了大量的精力实现了功能的简洁，并正交于其它语言——在 2009 年这是一个启示——在我的印象里，直到今天它仍然是无与伦比的。

Bourgon：Go kit 仍然是一个新兴的项目，还有很多工作需要完成，可以向很多有趣的方向发展。可以这么说，Go kit 的未来是光明和广阔的，任何有兴趣参与贡献的人都可以在底层加入进来。你可以通过 github.com/go-kit/kit 检查 GitHub 资源库来查看项目当前的状态，可以通过查看 issues 页面 了解我们的近期路线图。

我们在 Google Groups 有一个邮件列表，那是一个广泛讨论和传播设计思想的好地方。并且我们在 ongophers.slack.com 网站的 #go-kit 频道有一个活跃的社区。如果你有什么问题或者好的建议，那是能联系到我，或者是任何一个贡献者和用户的最佳地点。

Bourgon：如果有人阅读了这篇采访，并且在他们的组织已经构建了此类项目，愿意分享你的意见、或者故事，我很乐意聆听。请来 Slack 网页我们的专有频道，给我发电子邮件，或者在 Twitter 上联系我 @peterbourgon。

而且，尤其是如果有人阅读了这篇采访，并乐意在他们的组织里采用 Go kit，但是还需要一些特定的功能，或者对某一集成的工作方法还不太确定，请一定跟我联系。我很乐意跟你携手构建任何你想要的模块，并给 Go 一个机会展示它的实力。

谢谢你邀请我！