從零開始搭建創業公司後台技術棧

  • 2019 年 11 月 11 日
  • 筆記

在大多數創業公司，因為沒有大公司那些完善的基礎設施，需要從開源界的一個個系統和組件做選型，最終形成整個的後台技術棧。

文章乾貨過長，感謝，轉發，點在看

目錄

一、各系統組件選型

1、項目管理/Bug管理/問題管理

2、DNS

3、LB(負載均衡)

4、CDN

5、RPC框架

6、名字發現/服務發現

7、關係資料庫

8、NoSQL

9、消息中間件

10 、代 碼管理

11、持續集成

12、日誌系統

13、監控系統

14、配置系統

15、發布系統/部署系統

16、跳板機

17、機器管理

二、創業公司的選擇

1、選擇合適的語言

2、選擇合適的組件和雲服務商

3、制定流程和規範

4、自研和選型合適的輔助系統

5、選擇過程中需要思考的問題

最新粉絲福利

騰訊雲，1核2G，1年88元，3年268元，限量秒殺

說到後台技術棧，腦海中是不是浮現的是這樣一幅圖？

圖 1

有點眼暈，以上只是我們會用到的一些語言的合集，而且只是語言層面的一部分，就整個後台技術棧來說，這只是一個開始，從語言開始，還有很多很多的內容。今天要說的後台是大後台的概念，放在伺服器上的東西都屬於後台的東西，比如使用的框架，語言，資料庫，服務，作業系統等等，整個後台技術棧我的理解包括4個層面的內容：

語言：用了哪些開發語言，

如：c++/java/go/php/python/ruby等等；

組件：用了哪些組件，如：MQ組件，資料庫組件等等；

流程：怎樣的流程和規範，如：開發流程，項目流程，發布流程，監控告警流程，程式碼規範等等；

系統：系統化建設，上面的流程需要有系統來保證，如：規範發布流程的發布系統，程式碼管理系統等等；

結合以上的的4個層面的內容，整個後台技術棧的結構如圖2所示：

[圖2 後台技術棧結構]

以上的這些內容都需要我們從零開始搭建，在創業公司，沒有大公司那些完善的基礎設施，需要我們從開源界，從雲服務商甚至有些需要自己去組合，去拼裝，去開發一個適合自己的組件或系統以達成我們的目標。咱們一個個系統和組件的做選型，最終形成我們的後台技術棧。

一、各系統組件選型

1、項目管理/Bug管理/問題管理

項目管理軟體是整個業務的需求，問題，流程等等的集中地，大家的跨部門溝通協同大多依賴於項目管理工具。有一些 SAAS 的項目管理服務可以使用，但是很多時間不滿足需求，此時我們可以選擇一些開源的項目，這些項目本身有一定的訂製能力，有豐富的插件可以使用，一般的創業公司需求基本上都能得到滿足，常用的項目如下：

Redmine： 用 Ruby 開發的，有較多的插件可以使用，能自定義欄位，集成了項目管理，BUG 問題跟蹤，WIKI 等功能，不過好多插件 N 年沒有更新了;

Phabricator：用 PHP 開發的，facebook 之前的內部工具，開發這工具的哥們離職後自己搞了一個公司專門做這個軟體，集成了程式碼託管， Code Review，任務管理，文檔管理，問題跟蹤等功能，強烈推薦較敏捷的團隊使用；

Jira：用 Java 開發的，有用戶故事，task 拆分，燃盡圖等等，可以做項目管理，也可以應用於跨部門溝通場景，較強大；

悟空CRM ：這個不是項目管理，這個是客戶管理，之所以在這裡提出來，是因為在 To B 的創業公司裡面，往往是以客戶為核心來做事情的，可以將項目管理和問題跟進的在悟空 CRM 上面來做，他的開源版本已經基本實現了 CR< 的核心 功能，還帶有一個任務管理功能，用於問題跟進，不過用這個的話，還是需要另一個項目管理的軟體協助，順便說一嘴，這個系統的程式碼寫得很難維護，只能適用於客戶規模小（1萬以內）時。

2、DNS

DNS 是一個很通用的服務，創業公司基本上選擇一個合適的雲廠商就行了，中國主要是兩家：

阿里萬網：阿里 2014 年收購了萬網，整合了其域名服務，最終形成了現在的阿里萬網，其中就包含 DNS 這塊的服務；

