main函式在哪裡？

看到這個go檔案時大家是不是有一種找到入口的欣喜，同時有一種難以言表的鬱悶，為什麼那麼短？獲取一個command，然後執行一個Execute()就運行了？好像是這麼回事，然後點開了Execute()方法：

越往下看越鬱悶，咋那麼難。。。

這時候看一下我們在哪裡，可以發現當前路徑是：

D:/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:790

尷尬，一開始就陷入了3方庫。點開NewSchedulerCommand()函式看看呢：

到這裡好像我們發現了什麼，cobra是個什麼東西？似乎cobra影響了整個程式碼結構，獲取command是cobra的Command物件，最後的Execute()方法也是cobra提供的方法。於是不難發現，這是一個繞不過去的三方庫，我們得先花點力氣查查cobra是什麼！

 

cobra是什麼？

我們可以在github上看到這個專案

來自spf13，看來是精品！上圖的英文介紹裡可以看到一點訊息：A Commander for modern Go CLI interactions

然後瀏覽一下README.md（建議大家到github上認真看一下這個說明文件），我們大致可以看出來

天哪，那麼多知名開源go專案，k8s生態的etcd、docker、之上的openshift等等居然都用了cobra！明顯這些專案都用了cobra當做“腳手架”，也就是入口風格會很像！spf13寫的pflag等都是大名鼎鼎的輪子中的精品啊，看來cobra很值得稍微深入一下，如果自己開發命令列工具，需要用到子命令和flag的話，spf13的cobra和pflag是不二之選了。

一句話介紹cobra，然後我們簡單實踐一下：支援子命令列模式和複雜flag的時髦命令列程式腳手架！

 

cobra程式長什麼樣？

要寫個demo，當然得先install cobra. 作為一隻gopher，我相信大家install 一個github上的go專案是沒有壓力的，此中無非可能遇到網路問題，go get不行就git clone，缺啥找啥，最終下載完是這樣的：

 

下面我們試著寫一個小小的cobra程式：

如上命令，cobra告訴我們application is ready at xxx，所以我們看一下本地生成了些什麼：

本地自動建立好了一個專案，我們看一下main.go裡面是什麼：

是不是有點小激動？和kube-scheduler的入口一樣一樣的！我們執行如下命令來新增2個command：

我們開啟version.go稍微修改一下：

 

發現沒有，當我們執行一個命令時，對應的command中Run方法會被執行！我們最後看一個子命令的玩法：

怎麼樣，輕輕鬆鬆寫了一個支援多級命令的程式，後面一張圖可以看到上面我們輸入命令中serverCmd的含義：

 

下面看kube-scheduler中對應的Run在哪裡？

cmd/kube-scheduler/app/server.go:322 func NewSchedulerCommand() *cobra.Command

繼續看一下Run：後面是什麼：

這個Run()方法繼續跟一下：

是不是發現好像接近真相了？

這個server.Run()我們繼續看看：

太和諧了！這個註釋也可以直觀看到這就是執行SchedulerServer的入口，這個函式接收到stop資訊前會一直執行下去，也就是一直執行著的kube-scheduler！！！

我們最後回頭看一下main.go

是不是很好理解了？第一個紅框中設定Run()方法中需要做什麼，後面的Execute()方法其實就是運行了前面定義的Run()方法！

今天就講到這裡，我們下一講尋找排程演算法！