hi 大家好，今天要說的后臺是指服務器后臺系統(tǒng)架構，比如使用的框架，語言，數(shù)據(jù)庫，服務，操作系統(tǒng)等等。

整個后臺技術棧我的理解包括 4 個層面的內(nèi)容：

• 語言：用了哪些開發(fā)語言，如：C++/Java/Go/PHP/Python/Ruby 等等；

• 組件：用了哪些組件，如：MQ 組件，數(shù)據(jù)庫組件等等；

• 流程：怎樣的流程和規(guī)范，如：開發(fā)流程，項目流程，發(fā)布流程，監(jiān)控告警流程，代碼規(guī)范等等；

• 系統(tǒng)：系統(tǒng)化建設，上面的流程需要有系統(tǒng)來保證，如：規(guī)范發(fā)布流程的發(fā)布系統(tǒng)，代碼管理系統(tǒng)等等；

結合以上的的 4 個層面的內(nèi)容，整個后臺技術棧的結構如圖 2 所示：

后臺技術棧結構以上的這些內(nèi)容都需要我們從零開始搭建，在創(chuàng)業(yè)公司，沒有大公司那些完善的基礎設施，需要我們從開源界，從云服務商甚至有些需要自己去組合，去拼裝，去開發(fā)一個適合自己的組件或系統(tǒng)以達成我們的目標。咱們一個個系統(tǒng)和組件的做選型，最終形成我們的后臺技術棧。

各系統(tǒng)組件選型

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

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

• Redmine：用 Ruby 開發(fā)的，有較多的插件可以使用，能自定義字段，集成了項目管理，Bug 問題跟蹤，WIKI 等功能，不過好多插件 N 年沒有更新了；

• Phabricator：用 PHP 開發(fā)的，Facebook 之前的內(nèi)部工具，開發(fā)這工具的哥們離職后自己搞了一個公司專門做這個軟件，集成了代碼托管， Code Review，任務管理，文檔管理，問題跟蹤等功能，強烈推薦較敏捷的團隊使用；

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

• 悟空 CRM ：這個不是項目管理，這個是客戶管理，之所以在這里提出來，是因為在 To B 的創(chuàng)業(yè)公司里面，往往是以客戶為核心來做事情的，可以將項目管理和問題跟進的在悟空 CRM 上面來做，他的開源版本已經(jīng)基本實現(xiàn)了 CR< 的核心 功能，還帶有一個任務管理功能，用于問題跟進，不過用這個的話，還是需要另一個項目管理的軟件協(xié)助，順便說一嘴，這個系統(tǒng)的代碼寫得很難維護，只能適用于客戶規(guī)模小（1萬以內(nèi)）時。

2、DNS

DNS 是一個很通用的服務，創(chuàng)業(yè)公司基本上選擇一個合適的云廠商就行了，國內(nèi)主要是兩家：

• 阿里萬網(wǎng)：阿里 2014 年收購了萬網(wǎng)，整合了其域名服務，最終形成了現(xiàn)在的阿里萬網(wǎng)，其中就包含 DNS 這塊的服務；

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

如果你的業(yè)務是在國內(nèi)，主要就是這兩家，選 一個就好，像今日頭條這樣的企業(yè)用的也是 DNSPod 的服務，除非一些特殊的原因才需要自建，比如一些 CDN 廠商，或者對區(qū)域有特殊限制的。要實惠一點用阿里最便宜的基礎版就好了，要成功率高一些，還是用 DNSPod 的貴的那種。

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

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

如果是國外，優(yōu)先選擇亞馬遜，如果需要國內(nèi)外互通并且有自己的 APP 的話，建議還是自己實現(xiàn)一些容災邏輯或者智能調(diào)度，因為沒有一個現(xiàn)成的 DNS 服務能同時較好的滿足國內(nèi)外場景，或者用多個域名，不同的域名走不同的 DNS 。