騰訊 DNSPod: 騰訊 2012 年以 4000 萬收購 DNSPod 100% 股份，主要提供域名解析和一些防護功能；

如果你的業務是在中國，主要就是這兩家，選 一個就好，像今日頭條這樣的企業用的也是 DNSPod 的服務，除非一些特殊的原因才需要自建，比如一些 CDN 廠商，或者對區域有特殊限制的。要實惠一點用阿里最便宜的基礎版就好了，要成功率高一些，還是用DNSPod 的貴的那種。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

在國外還是選擇亞馬遜吧，阿里的 DNS 服務只有在日本和美國有節點，東南亞最近才開始部點， DNSPod 也只有美國和日本，像一些出海的企業，其選擇的雲服務基本都是亞馬遜。

如果是線上產品，DNS 強烈建議用付費版，阿里的那幾十塊錢的付費版基本可以滿足需求。如果還需要一些按省份或按區域調試的邏輯，則需要加錢，一年也就幾百塊，省錢省力。

如果是國外，優先選擇亞馬遜，如果需要中國外互通並且有自己的 APP 的話，建議還是自己實現一些容災邏輯或者智慧調度，因為沒有一個現成的 DNS 服務能同時較好的滿足中國外場景，或者用多個域名，不同的域名走不同的 DNS 。

3、LB(負載均衡)

LB(負載均衡)是一個通用服務，一般雲廠商的 LB 服務基本都會如下功能：

  • 支援四層協議請求（包括 TCP、UDP 協議）;
  • 支援七層協議請求（包括 HTTP、HTTPS 協議）;
  • 集中化的證書管理系統支援 HTTPS 協議;
  • 健康檢查;

如果你線上的服務機器都是用的雲服務，並且是在同一個雲服務商的話，可以直接使用雲服務商提供的 LB 服務，如阿里雲的 SLB，騰訊雲的 CLB， 亞馬遜 的 ELB 等等。如果是自建機房基本都是 LVS + Nginx。

4、CDN

CDN 現在已經是一個很紅很紅的市場，基本上只能掙一些辛苦錢，都是貼著成本在賣。中國以網宿為龍頭，他們家佔據整個中國市場份額的40%以上，後面就是騰訊，阿里。網宿有很大一部分是因為直播的興起而崛起。

國外，Amazon 和 Akamai 合起來佔比大概在 50%，曾經的國際市場老大 Akamai 擁有全球超一半的份額，在 Amazon CDN入局後，份額跌去了將近 20%，眾多中小企業都轉向後者，Akamai 也是無能為力。

中國出海的 CDN 廠商，更多的是為中國的出海企業服務，三家大一點的 CDN 服務商裡面也就網宿的節點多一些，但是也多不了多少。阿里和騰訊還處於前期階段，僅少部分國家有節點。

就創業公司來說，CDN 用騰訊雲或阿里雲即可，其相關係統較完善，能輕鬆接入，網宿在系統支援層面相對較弱一些，而且還貴一些。並且，當流量上來後，CDN 不能只用一家，需要用多家，不同的 CDN 在全國的節點覆蓋不一樣，而且針對不同的客戶雲廠商內部有些區分客戶集群，並不是全節點覆蓋（但有些雲廠商說自己是全網節點），除了節點覆蓋的問題，多 CDN 也在一定程度上起到容災的作用。

5、RPC框架

維基百科對 RPC 的定義是：遠程過程調用（Remote Procedure Call，RPC）是一個電腦通訊協議。該協議允許運行於一台電腦的程式調用另一台電腦的子程式，而程式設計師無需額外地為這個交互作用編程。

通俗來講，一個完整的RPC調用過程，就是 Server 端實現了一個函數，客戶端使用 RPC 框架提供的介面，調用這個函數的實現，並獲取返回值的過程。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

業界 RPC 框架大致分為兩大流派，一種側重跨語言調用，另一種是偏重服務治理。

跨語言調用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。這類 RPC 框架側重於服務的跨語言調用，能夠支援大部分的語言進行語言無關的調用，非常適合多語言調用場景。但這類框架沒有服務發現相關機制，實際使用時需要代理層進行請求轉發和負載均衡策略控制。

其中，gRPC 是 Google 開發的高性能、通用的開源 RPC 框架，其由 Google 主要面向移動應用開發並基於 HTTP/2 協議標準而設計，基於 ProtoBuf(Protocol Buffers) 序列化協議開發，且支援眾多開發語言。本身它不是分散式的，所以要實現框架的功能需要進一步的開發。

