作者：潘錦
編輯：陶家龍届搁、孫淑娟
出處：本文轉(zhuǎn)載自微信公眾號(hào)：架構(gòu)與遠(yuǎn)方
在大多數(shù)創(chuàng)業(yè)公司缘薛，因?yàn)闆]有大公司那些完善的基礎(chǔ)設(shè)施窍育，需要從開源界的一個(gè)個(gè)系統(tǒng)和組件做選型，最終形成整個(gè)的后臺(tái)技術(shù)棧掩宜。
說到后臺(tái)技術(shù)棧蔫骂，腦海中是不是浮現(xiàn)的下面這樣一幅圖？
有點(diǎn)眼暈牺汤，以下只是我們會(huì)用到的一些語言的合集辽旋，而且只是語言層面的一部分，就整個(gè)后臺(tái)技術(shù)棧來說檐迟，這只是一個(gè)開始补胚，從語言開始，還有很多很多的內(nèi)容追迟。
今天要說的后臺(tái)是大后臺(tái)的概念溶其，放在服務(wù)器上的東西都屬于后臺(tái)的東西，比如使用的框架敦间，語言瓶逃，數(shù)據(jù)庫，服務(wù)廓块，操作系統(tǒng)等等厢绝。
整個(gè)后臺(tái)技術(shù)棧，我的理解包括四個(gè)層面的內(nèi)容：
語言：用了哪些開發(fā)語言带猴，如：C++/Java/Go/PHP/Python/Ruby 等等昔汉。
組件：用了哪些組件，如：MQ 組件拴清，數(shù)據(jù)庫組件等等靶病。
流程：怎樣的流程和規(guī)范，如：開發(fā)流程口予，項(xiàng)目流程娄周，發(fā)布流程，監(jiān)控告警流程沪停，代碼規(guī)范等等昆咽。
系統(tǒng)：系統(tǒng)化建設(shè)，上面的流程需要有系統(tǒng)來保證牙甫，如：規(guī)范發(fā)布流程的發(fā)布系統(tǒng)掷酗，代碼管理系統(tǒng)等等样屠。
結(jié)合以上的的 4 個(gè)層面的內(nèi)容漓穿，整個(gè)后臺(tái)技術(shù)棧的結(jié)構(gòu)如圖 2 所示：
以上的這些內(nèi)容都需要我們從零開始搭建，在創(chuàng)業(yè)公司俗孝，沒有大公司那些完善的基礎(chǔ)設(shè)施且轨，需要我們從開源界浮声，從云服務(wù)商甚至有些需要自己去組合虚婿，去拼裝，去開發(fā)一個(gè)適合自己的組件或系統(tǒng)以達(dá)成我們的目標(biāo)泳挥。
咱們一個(gè)個(gè)系統(tǒng)和組件的做選型然痊，最終形成我們的后臺(tái)技術(shù)棧。
各系統(tǒng)組件選型
項(xiàng)目管理/Bug 管理/問題管理
項(xiàng)目管理軟件是整個(gè)業(yè)務(wù)的需求屉符，問題剧浸，流程等等的集中地，大家的跨部門溝通協(xié)同大多依賴于項(xiàng)目管理工具矗钟。
有一些 SaaS 的項(xiàng)目管理服務(wù)可以使用唆香，但是很多時(shí)間不滿足需求，此時(shí)我們可以選擇一些開源的項(xiàng)目吨艇，這些項(xiàng)目本身有一定的定制能力躬它，有豐富的插件可以使用。
一般的創(chuàng)業(yè)公司需求基本上都能得到滿足东涡，常用的項(xiàng)目如下：
Redmine：用 Ruby 開發(fā)的冯吓，有較多的插件可以使用，能自定義字段疮跑，集成了項(xiàng)目管理组贺，Bug 問題跟蹤，WiKi 等功能祸挪，不過好多插件 N 年沒有更新了。
Phabricator：用 PHP 開發(fā)的贞间，F(xiàn)acebook 之前的內(nèi)部工具贿条，開發(fā)這工具的哥們離職后自己搞了一個(gè)公司專門做這個(gè)軟件，集成了代碼托管增热， Code Review整以，任務(wù)管理，文檔管理峻仇，問題跟蹤等功能公黑，強(qiáng)烈推薦較敏捷的團(tuán)隊(duì)使用。
Jira：用 Java 開發(fā)的摄咆，有用戶故事凡蚜，Task 拆分，燃盡圖等等吭从，可以做項(xiàng)目管理朝蜘，也可以應(yīng)用于跨部門溝通場(chǎng)景，較強(qiáng)大涩金。
-
悟空 CRM ：這個(gè)不是項(xiàng)目管理谱醇，這個(gè)是客戶管理暇仲，之所以在這里提出來，是因?yàn)樵?To B 的創(chuàng)業(yè)公司里面副渴，往往是以客戶為核心來做事情的奈附，可以將項(xiàng)目管理和問題跟進(jìn)的在悟空 CRM 上面來做。
它的開源版本已經(jīng)基本實(shí)現(xiàn)了 CRM 的核心功能煮剧，還帶有一個(gè)任務(wù)管理功能斥滤，用于問題跟進(jìn)，不過用這個(gè)的話轿秧，還是需要另一個(gè)項(xiàng)目管理的軟件協(xié)助中跌，順便說一嘴，這個(gè)系統(tǒng)的代碼寫得很難維護(hù)菇篡，只能適用于客戶規(guī)模袖龇（1 萬以內(nèi)）時(shí)。
DNS
DNS 是一個(gè)很通用的服務(wù)驱还，創(chuàng)業(yè)公司基本上選擇一個(gè)合適的云廠商就行了嗜暴，國內(nèi)主要是兩家：
阿里萬網(wǎng)：阿里 2014 年收購了萬網(wǎng)，整合了其域名服務(wù)议蟆，最終形成了現(xiàn)在的阿里萬網(wǎng)闷沥，其中就包含 DNS 這塊的服務(wù)。
騰訊 DNSPod：騰訊 2012 年以 4000 萬收購 DNSPod 100% 股份咐容，主要提供域名解析和一些防護(hù)功能舆逃。
如果你的業(yè)務(wù)是在國內(nèi)，主要就是這兩家戳粒，選 一個(gè)就好路狮，像今日頭條這樣的企業(yè)用的也是 DNSPod 的服務(wù)，除非一些特殊的原因才需要自建蔚约，比如一些 CDN 廠商奄妨，或者對(duì)區(qū)域有特殊限制的。
要實(shí)惠一點(diǎn)用阿里最便宜的基礎(chǔ)版就好了苹祟，要成功率高一些砸抛，還是用 DNSPod 的貴的那種。
在國外還是選擇亞馬遜吧树枫，阿里的 DNS 服務(wù)只有在日本和美國有節(jié)點(diǎn)直焙，東南亞最近才開始部點(diǎn)，DNSPod 也只有美國和日本砂轻，像一些出海的企業(yè)箕般，其選擇的云服務(wù)基本都是亞馬遜。
如果是線上產(chǎn)品舔清，DNS 強(qiáng)烈建議用付費(fèi)版丝里，阿里的那幾十塊錢的付費(fèi)版基本可以滿足需求曲初。
如果還需要一些按省份或按區(qū)域調(diào)試的邏輯，則需要加錢杯聚，一年也就幾百塊臼婆，省錢省力。
如果是國外幌绍，優(yōu)先選擇亞馬遜颁褂，如果需要國內(nèi)外互通并且有自己的 App 的話，建議還是自己實(shí)現(xiàn)一些容災(zāi)邏輯或者智能調(diào)度傀广。
因?yàn)闆]有一個(gè)現(xiàn)成的 DNS 服務(wù)能同時(shí)較好的滿足國內(nèi)外場(chǎng)景颁独，或者用多個(gè)域名，不同的域名走不同的 DNS 伪冰。
LB（負(fù)載均衡）
LB（負(fù)載均衡）是一個(gè)通用服務(wù)誓酒，一般云廠商的 LB 服務(wù)基本都有如下功能：
支持四層協(xié)議請(qǐng)求（包括 TCP、UDP 協(xié)議）
支持七層協(xié)議請(qǐng)求（包括 HTTP贮聂、HTTPS 協(xié)議）
集中化的證書管理系統(tǒng)支持 HTTPS 協(xié)議
健康檢查
如果你線上的服務(wù)機(jī)器都是用的云服務(wù)靠柑，并且是在同一個(gè)云服務(wù)商的話，可以直接使用云服務(wù)商提供的 LB 服務(wù)吓懈，如阿里云的 SLB歼冰，騰訊云的 CLB，亞馬遜的 ELB 等等耻警。如果是自建機(jī)房基本都是 LVS + Nginx隔嫡。
CDN
CDN 現(xiàn)在已經(jīng)是一個(gè)很紅很紅的市場(chǎng)，基本上只能掙一些辛苦錢甘穿，都是貼著成本在賣腮恩。
國內(nèi)以網(wǎng)宿為龍頭，他們家占據(jù)整個(gè)國內(nèi)市場(chǎng)份額的 40% 以上扒磁，后面就是騰訊庆揪，阿里式曲。網(wǎng)宿有很大一部分是因?yàn)橹辈サ呐d起而崛起妨托。
國外，Amazon 和 Akamai 合起來占比大概在 50%吝羞，曾經(jīng)的國際市場(chǎng)老大 Akamai 擁有全球超一半的份額兰伤，在 Amazon CDN入局后，份額跌去了將近 20%钧排，眾多中小企業(yè)都轉(zhuǎn)向后者敦腔，Akamai 也是無能為力。
國內(nèi)出海的 CDN 廠商恨溜，更多的是為國內(nèi)的出海企業(yè)服務(wù)符衔，三家大一點(diǎn)的 CDN 服務(wù)商里面也就網(wǎng)宿的節(jié)點(diǎn)多一些找前，但是也多不了多少。阿里和騰訊還處于前期階段判族，僅少部分國家有節(jié)點(diǎn)躺盛。
就創(chuàng)業(yè)公司來說，CDN 用騰訊云或阿里云即可形帮，其相關(guān)系統(tǒng)較完善槽惫，能輕松接入，網(wǎng)宿在系統(tǒng)支持層面相對(duì)較弱一些辩撑，而且還貴一些界斜。
并且，當(dāng)流量上來后合冀，CDN 不能只用一家各薇，需要用多家，不同的 CDN 在全國的節(jié)點(diǎn)覆蓋不一樣水慨。
而且針對(duì)不同的客戶云廠商內(nèi)部有些區(qū)分客戶集群得糜，并不是全節(jié)點(diǎn)覆蓋（但有些云廠商說自己是全網(wǎng)節(jié)點(diǎn)），除了節(jié)點(diǎn)覆蓋的問題晰洒，多 CDN 也在一定程度上起到容災(zāi)的作用朝抖。
RPC 框架
維基百科對(duì) RPC 的定義是：遠(yuǎn)程過程調(diào)用（Remote Procedure Call，RPC）是一個(gè)計(jì)算機(jī)通信協(xié)議谍珊。
該協(xié)議允許運(yùn)行于一臺(tái)計(jì)算機(jī)的程序調(diào)用另一臺(tái)計(jì)算機(jī)的子程序治宣，而程序員無需額外地為這個(gè)交互作用編程。
通俗來講砌滞，一個(gè)完整的 RPC 調(diào)用過程侮邀，就是 Server 端實(shí)現(xiàn)了一個(gè)函數(shù)，客戶端使用 RPC 框架提供的接口贝润，調(diào)用這個(gè)函數(shù)的實(shí)現(xiàn)绊茧，并獲取返回值的過程。
業(yè)界 RPC 框架大致分為兩大流派打掘，一種側(cè)重跨語言調(diào)用华畏，另一種是偏重服務(wù)治理。
跨語言調(diào)用型的 RPC 框架有 Thrift尊蚁、gRPC亡笑、Hessian、Hprose 等横朋。這類 RPC 框架側(cè)重于服務(wù)的跨語言調(diào)用仑乌，能夠支持大部分的語言進(jìn)行語言無關(guān)的調(diào)用，非常適合多語言調(diào)用場(chǎng)景。
但這類框架沒有服務(wù)發(fā)現(xiàn)相關(guān)機(jī)制晰甚，實(shí)際使用時(shí)需要代理層進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)和負(fù)載均衡策略控制衙传。
其中，gRPC 是 Google 開發(fā)的高性能厕九、通用的開源 RPC 框架粪牲，其由 Google 主要面向移動(dòng)應(yīng)用開發(fā)并基于 HTTP/2 協(xié)議標(biāo)準(zhǔn)而設(shè)計(jì)，基于 ProtoBuf（Protocol Buffers）序列化協(xié)議開發(fā)止剖，且支持眾多開發(fā)語言腺阳。本身它不是分布式的，所以要實(shí)現(xiàn)框架的功能需要進(jìn)一步的開發(fā)穿香。
Hprose（High Performance Remote Object Service Engine）是一個(gè) MIT 開源許可的新型輕量級(jí)跨語言跨平臺(tái)的面向?qū)ο蟮母咝阅苓h(yuǎn)程動(dòng)態(tài)通訊中間件亭引。
服務(wù)治理型的 RPC 框架的特點(diǎn)是功能豐富，提供高性能的遠(yuǎn)程調(diào)用皮获、服務(wù)發(fā)現(xiàn)及服務(wù)治理能力焙蚓，適用于大型服務(wù)的服務(wù)解耦及服務(wù)治理洒宝，對(duì)于特定語言(Java)的項(xiàng)目可以實(shí)現(xiàn)透明化接入购公。
缺點(diǎn)是語言耦合度較高，跨語言支持難度較大。國內(nèi)常見的冶理型 RPC 框架如下：
-
Dubbo：Dubbo 是阿里巴巴公司開源的一個(gè) Java 高性能優(yōu)秀的服務(wù)框架父能，使得應(yīng)用可通過高性能的 RPC 實(shí)現(xiàn)服務(wù)的輸出和輸入功能溉委，可以和 Spring 框架無縫集成。
當(dāng)年在淘寶內(nèi)部絮爷，Dubbo 由于跟淘寶另一個(gè)類似的框架 HSF 有競(jìng)爭(zhēng)關(guān)系，導(dǎo)致 Dubbo 團(tuán)隊(duì)解散，最近又活過來了，有專職同學(xué)投入。
-
DubboX：DubboX 是由當(dāng)當(dāng)在基于 Dubbo 框架擴(kuò)展的一個(gè) RPC 框架，支持 REST 風(fēng)格的遠(yuǎn)程調(diào)用、Kryo/FST 序列化，增加了一些新的 feature驶臊。
Motan：Motan 是新浪微博開源的一個(gè) Java 框架。它誕生的比較晚，起于 2013 年绰垂，2016 年 5 月開源。Motan 在微博平臺(tái)中已經(jīng)廣泛應(yīng)用纯赎，每天為數(shù)百個(gè)服務(wù)完成近千億次的調(diào)用纺酸。
-
RPCX：RPCX 是一個(gè)類似阿里巴巴 Dubbo 和微博 Motan 的分布式的 RPC 服務(wù)框架，基于 Golang NET/RPC 實(shí)現(xiàn)址否。
但是 RPCX 基本只有一個(gè)人在維護(hù)餐蔬，沒有完善的社區(qū)，使用前要慎重佑附，之前做 Golang 的 RPC 選型時(shí)也有考慮這個(gè)樊诺，最終還是放棄了，選擇了 gRPC音同，如果想自己自研一個(gè) RPC 框架词爬，可以參考學(xué)習(xí)一下。
名字發(fā)現(xiàn)/服務(wù)發(fā)現(xiàn)
名字發(fā)現(xiàn)和服務(wù)發(fā)現(xiàn)分為兩種模式权均，一個(gè)是客戶端發(fā)現(xiàn)模式顿膨，一種是服務(wù)端發(fā)現(xiàn)模式∵瓷蓿框架中常用的服務(wù)發(fā)現(xiàn)是客戶端發(fā)現(xiàn)模式恋沃。
所謂服務(wù)端發(fā)現(xiàn)模式是指客戶端通過一個(gè)負(fù)載均衡器向服務(wù)發(fā)送請(qǐng)求，負(fù)載均衡器查詢服務(wù)注冊(cè)表并把請(qǐng)求路由到一臺(tái)可用的服務(wù)實(shí)例上”刂福現(xiàn)在常用的負(fù)載均衡器都是此類模式囊咏，常用于微服務(wù)中。
所有的名字發(fā)現(xiàn)和服務(wù)發(fā)現(xiàn)都要依賴于一個(gè)可用性非常高的服務(wù)注冊(cè)表塔橡，業(yè)界常用的服務(wù)注冊(cè)表有如下三個(gè)：
Etcd：一個(gè)高可用梅割、分布式、一致性葛家、Key-Value 方式的存儲(chǔ)户辞，被用在分享配置和服務(wù)發(fā)現(xiàn)中。兩個(gè)著名的項(xiàng)目使用了它：Kubernetes 和 Cloud Foundry癞谒。
Consul：一個(gè)發(fā)現(xiàn)和配置服務(wù)的工具底燎，為客戶端注冊(cè)和發(fā)現(xiàn)服務(wù)提供了API刃榨，Consul 還可以通過執(zhí)行健康檢查決定服務(wù)的可用性。
Apache ZooKeeper：一個(gè)廣泛使用书蚪、高性能的針對(duì)分布式應(yīng)用的協(xié)調(diào)服務(wù)。Apache ZooKeeper 本來是 Hadoop 的子工程迅栅，現(xiàn)在已經(jīng)是頂級(jí)工程了殊校。
除此之外也可以自己實(shí)現(xiàn)服務(wù)實(shí)現(xiàn)，或者用 Redis 也行读存，只是需要自己實(shí)現(xiàn)高可用性为流。
關(guān)系數(shù)據(jù)庫
關(guān)系數(shù)據(jù)庫分為兩種，一種是傳統(tǒng)關(guān)系數(shù)據(jù)庫让簿，如 Oracle敬察，MySQL，Maria尔当，DB2莲祸，PostgreSQL 等等。
另一種是 NewSQL椭迎，即至少要滿足以下五點(diǎn)的新型關(guān)系數(shù)據(jù)庫：
完整地支持 SQL锐帜，支持 JOIN / GROUP BY /子查詢等復(fù)雜 SQL 查詢。
支持傳統(tǒng)數(shù)據(jù)標(biāo)配的 ACID 事務(wù)畜号，支持強(qiáng)隔離級(jí)別缴阎。
具有彈性伸縮的能力，擴(kuò)容縮容對(duì)于業(yè)務(wù)層完全透明简软。
真正的高可用蛮拔，異地多活、故障恢復(fù)的過程不需要人為的接入痹升，系統(tǒng)能夠自動(dòng)地容災(zāi)和進(jìn)行強(qiáng)一致的數(shù)據(jù)恢復(fù)建炫。
具備一定的大數(shù)據(jù)分析能力。
傳統(tǒng)關(guān)系數(shù)據(jù)庫用得最多的是 MySQL疼蛾，因?yàn)槌墒祯饴眩€(wěn)定，一些基本的需求都能滿足据过，在一定數(shù)據(jù)量級(jí)之前基本單機(jī)傳統(tǒng)數(shù)據(jù)庫都可以搞定惋砂。
而且現(xiàn)在較多的開源系統(tǒng)都是基于 MySQL，開箱即用绳锅，再加上主從同步和前端緩存西饵，百萬 PV 的應(yīng)用都可以搞定了。
不過 CentOS 7 已經(jīng)放棄了 MySQL鳞芙，而改使用 MariaDB眷柔。MariaDB 數(shù)據(jù)庫管理系統(tǒng)是 MySQL 的一個(gè)分支期虾，主要由開源社區(qū)在維護(hù)，采用 GPL 授權(quán)許可驯嘱。
開發(fā)這個(gè)分支的原因之一是：甲骨文公司收購了 MySQL 后镶苞，有將 MySQL 閉源的潛在風(fēng)險(xiǎn)，因此社區(qū)采用分支的方式來避開這個(gè)風(fēng)險(xiǎn)鞠评。
在 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í)在大數(shù)據(jù)分析時(shí)已經(jīng)開始應(yīng)用 TiDB负乡，當(dāng)時(shí)應(yīng)用的主要原因是 MySQL 要使用分庫分表牍白，邏輯開發(fā)比較復(fù)雜，擴(kuò)展性不夠抖棘。
NoSQL
NoSQL 顧名思義就是 Not-Only SQL茂腥，也有人說是 No–SQL，個(gè)人偏向于 Not-Only SQL切省，它并不是用來替代關(guān)系庫础芍，而是作為關(guān)系型數(shù)據(jù)庫的補(bǔ)充而存在。
常見 NoSQL 有四個(gè)類型：
鍵值数尿，適用于內(nèi)容緩存仑性，適合混合工作負(fù)載并發(fā)高擴(kuò)展要求大的數(shù)據(jù)集，其優(yōu)點(diǎn)是簡單右蹦，查詢速度快诊杆，缺點(diǎn)是缺少結(jié)構(gòu)化數(shù)據(jù)，常見的有 Redis何陆，Memcache晨汹，BerkeleyDB 和 Voldemort 等等。
-
列式贷盲，以列簇式存儲(chǔ)淘这，將同一列數(shù)據(jù)存在一起，常見于分布式的文件系統(tǒng)巩剖，其中以 Hbase铝穷，Cassandra 為代表。
Cassandra 多用于寫多讀少的場(chǎng)景佳魔，國內(nèi)用得比較多的有 360曙聂，大概 1500 臺(tái)機(jī)器的集群，國外大規(guī)模使用的公司比較多鞠鲜，如 eBay宁脊，Instagram断国，Apple 和沃爾瑪?shù)鹊取?/p>
文檔，數(shù)據(jù)存儲(chǔ)方案非常適用承載大量不相關(guān)且結(jié)構(gòu)差別很大的復(fù)雜信息榆苞。性能介于 KV 和關(guān)系數(shù)據(jù)庫之間稳衬，它的靈感來自 Lotus Notes，常見的有 MongoDB坐漏，CouchDB 等等薄疚。
圖形，圖形數(shù)據(jù)庫擅長處理任何涉及關(guān)系的狀況仙畦，比如社交網(wǎng)絡(luò)输涕，推薦系統(tǒng)等音婶。專注于構(gòu)建關(guān)系圖譜慨畸，需要對(duì)整個(gè)圖做計(jì)算才能得出結(jié)果，不容易做分布式的集群方案衣式，常見的有 Neo4J寸士，InfoGrid 等。
除了以上 4 種類型碴卧，還有一些特種的數(shù)據(jù)庫弱卡，如對(duì)象數(shù)據(jù)庫，XML 數(shù)據(jù)庫住册，這些都有針對(duì)性對(duì)某些存儲(chǔ)類型做了優(yōu)化的數(shù)據(jù)庫婶博。
在實(shí)際應(yīng)用場(chǎng)景中，何時(shí)使用關(guān)系數(shù)據(jù)庫荧飞，何時(shí)使用 NoSQL凡人，使用哪種類型的數(shù)據(jù)庫，這是我們?cè)谧黾軜?gòu)選型時(shí)一個(gè)非常重要的考量叹阔，甚至?xí)绊懻麄€(gè)架構(gòu)的方案挠轴。
消息中間件
消息中間件在后臺(tái)系統(tǒng)中是必不可少的一個(gè)組件，一般我們會(huì)在以下場(chǎng)景中使用消息中間件：
-
異步處理：異步處理是使用消息中間件的一個(gè)主要原因耳幢，在工作中最常見的異步場(chǎng)景有用戶注冊(cè)成功后需要發(fā)送注冊(cè)成功郵件岸晦、緩存過期時(shí)先返回老的數(shù)據(jù)，然后異步更新緩存睛藻、異步寫日志等等启上。
通過異步處理，可以減少主流程的等待響應(yīng)時(shí)間店印，讓非主流程或者非重要業(yè)務(wù)通過消息中間件做集中的異步處理碧绞。
-
系統(tǒng)解耦：比如在電商系統(tǒng)中，當(dāng)用戶成功支付完成訂單后吱窝，需要將支付結(jié)果通知 ERP 系統(tǒng)讥邻、發(fā)票系統(tǒng)迫靖、WMS、推薦系統(tǒng)兴使、搜索系統(tǒng)系宜、風(fēng)控系統(tǒng)等進(jìn)行業(yè)務(wù)處理。
這些業(yè)務(wù)處理不需要實(shí)時(shí)處理发魄、不需要強(qiáng)一致盹牧，只需要最終一致性即可，因此可以通過消息中間件進(jìn)行系統(tǒng)解耦励幼。通過這種系統(tǒng)解耦還可以應(yīng)對(duì)未來不明確的系統(tǒng)需求汰寓。
-
削峰填谷：當(dāng)系統(tǒng)遇到大流量時(shí)，監(jiān)控圖上會(huì)看到一個(gè)一個(gè)的山峰樣的流量圖苹粟，通過使用消息中間件將大流量的請(qǐng)求放入隊(duì)列有滑，通過消費(fèi)者程序?qū)㈥?duì)列中的處理請(qǐng)求慢慢消化，達(dá)到削峰填谷的效果嵌削。
最典型的場(chǎng)景是秒殺系統(tǒng)毛好，在電商的秒殺系統(tǒng)中下單服務(wù)往往會(huì)是系統(tǒng)的瓶頸，因?yàn)橄聠涡枰獙?duì)庫存等做數(shù)據(jù)庫操作苛秕，需要保證強(qiáng)一致性肌访，此時(shí)使用消息中間件進(jìn)行下單排隊(duì)和流控，讓下單服務(wù)慢慢把隊(duì)列中的單處理完艇劫，保護(hù)下單服務(wù)吼驶，以達(dá)到削峰填谷的作用。
業(yè)界消息中間件是一個(gè)非常通用的東西店煞，大家在做選型時(shí)有使用開源的蟹演，也有自己造輪子的，甚至有直接用 MySQL 或 Redis 做隊(duì)列的浅缸，關(guān)鍵看是否滿足你的需求轨帜。
如果是使用開源的項(xiàng)目，以下的表格在選型時(shí)可以參考：
以上圖的緯度為：名字衩椒、成熟度蚌父、所屬社區(qū)/公司、文檔毛萌、授權(quán)方式苟弛、開發(fā)語言、支持的協(xié)議阁将、客戶端支持的語言膏秫、性能、持久化做盅、事務(wù)缤削、集群窘哈、負(fù)載均衡、管理界面亭敢、部署方式滚婉、評(píng)價(jià)。
代碼管理
代碼是互聯(lián)網(wǎng)創(chuàng)業(yè)公司的命脈之一帅刀，代碼管理很重要让腹，常見的考量點(diǎn)包括兩塊：
安全和權(quán)限管理，將代碼放到內(nèi)網(wǎng)并且對(duì)于關(guān)系公司命脈的核心代碼做嚴(yán)格的代碼控制和機(jī)器的物理隔離扣溺。
-
代碼管理工具骇窍，Git 作為代碼管理的不二之選，你值得擁有锥余。GitLab 是當(dāng)今最火的開源 Git 托管服務(wù)端腹纳，沒有之一，雖然有企業(yè)版哈恰，但是其社區(qū)版基本能滿足我們大部分需求只估，結(jié)合 Gerrit 做 Code Review志群，基本就完美了着绷。
當(dāng)然 GitLab 也有代碼對(duì)比，但沒 Gerrit 直觀锌云。Gerrit 比 GitLab 提供了更好的代碼檢查界面與主線管理體驗(yàn)荠医，更適合在對(duì)代碼質(zhì)量有高要求的文化下使用。
持續(xù)集成
持續(xù)集成簡稱 CI（continuous integration）桑涎，是一種軟件開發(fā)實(shí)踐彬向，即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作镀裤，每天可能會(huì)發(fā)生多次集成沃于。
每次集成都通過自動(dòng)化的構(gòu)建（包括編譯并鸵，發(fā)布津坑，自動(dòng)化測(cè)試）來驗(yàn)證先改，從而盡早地發(fā)現(xiàn)集成錯(cuò)誤片排。
持續(xù)集成為研發(fā)流程提供了代碼分支管理/比對(duì)际插、編譯哥艇、檢查禁谦、發(fā)布物輸出等基礎(chǔ)工作胁黑，為測(cè)試的覆蓋率版本編譯、生成等提供統(tǒng)一支持州泊。
業(yè)界免費(fèi)的持續(xù)集成工具中丧蘸，系統(tǒng)我們有如下一些選擇：
-
Jenkins：Java 寫的有強(qiáng)大的插件機(jī)制，MIT 協(xié)議開源 （免費(fèi)遥皂，定制化程度高力喷，它可以在多臺(tái)機(jī)器上進(jìn)行分布式地構(gòu)建和負(fù)載測(cè)試）刽漂。
Jenkins 可以算是無所不能，基本沒有 Jenkins 做不了的弟孟，無論從小型團(tuán)隊(duì)到大型團(tuán)隊(duì) Jenkins 都可以搞定爽冕。不過如果要大規(guī)模使用，還是需要有人力來學(xué)習(xí)和維護(hù)披蕉。
TeamCity：TeamCity 與 Jenkins 相比使用更加友好颈畸，也是一個(gè)高度可定制化的平臺(tái)。但是用的人多了没讲，TeamCity 就要收費(fèi)了眯娱。
Strider：Strider 是一個(gè)開源的持續(xù)集成和部署平臺(tái)，使用 Node.js 實(shí)現(xiàn)爬凑，存儲(chǔ)使用的是 MongoDB徙缴，BSD 許可證，概念上類似 Travis 和 Jenkins嘁信。
-
GitLab CI：從 GitLab 8.0 開始于样，GitLab CI 就已經(jīng)集成在 GitLab，我們只要在項(xiàng)目中添加一個(gè) .gitlab-ci.yml 文件潘靖，然后添加一個(gè) Runner穿剖，即可進(jìn)行持續(xù)集成。
并且 GitLab 與 Docker 有著非常好的相互協(xié)作的能力卦溢。免費(fèi)版與付費(fèi)版本的不同可以參見：https://about.gitlab.com/products/feature-comparison/糊余。
Travis：Travis 和 GitHub 強(qiáng)關(guān)聯(lián)；閉源代碼使用 SaaS 還需考慮安全問題单寂；不可定制贬芥；開源項(xiàng)目免費(fèi)，其他收費(fèi)宣决。
Go：Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身蘸劈。除了 ThoughtWorks 提供的商業(yè)支持，Go 是免費(fèi)的尊沸。它適用于 Windows威沫，Mac 和各種 Linux 發(fā)行版。
日志系統(tǒng)
日志系統(tǒng)一般包括打日志椒丧，采集壹甥，中轉(zhuǎn)，收集壶熏，存儲(chǔ)句柠，分析，呈現(xiàn)，搜索還有分發(fā)等溯职。
一些特殊的如染色精盅，全鏈條跟蹤或者監(jiān)控都可能需要依賴于日志系統(tǒng)實(shí)現(xiàn)。
日志系統(tǒng)的建設(shè)不僅僅是工具的建設(shè)谜酒，還有規(guī)范和組件的建設(shè)叹俏，最好一些基本的日志在框架和組件層面加就行了，比如全鏈接跟蹤之類的僻族。
對(duì)于常規(guī)日志系統(tǒng) ELK 能滿足大部分的需求粘驰，ELK 包括如下組件：
ElasticSearch 是個(gè)開源分布式搜索引擎，它的特點(diǎn)有：分布式述么，零配置蝌数，自動(dòng)發(fā)現(xiàn)，索引自動(dòng)分片度秘，索引副本機(jī)制顶伞，RESTful 風(fēng)格接口，多數(shù)據(jù)源剑梳，自動(dòng)搜索負(fù)載等唆貌。
Logstash 是一個(gè)完全開源的工具，它可以對(duì)你的日志進(jìn)行收集垢乙、分析锨咙，并將其存儲(chǔ)供以后使用。
Kibana 是一個(gè)開源和免費(fèi)的工具侨赡，它可以為 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面蓖租，可以幫助匯總粱侣、分析和搜索重要數(shù)據(jù)日志羊壹。
Filebeat 已經(jīng)完全替代了 Logstash-Forwarder 成為新一代的日志采集器，同時(shí)鑒于它輕量齐婴、安全等特點(diǎn)油猫，越來越多人開始使用它。
因?yàn)槊赓M(fèi)的 ELK 沒有任何安全機(jī)制柠偶，所以這里使用了 Nginx 作反向代理情妖，避免用戶直接訪問 Kibana 服務(wù)器。
加上配置 Nginx 實(shí)現(xiàn)簡單的用戶認(rèn)證诱担，一定程度上提高安全性毡证。另外，Nginx 本身具有負(fù)載均衡的作用蔫仙，能夠提高系統(tǒng)訪問性能料睛。
ELK 架構(gòu)如圖 4 所示：
對(duì)于有實(shí)時(shí)計(jì)算的需求，可以使用 Flume + Kafka + Storm + MySQL 方案，一般架構(gòu)如圖 5 所示：
其中：
-
Flume 是一個(gè)分布式恤煞、可靠屎勘、和高可用的海量日志采集、聚合和傳輸?shù)娜罩臼占到y(tǒng)居扒，支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方概漱，用于收集數(shù)據(jù)。
同時(shí)喜喂，F(xiàn)lume 提供對(duì)數(shù)據(jù)進(jìn)行簡單處理瓤摧，并寫到各種數(shù)據(jù)接受方（可定制）的能力。
-
Kafka 是由 Apache 軟件基金會(huì)開發(fā)的一個(gè)開源流處理平臺(tái)玉吁，由 Scala 和 Java 編寫姻灶。
其本質(zhì)上是一個(gè)“按照分布式事務(wù)日志架構(gòu)的大規(guī)模發(fā)布/訂閱消息隊(duì)列”，它以可水平擴(kuò)展和高吞吐率而被廣泛使用诈茧。
Kafka 追求的是高吞吐量产喉、高負(fù)載，F(xiàn)lume 追求的是數(shù)據(jù)的多樣性敢会，二者結(jié)合起來簡直完美曾沈。
監(jiān)控系統(tǒng)
監(jiān)控系統(tǒng)只包含與后臺(tái)相關(guān)的，這里主要是兩塊鸥昏，一個(gè)是操作系統(tǒng)層的監(jiān)控塞俱，比如機(jī)器負(fù)載，IO吏垮，網(wǎng)絡(luò)流量障涯，CPU，內(nèi)存等操作系統(tǒng)指標(biāo)的監(jiān)控膳汪。
另一個(gè)是服務(wù)質(zhì)量和業(yè)務(wù)質(zhì)量的監(jiān)控唯蝶，比如服務(wù)的可用性，成功率遗嗽，失敗率粘我，容量，QPS 等等痹换。
常見業(yè)務(wù)的監(jiān)控系統(tǒng)先有操作系統(tǒng)層面的監(jiān)控（這部分較成熟）征字，然后擴(kuò)展出其他監(jiān)控，如 Zabbix娇豫，小米的 Open-Falcon匙姜，也有一出來就是兩者都支持的，如 Prometheus冯痢。
如果對(duì)業(yè)務(wù)監(jiān)控要求比較高一些氮昧，在創(chuàng)業(yè)選型中建議可以優(yōu)先考慮 Prometheus或详。
這里有一個(gè)有趣的分布，如圖 6 所示：
亞洲區(qū)域使用 Zabbix 較多郭计，而美洲和歐洲霸琴，以及澳大利亞使用 Prometheus 居多，換句話說昭伸，英文國家地區(qū)（發(fā)達(dá)國家梧乘？）使用 Prometheus 較多。
Prometheus 是由 Sound Cloud 開發(fā)的開源監(jiān)控報(bào)警系統(tǒng)和時(shí)序列數(shù)據(jù)庫（TSDB）庐杨。
Prometheus 使用 Go 語言開發(fā)，是 Google BorgMon 監(jiān)控系統(tǒng)的開源版本仁堪。
相對(duì)于其他監(jiān)控系統(tǒng)使用的 Push 數(shù)據(jù)的方式填渠，Prometheus 使用的是 Pull 的方式弦聂，其架構(gòu)如圖 7 所示：
如上圖所示氛什，Prometheus 包含的主要組件如下：
-
Prometheus Server：主要負(fù)責(zé)數(shù)據(jù)采集和存儲(chǔ)，提供 PromQL 查詢語言的支持枪眉。Server 通過配置文件捺檬、文本文件贸铜、ZooKeeper、Consul烤镐、DNS SRV Lookup 等方式指定抓取目標(biāo)渤早。
根據(jù)這些目標(biāo)，Server 會(huì)定時(shí)去抓取 Metrics 數(shù)據(jù)，每個(gè)抓取目標(biāo)需要暴露一個(gè) HTTP 服務(wù)的接口給它定時(shí)抓取扛芽。
客戶端 SDK：官方提供的客戶端類庫有 Go川尖、Java、Scala被芳、Python、Ruby剩晴，其他還有很多第三方開發(fā)的類庫侵状，支持 Nodejs、PHP绽左、Erlang 等艇潭。
Push Gateway：支持臨時(shí)性 Job 主動(dòng)推送指標(biāo)的中間網(wǎng)關(guān)蹋凝。
-
Exporter Exporter：是 Prometheus 的一類數(shù)據(jù)采集組件的總稱。它負(fù)責(zé)從目標(biāo)處搜集數(shù)據(jù)房交，并將其轉(zhuǎn)化為 Prometheus 支持的格式伐割。
與傳統(tǒng)的數(shù)據(jù)采集組件不同的是，它并不向中央服務(wù)器發(fā)送數(shù)據(jù)白群，而是等待中央服務(wù)器主動(dòng)前來抓取硬霍。
Prometheus 提供多種類型的 Exporter 用于采集各種不同服務(wù)的運(yùn)行狀態(tài)。目前支持的有數(shù)據(jù)庫唯卖、硬件、消息中間件抽减、存儲(chǔ)系統(tǒng)卵沉、HTTP 服務(wù)器、JMX 等史汗。
Alertmanager：是一個(gè)單獨(dú)的服務(wù)，可以支持 Prometheus 的查詢語句瓷蛙，提供十分靈活的報(bào)警方式怜森。
Prometheus HTTP API 的查詢方式副硅，自定義所需要的輸出。
Grafana：是一套開源的分析監(jiān)視平臺(tái)恐疲，支持 Graphite培己，InfluxDB省咨，OpenTSDB，Prometheus笤受，Elasticsearch敌蜂，CloudWatch 等數(shù)據(jù)源章喉，其 UI 非常漂亮且高度定制化秸脱。
創(chuàng)業(yè)公司選擇 Prometheus + Grafana 的方案，再加上統(tǒng)一的服務(wù)框架（如 gRPC）妥色，可以滿足大部分中小團(tuán)隊(duì)的監(jiān)控需求嘹害。
配置系統(tǒng)
隨著程序功能的日益復(fù)雜吮便，程序的配置日益增多：各種功能的開關(guān)髓需、降級(jí)開關(guān)，灰度開關(guān)微渠，參數(shù)的配置逞盆、服務(wù)器的地址松申、數(shù)據(jù)庫配置等等贸桶。
除此之外，對(duì)后臺(tái)程序配置的要求也越來越高：配置修改后實(shí)時(shí)生效琉历，灰度發(fā)布旗笔，分環(huán)境离例、分用戶宫蛆，分集群管理配置，完善的權(quán)限想虎、審核機(jī)制等等舌厨。
在這樣的大環(huán)境下忿薇，傳統(tǒng)的通過配置文件躏哩、數(shù)據(jù)庫等方式已經(jīng)越來越無法滿足開發(fā)人員對(duì)配置管理的需求扫尺。
業(yè)界有如下兩種方案：
-
基于 ZK 和 Etcd炊汤，支持界面和 API 抢腐，用數(shù)據(jù)庫來保存版本歷史迈倍，預(yù)案，走審核流程醋界，最后下發(fā)到 ZK 或 Etcd 這種有推送能力的存儲(chǔ)里（服務(wù)注冊(cè)本身也是用 ZK 或 Etcd形纺，選型就一塊了）徒欣。
客戶端都直接和 ZK 或 Etcd 打交道打肝。至于灰度發(fā)布，各家不同争便，有一種實(shí)現(xiàn)是同時(shí)發(fā)布一個(gè)需要灰度的 IP 列表滞乙，客戶端監(jiān)聽到配置節(jié)點(diǎn)變化時(shí)斩启，對(duì)比一下自己是否屬于該列表醉锅。
PHP 這種無狀態(tài)的語言和其他 ZK/Etcd 不支持的語言，只好自己在客戶端的機(jī)器上起一個(gè) Agent 來監(jiān)聽變化边酒，再寫到配置文件或共享內(nèi)存此虑，如 360 的 Qconf朦前。
基于運(yùn)維自動(dòng)化的配置文件的推送韭寸，審核流程荆隘，配置數(shù)據(jù)管理和方案一類似椰拒，下發(fā)時(shí)生成配置文件燃观，基于運(yùn)維自動(dòng)化工具如 Puppet，Ansible 推送到每個(gè)客戶端番川，而應(yīng)用則定時(shí)重新讀取這個(gè)外部的配置文件颁督，灰度發(fā)布在下發(fā)配置時(shí)指定 IP 列表浇雹。
創(chuàng)業(yè)公司前期不需要這種復(fù)雜昭灵，直接上 ZK虎锚，弄一個(gè)界面管理 ZK 的內(nèi)容窜护，記錄一下所有人的操作日志，程序直連 ZK缓屠，或者或者用 Qconf 等基于 ZK 優(yōu)化后的方案敌完。
發(fā)布系統(tǒng)/部署系統(tǒng)
從軟件生產(chǎn)的層面看，代碼到最終服務(wù)的典型流程如圖 8 所示：
從上圖中可以看出，從開發(fā)人員寫下代碼到服務(wù)最終用戶是一個(gè)漫長過程闽撤，整體可以分成三個(gè)階段：
從代碼（Code）到成品庫（Artifact）這個(gè)階段主要對(duì)開發(fā)人員的代碼做持續(xù)構(gòu)建并把構(gòu)建產(chǎn)生的制品集中管理脯颜，是為部署系統(tǒng)準(zhǔn)備輸入內(nèi)容的階段栋操。
從制品到可運(yùn)行服務(wù) 這個(gè)階段主要完成制品部署到指定環(huán)境矾芙，是部署系統(tǒng)的最基本工作內(nèi)容。
從開發(fā)環(huán)境到最終生產(chǎn)環(huán)境 這個(gè)階段主要完成一次變更在不同環(huán)境的遷移场勤，是部署系統(tǒng)上線最終服務(wù)的核心能力和媳。
發(fā)布系統(tǒng)集成了制品管理留瞳，發(fā)布流程骚秦，權(quán)限控制作箍，線上環(huán)境版本變更胞得，灰度發(fā)布，線上服務(wù)回滾等幾方面的內(nèi)容跃巡，是開發(fā)人員工作結(jié)晶最終呈現(xiàn)的重要通道素邪。
開源的項(xiàng)目中沒有完全滿足的項(xiàng)目兔朦，如果只是 Web 類項(xiàng)目，Walle淋昭、Piplin 都是可用的，但是功能不太滿足盏檐，創(chuàng)業(yè)初期可以集成 Jenkins + Gitlab + Walle（可以考慮兩天時(shí)間完善一下）胡野。
以上方案基本包括制品管理痕鳍，發(fā)布流程笼呆，權(quán)限控制诗赌，線上環(huán)境版本變更铭若，灰度發(fā)布（需要自己實(shí)現(xiàn)），線上服務(wù)回滾等功能瞳腌。
跳板機(jī)
跳板機(jī)面對(duì)的是需求是要有一種能滿足角色管理與授權(quán)審批嫂侍、信息資源訪問控制吵冒、操作記錄和審計(jì)痹栖、系統(tǒng)變更和維護(hù)控制要求，并生成一些統(tǒng)計(jì)報(bào)表配合管理規(guī)范來不斷提升 IT 內(nèi)控的合規(guī)性疗我。
它能對(duì)運(yùn)維人員操作行為的進(jìn)行控制和審計(jì)吴裤，對(duì)誤操作麦牺、違規(guī)操作導(dǎo)致的操作事故剖膳，快速定位原因和責(zé)任人岭辣。其功能模塊一般包括：帳戶管理沦童、認(rèn)證管理偷遗、授權(quán)管理鹦肿、審計(jì)管理等等箩溃。
開源項(xiàng)目中，Jumpserver 能夠?qū)崿F(xiàn)跳板機(jī)常見需求歪架，如授權(quán)和蚪、用戶管理攒霹、服務(wù)器基本信息記錄等催束，同時(shí)又可批量執(zhí)行腳本等功能。
其中錄像回放塔淤、命令搜索高蜂、實(shí)時(shí)監(jiān)控等特點(diǎn)备恤，又能幫助運(yùn)維人員回溯操作歷史烘跺，方便查找操作痕跡，便于管理其他人員對(duì)服務(wù)器的操作控制梧喷。
機(jī)器管理
機(jī)器管理的工具選擇的考量可以包含以下三個(gè)方面：
是否簡單铺敌，是否需要每臺(tái)機(jī)器部署 Agent（客戶端）偿凭。
語言的選擇（Puppet/Chef vs Ansible/SaltStack ）開源技術(shù)弯囊，不看官網(wǎng)不足以熟練匾嘱，不懂源碼不足以精通霎烙；Puppet、Chef 基于 Ruby 開發(fā)甘苍，Ansible载庭、SaltStack 基于 Python 開發(fā)的昧捷。
-
速度的選擇（Ansible vs SaltStack）罐寨，Ansible 基于 SSH 協(xié)議傳輸數(shù)據(jù)鸯绿，SaltStack 使用消息隊(duì)列 zeroMQ 傳輸數(shù)據(jù)瓶蝴。
大規(guī)模并發(fā)的能力對(duì)于幾十臺(tái)到 200 臺(tái)規(guī)模的兄弟來講舷手，Ansible 的性能也可接受男窟，如果一次操作上千臺(tái)歉眷，用 SaltStack 好一些汗捡。
如圖 9 所示：
一般創(chuàng)業(yè)公司選擇 Ansible 能解決大部分問題扇住，其簡單台囱，不需要安裝額外的客戶端簿训，可以從命令行來運(yùn)行，不需要使用配置文件屈糊。
至于比較復(fù)雜的任務(wù)逻锐，Ansible 配置通過名為 Playbook 的配置文件中的 YAML 語法來加以處理昧诱。Playbook 還可以使用模板來擴(kuò)展其功能。
創(chuàng)業(yè)公司的選擇
選擇合適的語言：
選擇團(tuán)隊(duì)熟悉的/能掌控的所袁，創(chuàng)業(yè)公司人少事多盏档，無太多冗余讓研發(fā)團(tuán)隊(duì)熟悉新的語言，能快速上手燥爷，能快速出活蜈亩，出了問題能快速解決的問題的語言才是好的選擇。
選擇更現(xiàn)代一些的前翎，這里的現(xiàn)代是指語言本身已經(jīng)完成一些之前需要特殊處理的特性，比如內(nèi)存管理港华，線程等等道川。
選擇開源輪子多的或者社區(qū)活躍度高的，這個(gè)原則是為了保證在開發(fā)過程中減少投入立宜，有穩(wěn)定可靠的輪子可以使用愤惰，遇到問題可以在網(wǎng)上快速搜索到答案。
選擇好招人的一門合適的語言會(huì)讓創(chuàng)業(yè)團(tuán)隊(duì)減少招聘的成本赘理，快速招到合適的人。
選擇能讓人有興趣的與上面一點(diǎn)相關(guān)扇单，讓人感興趣商模，在后面留人時(shí)有用。
選擇合適的組件和云服務(wù)商：
選擇靠譜的云服務(wù)商蜘澜。
選擇云服務(wù)商的組件施流。
選擇成熟的開源組件，而不是最新出的組件鄙信。
選擇采用在一線互聯(lián)網(wǎng)公司落地并且開源的瞪醋，且在社區(qū)內(nèi)形成良好口碑的產(chǎn)品。
開源社區(qū)活躍度装诡。
選擇靠譜的云服務(wù)商银受，其實(shí)這是一個(gè)偽命題践盼，因?yàn)槟膫€(gè)服務(wù)商都不靠譜，他們所承諾的那些可用性問題基本上都會(huì)在你的身上發(fā)生宾巍。
這里我們還是需要自己做一些工作咕幻，比如多服務(wù)商備份，如用 CDN顶霞，你一定不要只選一家肄程，至少選兩家，一個(gè)是災(zāi)備选浑，保持后臺(tái)切換的能力蓝厌，另一個(gè)是多點(diǎn)覆蓋，不同的服務(wù)商在 CDN 節(jié)點(diǎn)上的資源是不一樣的古徒。
選擇了云服務(wù)商以后拓提，就會(huì)有很多的產(chǎn)品你可以選擇了，比較存儲(chǔ)描函，隊(duì)列這些都會(huì)有現(xiàn)成的產(chǎn)品崎苗，這個(gè)時(shí)候就糾結(jié)了，是用呢舀寓？還是自己在云主機(jī)上搭呢胆数？
在這里我的建議是前期先用云服務(wù)商的，大了后再自己搞互墓，這樣會(huì)少掉很多運(yùn)維的事情必尼，但是這里要多了解一下云服務(wù)商的組件特性以及一些坑。
比如他們內(nèi)網(wǎng)會(huì)經(jīng)常斷開篡撵，他們升級(jí)也會(huì)閃斷判莉，所以在業(yè)務(wù)側(cè)要做好容錯(cuò)和規(guī)避。
關(guān)于開源組件育谬，盡可能選擇成熟的券盅，成熟的組件經(jīng)歷了時(shí)間的考驗(yàn)，基本不會(huì)出大的問題膛檀，并且有成套的配套工具锰镀，出了問題在網(wǎng)上也可以很快的找到答案，你所遇到的坑基本上都有人踩過了咖刃。
制定流程和規(guī)范：
制定開發(fā)的規(guī)范泳炉，代碼及代碼分支管理規(guī)范，關(guān)鍵性代碼僅少數(shù)人有權(quán)限
制定發(fā)布流程規(guī)范嚎杨，從發(fā)布系統(tǒng)落地
制定運(yùn)維規(guī)范
制定數(shù)據(jù)庫操作規(guī)范花鹅，收攏數(shù)據(jù)庫操作權(quán)限
制定告警處理流程，做到告警有人看有人處理
制定匯報(bào)機(jī)制枫浙，晨會(huì)/周報(bào)
自研和選型合適的輔助系統(tǒng)
所有的流程和規(guī)范都需要用系統(tǒng)來固化刨肃，否則就是空中樓閣古拴，如何選擇這些系統(tǒng)呢？
參照上個(gè)章節(jié)咱們那些開源的之景，對(duì)比一下選擇的語言斤富，組件之類的，選擇一個(gè)最合適的即可锻狗。
比如項(xiàng)目管理的满力，看下自己是什么類型的公司，開發(fā)的節(jié)奏是怎樣的轻纪，瀑布油额，敏捷的按項(xiàng)目劃分，還是按客戶劃分等等刻帚，平時(shí)是按項(xiàng)目組織還是按任務(wù)組織等等潦嘶。
比如日志系統(tǒng)，之前是打的文本崇众，那么上一個(gè) ELK掂僵，規(guī)范化一些日志組件，基本上很長一段時(shí)間內(nèi)不用考慮日志系統(tǒng)的問題顷歌，最多拆分一下或者擴(kuò)容一下锰蓬。等到組織大了，自己搞一個(gè)日志系統(tǒng)眯漩。
比如代碼管理芹扭，項(xiàng)目管理系統(tǒng)這些都放內(nèi)網(wǎng)，安全赦抖，在互聯(lián)網(wǎng)公司來說舱卡，屬于命脈了，命脈的東西還是放在別人拿不到或很難拿到的地方會(huì)比較靠譜一些队萤。
選擇過程中需要思考的問題
技術(shù)棧的選擇有點(diǎn)像做出了某種承諾轮锥，在一定的時(shí)間內(nèi)這種承諾沒法改變，于是我們需要在選擇的時(shí)候有一些思考要尔。
看前面內(nèi)容交胚，有一個(gè)詞出現(xiàn)了三次，合適盈电，選擇是合適的，不是最好杯活，也不是最新匆帚，是最合適，適合是針對(duì)當(dāng)下旁钧，這種選擇是最合適的嗎吸重？
比如用 Go 這條線的東西互拾，技術(shù)比較新，業(yè)界組件儲(chǔ)備夠嗎嚎幸？組織內(nèi)的人員儲(chǔ)備夠嗎颜矿？學(xué)習(xí)成本多少？寫出來的東西能滿足業(yè)務(wù)性能要求嗎嫉晶？能滿足時(shí)間要求嗎骑疆？
向未來看一眼，在一年到三年內(nèi)替废，我們需要做出改變嗎箍铭？技術(shù)棧要做根本性的改變嗎？如果組織發(fā)展很快椎镣，在 200 人诈火，500 人時(shí)，現(xiàn)有的技術(shù)棧是否需要大動(dòng)状答？
創(chuàng)業(yè)過程中需要考慮成本冷守，這里的成本不僅僅是花費(fèi)多少錢，付出多少工資惊科，有時(shí)更重要的是時(shí)間成本拍摇，很多業(yè)務(wù)在創(chuàng)業(yè)時(shí)大家拼的就是時(shí)間，就是一個(gè)時(shí)間窗译断，過了就沒你什么事兒了授翻。
基于云的創(chuàng)業(yè)公司后臺(tái)技術(shù)架構(gòu)
結(jié)合上面內(nèi)容的考量，在對(duì)一個(gè)個(gè)系統(tǒng)和組件的做選型之后孙咪，以云服務(wù)為基礎(chǔ)堪唐，一個(gè)創(chuàng)業(yè)公司的后臺(tái)技術(shù)架構(gòu)如圖 10 所示：