3、LB（負載均衡）

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

• 支持四層協(xié)議請求（包括 TCP、UDP 協(xié)議）；

• 支持七層協(xié)議請求（包括 HTTP、HTTPS 協(xié)議）；

• 集中化的證書管理系統(tǒng)支持 HTTPS 協(xié)議；

• 健康檢查；

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

4、CDN

CDN 現(xiàn)在已經(jīng)是一個很紅很紅的市場，基本上只能掙一些辛苦錢，都是貼著成本在賣。國內(nèi)以網(wǎng)宿為龍頭，他們家占據(jù)整個國內(nèi)市場份額的 40% 以上，后面就是騰訊，阿里。網(wǎng)宿有很大一部分是因為直播的興起而崛起。

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

國內(nèi)出海的 CDN 廠商，更多的是為國內(nèi)的出海企業(yè)服務，三家大一點的 CDN 服務商里面也就網(wǎng)宿的節(jié)點多一些，但是也多不了多少。阿里和騰訊還處于前期階段，僅少部分國家有節(jié)點。

就創(chuàng)業(yè)公司來說，CDN 用騰訊云或阿里云即可，其相關系統(tǒng)較完善，能輕松接入，網(wǎng)宿在系統(tǒng)支持層面相對較弱一些，而且還貴一些。并且，當流量上來后，CDN 不能只用一家，需要用多家，不同的 CDN 在全國的節(jié)點覆蓋不一樣，而且針對不同的客戶云廠商內(nèi)部有些區(qū)分客戶集群，并不是全節(jié)點覆蓋（但有些云廠商說自己是全網(wǎng)節(jié)點），除了節(jié)點覆蓋的問題，多 CDN 也在一定程度上起到容災的作用。

5、RPC 框架

維基百科對 RPC 的定義是：遠程過程調(diào)用（Remote Procedure Call，RPC）是一個計算機通信協(xié)議。該協(xié)議允許運行于一臺計算機的程序調(diào)用另一臺計算機的子程序，而程序員無需額外地為這個交互作用編程。

通俗來講，一個完整的 RPC 調(diào)用過程，就是 Server 端實現(xiàn)了一個函數(shù)，客戶端使用 RPC 框架提供的接口，調(diào)用這個函數(shù)的實現(xiàn)，并獲取返回值的過程。

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

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

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

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

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

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

• DubboX：DubboX 是由當當在基于 Dubbo 框架擴展的一個 RPC 框架，支持 REST 風格的遠程調(diào)用、Kryo/FST 序列化，增加了一些新的feature。Motan：Motan 是新浪微博開源的一個 Java 框架。它誕生的比較晚，起于 2013 年，2016 年 5 月開源。Motan 在微博平臺中已經(jīng)廣泛應用，每天為數(shù)百個服務完成近千億次的調(diào)用。

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

6、名字發(fā)現(xiàn)/服務發(fā)現(xiàn)

名字發(fā)現(xiàn)和服務發(fā)現(xiàn)分為兩種模式，一個是客戶端發(fā)現(xiàn)模式，一種是服務端發(fā)現(xiàn)模式。

框架中常用的服務發(fā)現(xiàn)是客戶端發(fā)現(xiàn)模式。

所謂服務端發(fā)現(xiàn)模式是指客戶端通過一個負載均衡器向服務發(fā)送請求，負載均衡器查詢服務注冊表并把請求路由到一臺可用的服務實例上。現(xiàn)在常用的負載均衡器都是此類模式，常用于微服務中。

所有的名字發(fā)現(xiàn)和服務發(fā)現(xiàn)都要依賴于一個可用性非常高的服務注冊表，業(yè)界常用的服務注冊表有如下三個：

• etcd，一個高可用、分布式、一致性、key-value 方式的存儲，被用在分享配置和服務發(fā)現(xiàn)中。兩個著名的項目使用了它：Kubernetes 和 Cloud Foundry。