Hprose(High Performance Remote Object Service Engine) 是一個 MIT 開源許可的新型輕量級跨語言跨平台的面向對象的高性能遠程動態通訊中間件。

服務治理型的 RPC 框架的特點是功能豐富，提供高性能的遠程調用、服務發現及服務治理能力，適用於大型服務的服務解耦及服務治理，對於特定語言(Java)的項目可以實現透明化接入。缺點是語言耦合度較高，跨語言支援難度較大。中國常見的冶理型 RPC 框架如下：

Dubbo: Dubbo 是阿里巴巴公司開源的一個 Java 高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring 框架無縫集成。當年在淘寶內部，Dubbo 由於跟淘寶另一個類似的框架 HSF 有競爭關係，導致 Dubbo 團隊解散，最近又活過來了，有專職同學投入

DubboX: DubboX 是由噹噹在基於 Dubbo 框架擴展的一個 RPC 框架，支援 REST 風格的遠程調用、Kryo/FST 序列化，增加了一些新的feature。

Motan: Motan 是新浪微博開源的一個 Java 框架。它誕生的比較晚，起於 2013 年，2016 年 5 月開源。Motan 在微博平台中已經廣泛應用，每天為數百個服務完成近千億次的調用。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

rpcx: rpcx 是一個類似阿里巴巴Dubbo 和微博 Motan 的分散式的 RPC 服務框架，基於 Golang net/rpc 實現。但是 rpcx 基本只有一個人在維護，沒有完善的社區，使用前要慎重，之前做 Golang 的 RPC 選型時也有考慮這個，最終還是放棄了，選擇了 gRPC，如果想自己自研一個 RPC 框架，可以參考學習一下。

6、名字發現/服務發現

名字發現和服務發現分為兩種模式，一個是客戶端發現模式，一種是服務端發現模式。

框架中常用的服務發現是客戶端發現模式。

所謂服務端發現模式是指客戶端通過一個負載均衡器向服務發送請求，負載均衡器查詢服務註冊表並把請求路由到一台可用的服務實例上。現在常用的負載均衡器都是此類模式，常用於微服務中。

所有的名字發現和服務發現都要依賴於一個可用性非常高的服務註冊表，業界常用的服務註冊表有如下三個：

etcd，一個高可用、分散式、一致性、key-value方式的存儲，被用在分享配置和服務發現中。兩個著名的項目使用了它：k8s和Cloud Foundry。

consul，一個發現和配置服務的工具，為客戶端註冊和發現服務提供了API，Consul還可以通過執行健康檢查決定服務的可用性。

Apache Zookeeper，是一個廣泛使用、高性能的針對分散式應用的協調服務。Apache Zookeeper本來是 Hadoop 的子工程，現在已經是頂級工程了。

除此之外也可以自己實現服務實現，或者用 Redis 也行，只是需要自己實現高可用性。

7、關係資料庫

關係資料庫分為兩種，一種是傳統關係數據，如 Oracle, MySQL，Maria, DB2，PostgreSQL 等等，另一種是 NewSQL，即至少要滿足以下五點的新型關係資料庫：

1、完整地支援SQL，支援JOIN / GROUP BY /子查詢等複雜SQL查詢；

2、支援傳統數據標配的 ACID 事務，支援強隔離級別。

3、具有彈性伸縮的能力，擴容縮容對於業務層完全透明。

4、真正的高可用，異地多活、故障恢復的過程不需要人為的接入，系統能夠自動地容災和進行強一致的數據恢復。

5、具備一定的大數據分析能力

傳統關係資料庫用得最多的是 MySQL，成熟，穩定，一些基本的需求都能滿足，在一定數據量級之前基本單機傳統資料庫都可以搞定，而且現在較多的開源系統都是基於 MySQL，開箱即用，再加上主從同步和前端快取，百萬 pv 的應用都可以搞定了。不過 CentOS 7 已經放棄了 MySQL，而改使用 MariaDB。MariaDB 資料庫管理系統是 MySQ L的一個分支，主要由開源社區在維護，採用GPL 授權許可。開發這個分支的原因之一是：甲骨文公司收購了 MySQL 後，有將 MySQ L閉源的潛在風險，因此社區採用分支的方式來避開這個風險。

