談談創業公司的技術選型
從公司成立第一天起，我們就以 Google 的技術標準要求團隊，鼓勵使用新技術、鼓勵重新造輪子、鼓勵全棧，同時因為業務涉及視頻、電商、社交多個領域，我們在創業環境下對微服務、DevOps、自動化測試和部署、搜索、交易、數據監控、直播技術方面的技術選型積累了一定經驗。非常高興能把這些經驗分享給各位同在創業的小伙伴。
我們的技術選型原則
技術選型對創業公司至關重要，好的選型會讓你少走彎路，產品更快推向市場，比競爭對手更快贏得客戶，獲得更多融資，有更多資源投入產品研發和市場擴展 … 如此往復形成良性循環。相反，每一個錯誤選型都會帶來巨大的技術債務，我知道一些創業公司把 demo 時的選型一直用到 A 輪甚至 B 輪，然后不得不停下業務花幾個月時間去重構整個系統。
可以說，對初創團隊的技術 leader，最重要的事情就是選擇正確的技術體系。
下面是我們技術選型的三個原則：
一、利用好創業公司技術選型的后發優勢
大公司的基礎設施往往超過 N 年沒有更新，在建立之初可能是前沿的，但很多已經遠落后社區，而且因為所謂的穩定性和技術棧的統一，不允許團隊使用最新的技術。創業了，就打開了所有的禁忌，do what the fuck you want，只要你精挑細選，總有一款工具是最適合你的。工具不僅能提高工程師的生產力，工具更定義了你的工作模式，選擇你的工具，而不是被工具選擇。
這對從大公司出來的技術 leader 尤為重要，把之前 BAT 的那套放在腦后，重新出發，你的面前就會打開一扇寶庫大門。
二、第三方付費服務很多不靠譜，小心繞開雷區
花錢買的未必就好，有時候花錢買來的是坑，還得自己填。第三方服務，小的不穩定，大的沒法訂制，提個需求都可以排到兩個月后了。這里的名單很長，特別留心那些給無線開發者提供的服務，很多不靠譜。
解決方案：讓第三方服務成為可動態配置的組件，多個服務方互備，配置而不集成。比如我們的 SMS 推送服務就使用了多個服務互備，極大降低了短信丟失率，另外可以通過配置隨時替換服務方，降低了對單一服務方的依賴。
三、自力更生、重造輪子
因為輪子是你的車最重要的組件，同時沒有哪個輪子合適裝在你的車上，你的車是獨一無二的噴氣火箭戰車。我不是說你需要重寫 MySQL 或者 CDN，而是把你的業務系統中除了網絡和存儲的組件自己開發，從交易到賬號到搜索到推送系統，網絡和存儲交給公有云并克制在這塊造輪子的沖動。
你應該重寫 leancloud，重寫 fir.im，重寫 elasticsearch，而且要在兩周內完成。如果你對此嗤之以鼻，說明你沒找到最優秀的工程師，或者是他們的野心還沒有被發動。相信我，這不難，我們已經這樣做了而且比使用外部服務更好。
創業，要有“無論什么技術我們都可以實現而且比其他人做的更好”的信念，這是創業賦予你最大的自由，抓住這個自由。
我們選擇的技術
下圖是我們后臺系統選擇的一部分技術棧：
一、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 完全可以勝任所有的后臺開發工作，而且有極高的效率和工程實現質量。
二、Kubernetes
我們是微服務的堅定踐行者，微服務技術的核心是容器編排系統，現在最流行的三個容器編排系統是 Kubernetes，Mesos，Swarm。
通過比較我們選擇了 Kubernetes（簡稱 k8s），因為 Kubernetes 的設計最吸引我們，有 Google 支持，社區活躍度和發展前景俱佳。我們整個后臺系統基于 Kubernetes，并且已經完全微服務化，有 80 多個微服務數百個容器在運行。
我們在實戰中使用 Kubernetes 的幾點經驗如下。
1、二進制版本和配置版本要做分離，且代碼化
微服務的配置 yaml 文件 checkin 到 git 代碼庫，而且做 binary/config 分離，分別控制二進制和配置環境的版本，所有的線上部署的改動都在代碼中反映出來。舉個 k8s 中微服務配置的例子，如下圖。
這是我們一個微服務的 deployment 文件，我們用 git 的版本號做 docker 鏡像的 tag（jenkins 自動打包后加上去的），docker 鏡像里只包含 binary 文件，配置文件通過 configmap 的 volume mount 為容器內的一個目錄，而且配置文件也做了版本號控制，數據庫密碼等不走代碼，而是由集群管理員手工輸入為 kubernetes 的 secret，不留任何記錄，從而避免了敏感信息的泄露。
2、集群管理
考慮混合云上多 k8s 集群的管理需求，我們用 zone 來標識不同數據中心的 kubernetes 集群，zone 由三個字母標識，如下圖
通過三字母標識法，我們將混合云部署統一化，極大方便了代碼和文檔中的服務標識。
3、使用 Namespace
Kubernetes 的 namespace 極有用，我們用 production namespace 指代生產環境，staging 指代預發，kube-system 指代集群系統級別的服務比如 DNS、prometheus 監控和報警等。
另外 k8s 也支持通過 namespace 的 node selector 來指定某個服務需要運行在哪類機器節點上，這樣就可以將預發和生產環境運行在不同的機器上，做到不同環境的資源隔離。
4、基于 DNS 的自動化服務注冊、發現和負載均衡
通過 skyDNS 就可以將一個服務的分布在不同服務器上的 instance 命名歸一化，比如通過調用 ama-server.production.svc.k8s:20001 就可以將調用請求自動路由到某個服務節點上，調用端不需要關心服務是怎么部署的，服務注冊和服務發現自動完成。
關于 Kubernetes 和微服務化還有很多細節，如果有機會再分享給大家。
三、Prometheus 和 Grafana 監控系統
如果你知道 ELK，那 Prometheus+Grafana 實現了一套更為優秀的數據監控系統。比如我們在 gRPC 服務的 /metrics 下添加了類似下面的指標來監控 RPC 性能：
然后 prometheus 會根據 kubernetes 的配置自動找到這些 metrics，我們設置這樣的語句進行計算
最后在 Grafana 里通過這樣的界面展示出來：
如果你在 Google 工作過會心中竊喜，這不就是 Google 的 Borgmon 嘛！對的，Prometheus 就是由一位 xoogler 工程師寫的，參考了 Google 內部數據監控系統的設計。
這套體系和 ELK 相比較輕，且非常容易擴展，我們寫了幾個模塊把服務日志和前端訪問記錄融合在一起做分析，同時 Prometheus 指標描述能力非常強大幾乎可以做任何運算（事實上這種語言是圖靈完備的）。
四、gRPC
集群內部服務間通訊我們用 Google 開源的 gRPC，最近出了 1.0 穩定版。你可能聽說過無數個基于 protobuf 的 RPC 實現，請放棄它們轉用 Google 自己的 gRPC 吧。
五、Github
我們用 Github 做代碼倉庫，她的用戶分組和權限管理很有用，而且支持通過 webhook 提醒 Jenkins 完成后續的持續集成工作。
使用 Github 的另一個好處是，當你想把一個內部項目開源時，只要點幾個按鈕就可以了，后續開發流程不變，無縫銜接。
六、Phabricator
非死book 的一款項目管理工具，我們用它做文檔中心和代碼審查工具。
七、Bearychat
非常好用的團隊溝通工具，好到讓你想放棄郵件溝通，因為這比寫郵件快多了。我們建了幾十個頻道，大家分組針對特定話題做深入討論。而且 bearychat 支持機器人，可以把各種系統通知平滑銜接進來，ChatOps 的利器。
八、Jenkins
我們在 Jenkins 上做微服務和 iOS/Android app 的測試和打包，可以說 Jenkins 是整個持續集成的樞紐，任何的代碼改動都可以從這里觸發后續行為，從 docker 自動打包，到推送 bearychat 消息提醒，到服務或 app 發布等。
九、Bugtags
付費服務，幫助我們組織測試環節的部分工作流程，避免上線前遺漏 bug fix。
十、Whiteboard
就是白板啦！我們將任務分解為原子 task，子團隊縱切（產品、UED、前端、后端），任務狀態橫切（待開始、進行中、blocked、完成），不同迭代版本使用不同顏色，每日晨會更新，進度一目了然，“石器時代”的技術選型還是那么有效 :)
最后的話
來自：http://mp.weixin.qq.com/s?__biz=MjM5ODIzNDQ3Mw==&mid=2649966152&idx=1&sn=af685139039907fddcd73cab2b63f03f&chksm=beca364e89bdbf5854e3e517fc49577e3d322ef0bb1cc5a38ab47f5971f1149e18462a98e261&scene=0