1 前言

說到后臺技術棧，腦海中是不是浮現(xiàn)的是這樣一幅圖藕漱？

圖?1

有點眼暈欲侮，以下只是我們會用到的一些語言的合集，而且只是語言層面的一部分肋联，就整個后臺技術棧來說威蕉，這只是一個開始，從語言開始橄仍，還有很多很多的內容韧涨。今天要說的后臺是大后臺的概念，放在服務器上的東西都屬于后臺的東西沙兰，比如使用的框架氓奈，語言，數(shù)據(jù)庫鼎天，服務舀奶，操作系統(tǒng)等等。

整個后臺技術棧我的理解包括 4 個層面的內容：

語言：用了哪些開發(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 個層面的內容拆火，整個后臺技術棧的結構如圖 2 所示：

圖2 后臺技術棧結構?

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

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

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

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

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

Phabricator：用 PHP 開發(fā)的祸憋，F(xiàn)acebook 之前的內部工具，開發(fā)這工具的哥們離職后自己搞了一個公司專門做這個軟件肖卧，集成了代碼托管蚯窥， Code Review，任務管理塞帐，文檔管理拦赠，問題跟蹤等功能茬祷，強烈推薦較敏捷的團隊使用奖地；

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

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

2仰坦、DNS

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

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

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

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

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

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

如果是國外荠瘪，優(yōu)先選擇亞馬遜，如果需要國內外互通并且有自己的 APP 的話赛惩，建議還是自己實現(xiàn)一些容災邏輯或者智能調度，因為沒有一個現(xiàn)成的 DNS 服務能同時較好的滿足國內外場景季惯，或者用多個域名隐圾，不同的域名走不同的 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)是一個很紅很紅的市場盗蟆，基本上只能掙一些辛苦錢戈二，都是貼著成本在賣。國內以網(wǎng)宿為龍頭喳资，他們家占據(jù)整個國內市場份額的 40%?以上觉吭，后面就是騰訊，阿里仆邓。網(wǎng)宿有很大一部分是因為直播的興起而崛起鲜滩。

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

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

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

5、RPC 框架

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

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

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

跨語言調用型的 RPC 框架有 Thrift漓摩、gRPC裙士、Hessian、Hprose 等管毙。這類 RPC 框架側重于服務的跨語言調用腿椎，能夠支持大部分的語言進行語言無關的調用，非常適合多語言調用場景夭咬。但這類框架沒有服務發(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 框架的特點是功能豐富尊浪，提供高性能的遠程調用匣屡、服務發(fā)現(xiàn)及服務治理能力，適用于大型服務的服務解耦及服務治理拇涤，對于特定語言(Java)的項目可以實現(xiàn)透明化接入耸采。缺點是語言耦合度較高，跨語言支持難度較大工育。國內常見的冶理型 RPC 框架如下：

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

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

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é)調服務邓梅。

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吞获。國內已經(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個類型：

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

列式痘番，以列簇式存儲，將同一列數(shù)據(jù)存在一起平痰，常見于分布式的文件系統(tǒng)汞舱，其中以 Hbase，Cassandra 為代表宗雇。Cassandra 多用于寫多讀少的場景昂芜，國內用得比較多的有 360，大概 1500?臺機器的集群赔蒲，國外大規(guī)模使用的公司比較多泌神，如 eBay良漱，Instagram，Apple 和沃爾瑪?shù)鹊龋?/p>

文檔欢际，數(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 做隊列的，關鍵看是否滿足你的需求隘擎，如果是使用開源的項目殴穴，以下的表格在選型時可以參考：

圖 3

以上圖的緯度為：名字、成熟度货葬、所屬社區(qū)/公司采幌、文檔、授權方式震桶、開發(fā)語言休傍、支持的協(xié)議、客戶端支持的語言蹲姐、性能磨取、持久化人柿、事務、集群忙厌、負載均衡凫岖、管理界面、部署方式逢净、評價哥放。

10、代碼管理

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

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

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

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ù)；同時畦贸，F(xiàn)lume 提供對數(shù)據(jù)進行簡單處理税朴，并寫到各種數(shù)據(jù)接受方（可定制）的能力。

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