• Consul，一個發(fā)現(xiàn)和配置服務的工具，為客戶端注冊和發(fā)現(xiàn)服務提供了API，Consul還可以通過執(zhí)行健康檢查決定服務的可用性。

• Apache ZooKeeper，是一個廣泛使用、高性能的針對分布式應用的協(xié)調(diào)服務。Apache ZooKeeper 本來是 Hadoop 的子工程，現(xiàn)在已經(jīng)是頂級工程了。

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

7、關系數(shù)據(jù)庫

關系數(shù)據(jù)庫分為兩種，一種是傳統(tǒng)關系數(shù)據(jù)，如 Oracle，MySQL，Maria，DB2，PostgreSQL 等等，另一種是 NewSQL，即至少要滿足以下五點的新型關系數(shù)據(jù)庫：

完整地支持 SQL，支持 JOIN / GROUP BY /子查詢等復雜 SQL 查詢。

支持傳統(tǒng)數(shù)據(jù)標配的 ACID 事務，支持強隔離級別。

具有彈性伸縮的能力，擴容縮容對于業(yè)務層完全透明。

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

具備一定的大數(shù)據(jù)分析能力。

傳統(tǒng)關系數(shù)據(jù)庫用得最多的是 MySQL，成熟，穩(wěn)定，一些基本的需求都能滿足，在一定數(shù)據(jù)量級之前基本單機傳統(tǒng)數(shù)據(jù)庫都可以搞定，而且現(xiàn)在較多的開源系統(tǒng)都是基于 MySQL，開箱即用，再加上主從同步和前端緩存，百萬 pv 的應用都可以搞定了。不過 CentOS 7 已經(jīng)放棄了 MySQL，而改使用 MariaDB。MariaDB 數(shù)據(jù)庫管理系統(tǒng)是 MySQ L的一個分支，主要由開源社區(qū)在維護，采用 GPL 授權許可。開發(fā)這個分支的原因之一是：甲骨文公司收購了 MySQL 后，有將 MySQL 閉源的潛在風險，因此社區(qū)采用分支的方式來避開這個風險。

在 Google 發(fā)布了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 之后，業(yè)界開始流行起 NewSQL。于是有了 CockroachDB，于是有了奇叔公司的 TiDB。國內(nèi)已經(jīng)有比較多的公司使用 TiDB，之前在創(chuàng)業(yè)公司時在大數(shù)據(jù)分析時已經(jīng)開始應用 TiDB，當時應用的主要原因是 MySQL 要使用分庫分表，邏輯開發(fā)比較復雜，擴展性不夠。

8、NoSQL

NoSQL 顧名思義就是 Not-Only SQL，也有人說是 No – SQL，個人偏向于 Not-Only SQL，它并不是用來替代關系庫，而是作為關系型數(shù)據(jù)庫的補充而存在。

常見 NoSQL 有4個類型：

• 鍵值，適用于內(nèi)容緩存，適合混合工作負載并發(fā)高擴展要求大的數(shù)據(jù)集，其優(yōu)點是簡單，查詢速度快，缺點是缺少結構化數(shù)據(jù)，常見的有 Redis，Memcache，BerkeleyDB 和 Voldemort 等等；

• 列式，以列簇式存儲，將同一列數(shù)據(jù)存在一起，常見于分布式的文件系統(tǒng)，其中以 Hbase，Cassandra 為代表。Cassandra 多用于寫多讀少的場景，國內(nèi)用得比較多的有 360，大概 1500 臺機器的集群，國外大規(guī)模使用的公司比較多，如 eBay，Instagram，Apple 和沃爾瑪?shù)鹊?#xff1b;

• 文檔，數(shù)據(jù)存儲方案非常適用承載大量不相關且結構差別很大的復雜信息。性能介于 kv 和關系數(shù)據(jù)庫之間，它的靈感來于 lotus notes，常見的有 MongoDB，CouchDB 等等；