在 Google 發布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google』s Globally-Distributed Databasa 之後，業界開始流行起 NewSQL。於是有了 CockroachDB，於是有了 奇叔公司的 TiDB。中國已經有比較多的公司使用 TiDB，之前在創業公司時在大數據分析時已經開始應用 TiDB，當時應用的主要原因是 MySQL 要使用分庫分表，邏輯開發比較複雜，擴展性不夠。

8、NoSQL

NoSQL 顧名思義就是 Not-Only SQL，也有人說是 No – SQL, 個人偏向於Not – Only SQL,它並不是用來替代關係庫，而是作為關係型資料庫的補充而存在。

常見 NoSQL 有4個類型：

1、鍵值，適用於內容快取，適合混合工作負載並發高擴展要求大的數據集，其優點是簡單，查詢速度快，缺點是缺少結構化數據，常見的有 Redis, Memcache, BerkeleyDB 和 Voldemort 等等；

2、列式，以列簇式存儲，將同一列數據存在一起，常見於分散式的文件系統，其中以 Hbase，Cassandra 為代表。Cassandra 多用於寫多讀少的場景，中國用得比較多的有 360，大概 1500 台機器的集群，國外大規模使用的公司比較多，如 Ebay，Instagram，Apple 和沃爾瑪等等；

3、文檔，數據存儲方案非常適用承載大量不相關且結構差別很大的複雜資訊。性能介於 kv 和關係資料庫之間，它的靈感來於 lotus notes，常見的有 MongoDB，CouchDB 等等；

4、圖形，圖形資料庫擅長處理任何涉及關係的狀況。社交網路，推薦系統等。專註於構建關係圖譜，需要對整個圖做計算才能得出結果，不容易做分散式的集群方案，常見的有 Neo4J，InfoGrid 等。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

除了以上4種類型，還有一些特種的資料庫，如對象資料庫，XML 資料庫，這些都有針對性對某些存儲類型做了優化的資料庫。

在實際應用場景中，何時使用關係資料庫，何時使用 NoSQL，使用哪種類型的資料庫，這是我們在做架構選型時一個非常重要的考量，甚至會影響整個架構的方案。

9、消息中間件

消息中間件在後台系統中是必不可少的一個組件，一般我們會在以下場景中使用消息中間件：

非同步處理：非同步處理是使用消息中間件的一個主要原因，在工作中最常見的非同步場景有用戶註冊成功後需要發送註冊成功郵件、快取過期時先返回老的數據，然後非同步更新快取、非同步寫日誌等等；通過非同步處理，可以減少主流程的等待響應時間，讓非主流程或者非重要業務通過消息中間件做集中的非同步處理。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

系統解耦：比如在電商系統中，當用戶成功支付完成訂單後，需要將支付結果給通知ERP系統、發票系統、WMS、推薦系統、搜索系統、風控系統等進行業務處理；這些業務處理不需要實時處理、不需要強一致，只需要最終一致性即可，因此可以通過消息中間件進行系統解耦。通過這種系統解耦還可以應對未來不明確的系統需求。

削峰填谷：當系統遇到大流量時，監控圖上會看到一個一個的山峰樣的流量圖，通過使用消息中間件將大流量的請求放入隊列，通過消費者程式將隊列中的處理請求慢慢消化，達到消峰填谷的效果。最典型的場景是秒殺系統，在電商的秒殺系統中下單服務往往會是系統的瓶頸，因為下單需要對庫存等做資料庫操作，需要保證強一致性，此時使用消息中間件進行下單排隊和流控，讓下單服務慢慢把隊列中的單處理完，保護下單服務，以達到削峰填谷的作用。

業界消息中間件是一個非常通用的東西，大家在做選型時有使用開源的，也有自己造輪子的，甚至有直接用 MySQL 或 Redis 做隊列的，關鍵看是否滿足你的需求，如果是使用開源的項目，以下的表格在選型時可以參考：

[圖3]

以上圖的緯度為：名字 成熟度所屬社區/公司 文檔 授權方式 開發語言支援的協議 客戶端支援的語言 性能 持久化 事務 集群 負載均衡 管理介面 部署方式 評價

10 、代 碼管理

程式碼是互聯網創業公司的命脈之一，程式碼管理很重要，常見的考量點包括兩塊：

1、安全和許可權管理，將程式碼放到內網並且對於關係公司命脈的核心程式碼做嚴格的程式碼控制和機器的物理隔離；

