從公司成立第一天起，我們就以 Google 的技術(shù)標(biāo)準(zhǔn)要求團(tuán)隊(duì)，鼓勵(lì)使用新技術(shù)、鼓勵(lì)重新造輪子、鼓勵(lì)全棧，同時(shí)因?yàn)闃I(yè)務(wù)涉及視頻、電商、社交多個(gè)領(lǐng)域，我們?cè)趧?chuàng)業(yè)環(huán)境下對(duì)微服務(wù)、DevOps、自動(dòng)化測試和部署、搜索、交易、數(shù)據(jù)監(jiān)控、直播技術(shù)方面的技術(shù)選型積累了一定經(jīng)驗(yàn)。非常高興能把這些經(jīng)驗(yàn)分享給各位同在創(chuàng)業(yè)的小伙伴。

我們的技術(shù)選型原則

技術(shù)選型對(duì)創(chuàng)業(yè)公司至關(guān)重要，好的選型會(huì)讓你少走彎路，產(chǎn)品更快推向市場，比競爭對(duì)手更快贏得客戶，獲得更多融資，有更多資源投入產(chǎn)品研發(fā)和市場擴(kuò)展 … 如此往復(fù)形成良性循環(huán)。相反，每一個(gè)錯(cuò)誤選型都會(huì)帶來巨大的技術(shù)債務(wù)，我知道一些創(chuàng)業(yè)公司把 demo 時(shí)的選型一直用到 A 輪甚至 B 輪，然后不得不停下業(yè)務(wù)花幾個(gè)月時(shí)間去重構(gòu)整個(gè)系統(tǒng)。

可以說，對(duì)初創(chuàng)團(tuán)隊(duì)的技術(shù) leader，最重要的事情就是選擇正確的技術(shù)體系。

下面是我們技術(shù)選型的三個(gè)原則：

一、利用好創(chuàng)業(yè)公司技術(shù)選型的后發(fā)優(yōu)勢

大公司的基礎(chǔ)設(shè)施往往超過 N 年沒有更新，在建立之初可能是前沿的，但很多已經(jīng)遠(yuǎn)落后社區(qū)，而且因?yàn)樗^的穩(wěn)定性和技術(shù)棧的統(tǒng)一，不允許團(tuán)隊(duì)使用最新的技術(shù)。創(chuàng)業(yè)了，就打開了所有的禁忌，do what the fuck you want，只要你精挑細(xì)選，總有一款工具是最適合你的。工具不僅能提高工程師的生產(chǎn)力，工具更定義了你的工作模式，選擇你的工具，而不是被工具選擇。

這對(duì)從大公司出來的技術(shù) leader 尤為重要，把之前 BAT 的那套放在腦后，重新出發(fā)，你的面前就會(huì)打開一扇寶庫大門。

二、第三方付費(fèi)服務(wù)很多不靠譜，小心繞開雷區(qū)

花錢買的未必就好，有時(shí)候花錢買來的是坑，還得自己填。第三方服務(wù)，小的不穩(wěn)定，大的沒法訂制，提個(gè)需求都可以排到兩個(gè)月后了。這里的名單很長，特別留心那些給無線開發(fā)者提供的服務(wù)，很多不靠譜。

解決方案：讓第三方服務(wù)成為可動(dòng)態(tài)配置的組件，多個(gè)服務(wù)方互備，配置而不集成。比如我們的 SMS 推送服務(wù)就使用了多個(gè)服務(wù)互備，極大降低了短信丟失率，另外可以通過配置隨時(shí)替換服務(wù)方，降低了對(duì)單一服務(wù)方的依賴。

三、自力更生、重造輪子

因?yàn)檩喿邮悄愕能囎钪匾慕M件，同時(shí)沒有哪個(gè)輪子合適裝在你的車上，你的車是獨(dú)一無二的噴氣火箭戰(zhàn)車。我不是說你需要重寫 MySQL 或者 CDN，而是把你的業(yè)務(wù)系統(tǒng)中除了網(wǎng)絡(luò)和存儲(chǔ)的組件自己開發(fā)，從交易到賬號(hào)到搜索到推送系統(tǒng)，網(wǎng)絡(luò)和存儲(chǔ)交給公有云并克制在這塊造輪子的沖動(dòng)。

你應(yīng)該重寫 leancloud，重寫 fir.im，重寫 elasticsearch，而且要在兩周內(nèi)完成。如果你對(duì)此嗤之以鼻，說明你沒找到最優(yōu)秀的工程師，或者是他們的野心還沒有被發(fā)動(dòng)。相信我，這不難，我們已經(jīng)這樣做了而且比使用外部服務(wù)更好。

創(chuàng)業(yè)，要有“無論什么技術(shù)我們都可以實(shí)現(xiàn)而且比其他人做的更好”的信念，這是創(chuàng)業(yè)賦予你最大的自由，抓住這個(gè)自由。

我們選擇的技術(shù)