• 圖形，圖形數(shù)據(jù)庫擅長處理任何涉及關系的狀況。社交網(wǎng)絡，推薦系統(tǒng)等。專注于構建關系圖譜，需要對整個圖做計算才能得出結果，不容易做分布式的集群方案，常見的有 Neo4J，InfoGrid 等。

除了以上4種類型，還有一些特種的數(shù)據(jù)庫，如對象數(shù)據(jù)庫，XML 數(shù)據(jù)庫，這些都有針對性對某些存儲類型做了優(yōu)化的數(shù)據(jù)庫。

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

9、消息中間件

消息中間件在后臺系統(tǒng)中是必不可少的一個組件，一般我們會在以下場景中使用消息中間件：

• 異步處理：異步處理是使用消息中間件的一個主要原因，在工作中最常見的異步場景有用戶注冊成功后需要發(fā)送注冊成功郵件、緩存過期時先返回老的數(shù)據(jù)，然后異步更新緩存、異步寫日志等等；通過異步處理，可以減少主流程的等待響應時間，讓非主流程或者非重要業(yè)務通過消息中間件做集中的異步處理。

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

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

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

10、代碼管理

代碼是互聯(lián)網(wǎng)創(chuàng)業(yè)公司的命脈之一，代碼管理很重要，常見的考量點包括兩塊：

• 安全和權限管理，將代碼放到內(nèi)網(wǎng)并且對于關系公司命脈的核心代碼做嚴格的代碼控制和機器的物理隔離；

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

11、持續(xù)集成

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

業(yè)界免費的持續(xù)集成工具中系統(tǒng)我們有如下一些選擇：

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

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

• Strider：Strider 是一個開源的持續(xù)集成和部署平臺，使用 Node.js 實現(xiàn)，存儲使用的是 MongoDB，BSD 許可證，概念上類似 Travis 和Jenkins。

• GitLab CI：從GitLab 8.0開始，GitLab CI 就已經(jīng)集成在 GitLab，我們只要在項目中添加一個 .gitlab-ci.yml 文件，然后添加一個 Runner，即可進行持續(xù)集成。并且 GitLab 與 Docker 有著非常好的相互協(xié)作的能力。免費版與付費版本不同可以參見這里：https://about.gitlab.com/products/feature-comparison/。

• Travis：Travis 和 GitHub 強關聯(lián)；閉源代碼使用 SaaS 還需考慮安全問題；不可定制；開源項目免費，其它收費。

• Go：Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身。除了 ThoughtWorks 提供的商業(yè)支持，Go 是免費的。它適用于 Windows，Mac 和各種 Linux 發(fā)行版。

12、日志系統(tǒng)

日志系統(tǒng)一般包括打日志，采集，中轉，收集，存儲，分析，呈現(xiàn)，搜索還有分發(fā)等。一些特殊的如染色，全鏈條跟蹤或者監(jiān)控都可能需要依賴于日志系統(tǒng)實現(xiàn)。日志系統(tǒng)的建設不僅僅是工具的建設，還有規(guī)范和組件的建設，最好一些基本的日志在框架和組件層面加就行了，比如全鏈接跟蹤之類的。

對于常規(guī)日志系統(tǒng)ELK能滿足大部分的需求，ELK 包括如下組件：

• ElasticSearch 是個開源分布式搜索引擎，它的特點有：分布式，零配置，自動發(fā)現(xiàn)，索引自動分片，索引副本機制，RESTful 風格接口，多數(shù)據(jù)源，自動搜索負載等。

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

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

• Filebeat 已經(jīng)完全替代了 Logstash-Forwarder 成為新一代的日志采集器，同時鑒于它輕量、安全等特點，越來越多人開始使用它。

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

圖 4，ELK 流程圖

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

圖 5，實時分析系統(tǒng)架構圖

其中：

