寫在前面

最近一年來，我都在做公司的RTB廣告系統(tǒng)，包括SSP曝光服務(wù)，ADX服務(wù)和DSP系統(tǒng)。因為是第一次在公司用Go語言實現(xiàn)這么一個大的系統(tǒng)，中間因為各種原因造了很多輪子?，F(xiàn)在稍微有點時間，覺著有必要總結(jié)這一年來用Go造輪子的經(jīng)驗和不足。

集群中遇到的配置文件管理問題

RTB廣告系統(tǒng)中涉及到的服務(wù)程序并不算很多，但是因為RTB系統(tǒng)會面臨很多的流量，而且為了確?？捎眯?，最基本的就是多實例組成集群，同時考慮到后續(xù)業(yè)務(wù)增長，集群的擴縮容也是要做的。我們在設(shè)計的時候，基于ZoooKeeper做了服務(wù)發(fā)現(xiàn)，而我們的服務(wù)接入依靠Nginx集群，然后通過反向代理把請求負載均衡到不同的服務(wù)實例中。這里就存在以下問題：

  • 當我們升級某個服務(wù)時，如何通知Nginx集群自動的摘除或者添加該服務(wù)實例，保證我們的升級不會影響到業(yè)務(wù)和用戶體驗

  • 進一步，任意一個服務(wù)集群內(nèi)的配置數(shù)據(jù)該如何自動更新和應(yīng)用?

業(yè)界方案

業(yè)界其實有很多成熟的方案解決這類問題：

  • 比如開源項目consul-template，但是這個工具只支持后端consul，而我們用的是ZooKeeper

  • 再比如confd，可以支持多種后端，比如etcd或者zookeeper，但是它用的ZooKeeper客戶端不支持在故障時對業(yè)務(wù)請求進行重試，比如發(fā)起了一個GetW請求，而Session變成超時狀態(tài)，這個時候GetW返回的Channel就不可用了，只能重新發(fā)起請求，但是重試多少次請求其實是不知道的，針對這個情況，我還在項目一開始的時候?qū)崿F(xiàn)了新的包，加入了對業(yè)務(wù)層透明的重試機制。

整體工作流程

  1. 解析模版，獲取要動態(tài)查詢的節(jié)點

  2. 向指定的服務(wù)器，比如ZooKeeper發(fā)起查詢請求，并觀察指定節(jié)點的變化

  3. 當?shù)谝淮位蛘吖?jié)點發(fā)生變更后，查詢最新數(shù)據(jù)

  4. 把最新數(shù)據(jù)應(yīng)用到模版中生成新的配置文件數(shù)據(jù)

  5. 保存最新的配置文件數(shù)據(jù)到目標路徑，并調(diào)用指定的命令應(yīng)用最新的配置文件

實現(xiàn)

模版機制

Go官方標準庫提供了Template包，支持if, range等控制語句，也支持用戶自定義方法。模版機制的方便之處在于，它本身是一種DSL,也算是一種支持計算的超級printf。舉例如下：

        		
網(wǎng)友評論