2、程式碼管理工具，Git 作為程式碼管理的不二之選，你值得擁有。Gitlab 是當今最火的開源 Git 託管服務端，沒有之一，雖然有企業版，但是其社區版基本能滿足我們大部分需求，結合 Gerrit 做 Code review，基本就完美了。當然 Gitlab 也有程式碼對比，但沒Gerrit 直觀。Gerrit 比 Gitlab 提供了更好的程式碼檢查介面與主線管理體驗，更適合在對程式碼品質有高要求的文化下使用。

11、持續集成

持續集成簡，稱 CI(continuous integration)， 是一種軟體開發實踐，即團隊開發成員經常集成他們的工作，每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而儘早地發現集成錯誤。持續集成為研發流程提供了程式碼分支管理/比對、編譯、檢查、發布物輸出等基礎工作，為測試的覆蓋率版本編譯、生成等提供統一支援。

業界免費的持續集成工具中系統我們有如下一些選擇：

Jenkins：Java寫的 有強大的插件機制，MIT協議開源 （免費，訂製化程度高，它可以在多台機器上進行分散式地構建和負載測試）。Jenkins可以算是無所不能，基本沒有 Jenkins 做不了的，無論從小型團隊到大型團隊 Jenkins 都可以搞定。不過如果要大規模使用，還是需要有人力來學習和維護。

TeamCity： TeamCity與Jenkins相比使用更加友好，也是一個高度可訂製化的平台。但是用的人多了，TeamCity就要收費了。

Strider： Strider 是一個開源的持續集成和部署平台，使用 Node.js 實現，存儲使用的是 MongoDB，BSD 許可證，概念上類似 Travis 和Jenkins。

GitLabCI：從GitLab8.0開始，GitLab CI 就已經集成在 GitLab，我們只要在項目中添加一個 .gitlab-ci.yml 文件，然後添加一個Runner，即可進行持續集成。並且 Gitlab 與 Docker 有著非常好的相互協作的能力。免費版與付費版本不同可以參見這裡：https://about.gitlab.com/products/feature-comparison/

Travis：Travis 和 Github 強關聯；閉源程式碼使用 SaaS 還需考慮安全問題；不可訂製；開源項目免費，其它收費；

Go: Go是ThoughtWorks公司最新的Cruise Control的化身。除了 ThoughtWorks 提供的商業支援，Go是免費的。它適用於Windows，Mac和各種Linux發行版。

12、日誌系統

日誌系統一般包括打日誌，採集，中轉，收集，存儲，分析，呈現，搜索還有分發等。一些特殊的如染色，全鏈條跟蹤或者監控都可能需要依賴於日誌系統實現。日誌系統的建設不僅僅是工具的建設，還有規範和組件的建設，最好一些基本的日誌在框架和組件層面加就行了，比如全鏈接跟蹤之類的。

對於常規日誌系統ELK能滿足大部分的需求，ELK 包括如下組件：

ElasticSearch 是個開源分散式搜索引擎，它的特點有：分散式，零配置，自動發現，索引自動分片，索引副本機制，restful風格介面，多數據源，自動搜索負載等。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

Logstash 是一個完全開源的工具，它可以對你的日誌進行收集、分析，並將其存儲供以後使用。

Kibana是一個開源和免費的工具，它可以為 Logstash 和 ElasticSearch 提供的日誌分析友好的 Web 介面，可以幫助匯總、分析和搜索重要數據日誌。

Filebeat 已經完全替代了 Logstash-Forwarder 成為新一代的日誌採集器，同時鑒於它輕量、安全等特點，越來越多人開始使用它。

因為免費的 ELK 沒有任何安全機制，所以這裡使用了 Nginx 作反向代理，避免用戶直接訪問 Kibana 伺服器。加上配置 Nginx 實現簡單的用戶認證，一定程度上提高安全性。另外，Nginx 本身具有負載均衡的作用，能夠提高系統訪問性能。ELK 架構如圖4所示：

[圖4] ELK 流程圖

對於有實時計算的需求，可以使用 Flume+Kafka+Storm+MySQL方案，一 般架構如圖5所示：

[圖5] 實時分析系統架構圖

其中：

Flume 是一個分散式、可靠、和高可用的海量日誌採集、聚合和傳輸的日誌收集系統，支援在日誌系統中訂製各類數據發送方，用於收集數據;同時，Flume 提供對數據進行簡單處理，並寫到各種數據接受方(可訂製)的能力。