• Flume 是一個分布式、可靠、和高可用的海量日志采集、聚合和傳輸?shù)娜罩臼占到y(tǒng)，支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，Flume 提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力。

• Kafka 是由 Apache 軟件基金會開發(fā)的一個開源流處理平臺，由 Scala 和 Java 編寫。其本質(zhì)上是一個“按照分布式事務日志架構的大規(guī)模發(fā)布/訂閱消息隊列”，它以可水平擴展和高吞吐率而被廣泛使用。

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

13、監(jiān)控系統(tǒng)

監(jiān)控系統(tǒng)只包含與后臺相關的，這里主要是兩塊，一個是操作系統(tǒng)層的監(jiān)控，比如機器負載，IO，網(wǎng)絡流量，CPU，內(nèi)存等操作系統(tǒng)指標的監(jiān)控。另一個是服務質(zhì)量和業(yè)務質(zhì)量的監(jiān)控，比如服務的可用性，成功率，失敗率，容量，QPS 等等。常見業(yè)務的監(jiān)控系統(tǒng)先有操作系統(tǒng)層面的監(jiān)控（這部分較成熟），然后擴展出其它監(jiān)控，如 Zabbix，小米的 Open-Falcon，也有一出來就是兩者都支持的，如 Prometheus。如果對業(yè)務監(jiān)控要求比較高一些，在創(chuàng)業(yè)選型中建議可以優(yōu)先考慮 Prometheus。這里有一個有趣的分布，如圖6所示。

圖 6，監(jiān)控系統(tǒng)分布

亞洲區(qū)域使用 Zabbix 較多，而美洲和歐洲，以及澳大利亞使用 Prometheus 居多，換句話說，英文國家地區(qū)（發(fā)達國家？）使用 Prometheus 較多。

Prometheus 是由 SoundCloud 開發(fā)的開源監(jiān)控報警系統(tǒng)和時序列數(shù)據(jù)庫（TSDB）。Prometheus 使用 Go 語言開發(fā)，是 Google BorgMon 監(jiān)控系統(tǒng)的開源版本。相對于其它監(jiān)控系統(tǒng)使用的 push 數(shù)據(jù)的方式，Prometheus 使用的是 pull 的方式，其架構如圖 7 所示：

圖 7，Prometheus 架構圖

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

• Prometheus Server 主要負責數(shù)據(jù)采集和存儲，提供 PromQL 查詢語言的支持。Server 通過配置文件、文本文件、ZooKeeper、Consul、DNS SRV Lookup 等方式指定抓取目標。根據(jù)這些目標會，Server 定時去抓取 metrics 數(shù)據(jù)，每個抓取目標需要暴露一個 http 服務的接口給它定時抓取。

• 客戶端 SDK：官方提供的客戶端類庫有 Go、Java、Scala、Python、Ruby，其他還有很多第三方開發(fā)的類庫，支持 Nodejs、PHP、Erlang 等。

• Push Gateway 支持臨時性 Job 主動推送指標的中間網(wǎng)關。

• Exporter Exporter 是 Prometheus 的一類數(shù)據(jù)采集組件的總稱。它負責從目標處搜集數(shù)據(jù)，并將其轉化為 Prometheus 支持的格式。與傳統(tǒng)的數(shù)據(jù)采集組件不同的是，它并不向中央服務器發(fā)送數(shù)據(jù)，而是等待中央服務器主動前來抓取。Prometheus 提供多種類型的 Exporter 用于采集各種不同服務的運行狀態(tài)。目前支持的有數(shù)據(jù)庫、硬件、消息中間件、存儲系統(tǒng)、HTTP 服務器、JMX 等。

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

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

• Grafana 是一套開源的分析監(jiān)視平臺，支持 Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch 等數(shù)據(jù)源，其 UI 非常漂亮且高度定制化。

創(chuàng)業(yè)公司選擇 Prometheus + Grafana 的方案，再加上統(tǒng)一的服務框架（如 gRPC），可以滿足大部分中小團隊的監(jiān)控需求。

