[轉]從零開始搭建創業公司後臺技術棧

時間 2019-11-30

原文原文鏈接

此爲轉載文章，僅作記錄使用，方便往後查看，原文連接：http://www.phppan.com/2018/04/svr-stack/php

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

[圖1]前端

有點眼暈，以上只是咱們會用到的一些語言的合集，並且只是語言層面的一部分，就整個後臺技術棧來講，這只是一個開始，從語言開始，還有不少不少的內容。今天要說的後臺是大後臺的概念，放在服務器上的東西都屬於後臺的東西，好比使用的框架，語言，數據庫，服務，操做系統等等，整個後臺技術棧個人理解包括4個層面的內容：java

語言：用了哪些開發語言，如：c++/java/go/php/python/ruby等等；node
組件：用了哪些組件，如：MQ組件，數據庫組件等等；python
流程：怎樣的流程和規範，如：開發流程，項目流程，發佈流程，監控告警流程，代碼規範等等；c++
系統：系統化建設，上面的流程須要有系統來保證，如：規範發佈流程的發佈系統，代碼管理系統等等；git

結合以上的的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萬之內）時。

二、DNS

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

阿里萬網：阿里 2014 年收購了萬網，整合了其域名服務，最終造成了如今的阿里萬網，其中就包含 DNS 這塊的服務；
騰訊 DNSPod: 騰訊 2012 年以 4000 萬收購 DNSPod 100% 股份，主要提供域名解析和一些防禦功能；

若是你的業務是在國內，主要就是這兩家，選一個就好，像今日頭條這樣的企業用的也是 DNSPod 的服務，除非一些特殊的緣由才須要自建，好比一些 CDN 廠商，或者對區域有特殊限制的。要實惠一點用阿里最便宜的基礎版就行了，要成功率高一些，仍是用DNSPod 的貴的那種。

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

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

若是是國外，優先選擇亞馬遜，若是須要國內外互通而且有本身的 APP 的話，建議仍是本身實現一些容災邏輯或者智能調度，由於沒有一個現成的 DNS 服務能同時較好的知足國內外場景，或者用多個域名，不一樣的域名走不一樣的 DNS 。

三、LB(負載均衡)

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

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

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

四、CDN

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

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

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

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

五、RPC框架

維基百科對 RPC 的定義是：遠程過程調用（Remote Procedure Call，RPC）是一個計算機通訊協議。該協議容許運行於一臺計算機的程序調用另外一臺計算機的子程序，而程序員無需額外地爲這個交互做用編程。

通俗來說，一個完整的RPC調用過程，就是 Server 端實現了一個函數，客戶端使用 RPC 框架提供的接口，調用這個函數的實現，並獲取返回值的過程。

業界 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 在微博平臺中已經普遍應用，天天爲數百個服務完成近千億次的調用。
rpcx: rpcx 是一個相似阿里巴巴Dubbo 和微博 Motan 的分佈式的 RPC 服務框架，基於 Golang net/rpc 實現。可是 rpcx 基本只有一我的在維護，沒有完善的社區，使用前要慎重，以前作 Golang 的 RPC 選型時也有考慮這個，最終仍是放棄了，選擇了 gRPC，若是想本身自研一個 RPC 框架，能夠參考學習一下。

六、名字發現/服務發現

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

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

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

全部的名字發現和服務發現都要依賴於一個可用性很是高的服務註冊表，業界經常使用的服務註冊表有以下三個：

etcd，一個高可用、分佈式、一致性、key-value方式的存儲，被用在分享配置和服務發現中。兩個著名的項目使用了它：k8s和Cloud Foundry。
consul，一個發現和配置服務的工具，爲客戶端註冊和發現服務提供了API，Consul還能夠經過執行健康檢查決定服務的可用性。
Apache Zookeeper，是一個普遍使用、高性能的針對分佈式應用的協調服務。Apache Zookeeper原本是 Hadoop 的子工程，如今已是頂級工程了。

除此以外也能夠本身實現服務實現，或者用 Redis 也行，只是須要本身實現高可用性。

七、關係數據庫

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

完整地支持SQL，支持JOIN / GROUP BY /子查詢等複雜SQL查詢；
支持傳統數據標配的 ACID 事務，支持強隔離級別。
具備彈性伸縮的能力，擴容縮容對於業務層徹底透明。
真正的高可用，異地多活、故障恢復的過程不須要人爲的接入，系統可以自動地容災和進行強一致的數據恢復。
具有必定的大數據分析能力

傳統關係數據庫用得最多的是 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 要使用分庫分表，邏輯開發比較複雜，擴展性不夠。

八、NoSQL

NoSQL 顧名思義就是 Not-Only SQL，也有人說是 No – SQL, 我的偏向於Not – Only SQL,它並非用來替代關係庫，而是做爲關係型數據庫的補充而存在。

常見 NoSQL 有4個類型：

