OpenStack社區中的GO語言之爭

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

1 背景介紹

     Swift之前幾乎所有的代碼都是用Python實現的，但是效能一直不理想，

     社區為瞭解決效能問題，嘗試過很多方法，後來發現用Golang語言進行一部分代碼重寫，

     效能得到了一定的提升，社區把這部分重寫的分支命名為hummingbird。

     但是目前OpenStack的基礎設施還無法支援Golang語言，

     比如跑單元測試，整合測試的工具支援。

     所以，目前hummingbird分支社區沒法完全按照一般python代碼合入、管理。

     於是有人向社區申請OpenStack社區提供對Golang語言的支援，從而引發了社區的激烈討論。

 

2 Golang的優劣

(1) 給OpenStack帶來的收益：

    效能：直接編譯成機器碼，不依賴其他庫；運行環境不局限在某一個CPU核心，可以有效利用多核，比原生Python在處理瓶頸業務時效能高一個數量級。

    並發處理： Go routine和channel大大的降低了編寫高並發伺服器的難度，很多情況下不用過多的考慮鎖機制。

 

(2) 給OpenStack帶來的問題：

    一個項目採用兩種語言，需要同時維護多個分支，很難找到既精通Python又精通Golang的人。

    社區可能會面臨Python和Golang的分裂，所有的項目可能會被Go重寫。

    需要基礎設施支援，對於社區來講也是一個不小的開支。

 

3 社區核心觀點

(1) 贊成派：

      認為Golang能為社區解決效能問題，同時也是技術發展趨勢，業界有很多雲平台都是基於Golang開發，

      最熱門的Docker也是用Golang開發，社區沒有理由阻止創新。

(2) 反對派：

      認為其實Python一樣也能寫出高效能的代碼，從目前來看Golang語言的訴求主要還是來自於資料面，

      而OpenStack主要還是定位為控制面。同時為了支援一門新語言，社區需要投入很大的工作量，引入的代價太大。

 

4 各種解決方案提議

(1) OpenStack引入Golang

    兩種語言共存會為OpenStack社區工作帶來很多挑戰：需要社區提供基礎設施支援，

    同時還需要各個誇項目團隊增加很多工作，例如文檔、發行管理等等；

    需要有既精通Python又精通Golang的專家。

    引入Golang作為官方語言，社區擔心會有人用Golang重寫OpenStack的項目。

    會議上有人就提出如果Golang成為了官方語言，他將第一個人出來用Golang重寫OpenStack。

 

(2) OpenStack不引入Golang，將OpenStack定位為控制面。

    將Swift拆分為控制面和資料面兩部分。

    其中控制面在OpenStack社區管理（類似於Cinder、Manila），資料面則在其它外部社區管理。

    有些人認為這種方案使得OpenStack不完整了，同時如果OpenStack後續只做控制面，

    那麼OpenStack就像是一個Rest Wrapper，沒有什麼技術含量，失去了技術創新。

    這裡引申出了OpenStack的定位：是否只定位為控制面。

 

(3) 明確各自語言的用途

     Python定位為實現大部分功能，JS定位用於實現Web，Golang則用於Native相關的一些功能。

 

5 社區裡的一些聲音

    -- 有人認為引入Go，那麼很多功能需要完全重寫，不符合開源精神，甚至有人提出如果go接受作為官方語言，他將第一開始用Go重寫OpenStack的項目。

    -- 有人說之前python和perl、c也爭論過，那時有人認為C也可以寫任何功能的代碼，但是最後還是python成了主流，現在也不應該阻礙Golang。

   -- 有人認為為Go維護一個分支，對基礎設施要求、花費的代價都很大，同時還有Release管理，文件管理等各個方面工作，引入代價太大。

   -- 有人認為不能因為說難而拒絕創新。

   -- 有人認為如果OpenStack只是做控制面，那OpenStack就是一個Rest Wrapper，沒有什麼創新，需要有資料面，應該支援Golang。

目前社區還沒有具體的定論，後面討論還會持續。。。

 

編者註：本文來自OpenStack開源團隊工程師李中華