Kafka 是由 Apache 軟體基金會開發的一個開源流處理平台，由 Scala 和 Java 編寫。其本質上是一個「按照分散式事務日誌架構的大規模發布/訂閱消息隊列」，它以可水平擴展和高吞吐率而被廣泛使用。

Kafka 追求的是高吞吐量、高負載，Flume 追求的是數據的多樣性，二者結合起來簡直完美。

13、監控系統

監控系統只包含與後台相關的，這裡主要是兩塊，一個是作業系統層的監控，比如機器負載，IO，網路流量，CPU，記憶體等作業系統指標的監控。另一個是服務品質和業務品質的監控，比如服務的可用性，成功率，失敗率，容量，QPS 等等。常見業務的監控系統先有作業系統層面的監控（這部分較成熟），然後擴展出其它監控，如 zabbix，小米的 open-falcon，也有一出來就是兩者都支援的，如 prometheu s。如果對業務監控要求比較高一些，在創業選型中建議可以優先考慮 prometheus。這裡有一個有趣的分布，如圖6所示

[圖6 監控系統分布]

亞洲區域使用 zabbix 較多，而美洲和歐洲，以及澳大利亞使用 prometheus 居多，換句話說，英文國家地區（發達國家？）使用prometheus 較多。

Prometheus 是由 SoundCloud 開發的開源監控報警系統和時序列資料庫( TSDB )。Prometheus 使用 Go 語言開發，是 Google BorgMon 監控系統的開源版本。相對於其它監控系統使用的 push 數據的方式，prometheus 使用的是 pull 的方式，其架構如圖7所示：

[圖7] prometheus架構圖

如上圖所示，prometheus 包含的主要組件如下：

Prometheus Server 主要負責數據採集和存儲，提供 PromQL 查詢語言的支援。Server 通過配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目標。根據這些目標會，Server 定時去抓取 metric s數據，每個抓取目標需要暴露一個 http 服務的介面給它定時抓取。

客戶端SDK：官方提供的客戶端類庫有 go、java、scala、python、ruby，其他還有很多第三方開發的類庫，支援 nodejs、php、erlang 等。

Push Gateway 支援臨時性 Job 主動推送指標的中間網關。

Exporter Exporter 是Prometheus的一類數據採集組件的總稱。它負責從目標處搜集數據，並將其轉化為 Prometheus 支援的格式。與傳統的數據採集組件不同的是，它並不向中央伺服器發送數據，而是等待中央伺服器主動前來抓取。Prometheus提供多種類型的 Exporter 用於採集各種不同服務的運行狀態。目前支援的有資料庫、硬體、消息中間件、存儲系統、HTTP伺服器、JMX等。

alertmanager：是一個單獨的服務，可以支援 Prometheus 的查詢語句，提供十分靈活的報警方式。

*Prometheus *HTTP API的查詢方式，自定義所需要的輸出。

*Grafana *是一套開源的分析監視平台，支援 Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, CloudWatch 等數據源，其 UI 非常漂亮且高度訂製化。

創業公司選擇 Prometheus + Grafana 的方案，再加上統一的服務框架(如 gRPC )，可以滿足大部分中小團隊的監控需求。

14、配置系統

隨著程式功能的日益複雜，程式的配置日益增多：各種功能的開關、降級開關，灰度開關，參數的配置、伺服器的地址、資料庫配置等等，除此之外，對後台程式配置的要求也越來越高：配置修改後實時生效，灰度發布，分環境、分用戶，分集群管理配置，完善的許可權、審核機制等等，在這樣的大環境下，傳統的通過配置文件、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求，業界有如下兩種方案：

基於 zk 和 etcd，支援介面和 api ，用資料庫來保存版本歷史，預案，走審核流程，最後下發到 zk 或 etcd 這種有推送能力的存儲里（服務註冊本身也是用 zk 或 etcd，選型就一塊了）。客戶端都直接和 zk 或 etcd 打交道。至於灰度發布，各家不同，有一種實現是同時發布一個需要灰度的 IP 列表，客戶端監聽到配置節點變化時，對比一下自己是否屬於該列表。PHP 這種無狀態的語言和其他 zk/etcd 不支援的語言，只好自己在客戶端的機器上起一個 Agent 來監聽變化，再寫到配置文件或共享記憶體，如 360 的 Qconf。