鍵值，適用於內容緩存，適合混合工做負載併發高擴展要求大的數據集，其優勢是簡單，查詢速度快，缺點是缺乏結構化數據，常見的有 Redis, Memcache, BerkeleyDB 和 Voldemort 等等；
列式，以列簇式存儲，將同一列數據存在一塊兒，常見於分佈式的文件系統，其中以 Hbase，Cassandra 爲表明。Cassandra 多用於寫多讀少的場景，國內用得比較多的有 360，大概 1500 臺機器的集羣，國外大規模使用的公司比較多，如 Ebay，Instagram，Apple 和沃爾瑪等等；
文檔，數據存儲方案很是適用承載大量不相關且結構差異很大的複雜信息。性能介於 kv 和關係數據庫之間，它的靈感來於 lotus notes，常見的有 MongoDB，CouchDB 等等；
圖形，圖形數據庫擅長處理任何涉及關係的情況。社交網絡，推薦系統等。專一於構建關係圖譜，須要對整個圖作計算才能得出結果，不容易作分佈式的集羣方案，常見的有 Neo4J，InfoGrid 等。

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

在實際應用場景中，什麼時候使用關係數據庫，什麼時候使用 NoSQL，使用哪一種類型的數據庫，這是咱們在作架構選型時一個很是重要的考量，甚至會影響整個架構的方案。

九、消息中間件

消息中間件在後臺系統中是必不可少的一個組件，通常咱們會在如下場景中使用消息中間件：

異步處理：異步處理是使用消息中間件的一個主要緣由，在工做中最多見的異步場景有用戶註冊成功後須要發送註冊成功郵件、緩存過時時先返回老的數據，而後異步更新緩存、異步寫日誌等等；經過異步處理，能夠減小主流程的等待響應時間，讓非主流程或者非重要業務經過消息中間件作集中的異步處理。
系統解耦：好比在電商系統中，當用戶成功支付完成訂單後，須要將支付結果給通知ERP系統、發票系統、WMS、推薦系統、搜索系統、風控系統等進行業務處理；這些業務處理不須要實時處理、不須要強一致，只須要最終一致性便可，所以能夠經過消息中間件進行系統解耦。經過這種系統解耦還能夠應對將來不明確的系統需求。
削峯填谷：當系統遇到大流量時，監控圖上會看到一個一個的山峯樣的流量圖，經過使用消息中間件將大流量的請求放入隊列，經過消費者程序將隊列中的處理請求慢慢消化，達到消峯填谷的效果。最典型的場景是秒殺系統，在電商的秒殺系統中下單服務每每會是系統的瓶頸，由於下單須要對庫存等作數據庫操做，須要保證強一致性，此時使用消息中間件進行下單排隊和流控，讓下單服務慢慢把隊列中的單處理完，保護下單服務，以達到削峯填谷的做用。

業界消息中間件是一個很是通用的東西，你們在作選型時有使用開源的，也有本身造輪子的，甚至有直接用 MySQL 或 Redis 作隊列的，關鍵看是否知足你的需求，若是是使用開源的項目，如下的表格在選型時能夠參考：

[圖3]

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

10 、代碼管理

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

安全和權限管理，將代碼放到內網而且對於關係公司命脈的核心代碼作嚴格的代碼控制和機器的物理隔離；
代碼管理工具，Git 做爲代碼管理的不二之選，你值得擁有。Gitlab 是當今最火的開源 Git 託管服務端，沒有之一，雖然有企業版，可是其社區版基本能知足咱們大部分需求，結合 Gerrit 作 Code review，基本就完美了。固然 Gitlab 也有代碼對比，但沒Gerrit 直觀。Gerrit 比 Gitlab 提供了更好的代碼檢查界面與主線管理體驗，更適合在對代碼質量有高要求的文化下使用。

十一、持續集成

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

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

Jenkins：Jjava寫的有強大的插件機制，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發行版。

十二、日誌系統

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

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

ElasticSearch 是個開源分佈式搜索引擎，它的特色有：分佈式，零配置，自動發現，索引自動分片，索引副本機制，restful風格接口，多數據源，自動搜索負載等。
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 追求的是數據的多樣性，兩者結合起來簡直完美。

1三、監控系統

監控系統只包含與後臺相關的，這裏主要是兩塊，一個是操做系統層的監控，好比機器負載，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 )，能夠知足大部分中小團隊的監控需求。

1四、配置系統

隨着程序功能的日益複雜，程序的配置日益增多：各類功能的開關、降級開關，灰度開關，參數的配置、服務器的地址、數據庫配置等等，除此以外，對後臺程序配置的要求也愈來愈高：配置修改後實時生效，灰度發佈，分環境、分用戶，分集羣管理配置，完善的權限、審覈機制等等，在這樣的大環境下，傳統的經過配置文件、數據庫等方式已經愈來愈沒法知足開發人員對配置管理的需求，業界有以下兩種方案：