14、配置系統(tǒng)

隨著程序功能的日益復雜，程序的配置日益增多：各種功能的開關、降級開關，灰度開關，參數(shù)的配置、服務器的地址、數(shù)據(jù)庫配置等等，除此之外，對后臺程序配置的要求也越來越高：配置修改后實時生效，灰度發(fā)布，分環(huán)境、分用戶，分集群管理配置，完善的權限、審核機制等等，在這樣的大環(huán)境下，傳統(tǒng)的通過配置文件、數(shù)據(jù)庫等方式已經(jīng)越來越無法滿足開發(fā)人員對配置管理的需求，業(yè)界有如下兩種方案：

• 基于 zk 和 etcd，支持界面和 api ，用數(shù)據(jù)庫來保存版本歷史，預案，走審核流程，最后下發(fā)到 zk 或 etcd 這種有推送能力的存儲里（服務注冊本身也是用 zk 或 etcd，選型就一塊了）。客戶端都直接和 zk 或 etcd 打交道。至于灰度發(fā)布，各家不同，有一種實現(xiàn)是同時發(fā)布一個需要灰度的 IP 列表，客戶端監(jiān)聽到配置節(jié)點變化時，對比一下自己是否屬于該列表。PHP 這種無狀態(tài)的語言和其他 zk/etcd 不支持的語言，只好自己在客戶端的機器上起一個 Agent 來監(jiān)聽變化，再寫到配置文件或共享內(nèi)存，如 360 的 Qconf。

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

創(chuàng)業(yè)公司前期不需要這種復雜，直接上 zk，弄一個界面管理 zk 的內(nèi)容，記錄一下所有人的操作日志，程序直連 zk，或者或者用 Qconf 等基于 zk 優(yōu)化后的方案。

15、發(fā)布系統(tǒng)/部署系統(tǒng)

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

圖 8，流程圖

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

• 從代碼（Code）到成品庫（Artifact）這個階段主要對開發(fā)人員的代碼做持續(xù)構建并把構建產(chǎn)生的制品集中管理，是為部署系統(tǒng)準備輸入內(nèi)容的階段。

• 從制品到可運行服務 這個階段主要完成制品部署到指定環(huán)境，是部署系統(tǒng)的最基本工作內(nèi)容。

• 從開發(fā)環(huán)境到最終生產(chǎn)環(huán)境 這個階段主要完成一次變更在不同環(huán)境的遷移，是部署系統(tǒng)上線最終服務的核心能力。

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

16、跳板機

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

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

17、機器管理

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

是否簡單，是否需要每臺機器部署 Agent（客戶端）

語言的選擇（Puppet/Chef vs Ansible/SaltStack ）開源技術，不看官網(wǎng)不足以熟練，不懂源碼不足以精通；Puppet、Chef 基于 Ruby 開發(fā)，Ansible、SaltStack 基于 Python 開發(fā)的

速度的選擇（Ansible vs SaltStack）Ansible 基于 SSH 協(xié)議傳輸數(shù)據(jù)，SaltStack 使用消息隊列 zeroMQ 傳輸數(shù)據(jù)；大規(guī)模并發(fā)的能力對于幾十臺-200 臺規(guī)模的兄弟來講，Ansible的性能也可接受，如果一次操作上千臺，用 salt 好一些。

如圖9所示：

圖 9，機器管理軟件對比

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

技術選型

1、選擇合適的語言

• 選擇團隊熟悉的/能掌控的，創(chuàng)業(yè)公司人少事多，無太多冗余讓研發(fā)團隊熟悉新的語言，能快速上手，能快速出活，出了問題能快速解決的問題的語言才是好的選擇。

• 選擇更現(xiàn)代一些的，這里的現(xiàn)代是指語言本身已經(jīng)完成一些之前需要特殊處理的特性，比如內(nèi)存管理，線程等等。

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

