談談創業公司的技術選型

從公司成立第一天起，咱們就以 Google 的技術標準要求團隊，鼓勵使用新技術、鼓勵從新造輪子、鼓勵全棧，同時由於業務涉及視頻、電商、社交多個領域，咱們在創業環境下對微服務、DevOps、自動化測試和部署、搜索、交易、數據監控、直播技術方面的技術選型積累了必定經驗。很是高興能把這些經驗分享給各位同在創業的小夥伴。

咱們的技術選型原則

技術選型對創業公司相當重要，好的選型會讓你少走彎路，產品更快推向市場，比競爭對手更快贏得客戶，得到更多融資，有更多資源投入產品研發和市場擴展 … 如此往復造成良性循環。相反，每個錯誤選型都會帶來巨大的技術債務，我知道一些創業公司把 demo 時的選型一直用到 A 輪甚至 B 輪，而後不得不停下業務花幾個月時間去重構整個系統。

能夠說，對初創團隊的技術 leader，最重要的事情就是選擇正確的技術體系。

下面是咱們技術選型的三個原則：

1、利用好創業公司技術選型的後發優點

大公司的基礎設施每每超過 N 年沒有更新，在創建之初多是前沿的，但不少已經遠落後社區，並且由於所謂的穩定性和技術棧的統一，不容許團隊使用最新的技術。創業了，就打開了全部的禁忌，do what the fuck you want，只要你精挑細選，總有一款工具是最適合你的。工具不只能提升工程師的生產力，工具更定義了你的工做模式，選擇你的工具，而不是被工具選擇。

這對從大公司出來的技術 leader 尤其重要，把以前 BAT 的那套放在腦後，從新出發，你的面前就會打開一扇寶庫大門。

2、第三方付費服務不少不靠譜，當心繞開雷區

花錢買的未必就好，有時候花錢買來的是坑，還得本身填。第三方服務，小的不穩定，大的無法訂製，提個需求均可以排到兩個月後了。這裏的名單很長，特別留心那些給無線開發者提供的服務，不少不靠譜。

解決方案：讓第三方服務成爲可動態配置的組件，多個服務方互備，配置而不集成。好比咱們的 SMS 推送服務就使用了多個服務互備，極大下降了短信丟失率，另外能夠經過配置隨時替換服務方，下降了對單一服務方的依賴。

3、自力更生、重造輪子

由於輪子是你的車最重要的組件，同時沒有哪一個輪子合適裝在你的車上，你的車是獨一無二的噴氣火箭戰車。我不是說你須要重寫 MySQL 或者 CDN，而是把你的業務系統中除了網絡和存儲的組件本身開發，從交易到帳號到搜索到推送系統，網絡和存儲交給公有云並剋制在這塊造輪子的衝動。

你應該重寫 leancloud，重寫 fir.im，重寫 elasticsearch，並且要在兩週內完成。若是你對此嗤之以鼻，說明你沒找到最優秀的工程師，或者是他們的野心尚未被髮動。相信我，這不難，咱們已經這樣作了並且比使用外部服務更好。

創業，要有「不管什麼技術咱們均可以實現並且比其餘人作的更好」的信念，這是創業賦予你最大的自由，抓住這個自由。

咱們選擇的技術

下圖是咱們後臺系統選擇的一部分技術棧：

1、Go 語言

我經歷過的兩家公司， Google 主要用 C++，阿里用 Java。前者是一種存在天生設計缺陷的語言，並且 C++ 的開發效率真不算高，即便是對 Google 這樣的工程團隊，也作了 Style Guild 來規避 C++ 存在的雷區。 而 Java 過於臃腫，缺少原生的多線程支持，運行環境龐大不適合容器化微服務，若是你給 Java 程序打過 docker 包就知道了，動輒上百兆的運行時。

從創業的第一天，咱們選擇 Go 做爲後臺系統開發語言，如今看來是咱們作過的最好的決定之一。Go 的優勢包括：原生支持多線程編程，可編譯爲 standalone binary 無需運行時環境（docker 鏡像通常 10 幾兆就搞定了），自帶格式化工具可以統一團隊的編程風格，極適合寫微服務，並且學習上手快，Java 或者 C++ 程序員只要一個星期就能夠達到熟練運用的水平。

創業以來咱們用 Go 從頭實現了整套後臺系統，包括 RTMP 直播服務器、用戶體系、交易、IM、搜索、監控、小二後臺，咱們甚至用 Go 寫機器學習代碼和機械臂控制程序（咱們在用的 Google 的tensorflow 最近也加入了 Go 語言支持） … 實踐證實 Go 徹底能夠勝任全部的後臺開發工做，並且有極高的效率和工程實現質量。

2、Kubernetes

咱們是微服務的堅決踐行者，微服務技術的核心是容器編排系統，如今最流行的三個容器編排系統是 Kubernetes，Mesos，Swarm。

經過比較咱們選擇了 Kubernetes（簡稱 k8s），由於 Kubernetes 的設計最吸引咱們，有 Google 支持，社區活躍度和發展前景俱佳。咱們整個後臺系統基於 Kubernetes，而且已經徹底微服務化，有 80 多個微服務數百個容器在運行。