下圖是我們后臺(tái)系統(tǒng)選擇的一部分技術(shù)棧：

一、Go 語言

我經(jīng)歷過的兩家公司， Google 主要用 C++，阿里用 Java。前者是一種存在天生設(shè)計(jì)缺陷的語言，而且 C++ 的開發(fā)效率真不算高，即使是對(duì) Google 這樣的工程團(tuán)隊(duì)，也做了 Style Guild 來規(guī)避 C++ 存在的雷區(qū)。 而 Java 過于臃腫，缺乏原生的多線程支持，運(yùn)行環(huán)境龐大不適合容器化微服務(wù)，如果你給 Java 程序打過 docker 包就知道了，動(dòng)輒上百兆的運(yùn)行時(shí)。

從創(chuàng)業(yè)的第一天，我們選擇 Go 作為后臺(tái)系統(tǒng)開發(fā)語言，現(xiàn)在看來是我們做過的最好的決定之一。Go 的優(yōu)點(diǎn)包括：原生支持多線程編程，可編譯為 standalone binary 無需運(yùn)行時(shí)環(huán)境（docker 鏡像一般 10 幾兆就搞定了），自帶格式化工具能夠統(tǒng)一團(tuán)隊(duì)的編程風(fēng)格，極適合寫微服務(wù)，而且學(xué)習(xí)上手快，Java 或者 C++ 程序員只要一個(gè)星期就可以達(dá)到熟練運(yùn)用的水平。

創(chuàng)業(yè)以來我們用 Go 從頭實(shí)現(xiàn)了整套后臺(tái)系統(tǒng)，包括 RTMP 直播服務(wù)器、用戶體系、交易、IM、搜索、監(jiān)控、小二后臺(tái)，我們甚至用 Go 寫機(jī)器學(xué)習(xí)代碼和機(jī)械臂控制程序（我們?cè)谟玫?Google 的tensorflow 最近也加入了 Go 語言支持） … 實(shí)踐證明 Go 完全可以勝任所有的后臺(tái)開發(fā)工作，而且有極高的效率和工程實(shí)現(xiàn)質(zhì)量。

二、Kubernetes

我們是微服務(wù)的堅(jiān)定踐行者，微服務(wù)技術(shù)的核心是容器編排系統(tǒng)，現(xiàn)在最流行的三個(gè)容器編排系統(tǒng)是 Kubernetes，Mesos，Swarm。

通過比較我們選擇了 Kubernetes（簡稱 k8s），因?yàn)?Kubernetes 的設(shè)計(jì)最吸引我們，有 Google 支持，社區(qū)活躍度和發(fā)展前景俱佳。我們整個(gè)后臺(tái)系統(tǒng)基于 Kubernetes，并且已經(jīng)完全微服務(wù)化，有 80 多個(gè)微服務(wù)數(shù)百個(gè)容器在運(yùn)行。

我們?cè)趯?shí)戰(zhàn)中使用 Kubernetes 的幾點(diǎn)經(jīng)驗(yàn)如下。

1、二進(jìn)制版本和配置版本要做分離，且代碼化

微服務(wù)的配置 yaml 文件 checkin 到 git 代碼庫，而且做 binary/config 分離，分別控制二進(jìn)制和配置環(huán)境的版本，所有的線上部署的改動(dòng)都在代碼中反映出來。舉個(gè) k8s 中微服務(wù)配置的例子，如下圖。

這是我們一個(gè)微服務(wù)的 deployment 文件，我們用 git 的版本號(hào)做 docker 鏡像的 tag（jenkins 自動(dòng)打包后加上去的），docker 鏡像里只包含 binary 文件，配置文件通過 configmap 的 volume mount 為容器內(nèi)的一個(gè)目錄，而且配置文件也做了版本號(hào)控制，數(shù)據(jù)庫密碼等不走代碼，而是由集群管理員手工輸入為 kubernetes 的 secret，不留任何記錄，從而避免了敏感信息的泄露。

2、集群管理

考慮混合云上多 k8s 集群的管理需求，我們用 zone 來標(biāo)識(shí)不同數(shù)據(jù)中心的 kubernetes 集群，zone 由三個(gè)字母標(biāo)識(shí)，如下圖

通過三字母標(biāo)識(shí)法，我們將混合云部署統(tǒng)一化，極大方便了代碼和文檔中的服務(wù)標(biāo)識(shí)。

3、使用 Namespace

Kubernetes 的 namespace 極有用，我們用 production namespace 指代生產(chǎn)環(huán)境，staging 指代預(yù)發(fā)，kube-system 指代集群系統(tǒng)級(jí)別的服務(wù)比如 DNS、prometheus 監(jiān)控和報(bào)警等。

另外 k8s 也支持通過 namespace 的 node selector 來指定某個(gè)服務(wù)需要運(yùn)行在哪類機(jī)器節(jié)點(diǎn)上，這樣就可以將預(yù)發(fā)和生產(chǎn)環(huán)境運(yùn)行在不同的機(jī)器上，做到不同環(huán)境的資源隔離。

