從0開始搭建公司後臺技術棧，這套架構值得擁有...

其中，gRPC 是 Google 開發的高效能、通用的開源 RPC 框架，其由 Google 主要面向移動應用開發並基於 HTTP/2 協議標準而設計，基於 ProtoBuf（Protocol Buffers）序列化協議開發，且支援眾多開發語言。本身它不是分散式的，所以要實現框架的功能需要進一步的開發。

Hprose（High Performance Remote Object Service Engine）是一個 MIT 開源許可的新型輕量級跨語言跨平臺的面向物件的高效能遠端動態通訊中介軟體。

服務治理型的 RPC 框架的特點是功能豐富，提供高效能的遠端呼叫、服務發現及服務治理能力，適用於大型服務的服務解耦及服務治理，對於特定語言(Java)的專案可以實現透明化接入。缺點是語言耦合度較高，跨語言支援難度較大。國內常見的冶理型 RPC 框架如下：

6、名字發現/服務發現

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

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

所謂服務端發現模式是指客戶端通過一個負載均衡器向服務傳送請求，負載均衡器查詢服務登錄檔並把請求路由到一臺可用的服務例項上。現在常用的負載均衡器都是此類模式，常用於微服務中。

所有的名字發現和服務發現都要依賴於一個可用性非常高的服務登錄檔，業界常用的服務登錄檔有如下三個：

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

7、關係資料庫

關係資料庫分為兩種，一種是傳統關係資料，如 Oracle，MySQL，Maria，DB2，PostgreSQL 等等，另一種是 NewSQL，即至少要滿足以下五點的新型關係資料庫：

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

傳統關係資料庫用得最多的是 MySQL，成熟，穩定，一些基本的需求都能滿足，在一定資料量級之前基本單機傳統資料庫都可以搞定，而且現在較多的開源系統都是基於 MySQL，開箱即用，再加上主從同步和前端快取，百萬 pv 的應用都可以搞定了。不過 CentOS 7 已經放棄了 MySQL，而改使用 MariaDB。MariaDB 資料庫管理系統是 MySQ L的一個分支，主要由開源社群在維護，採用 GPL 授權許可。開發這個分支的原因之一是：甲骨文公司收購了 MySQL 後，有將 MySQL 閉源的潛在風險，因此社群採用分支的方式來避開這個風險。

在 Google 釋出了 F1: A Distributed SQL Database That Scales 和 Spanner: Google’s Globally-Distributed Databasa 之後，業界開始流行起 NewSQL。於是有了 CockroachDB，於是有了奇叔公司的 TiDB。國內已經有比較多的公司使用 TiDB，之前在創業公司時在大資料分析時已經開始應用 TiDB，當時應用的主要原因是 MySQL 要使用分庫分表，邏輯開發比較複雜，擴充套件性不夠。

8、NoSQL

NoSQL 顧名思義就是 Not-Only SQL，也有人說是 No – SQL，個人偏向於 Not-Only SQL，它並不是用來替代關係庫，而是作為關係型資料庫的補充而存在。

常見 NoSQL 有4個型別：

除了以上4種類型，還有一些特種的資料庫，如物件資料庫，XML 資料庫，這些都有針對性對某些儲存型別做了優化的資料庫。

在實際應用場景中，何時使用關係資料庫，何時使用 NoSQL，使用哪種型別的資料庫，這是我們在做架構選型時一個非常重要的考量，甚至會影響整個架構的方案。

9、訊息中介軟體

訊息中介軟體在後臺系統中是必不可少的一個元件，一般我們會在以下場景中使用訊息中介軟體：

非同步處理：非同步處理是使用訊息中介軟體的一個主要原因，在工作中最常見的非同步場景有使用者註冊成功後需要傳送註冊成功郵件、快取過期時先返回老的資料，然後非同步更新快取、非同步寫日誌等等；通過非同步處理，可以減少主流程的等待響應時間，讓非主流程或者非重要業務通過訊息中介軟體做集中的非同步處理。
系統解耦：比如在電商系統中，當用戶成功支付完成訂單後，需要將支付結果給通知ERP系統、發票系統、WMS、推薦系統、搜尋系統、風控系統等進行業務處理；這些業務處理不需要實時處理、不需要強一致，只需要最終一致性即可，因此可以通過訊息中介軟體進行系統解耦。通過這種系統解耦還可以應對未來不明確的系統需求。
削峰填谷：當系統遇到大流量時，監控圖上會看到一個一個的山峰樣的流量圖，通過使用訊息中介軟體將大流量的請求放入佇列，通過消費者程式將佇列中的處理請求慢慢消化，達到消峰填谷的效果。最典型的場景是秒殺系統，在電商的秒殺系統中下單服務往往會是系統的瓶頸，因為下單需要對庫存等做資料庫操作，需要保證強一致性，此時使用訊息中介軟體進行下單排隊和流控，讓下單服務慢慢把佇列中的單處理完，保護下單服務，以達到削峰填谷的作用。