咱們在實戰中使用 Kubernetes 的幾點經驗以下。

一、二進制版本和配置版本要作分離，且代碼化

微服務的配置 yaml 文件 checkin 到 git 代碼庫，並且作 binary/config 分離，分別控制二進制和配置環境的版本，全部的線上部署的改動都在代碼中反映出來。舉個 k8s 中微服務配置的例子，以下圖。

這是咱們一個微服務的 deployment 文件，咱們用 git 的版本號作 docker 鏡像的 tag（jenkins 自動打包後加上去的），docker 鏡像裏只包含 binary 文件，配置文件經過 configmap 的 volume mount 爲容器內的一個目錄，並且配置文件也作了版本號控制，數據庫密碼等不走代碼，而是由集羣管理員手工輸入爲 kubernetes 的 secret，不留任何記錄，從而避免了敏感信息的泄露。

二、集羣管理

考慮混合雲上多 k8s 集羣的管理需求，咱們用 zone 來標識不一樣數據中心的 kubernetes 集羣，zone 由三個字母標識，以下圖

經過三字母標識法，咱們將混合雲部署統一化，極大方便了代碼和文檔中的服務標識。

三、使用 Namespace

Kubernetes 的 namespace 極有用，咱們用 production namespace 指代生產環境，staging 指代預發，kube-system 指代集羣系統級別的服務好比 DNS、prometheus 監控和報警等。

另外 k8s 也支持經過 namespace 的 node selector 來指定某個服務須要運行在哪類機器節點上，這樣就能夠將預發和生產環境運行在不一樣的機器上，作到不一樣環境的資源隔離。

四、基於 DNS 的自動化服務註冊、發現和負載均衡

經過 skyDNS 就能夠將一個服務的分佈在不一樣服務器上的 instance 命名歸一化，好比經過調用 ama-server.production.svc.k8s:20001 就能夠將調用請求自動路由到某個服務節點上，調用端不須要關心服務是怎麼部署的，服務註冊和服務發現自動完成。

關於 Kubernetes 和微服務化還有不少細節，若是有機會再分享給你們。

3、Prometheus 和 Grafana 監控系統

若是你知道 ELK，那 Prometheus+Grafana 實現了一套更爲優秀的數據監控系統。好比咱們在 gRPC 服務的 /metrics 下添加了相似下面的指標來監控 RPC 性能：

而後 prometheus 會根據 kubernetes 的配置自動找到這些 metrics，咱們設置這樣的語句進行計算

最後在 Grafana 裏經過這樣的界面展現出來：

若是你在 Google 工做過會心中竊喜，這不就是 Google 的 Borgmon 嘛！對的，Prometheus 就是由一位 xoogler 工程師寫的，參考了 Google 內部數據監控系統的設計。

這套體系和 ELK 相比較輕，且很是容易擴展，咱們寫了幾個模塊把服務日誌和前端訪問記錄融合在一塊兒作分析，同時 Prometheus 指標描述能力很是強大幾乎能夠作任何運算（事實上這種語言是圖靈完備的）。

4、gRPC

集羣內部服務間通信咱們用 Google 開源的 gRPC，最近出了 1.0 穩定版。你可能據說過無數個基於 protobuf 的 RPC 實現，請放棄它們轉用 Google 本身的 gRPC 吧。

5、Github

咱們用 Github 作代碼倉庫，她的用戶分組和權限管理頗有用，並且支持經過 webhook 提醒 Jenkins 完成後續的持續集成工做。

使用 Github 的另外一個好處是，當你想把一個內部項目開源時，只要點幾個按鈕就能夠了，後續開發流程不變，無縫銜接。

6、Phabricator

Facebook 的一款項目管理工具，咱們用它作文檔中心和代碼審查工具。

7、Bearychat

很是好用的團隊溝通工具，好到讓你想放棄郵件溝通，由於這比寫郵件快多了。咱們建了幾十個頻道，你們分組針對特定話題作深刻討論。並且 bearychat 支持機器人，能夠把各類系統通知平滑銜接進來，ChatOps 的利器。

8、Jenkins

咱們在 Jenkins 上作微服務和 iOS/Android app 的測試和打包，能夠說 Jenkins 是整個持續集成的樞紐，任何的代碼改動均可以從這裏觸發後續行爲，從 docker 自動打包，到推送 bearychat 消息提醒，到服務或 app 發佈等。

9、Bugtags

付費服務，幫助咱們組織測試環節的部分工做流程，避免上線前遺漏 bug fix。

10、Whiteboard

就是白板啦！咱們將任務分解爲原子 task，子團隊縱切（產品、UED、前端、後端），任務狀態橫切（待開始、進行中、blocked、完成），不一樣迭代版本使用不一樣顏色，每日晨會更新，進度一目瞭然，「石器時代」的技術選型仍是那麼有效 :)

最後的話

因篇幅緣由一些更細的內容好比微服務的搭建和配置沒法在這裏展開，若是有機會繼續分享一些好玩的「黑科技」給你們。謝謝！