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

阅读数:5491 2015 年 9 月 13 日

话题:架构DevOps语言 & 开发

Golang UK会议上,Peter Bourgon介绍了“Go kit”,“Go kit”是一种开源的微服务工具箱,可以用在现代企业应用程序栈中促进和规范化基于 Go 服务的创建。

Bourgon 是Weaveworks的一名工程师,他以尽管Google 的 Go 语言正迅速成为“服务器的语言”,但是在现代企业中还没有达到临界规模为开场白,开始了他的演讲。为了解决这一难题,Bourgon 创建了“Go kit”,“Go kit”是一种是微服务工具箱,是为了在较大的技术组织里实现简化(和规范化)基于 Go 微服务的创建而存在的一种机制。

接下来的演讲提供了对该工具箱的一个高层次的概述、存在的驱动力、和应用场景。在演讲中,为了突出框架内和使用语义中关键架构的选择,Bourgon 穿插了一系列的现场编码演示。

演讲过后,InfoQ 有幸采访了 Bourgon,并就 Go kit、微服务、和企业内 Go 的使用情况等提出了一系列问题。

InfoQ:欢迎您,Peter!您能向我们解释一下“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 作为他们业务逻辑时都会感到自信。

InfoQ:与单纯使用Go标准库相比,Go kit是如何让编写微服务变的更加容易的?

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

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

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

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

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

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

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

InfoQ:您给Go kit定位的是哪类开发者/组织?

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

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

InfoQGo正日益成为一门受欢迎的语言,可以用来编写微服务促进科技,比如DockerKubernetesHashiCorp基础设施工具集。您为什么认为Go语言会在这里大展身手?

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

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

InfoQ:哪种方式是感兴趣的InfoQ读者能够参与或为项目贡献的最佳方式?

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

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

InfoQPeter,感谢您今天的参与。您还有什么想跟我们InfoQ读者分享的吗?

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

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

谢谢你邀请我!

Bourgon 关于 Go kit 的演讲视频近期将可以在Golang UK 会议网站上下载,更多有关 Go kit 的信息请参考该项目的网页GitHub 资源库

查看英文原文Building Microservices with Go and ‘Go kit’:Peter Bourgon Q&A


感谢张龙对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。