從0開始搭建公司後臺技術棧,這套架構值得擁有...
-
Redmine:用 Ruby 開發的,有較多的外掛可以使用,能自定義欄位,集成了專案管理,Bug 問題跟蹤,WIKI 等功能,不過好多外掛 N 年沒有更新了;
-
Jira:用 Java 開發的,有使用者故事,task 拆分,燃盡圖等等,可以做專案管理,也可以應用於跨部門溝通場景,較強大;
DNS 是一個很通用的服務,創業公司基本上選擇一個合適的雲廠商就行了,國內主要是兩家:
在國外還是選擇亞馬遜吧,阿里的 DNS 服務只有在日本和美國有節點,東南亞最近才開始部點, DNSPod 也只有美國和日本,像一些出海的企業,其選擇的雲服務基本都是亞馬遜。
如果是線上產品,DNS 強烈建議用付費版,阿里的那幾十塊錢的付費版基本可以滿足需求。如果還需要一些按省份或按區域除錯的邏輯,則需要加錢,一年也就幾百塊,省錢省力。
LB(負載均衡)是一個通用服務,一般雲廠商的 LB 服務基本都會如下功能:
4、CDN
CDN 現在已經是一個很紅很紅的市場,基本上只能掙一些辛苦錢,都是貼著成本在賣。國內以網宿為龍頭,他們家佔據整個國內市場份額的 40% 以上,後面就是騰訊,阿里。網宿有很大一部分是因為直播的興起而崛起。
國外,Amazon 和 Akamai 合起來佔比大概在 50%,曾經的國際市場老大 Akamai 擁有全球超一半的份額,在 Amazon CDN入局後,份額跌去了將近 20%,眾多中小企業都轉向後者,Akamai 也是無能為力。
國內出海的 CDN 廠商,更多的是為國內的出海企業服務,三家大一點的 CDN 服務商裡面也就網宿的節點多一些,但是也多不了多少。阿里和騰訊還處於前期階段,僅少部分國家有節點。
5、RPC 框架
維基百科對 RPC 的定義是:遠端過程呼叫(Remote Procedure Call,RPC)是一個計算機通訊協議。該協議允許運行於一臺計算機的程式呼叫另一臺計算機的子程式,而程式設計師無需額外地為這個互動作用程式設計。
通俗來講,一個完整的 RPC 呼叫過程,就是 Server 端實現了一個函式,客戶端使用 RPC 框架提供的介面,呼叫這個函式的實現,並獲取返回值的過程。
業界 RPC 框架大致分為兩大流派,一種側重跨語言呼叫,另一種是偏重服務治理。
其中,gRPC 是 Google 開發的高效能、通用的開源 RPC 框架,其由 Google 主要面向移動應用開發並基於 HTTP/2 協議標準而設計,基於 ProtoBuf(Protocol Buffers)序列化協議開發,且支援眾多開發語言。本身它不是分散式的,所以要實現框架的功能需要進一步的開發。
Hprose(High Performance Remote Object Service Engine)是一個 MIT 開源許可的新型輕量級跨語言跨平臺的面向物件的高效能遠端動態通訊中介軟體。
服務治理型的 RPC 框架的特點是功能豐富,提供高效能的遠端呼叫、服務發現及服務治理能力,適用於大型服務的服務解耦及服務治理,對於特定語言(Java)的專案可以實現透明化接入。缺點是語言耦合度較高,跨語言支援難度較大。國內常見的冶理型 RPC 框架如下:
6、名字發現/服務發現
名字發現和服務發現分為兩種模式,一個是客戶端發現模式,一種是服務端發現模式。
框架中常用的服務發現是客戶端發現模式。
所謂服務端發現模式是指客戶端通過一個負載均衡器向服務傳送請求,負載均衡器查詢服務登錄檔並把請求路由到一臺可用的服務例項上。現在常用的負載均衡器都是此類模式,常用於微服務中。
所有的名字發現和服務發現都要依賴於一個可用性非常高的服務登錄檔,業界常用的服務登錄檔有如下三個:
-
etcd,一個高可用、分散式、一致性、key-value 方式的儲存,被用在分享配置和服務發現中。兩個著名的專案使用了它:Kubernetes 和 Cloud Foundry。
-
Consul,一個發現和配置服務的工具,為客戶端註冊和發現服務提供了API,Consul還可以通過執行健康檢查決定服務的可用性。
-
Apache ZooKeeper,是一個廣泛使用、高效能的針對分散式應用的協調服務。Apache ZooKeeper 本來是 Hadoop 的子工程,現在已經是頂級工程了。
除此之外也可以自己實現服務實現,或者用 Redis 也行,只是需要自己實現高可用性。
關係資料庫分為兩種,一種是傳統關係資料,如 Oracle,MySQL,Maria,DB2,PostgreSQL 等等,另一種是 NewSQL,即至少要滿足以下五點的新型關係資料庫:
-
完整地支援 SQL,支援 JOIN / GROUP BY /子查詢等複雜 SQL 查詢。
-
支援傳統資料標配的 ACID 事務,支援強隔離級別。
-
具有彈性伸縮的能力,擴容縮容對於業務層完全透明。
-
真正的高可用,異地多活、故障恢復的過程不需要人為的接入,系統能夠自動地容災和進行強一致的資料恢復。
-
具備一定的大資料分析能力。
NoSQL 顧名思義就是 Not-Only SQL,也有人說是 No – SQL,個人偏向於 Not-Only SQL,它並不是用來替代關係庫,而是作為關係型資料庫的補充而存在。
-
文件,資料儲存方案非常適用承載大量不相關且結構差別很大的複雜資訊。效能介於 kv 和關係資料庫之間,它的靈感來於 lotus notes,常見的有 MongoDB,CouchDB 等等;
-
圖形,圖形資料庫擅長處理任何涉及關係的狀況。社交網路,推薦系統等。專注於構建關係圖譜,需要對整個圖做計算才能得出結果,不容易做分散式的叢集方案,常見的有 Neo4J,InfoGrid 等。
除了以上4種類型,還有一些特種的資料庫,如物件資料庫,XML 資料庫,這些都有針對性對某些儲存型別做了優化的資料庫。
在實際應用場景中,何時使用關係資料庫,何時使用 NoSQL,使用哪種型別的資料庫,這是我們在做架構選型時一個非常重要的考量,甚至會影響整個架構的方案。
9、訊息中介軟體
訊息中介軟體在後臺系統中是必不可少的一個元件,一般我們會在以下場景中使用訊息中介軟體:
-
非同步處理:非同步處理是使用訊息中介軟體的一個主要原因,在工作中最常見的非同步場景有使用者註冊成功後需要傳送註冊成功郵件、快取過期時先返回老的資料,然後非同步更新快取、非同步寫日誌等等;通過非同步處理,可以減少主流程的等待響應時間,讓非主流程或者非重要業務通過訊息中介軟體做集中的非同步處理。
-
系統解耦:比如在電商系統中,當用戶成功支付完成訂單後,需要將支付結果給通知ERP系統、發票系統、WMS、推薦系統、搜尋系統、風控系統等進行業務處理;這些業務處理不需要實時處理、不需要強一致,只需要最終一致性即可,因此可以通過訊息中介軟體進行系統解耦。通過這種系統解耦還可以應對未來不明確的系統需求。
-
削峰填谷:當系統遇到大流量時,監控圖上會看到一個一個的山峰樣的流量圖,通過使用訊息中介軟體將大流量的請求放入佇列,通過消費者程式將佇列中的處理請求慢慢消化,達到消峰填谷的效果。最典型的場景是秒殺系統,在電商的秒殺系統中下單服務往往會是系統的瓶頸,因為下單需要對庫存等做資料庫操作,需要保證強一致性,此時使用訊息中介軟體進行下單排隊和流控,讓下單服務慢慢把佇列中的單處理完,保護下單服務,以達到削峰填谷的作用。
以上圖的緯度為:名字、成熟度、所屬社群/公司、文件、授權方式、開發語言、支援的協議、客戶端支援的語言、效能、持久化、事務、叢集、負載均衡、管理介面、部署方式、評價。
程式碼是網際網路創業公司的命脈之一,程式碼管理很重要,常見的考量點包括兩塊:
11、持續整合
-
TeamCity:TeamCity 與 Jenkins 相比使用更加友好,也是一個高度可定製化的平臺。但是用的人多了,TeamCity就要收費了。
-
Strider:Strider 是一個開源的持續整合和部署平臺,使用 Node.js 實現,儲存使用的是 MongoDB,BSD 許可證,概念上類似 Travis 和Jenkins。
-
Travis:Travis 和 GitHub 強關聯;閉原始碼使用 SaaS 還需考慮安全問題;不可定製;開源專案免費,其它收費。
12、日誌系統
對於常規日誌系統ELK能滿足大部分的需求,ELK 包括如下元件:
-
ElasticSearch 是個開源分散式搜尋引擎,它的特點有:分散式,零配置,自動發現,索引自動分片,索引副本機制,RESTful 風格介面,多資料來源,自動搜尋負載等。
-
Kibana 是一個開源和免費的工具,它可以為 Logstash 和 ElasticSearch 提供的日誌分析友好的 Web 介面,可以幫助彙總、分析和搜尋重要資料日誌。
-
Filebeat 已經完全替代了 Logstash-Forwarder 成為新一代的日誌採集器,同時鑑於它輕量、安全等特點,越來越多人開始使用它。
對於有實時計算的需求,可以使用 Flume + Kafka + Storm + MySQL 方案,一 般架構如圖 5 所示:
其中:
-
Flume 是一個分散式、可靠、和高可用的海量日誌採集、聚合和傳輸的日誌收集系統,支援在日誌系統中定製各類資料傳送方,用於收集資料;同時,Flume 提供對資料進行簡單處理,並寫到各種資料接受方(可定製)的能力。
-
Kafka 是由 Apache 軟體基金會開發的一個開源流處理平臺,由 Scala 和 Java 編寫。其本質上是一個“按照分散式事務日誌架構的大規模釋出/訂閱訊息佇列”,它以可水平擴充套件和高吞吐率而被廣泛使用。
Kafka 追求的是高吞吐量、高負載,Flume 追求的是資料的多樣性,二者結合起來簡直完美。
13、監控系統
監控系統只包含與後臺相關的,這裡主要是兩塊,一個是作業系統層的監控,比如機器負載,IO,網路流量,CPU,記憶體等作業系統指標的監控。另一個是服務質量和業務質量的監控,比如服務的可用性,成功率,失敗率,容量,QPS 等等。常見業務的監控系統先有作業系統層面的監控(這部分較成熟),然後擴展出其它監控,如 Zabbix,小米的 Open-Falcon,也有一出來就是兩者都支援的,如 Prometheus。如果對業務監控要求比較高一些,在創業選型中建議可以優先考慮 Prometheus。這裡有一個有趣的分佈,如圖6所示。
亞洲區域使用 Zabbix 較多,而美洲和歐洲,以及澳大利亞使用 Prometheus 居多,換句話說,英文國家地區(發達國家?)使用 Prometheus 較多。
Prometheus 是由 SoundCloud 開發的開源監控報警系統和時序列資料庫(TSDB)。Prometheus 使用 Go 語言開發,是 Google BorgMon 監控系統的開源版本。相對於其它監控系統使用的 push 資料的方式,Prometheus 使用的是 pull 的方式,其架構如圖 7 所示:
創業公司選擇 Prometheus + Grafana 的方案,再加上統一的服務框架(如 gRPC),可以滿足大部分中小團隊的監控需求。
14、配置系統
隨著程式功能的日益複雜,程式的配置日益增多:各種功能的開關、降級開關,灰度開關,引數的配置、伺服器的地址、資料庫配置等等,除此之外,對後臺程式配置的要求也越來越高:配置修改後實時生效,灰度釋出,分環境、分使用者,分叢集管理配置,完善的許可權、稽核機制等等,在這樣的大環境下,傳統的通過配置檔案、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求,業界有如下兩種方案:
創業公司前期不需要這種複雜,直接上 zk,弄一個介面管理 zk 的內容,記錄一下所有人的操作日誌,程式直連 zk,或者或者用 Qconf 等基於 zk 優化後的方案。
15、釋出系統/部署系統
從軟體生產的層面看,程式碼到最終服務的典型流程如圖 8 所示:
從上圖中可以看出,從開發人員寫下程式碼到服務終端使用者是一個漫長過程,整體可以分成三個階段:
-
從程式碼(Code)到成品庫(Artifact)這個階段主要對開發人員的程式碼做持續構建並把構建產生的製品集中管理,是為部署系統準備輸入內容的階段。
-
從製品到可執行服務 這個階段主要完成製品部署到指定環境,是部署系統的最基本工作內容。
-
從開發環境到最終生產環境 這個階段主要完成一次變更在不同環境的遷移,是部署系統上線最終服務的核心能力。
16、跳板機
跳板機面對的是需求是要有一種能滿足角色管理與授權審批、資訊資源訪問控制、操作記錄和審計、系統變更和維護控制要求,並生成一些統計報表配合管理規範來不斷提升IT內控的合規性,能對運維人員操作行為的進行控制和審計,對誤操作、違規操作導致的操作事故,快速定位原因和責任人。其功能模組一般包括:帳戶管理、認證管理、授權管理、審計管理等等。
17、機器管理
機器管理的工具選擇的考量可以包含以下三個方面:
如圖9所示:
一般創業公司選擇 Ansible 能解決大部問題,其簡單,不需要安裝額外的客戶端,可以從命令列來執行,不需要使用配置檔案。至於比較複雜的任務,Ansible 配置通過名為 Playbook 的配置檔案中的 YAML 語法來加以處理。Playbook 還可以使用模板來擴充套件其功能。
- 阿里、京東基於DDD的架構設計與最佳實踐
- 天畫-codeMaker元件化架構升級實踐
- 數字化轉型下的銀行雲單元架構
- 聊聊技術人的“績效考核”
- 敏捷效能提升的五大要素與誤區
- 精華:軟體架構模式的7種武器
- 聊聊真正的架構設計
- 業務系統性能問題分析和診斷
- 網站扛住 100 億次請求?我們來壓測試一試
- 解析OpenShift的儲存規劃
- 從0開始搭建公司後臺技術棧,這套架構值得擁有...
- 解密OpenShift內部通訊網路
- 用企業架構下好數字化轉型這盤大棋
- 一個電商供應鏈系統的DDD實戰
- PaaS中OpenShift持久化儲存的管理實踐
- 訊息冪等(去重)通用解決方案,RocketMQ
- “技術 管理”兩條腿走路,才能走得又快又穩
- 盒子科技聚合支付系統演進之路
- 資深架構師談 DDD 興起,解決難題與實現步驟
- 萬字長文剖析 APM 系統?如何設計與實現?