• 選擇好招人的 一門合適的語言會讓創(chuàng)業(yè)團隊減少招聘的成本，快速招到合適的人。

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

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

• 選擇靠譜的云服務商；

• 選擇云服務商的組件；

• 選擇成熟的開源組件，而不是最新出的組件；

• 選擇采用在一線互聯(lián)網(wǎng)公司落地并且開源的，且在社區(qū)內(nèi)形成良好口碑的產(chǎn)品；

• 開源社區(qū)活躍度；

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

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

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

3、制定流程和規(guī)范

• 制定開發(fā)的規(guī)范，代碼及代碼分支管理規(guī)范，關鍵性代碼僅少數(shù)人有權限；

• 制定發(fā)布流程規(guī)范，從發(fā)布系統(tǒng)落地；

• 制定運維規(guī)范；

• 制定數(shù)據(jù)庫操作規(guī)范，收攏數(shù)據(jù)庫操作權限；

• 制定告警處理流程，做到告警有人看有人處理；

• 制定匯報機制，晨會/周報；

4、自研和選型合適的輔助系統(tǒng)

所有的流程和規(guī)范都需要用系統(tǒng)來固化，否則就是空中樓閣，如何選擇這些系統(tǒng)呢？參照上個章節(jié)咱們那些開源的，對比一下選擇的語言，組件之類的，選擇一個最合適的即可。

比如項目管理的，看下自己是什么類型的公司，開發(fā)的節(jié)奏是怎樣的，瀑布，敏捷的 按項目劃分，還是按客戶劃分等等，平時是按項目組織還是按任務組織等等。

比如日志系統(tǒng)，之前是打的文本，那么上一個 ELK，規(guī)范化一些日志組件，基本上很長一段時間內(nèi)不用考慮日志系統(tǒng)的問題，最多拆分一下或者擴容一下。等到組織大了，自己搞一個日志系統(tǒng)。

比如代碼管理，項目管理系統(tǒng)這些都放內(nèi)網(wǎng)，安全，在互聯(lián)網(wǎng)公司來說，屬于命脈了，命脈的東西還是放在別人拿不到或很難拿到的地方會比較靠譜一些。

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

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

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

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

需要考慮成本，這里的成本不僅僅是花費多少錢，付出多少工資，有時更重要的是時間成本，很多業(yè)務在創(chuàng)業(yè)時大家拼的就是時間，就是一個時間窗，過了就沒你什么事兒了。

- END - 看完一鍵三連在看，轉發(fā)，點贊 是對文章最大的贊賞，極客重生感謝你推薦閱讀 后端技術趨勢指南|如何選擇自己的技術方向2022新年重磅技術分享|深入理解Linux操作系統(tǒng)強烈推薦|我做系統(tǒng)架構的一些原則你好，這里是極客重生，我是阿榮，大家都叫我榮哥，從華為->外企->到互聯(lián)網(wǎng)大廠，目前是大廠資深工程師，多次獲得五星員工，多年職場經(jīng)驗，技術扎實，專業(yè)后端開發(fā)和后臺架構設計，熱愛底層技術，豐富的實戰(zhàn)經(jīng)驗，分享技術的本質(zhì)原理，希望幫助更多人蛻變重生，拿BAT大廠offer，培養(yǎng)高級工程師能力，成為技術專家，實現(xiàn)高薪夢想，期待你的關注！點擊藍字查看我的成長之路。 校招/社招/簡歷/面試技巧/大廠技術棧分析/后端開發(fā)進階/優(yōu)秀開源項目/直播分享/技術視野/實戰(zhàn)高手等,?極客星球希望成為最有技術價值星球，盡最大努力為星球的同學提供技術和成長幫助！詳情查看->極客星球求點贊，在看，分享三連

總結

以上是生活随笔為你收集整理的如何从0搭建公司的后端技术栈的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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