基於 zk 和 etcd，支持界面和 api ，用數據庫來保存版本歷史，預案，走審覈流程，最後下發到 zk 或 etcd 這種有推送能力的存儲裏（服務註冊自己也是用 zk 或 etcd，選型就一塊了）。客戶端都直接和 zk 或 etcd 打交道。至於灰度發佈，各家不一樣，有一種實現是同時發佈一個須要灰度的 IP 列表，客戶端監聽到配置節點變化時，對比一下本身是否屬於該列表。PHP 這種無狀態的語言和其餘 zk/etcd 不支持的語言，只好本身在客戶端的機器上起一個 Agent 來監聽變化，再寫到配置文件或共享內存，如 360 的 Qconf。
基於運維自動化的配置文件的推送，審覈流程，配置數據管理和方案一相似，下發時生成配置文件，基於運維自動化工具如Puppet，Ansible 推送到每一個客戶端，而應用則定時從新讀取這個外部的配置文件，灰度發佈在下發配置時指定IP列表。

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

1五、發佈系統/部署系統

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

[圖8 流程圖]

從上圖中能夠看出，從開發人員寫下代碼到服務最終用戶是一個漫長過程，總體能夠分紅三個階段：

從代碼（Code）到成品庫（Artifact）這個階段主要對開發人員的代碼作持續構建並把構建產生的製品集中管理，是爲部署系統準備輸入內容的階段。
從製品到可運行服務這個階段主要完成製品部署到指定環境，是部署系統的最基本工做內容。
從開發環境到最終生產環境這個階段主要完成一次變動在不一樣環境的遷移，是部署系統上線最終服務的核心能力。

發佈系統集成了製品管理，發佈流程，權限控制，線上環境版本變動，灰度發佈，線上服務回滾等幾方面的內容，是開發人員工做結晶最終呈現的重要通道。開源的項目中沒有徹底知足的項目，若是隻是 Web 類項目，Walle、Piplin 都是可用的，可是功能不太知足，創業初期能夠集成 Jenkins + Gitlab + Walle (能夠考慮兩天時間完善一下)，以上方案基本包括製品管理，發佈流程，權限控制，線上環境版本變動，灰度發佈（須要本身實現），線上服務回滾等功能。

1六、跳板機

跳板機面對的是需求是要有一種能知足角色管理與受權審批、信息資源訪問控制、操做記錄和審計、系統變動和維護控制要求，並生成一些統計報表配合管理規範來不斷提高IT內控的合規性，能對運維人員操做行爲的進行控制和審計，對誤操做、違規操做致使的操做事故，快速定位緣由和責任人。其功能模塊通常包括：賬戶管理、認證管理、受權管理、審計管理等等

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

1七、機器管理

機器管理的工具選擇的考量能夠包含如下三個方面：

是否簡單，是否須要每臺機器部署agent（客戶端）
語言的選擇（puppet/chef vsansible/saltstack）開源技術，不看官網不足以熟練，不懂源碼不足以精通；Puppet、Chef基於Ruby開發，ansible、saltstack基於python開發的
速度的選擇(ansiblevssaltstack) ansible基於SSH協議傳輸數據，Saltstack使用消息隊列zeroMQ傳輸數據；大規模併發的能力對於幾十臺-200臺規模的兄弟來說，ansible的性能也可接受，若是一次操做上千臺，用salt好一些。

如圖9所示：

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

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

2、創業公司的選擇

一、選擇合適的語言

選擇團隊熟悉的/能掌控的，創業公司人少事多，無太多冗餘讓研發團隊熟悉新的語言，能快速上手，能快速出活，出了問題能快速解決的問題的語言纔是好的選擇。
選擇更現代一些的，這裏的現代是指語言自己已經完成一些以前須要特殊處理的特性，好比內存管理，線程等等。
選擇開源輪子多的或者社區活躍度高的，這個原則是爲了保證在開發過程當中減小投入，有穩定可靠的輪子可使用，遇到問題能夠在網上快速搜索到答案。
選擇好招人的一門合適的語言會讓創業團隊減小招聘的成本，快速招到合適的人。
選擇能讓人有興趣的與上面一點相關，讓人感興趣，在後面留人時有用。

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

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

選擇靠譜的雲服務商，其實這是一個僞命題，由於哪一個服務商都不靠譜，他們所承諾的那些可用性問題基本上都會在你的身上發生，這裏咱們仍是須要本身作一些工做，好比多服務商備份，如用CDN，你必定不要只選一家，至少選兩家，一個是災備，保持後臺切換的能力，另外一個是多點覆蓋，不一樣的服務商在CDN節點上的資源是不同的。

選擇了雲服務商之後，就會有不少的產品你能夠選擇了，比較存儲，隊列這些都會有現成的產品，這個時候就糾結了，是用呢？仍是本身在雲主機上搭呢？在這裏個人建議是前期先用雲服務商的，大了後再本身搞，這樣會少掉不少運維的事情，可是這裏要多瞭解一下雲服務商的組件特性以及一些坑，好比他們內網會常常斷開，他們升級也會閃斷，因此在業務側要作好容錯和規避。

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