業界訊息中介軟體是一個非常通用的東西，大家在做選型時有使用開源的，也有自己造輪子的，甚至有直接用 MySQL 或 Redis 做佇列的，關鍵看是否滿足你的需求，如果是使用開源的專案，以下的表格在選型時可以參考：

圖 3

以上圖的緯度為：名字、成熟度、所屬社群/公司、文件、授權方式、開發語言、支援的協議、客戶端支援的語言、效能、持久化、事務、叢集、負載均衡、管理介面、部署方式、評價。

10、程式碼管理

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

11、持續整合

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

業界免費的持續整合工具中系統我們有如下一些選擇：

12、日誌系統

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

對於常規日誌系統ELK能滿足大部分的需求，ELK 包括如下元件：

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

圖 4，ELK 流程圖

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

圖 5，實時分析系統架構圖

其中：

Flume 是一個分散式、可靠、和高可用的海量日誌採集、聚合和傳輸的日誌收集系統，支援在日誌系統中定製各類資料傳送方，用於收集資料；同時，Flume 提供對資料進行簡單處理，並寫到各種資料接受方（可定製）的能力。
Kafka 是由 Apache 軟體基金會開發的一個開源流處理平臺，由 Scala 和 Java 編寫。其本質上是一個“按照分散式事務日誌架構的大規模釋出/訂閱訊息佇列”，它以可水平擴充套件和高吞吐率而被廣泛使用。

Kafka 追求的是高吞吐量、高負載，Flume 追求的是資料的多樣性，二者結合起來簡直完美。

13、監控系統

監控系統只包含與後臺相關的，這裡主要是兩塊，一個是作業系統層的監控，比如機器負載，IO，網路流量，CPU，記憶體等作業系統指標的監控。另一個是服務質量和業務質量的監控，比如服務的可用性，成功率，失敗率，容量，QPS 等等。常見業務的監控系統先有作業系統層面的監控（這部分較成熟），然後擴展出其它監控，如 Zabbix，小米的 Open-Falcon，也有一出來就是兩者都支援的，如 Prometheus。如果對業務監控要求比較高一些，在創業選型中建議可以優先考慮 Prometheus。這裡有一個有趣的分佈，如圖6所示。

圖 6，監控系統分佈

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

Prometheus 是由 SoundCloud 開發的開源監控報警系統和時序列資料庫（TSDB）。Prometheus 使用 Go 語言開發，是 Google BorgMon 監控系統的開源版本。相對於其它監控系統使用的 push 資料的方式，Prometheus 使用的是 pull 的方式，其架構如圖 7 所示：

圖 7，Prometheus 架構圖

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

創業公司選擇 Prometheus + Grafana 的方案，再加上統一的服務框架（如 gRPC），可以滿足大部分中小團隊的監控需求。

14、配置系統

隨著程式功能的日益複雜，程式的配置日益增多：各種功能的開關、降級開關，灰度開關，引數的配置、伺服器的地址、資料庫配置等等，除此之外，對後臺程式配置的要求也越來越高：配置修改後實時生效，灰度釋出，分環境、分使用者，分叢集管理配置，完善的許可權、稽核機制等等，在這樣的大環境下，傳統的通過配置檔案、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求，業界有如下兩種方案：

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

15、釋出系統/部署系統

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

圖 8，流程圖

從上圖中可以看出，從開發人員寫下程式碼到服務終端使用者是一個漫長過程，整體可以分成三個階段：

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

釋出系統集成了製品管理，釋出流程，許可權控制，線上環境版本變更，灰度釋出，線上服務回滾等幾方面的內容，是開發人員工作結晶最終呈現的重要通道。開源的專案中沒有完全滿足的專案，如果只是 Web 類專案，Walle、Piplin 都是可用的，但是功能不太滿足，創業初期可以整合 Jenkins + Gitlab + Walle（可以考慮兩天時間完善一下），以上方案基本包括製品管理，釋出流程，許可權控制，線上環境版本變更，灰度釋出（需要自己實現），線上服務回滾等功能。

16、跳板機

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

開源專案中，Jumpserver 能夠實現跳板機常見需求，如授權、使用者管理、伺服器基本資訊記錄等，同時又可批量執行指令碼等功能；其中錄影回放、命令搜尋、實時監控等特點，又能幫助運維人員回溯操作歷史，方便查詢操作痕跡，便於管理其他人員對伺服器的操作控制。

17、機器管理

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

如圖9所示：

圖 9，機器管理軟體對比

一般創業公司選擇 Ansible 能解決大部問題，其簡單，不需要安裝額外的客戶端，可以從命令列來執行，不需要使用配置檔案。至於比較複雜的任務，Ansible 配置通過名為 Playbook 的配置檔案中的 YAML 語法來加以處理。Playbook 還可以使用模板來擴充套件其功能。

「其他文章」