在 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有着一套如何更恰当的编写微服务的久经沙场的信念和最佳的实践。