4、基于 DNS 的自動(dòng)化服務(wù)注冊(cè)、發(fā)現(xiàn)和負(fù)載均衡

通過 skyDNS 就可以將一個(gè)服務(wù)的分布在不同服務(wù)器上的 instance 命名歸一化，比如通過調(diào)用 ama-server.production.svc.k8s:20001 就可以將調(diào)用請(qǐng)求自動(dòng)路由到某個(gè)服務(wù)節(jié)點(diǎn)上，調(diào)用端不需要關(guān)心服務(wù)是怎么部署的，服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)自動(dòng)完成。

關(guān)于 Kubernetes 和微服務(wù)化還有很多細(xì)節(jié)，如果有機(jī)會(huì)再分享給大家。

三、Prometheus 和 Grafana 監(jiān)控系統(tǒng)

如果你知道 ELK，那 Prometheus+Grafana 實(shí)現(xiàn)了一套更為優(yōu)秀的數(shù)據(jù)監(jiān)控系統(tǒng)。比如我們?cè)?gRPC 服務(wù)的 /metrics 下添加了類似下面的指標(biāo)來監(jiān)控 RPC 性能：

然后 prometheus 會(huì)根據(jù) kubernetes 的配置自動(dòng)找到這些 metrics，我們?cè)O(shè)置這樣的語句進(jìn)行計(jì)算

最后在 Grafana 里通過這樣的界面展示出來：

如果你在 Google 工作過會(huì)心中竊喜，這不就是 Google 的 Borgmon 嘛！對(duì)的，Prometheus 就是由一位 xoogler 工程師寫的，參考了 Google 內(nèi)部數(shù)據(jù)監(jiān)控系統(tǒng)的設(shè)計(jì)。

這套體系和 ELK 相比較輕，且非常容易擴(kuò)展，我們寫了幾個(gè)模塊把服務(wù)日志和前端訪問記錄融合在一起做分析，同時(shí) Prometheus 指標(biāo)描述能力非常強(qiáng)大幾乎可以做任何運(yùn)算（事實(shí)上這種語言是圖靈完備的）。

四、gRPC

集群內(nèi)部服務(wù)間通訊我們用 Google 開源的 gRPC，最近出了 1.0 穩(wěn)定版。你可能聽說過無數(shù)個(gè)基于 protobuf 的 RPC 實(shí)現(xiàn)，請(qǐng)放棄它們轉(zhuǎn)用 Google 自己的 gRPC 吧。

五、Github

我們用 Github 做代碼倉庫，她的用戶分組和權(quán)限管理很有用，而且支持通過 webhook 提醒 Jenkins 完成后續(xù)的持續(xù)集成工作。

使用 Github 的另一個(gè)好處是，當(dāng)你想把一個(gè)內(nèi)部項(xiàng)目開源時(shí)，只要點(diǎn)幾個(gè)按鈕就可以了，后續(xù)開發(fā)流程不變，無縫銜接。

六、Phabricator

Facebook 的一款項(xiàng)目管理工具，我們用它做文檔中心和代碼審查工具。

七、Bearychat

非常好用的團(tuán)隊(duì)溝通工具，好到讓你想放棄郵件溝通，因?yàn)檫@比寫郵件快多了。我們建了幾十個(gè)頻道，大家分組針對(duì)特定話題做深入討論。而且 bearychat 支持機(jī)器人，可以把各種系統(tǒng)通知平滑銜接進(jìn)來，ChatOps 的利器。

八、Jenkins

我們?cè)?Jenkins 上做微服務(wù)和 iOS/Android app 的測試和打包，可以說 Jenkins 是整個(gè)持續(xù)集成的樞紐，任何的代碼改動(dòng)都可以從這里觸發(fā)后續(xù)行為，從 docker 自動(dòng)打包，到推送 bearychat 消息提醒，到服務(wù)或 app 發(fā)布等。

九、Bugtags

付費(fèi)服務(wù)，幫助我們組織測試環(huán)節(jié)的部分工作流程，避免上線前遺漏 bug fix。

十、Whiteboard

就是白板啦！我們將任務(wù)分解為原子 task，子團(tuán)隊(duì)縱切（產(chǎn)品、UED、前端、后端），任務(wù)狀態(tài)橫切（待開始、進(jìn)行中、blocked、完成），不同迭代版本使用不同顏色，每日晨會(huì)更新，進(jìn)度一目了然，“石器時(shí)代”的技術(shù)選型還是那么有效 :)

最后的話

因篇幅原因一些更細(xì)的內(nèi)容比如微服務(wù)的搭建和配置無法在這里展開，如果有機(jī)會(huì)繼續(xù)分享一些好玩的“黑科技”給大家。謝謝！

總結(jié)

以上是生活随笔為你收集整理的谈谈创业公司的技术选型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。