基於運維自動化的配置文件的推送，審核流程，配置數據管理和方案一類似，下發時生成配置文件，基於運維自動化工具如Puppet，Ansible 推送到每個客戶端，而應用則定時重新讀取這個外部的配置文件，灰度發布在下發配置時指定IP列表。

創業公司前期不需要這種複雜，直接上 zk，弄一個介面管理 zk 的內容，記錄一下所有人的操作日誌，程式直連 zk，或者或者用Qconf 等基於 zk 優化後的方案。

15、發布系統/部署系統

從軟體生產的層面看，程式碼到最終服務的典型流程如圖8所示：

[圖8 流程圖]

從上圖中可以看出，從開發人員寫下程式碼到服務最終用戶是一個漫長過程，整體可以分成三個階段：

1、從程式碼（Code）到成品庫（Artifact）這個階段主要對開發人員的程式碼做持續構建並把構建產生的製品集中管理，是為部署系統準備輸入內容的階段。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

2、從製品到可運行服務 這個階段主要完成製品部署到指定環境，是部署系統的最基本工作內容。

3、從開發環境到最終生產環境 這個階段主要完成一次變更在不同環境的遷移，是部署系統上線最終服務的核心能力。

發布系統集成了製品管理，發布流程，許可權控制，線上環境版本變更，灰度發布，線上服務回滾等幾方面的內容，是開發人員工作結晶最終呈現的重要通道。開源的項目中沒有完全滿足的項目，如果只是 Web 類項目，Walle、Piplin 都是可用的，但是功能不太滿足，創業初期可以集成 Jenkins + Gitlab + Walle (可以考慮兩天時間完善一下)，以上方案基本包括 製品管理，發布流程，許可權控制，線上環境版本變更，灰度發布（需要自己實現），線上服務回滾等功能。

16、跳板機

跳板機面對的是需求是要有一種能滿足角色管理與授權審批、資訊資源訪問控制、操作記錄和審計、系統變更和維護控制要求，並生成一些統計報表配合管理規範來不斷提升IT內控的合規性，能對運維人員操作行為的進行控制和審計，對誤操作、違規操作導致的操作事故，快速定位原因和責任人。其功能模組一般包括：帳戶管理、認證管理、授權管理、審計管理等等

開源項目中，Jumpserver 能夠實現跳板機常見需求，如授權、用戶管理、伺服器基本資訊記錄等，同時又可批量執行腳本等功能；其中錄像回放、命令搜索、實時監控等特點，又能幫助運維人員回溯操作歷史，方便查找操作痕迹，便於管理其他人員對伺服器的操作控制。

17、機器管理

機器管理的工具選擇的考量可以包含以下三個方面：

1、是否簡單，是否需要每台機器部署agent（客戶端）

2、語言的選擇（puppet/chef vsansible/saltstack）開源技術，不看官網不足以熟練，不懂源碼不足以精通；Puppet、Chef基於Ruby開發，ansible、saltstack基於python開發的。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

3、速度的選擇(ansiblevssaltstack) ansible基於SSH協議傳輸數據，Saltstack使用消息隊列zeroMQ傳輸數據；大規模並發的能力對於幾十台-200台規模的兄弟來講，ansible的性能也可接受，如果一次操作上千台，用salt好一些

[圖9 機器管理軟體對比]

一般創業公司選擇 Ansible 能解決大部問題，其簡單，不需要安裝額外的客戶端，可以從命令行來運行，不需要使用配置文件。至於比較複雜的任務，Ansible 配置通過名為 Playbook 的配置文件中的 YAML 語法來加以處理。Playbook 還可以使用模板來擴展其功能。

二、創業公司的選擇

1、選擇合適的語言

選擇團隊熟悉的/能掌控的，創業公司人少事多，無太多冗餘讓研發團隊熟悉新的語言，能快速上手，能快速出活，出了問題能快速解決的問題的語言才是好的選擇。

選擇更現代一些的，這裡的現代是指語言本身已經完成一些之前需要特殊處理的特性，比如記憶體管理，執行緒等等。

選擇開源輪子多的或者社區活躍度高的，這個原則是為了保證在開發過程中減少投入，有穩定可靠的輪子可以使用，遇到問題可以在網上快速搜索到答案。

選擇好招人的 一門合適的語言會讓創業團隊減少招聘的成本，快速招到合適的人。

選擇能讓人有興趣的 與上面一點相關，讓人感興趣，在後面留人時有用。

