摘要：在十二贊的深度應用我們是十二贊，一個致力于幫助電商賣家進入小程序的小團隊，我們的主頁是。我們的整個業務構建于阿里云之上，有臺每一對都有獨立的外網同時也在同一個內網之中。，我們把所有的文件都挪到阿里云的服務上。當然，也是可執行文件發布的。

Golang 在十二贊的深度應用

我們是“十二贊”，一個致力于幫助電商賣家進入小程序的小團隊，我們的主頁是http://www.12zan.cn/。在實際運行中，我們使用了大量由golang寫就的小工具，幾乎每一個工具代碼量都超短，一般在200行左右就完成了一個獨立的功能，同時擔當了相當重要的角色；像代理服務器，代碼量一共500行多一點點，卻是我們的核心支柱，壓測時QPS也直追nginx,表現優異。

基于Docker的基礎結構

做為基礎架構，我介紹一下我們的機器架構。

我們的整個業務構建于阿里云之上，有5臺server,每一對都有獨立的外網IP,同時也在同一個內網之中。在每一臺機器上都跑了一個我們自己用golang寫的守護進程，這個進程負責監聽一些業務重啟、新增域名等類似的指令并執行（這些指令最后都傳遞給了docker）。同時，每臺機器上都有一個consul進程，這些consul都join到了一起。另外，我們每一臺機器上，都用docker跑了一個nginx來做80端口的服務，同時跑了一個用golang自己寫的HTTP代理。nginx做做日志啊基礎的功能之后就把請求丟給這個http代理 ，HTTP代理會到consul里去查應該將請求轉發到哪個IP的哪個端口上。

400行Golang代碼寫的HTTP Proxy

在架構選型的第一天，我們就決定，我們會服務化，會大量使用http 接口來提供服務，并使用自己的http proxy來分發請求、添加自有的一些業務邏輯比如API的權限驗證等邏輯。我們限定，所有業務，域名都是*.app.12zan.net，比如我們要上一個聊天服務，請求的接口就會是chat.app.12zan.net,哪天再上個評論服務，請求的接口就是comment.app.12zan.net。

確定域名后我第一件事情，就是拿golang自己寫了一個非常簡單的基于consul的http proxy server;感謝Golang這完善的HTTP庫，我們只用了幾百行代碼就完成了所有功能。每當有http請求過來時，這個proxy server就會根據HTTP請求中HTTP_HOST 字段去consul去查，有哪些后端是用這個域名名稱來注冊服務的，并根據指定的算法，取出一臺后端來,把這個HTTP請求Proxy過去。每個具體的業務，可能運行在我們5臺機器中的任何一臺之中的docker上，也可能是多個docker實例上。所以這里有一個機制，選擇哪個實際的docker實例來服務這個請求的問題。我們現在支持隨機選取、按客戶端IP地址做hash之后選取、按URL做Hash選取、按負載選取幾種方式。

WEB服務的服務注冊

基于php+laralel和nodejs+koajs兩種場景，我們制作了自己的docker鏡像。這個鏡像除開可以將php+nginx和nodejs構建的web服務運行起來之外，還包含一個golang寫的consul客戶端。在docker容器里，這個客戶端隨著php+nginx或是nodejs的web服務一起啟動，啟動之后會向宿主機的consul 進程注冊自己這個服務，注冊的時候會通知說，某某應用，在某某IP某某端口提供服務啦，如果前面有到**.app.12zan.net的請求你可以轉發給我；同時會每隔一秒上報自己的進程數、當前機器CPU占用、內存占用情況。也是一樣的簡單，幾百行golang代碼，就鼓搗出了這個consul客戶端。為什么使用golang呢？第一個原因當然是因為consul天生是golang陣營，第二個，是因為我們的docker容器種類較多，所以這個客戶端直接就是在Mac上跨平臺編譯出來的在linux64平臺上運行的，不管docker容器是python為基準的還是ruby為基準的，還是nodejs的，只要把這個二進制文件拷貝進去就能正確運行，不像別的語言需要解決依賴問題。

我們還開發了一個web console界面，在這里，我們可以注冊app,也可以為app新增實例。注冊app時，我們要指定代碼倉庫的地址（對了，我們的代碼管理是用的golang寫的gogs）,指定對外服務的域名，指定是nodejs應用還是php+laravel應用。添加應用之后，可以在這個應用下新建實例，讓系統在指定的IP上去跑這個實例。實例運行的過程實際就是下發一個通知到某個機器上，去執行一個docker實例啟動的過程。docker啟動的時候帶了一些環境變量，比如當前內網IP、docker監聽的端口、對外提供服務時是用何域名提供服務。

日志和存儲

前面這種架構有一個問題，就是后端可能是在任何一臺機器上運行的，今天可能是A,明天可能是B，那我要是把文件存在A上了是不是讓B來提供服務的時候就掛掉了？所以我們想了這么一個辦法（也是因為窮。。。。），我們把所有的文件都挪到阿里云的OSS服務上。同時為了不管是Nodejs應用還是php應用 還是python寫的應用都能做到把用戶上傳的文件或是系統生成的文件存到oss上面，我們很省事地寫了一個ossUploader,編譯好的可執行文件發布，只需要執行它，傳進來本地路徑和oss上的目標路徑，就保證給你上傳到oss上去就完整，不需要再在nodejs、php、python、ruby、java各種平臺下都琢磨一遍oss的SDK。

對日志的處理是一樣的， 所有的日志文件的內容，都會被一個golang寫的工具gtail監聽著(就像linux 的tail -f命令一樣），所有新產生的內容都會被gtail挪到oss上去存儲。當然，也是可執行文件發布的。

這個實現之后， 我們的實際業務就真正可以在5臺機器上之間任意騰挪了。

消息廣播

得益于golang的一些開源倉庫，我們還做了一些好玩的東西。

比如，看到https://github.com/gorilla/we...，我們忍不住擼了一個websocket server,或是說叫群聊服務器更好一點。

接下來，我們看到有一個golang的庫叫go-mysql-elasticsearch,偽裝了一個mysql的slave，去MySQL的master機器上去讀binlog,讀到binlog以后就將MySQL里的數據發送給ElasticSearch去索引數據。

我們就結合了一個，把這兩個結合起來，修改了一下go-mysql-elastichsearch,讓它監聽到MySQL的數據變更之后，在WebSocket server的某個群聊里推送出來，形成一個數據變更的廣播。

再接下來我們就可以用nodejs寫一個應用，連上這個websocket server，加入特定的某個群聊，就源源不斷地收聽到數據變更的消息。這個nodejs端的代碼就非常簡潔了，只需要不到100行代碼可以做各種好玩的事情，比如監聽到用戶留言表有新增，可以發郵件讓運營馬上去審核。還有比如說，每當訂單表有成交的時候，我們某個小小的nodejs應用因為監聽了數據庫消息，第一時間就知道了，馬上就去追溯用戶來源，來計算返利；同時這個nodejs的代碼更新是和訂單主邏輯完全不相關的，寫這個業務的開發人員只需要知道訂單表的結構，不需要了解訂單應用后臺代碼。
【原文鏈接】