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選擇了推ter的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和推ter這樣的大型組織，這些通常都是消費者導向、技術驅動的公司，受激勵而成長。這些激勵措施驅使它們要承擔一定的技術風險，當這些風險轉變成好的結果時，它們也為軟件行業奠定了基調。 現在許多我們認為理所當然的想法 ——像不可變的基礎設施、或者開發/運維、或者函數式反應編程——往往都是在這樣的現代企業一開始以實驗而開展的。我想給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網頁我們的專有頻道，給我發電子郵件，或者在推ter上聯系我 @peterbourgon 。

而且，尤其是如果有人閱讀了這篇采訪，并樂意在他們的組織里采用Go kit，但是還需要一些特定的功能，或者對某一集成的工作方法還不太確定，請一定跟我聯系。我很樂意跟你攜手構建任何你想要的模塊，并給Go一個機會展示它的實力。

謝謝你邀請我！