Kafka 追求的是高吞吐量、高負載鼻忠，F(xiàn)lume 追求的是數(shù)據(jù)的多樣性涵但，二者結合起來簡直完美。

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

監(jiān)控系統(tǒng)只包含與后臺相關的矮瘟，這里主要是兩塊，一個是操作系統(tǒng)層的監(jiān)控塑娇，比如機器負載澈侠，IO，網(wǎng)絡流量埋酬，CPU哨啃，內存等操作系統(tǒng)指標的監(jiān)控。另一個是服務質量和業(yè)務質量的監(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)聽變化灾馒，再寫到配置文件或共享內存茎用，如 360?的 Qconf。

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

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

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

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

圖 8堪旧，流程圖?

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

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

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

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

發(fā)布系統(tǒng)集成了制品管理陨囊，發(fā)布流程弦疮，權限控制，線上環(huán)境版本變更蜘醋，灰度發(fā)布胁塞，線上服務回滾等幾方面的內容，是開發(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內控的合規(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 還可以使用模板來擴展其功能从绘。

3?創(chuàng)業(yè)公司的選擇

1秘蛇、選擇合適的語言

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

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

選擇了云服務商以后青扔，就會有很多的產(chǎn)品你可以選擇了，比較存儲翩伪，隊列這些都會有現(xiàn)成的產(chǎn)品微猖，這個時候就糾結了，是用呢缘屹？還是自己在云主機上搭呢凛剥？在這里我的建議是前期先用云服務商的，大了后再自己搞轻姿，這樣會少掉很多運維的事情犁珠，但是這里要多了解一下云服務商的組件特性以及一些坑互亮，比如他們內網(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ī)范化一些日志組件，基本上很長一段時間內不用考慮日志系統(tǒng)的問題，最多拆分一下或者擴容一下拍鲤。等到組織大了季稳，自己搞一個日志系統(tǒng)澈魄。

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

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

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

看前面內容，有一個詞出現(xiàn)了三次时迫，合適掠拳，選擇是合適的纸肉，不是最好柏肪，也不是最新烦味，是最合適，適合是針對當下柏靶，這種選擇是最合適的嗎宿礁？比如用 Go 這條線的東西蔬芥，技術比較新笔诵，業(yè)界組件儲備夠嗎乎婿？組織內的人員儲備夠嗎？學習成本多少捍靠？寫出來的東西能滿足業(yè)務性能要求嗎榨婆？能滿足時間要求嗎褒侧？

向未來看一眼，在一年到三年內统诺，我們需要做出改變嗎粮呢？技術棧要做根本性的改變嗎钞艇？如果組織發(fā)展很快香璃，在 200?人葡秒，500?人時嵌溢，現(xiàn)有的技術棧是否需要大動赖草？

創(chuàng)業(yè)過程中需要考慮成本秧骑，這里的成本不僅僅是花費多少錢，付出多少工資绒疗，有時更重要的是時間成本吓蘑，很多業(yè)務在創(chuàng)業(yè)時大家拼的就是時間磨镶，就是一個時間窗健提，過了就沒你什么事兒了私痹。

4?基于云的創(chuàng)業(yè)公司后臺技術架構

結合上面內容的考量，在對一個個系統(tǒng)和組件的做選型之后网沾，以云服務為基礎蕊爵，一個創(chuàng)業(yè)公司的后臺技術架構如圖10所示：

圖 10醋旦，后臺技術架構

參考資料[1] http://database.51cto.com/art/201109/291781.htm[2] https://zh.wikipedia.org/wiki/Kafka[3] https://prometheus.io/docs/introduction/overview/[4] http://deadline.top/2016/11/23/配置中心那點事/[5] http://blog.fit2cloud.com/2016/01/26/deployment-system.html

https://mp.weixin.qq.com/s/Dy6jkqKJMvR8Ie7XaUz_FA