2、選擇合適的組件和雲服務商

  • 選擇靠譜的雲服務商；
  • 選擇雲服務商的組件；
  • 選擇成熟的開源組件，而不是最新出的組件；
  • 選擇採用在一線互聯網公司落地並且開源的，且在社區內形成良好口碑的產品；
  • 開源社區活躍度；

選擇靠譜的雲服務商，其實這是一個偽命題，因為哪個服務商都不靠譜，他們所承諾的那些可用性問題基本上都會在你的身上發生，這裡我們還是需要自己做一些工作，比如多服務商備份，如用CDN，你一定不要只選一家，至少選兩家，一個是災備，保持後台切換的能力，另一個是多點覆蓋，不同的服務商在CDN節點上的資源是不一樣的。

選擇了雲服務商以後，就會有很多的產品你可以選擇了，比較存儲，隊列這些都會有現成的產品，這個時候就糾結了，是用呢？還是自己在雲主機上搭呢？在這裡我的建議是前期先用雲服務商的，大了後再自己搞，這樣會少掉很多運維的事情，但是這裡要多了解一下雲服務商的組件特性以及一些坑，比如他們內網會經常斷開，他們升級也會閃斷，所以在業務側要做好容錯和規避。

關於開源組件，儘可能選擇成熟的，成熟的組件經歷了時間的考驗，基本不會出大的問題，並且有成套的配套工具，出了問題在網上也可以很快的找到答案，你所遇到的坑基本上都有人踩過了。

3、制定流程和規範

  • 制定開發的規範，程式碼及程式碼分支管理規範，關鍵性程式碼僅少數人有許可權；
  • 制定發布流程規範，從發布系統落地；
  • 制定運維規範；
  • 制定資料庫操作規範，收攏資料庫操作許可權；
  • 制定告警處理流程，做到告警有人看有人處理；
  • 制定彙報機制，晨會/周報；

4、自研和選型合適的輔助系統

所有的流程和規範都需要用系統來固化，否則就是空中樓閣，如何選擇這些系統呢？對比一下選擇的語言，組件之類的，選擇一個最合適的即可。

比如項目管理的，看下自己是什麼類型的公司，開發的節奏是怎樣的，瀑布，敏捷的 按項目劃分，還是按客戶劃分等等，平時是按項目組織還是按任務組織等等。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

比如日誌系統，之前是打的文本，那麼上一個elk，規範化一些日誌組件，基本上很長一段時間內不用考慮日誌系統的問題，最多拆分一下或者擴容一下。等到組織大了，自己搞一個日誌系統。

比如程式碼管理，項目管理系統這些都放內網，安全，在互聯網公司來說，屬於命脈了，命脈的東西還是放在別人拿不到或很難拿到的地方會比較靠譜一些。

5、選擇過程中需要思考的問題

技術棧的選擇有點像做出了某種承諾，在一定的時間內這種承諾沒法改變，於是我們需要在選擇的時候有一些思考。

看前面內容，有一個詞出現了三次，合適，選擇是合適的，不是最好，也不是最新，是最合適，適合是針對當下，這種選擇是最合適的嗎？比如用 Go 這條線的東西，技術比較新，業界組件儲備夠嗎？組織內的人員儲備夠嗎？學習成本多少？寫出來的東西能滿足業務性能要求嗎？能滿足時間要求嗎？

向未來看一眼，在一年到三年內，我們需要做出改變嗎？技術棧要做根本性的改變嗎？如果組織發展很快，在 200 人，500 人時，現有的技術棧是否需要大動？

創業過程中需要考慮成本，這裡的成本不僅僅是花費多少錢，付出多少工資，有時更重要的是時間成本，很多業務在創業時大家拼的就是時間，就是一個時間窗，過了就沒你什麼事兒了。

三、基於雲的創業公司後台技術架構

結合上面內容的考量，在對一個個系統和組件的做選型之後，以雲服務為基礎，一個創業公司的後台技術架構如圖10所示：

[圖10 後台技術架構]

參考資料

http://database.51cto.com/art/201109/291781.htm

https://zh.wikipedia.org/wiki/Kafka

https://prometheus.io/docs/introduction/overview

http://deadline.top/2016/11/23/配置中心那點事

http://blog.fit2cloud.com/2016/01/26/deployment-system.html

作者：潘錦

VirMach 便宜 VPS

QNews

QNews