如果你當架構師，從0開始，如何做一個背景項目的架構？

▌前言：

在40歲老架構師 尼恩的讀者社群(50+)中，很多小夥伴要拿高薪，這就要面試架構師，要完成架構的更新，進入架構賽道。

在架構師的面試過程中，常常會遇到下面的問題：

如果給你一個項目要你從0到1做架構， 需要從哪些方面展開？

你是怎麼做項目的架構的？

40歲老架構師尼恩，不知道做過多少架構方案。目前尼恩已經專門從事架構師轉型輔導2年了，也不知道指導了多少開發完成了架構師的華麗轉身。

現在，給大家提供一份比較全面的參考答案。使得大家可以充分展示一下大家雄厚的 “技術肌肉”，讓你的主管、同僚愛到 “不能自已、口水直流”。

也一并把這個題目以及參考答案，收入咱們的 《尼恩Java面試寶典》V74版本，供後面的小夥伴參考，提升大家的 3高 架構、設計、開發水準。

最新《尼恩 架構筆記》《尼恩高并發三部曲》、《尼恩Java面試寶典》 的PDF檔案，請到公号【技術自由圈】擷取

▌本文目錄：

- 前言
- 總覽一下：背景技術棧結構
  - 團隊協助基礎工具鍊的選型和教育訓練
    - 40歲老架構師尼恩的建議
  - 搭建微服務開發基礎設施
    - 選擇合适的微服務架構和技術棧
    - 40歲老架構師尼恩的建議
  - 選擇合适的RPC架構
    - 40歲老架構師尼恩的建議
  - 選擇和搭建高可用的注冊中心
    - 40歲老架構師尼恩的建議
  - 選擇和搭建統一配置中心
    - 40歲老架構師尼恩的建議
  - 選擇和搭建高性能的緩存中間件
    - 40歲老架構師尼恩的建議
  - 選擇和搭建高性能的消息中間件
    - 40歲老架構師尼恩的建議
  - 選擇和搭建高性能的關系資料庫
  - 選擇和搭建高性能的NoSQL
  - CICD釋出系統/部署系統的架構
    - 代碼管理工具選型
    - 持續內建工具選型
    - 自動化測試平台的架構
  - 360度全方位監控和維護的架構
    - 日志系統
    - 監控系統
  - 生産環境高并發高吞吐負載均衡部署架構
    - DNS的選型和使用設計
    - LB（負載均衡）的選型和使用設計
    - CDN的選型和使用設計
- 說在最後：有問題可以找老架構取經
- 技術自由的實作路徑 PDF 擷取           

▌總覽一下：背景技術棧結構

如何您是一名團隊的技術負責人，如何從0搭建公司的後端技術棧。

作為40歲的老架構師，如果讓我從零開始搭建公司的後端技術棧，我會按照以下步驟進行：

架構1：團隊協助基礎工具鍊的選型和教育訓練

架構2：搭建微服務開發基礎設施

架構3：選擇合适的RPC架構

架構4：選擇和搭建高可用的注冊中心

架構5：選擇和搭建高可用的配置中心

架構6：選擇和搭建高性能的緩存中間件

架構7：選擇和搭建高性能的消息中間件

架構8：選擇和搭建高性能的關系資料庫

架構9：CICD釋出系統/部署系統的架構

架構10：360度全方位監控和維護的架構

架構11：生産環境高并發高吞吐負載均衡部署架構

整個背景技術架構，主要包括 4 個層面的内容：

• 語言：用了哪些開發語言，如：C++/Java/Go/PHP/Python/Ruby 等等；
• 元件：用了哪些元件，如：MQ 元件，資料庫元件等等；
• 流程：怎樣的流程和規範，如：開發流程，項目流程，釋出流程，監控告警流程，代碼規範等等；
• 系統：系統化建設，上面的流程需要有系統來保證，如：規範釋出流程的釋出系統，代碼管理系統等等；

結合以上的的 4 個層面的内容，

整個背景技術棧的結構如圖1 所示：

圖1 背景技術棧結構

咱們一個個系統群組件的做選型，最終形成我們的背景技術棧。

▌團隊協助基礎工具鍊的選型和教育訓練

團隊協助基礎工具鍊， 主要是三大管理

• 項目管理
• 任務管理
• 問題管理

項目管理軟體是整個業務的需求，問題，流程等等的集中地，大家的跨部門溝通協同大多依賴于項目管理工具。

有一些 SaaS 的項目管理服務可以使用，但是很多時間不滿足需求，此時我們可以選擇一些開源的項目，這些項目本身有一定的定制能力，有豐富的插件可以使用，一般的創業公司需求基本上都能得到滿足，常用的項目如下：

• Jira：用 Java 開發的，有使用者故事，task 拆分，燃盡圖等等，可以做項目管理，也可以應用于跨部門溝通場景，較強大；
• Redmine：用 Ruby 開發的，有較多的插件可以使用，能自定義字段，內建了項目管理，Bug 問題跟蹤，WIKI 等功能，不過好多插件 N 年沒有更新了；
• Phabricator：用 PHP 開發的，Facebook 之前的内部工具，開發這工具的哥們離職後自己搞了一個公司專門做這個軟體，內建了代碼托管， Code Review，任務管理，文檔管理，問題跟蹤等功能，強烈推薦較靈活的團隊使用；

▌40歲老架構師尼恩的建議

尼恩都用過，目前建議是 Jira

▌搭建微服務開發基礎設施

搭建微服務開發基礎設施需要考慮多個方面，包括但不限于以下幾點：

1. 選擇合适的微服務架構和技術棧：目前比較流行的微服務架構有 Spring Cloud、Go-Micro、gRPC 等，選擇适合自己團隊技術棧的架構非常重要。
2. 選擇合适的RPC架構
3. 建構基礎設施：包括但不限于服務注冊與發現、負載均衡、API 網關、分布式配置中心、分布式鎖、消息隊列等。
4. 安全：包括但不限于服務間通信的加密、通路控制、身份認證等。

在搭建微服務開發基礎設施之前，需要對自己的業務場景進行分析和規劃，确定需要哪些基礎設施和技術棧，然後再逐漸實作。同時，需要注重可擴充性和可維護性，以便在業務發展過程中能夠快速适應變化。

▌選擇合适的微服務架構和技術棧

選擇合适的微服務架構和技術棧需要考慮多個因素，包括以下幾個方面：

1. 業務需求：不同的業務需求需要不同的技術棧和架構來支援。比如，如果需要高并發和高可用性，可以選擇使用 Go 語言和 Kubernetes 等技術來建構微服務。
2. 開發團隊技能：選擇的技術棧和架構應該符合開發團隊的技能水準，以便開發人員能夠快速上手并高效開發。
3. 社群支援：選擇流行的技術棧和架構可以獲得更好的社群支援，能夠更快地解決問題和獲得更新的功能。
4. 性能和穩定性：選擇的技術棧和架構應該具有良好的性能和穩定性，以便能夠支援高負載和長時間運作。

常見的微服務架構和技術棧包括：

1. Spring Cloud：适用于 Java 開發團隊，具有豐富的功能和社群支援。
2. Go Micro：适用于 Go 開發團隊，具有高性能和簡單易用的特點。
3. Node.js + Express：适用于 JavaScript 開發團隊，具有輕量級和快速開發的特點。
4. Kubernetes：适用于需要高可用性和彈性的微服務架構，可以支援多種程式設計語言和架構。
5. Istio：适用于需要服務網格功能的微服務架構，可以提供流量管理、安全性和可觀察性等功能。

在選擇時，需要根據具體的業務需求和開發團隊技能來選擇合适的微服務架構和技術棧。

▌40歲老架構師尼恩的建議

40歲老架構師尼恩的建議，建議選用 SpringCloud Alibaba+ Dubbo RPC + Dubbo-Go，兩個原因：

（1） 高性能： 尼恩的性能測試案例中， Dubbo比Feign性能 強10倍， 具體請參見尼恩部落格

（2） 兼顧團隊技術棧： 可以跨Go 和Java 多語言微服務架構，Java技術棧的同學們，可以基于 Java開發業務微服務，這塊側重業務開發。Go 技術棧的同學們，可以基于 Go 開發高性能的 技術微服務，這塊側重技術開發和性能優化。

（3）功能和性能兼顧： Java側重功能的快速開發， Go側重性能的快速提升。

基于以上架構，尼恩指導了一個6年小夥伴，拿到了年薪 60W的offer。

▌選擇合适的RPC架構

維基百科對 RPC 的定義是：遠端過程調用（Remote Procedure Call，RPC）是一個計算機通信協定。該協定允許運作于一台計算機的程式調用另一台計算機的子程式，而程式員無需額外地為這個互動作用程式設計。

通俗來講，一個完整的 RPC 調用過程，就是 Server 端實作了一個函數，用戶端使用 RPC 架構提供的接口，調用這個函數的實作，并擷取傳回值的過程。

業界 RPC 架構大緻分為兩大流派，一種側重跨語言調用，另一種是偏重服務治理。

跨語言調用型RPC：

跨語言調用型的 RPC 架構有 Thrift、gRPC、Hessian、Hprose 等。這類 RPC 架構側重于服務的跨語言調用，能夠支援大部分的語言進行語言無關的調用，非常适合多語言調用場景。但這類架構沒有服務發現相關機制，實際使用時需要代理層進行請求轉發和負載均衡政策控制。

其中，gRPC 是 Google 開發的高性能、通用的開源 RPC 架構，其由 Google 主要面向移動應用開發并基于 HTTP/2 協定标準而設計，基于 ProtoBuf（Protocol Buffers）序列化協定開發，且支援衆多開發語言。本身它不是分布式的，是以要實作架構的功能需要進一步的開發。

Hprose（High Performance Remote Object Service Engine）是一個 MIT 開源許可的新型輕量級跨語言跨平台的面向對象的高性能遠端動态通訊中間件。

冶理型 RPC：

服務治理型的 RPC 架構的特點是功能豐富，提供高性能的遠端調用、服務發現及服務治理能力，适用于大型服務的服務解耦及服務治理，對于特定語言(Java)的項目可以實作透明化接入。缺點是語言耦合度較高，跨語言支援難度較大。

國内常見的冶理型 RPC 架構如下：

• Dubbo：Dubbo 是阿裡巴巴公司開源的一個 Java 高性能優秀的服務架構，使得應用可通過高性能的 RPC 實作服務的輸出和輸入功能，可以和 Spring 架構無縫內建。當年在淘寶内部，Dubbo 由于跟淘寶另一個類似的架構 HSF 有競争關系，導緻 Dubbo 團隊解散，最近又活過來了，有專職同學投入。
• DubboX：DubboX 是由當當在基于 Dubbo 架構擴充的一個 RPC 架構，支援 REST 風格的遠端調用、Kryo/FST 序列化，增加了一些新的feature。Motan：Motan 是新浪微網誌開源的一個 Java 架構。它誕生的比較晚，起于 2013 年，2016 年 5 月開源。Motan 在微網誌平台中已經廣泛應用，每天為數百個服務完成近千億次的調用。
• rpcx：rpcx 是一個類似阿裡巴巴 Dubbo 和微網誌 Motan 的分布式的 RPC 服務架構，基于 Golang net/rpc 實作。

但是 rpcx 基本隻有一個人在維護，沒有完善的社群，使用前要慎重。

▌40歲老架構師尼恩的建議

40歲老架構師尼恩的建議，建議選用Dubbo，兩個原因：

（1） 高性能： 尼恩的性能測試案例中， Dubbo比Feign性能 強10倍， 具體請參見尼恩部落格

（2） 跨語言： 可以跨Go 和Java 進行 雙語言的 RPC調用，進而實作 多語言微服務架構。

▌選擇和搭建高可用的注冊中心

名字發現和服務發現分為兩種模式，一個是用戶端發現模式，一種是服務端發現模式。架構中常用的服務發現是用戶端發現模式。

所謂服務端發現模式是指用戶端通過一個負載均衡器向服務發送請求，負載均衡器查詢服務系統資料庫并把請求路由到一台可用的服務執行個體上。現在常用的負載均衡器都是此類模式，常用于微服務中。

所有的名字發現和服務發現都要依賴于一個可用性非常高的服務系統資料庫，業界常用的服務系統資料庫有如下三個：

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

Consul，一個發現和配置服務的工具，為用戶端注冊和發現服務提供了API，Consul還可以通過執行健康檢查決定服務的可用性。

Apache ZooKeeper，是一個廣泛使用、高性能的針對分布式應用的協調服務。Apache ZooKeeper 本來是 Hadoop 的子工程，現在已經是頂級工程了。

除此之外還有eureka, nacos等，大家可以根據相關的元件特性，選擇适合自己的元件。

選擇和搭建高可用的注冊中心，需要考慮以下幾個方面：

1. 功能需求：選擇注冊中心時，需要根據自己的業務需求來選擇，比如服務發現、負載均衡、配置管理等。
2. 性能要求：注冊中心需要具備高性能，能夠支援高并發、高吞吐量的請求。
3. 可用性要求：注冊中心需要具備高可用性，能夠保證24小時不間斷運作，避免因為單點故障導緻整個系統不可用。
4. 安全要求：注冊中心需要具備一定的安全性，能夠保證資料的機密性和完整性，避免資料洩露和篡改。

常見的注冊中心有 ZooKeeper、Etcd、Consul 等，它們都具備高可用性和安全性，并且都支援服務發現和配置管理等功能。其中，ZooKeeper 是最早的分布式協調服務，具備成熟的生态系統和廣泛的應用場景；Etcd 是 CoreOS 推出的開源分布式鍵值存儲系統，具備高可用性和一緻性保證；Consul 是 HashiCorp 推出的服務發現和配置管理工具，具備易用性和可擴充性。

在搭建高可用的注冊中心時，需要采用cluster部署的方式，避免單點故障。同時，為了保證資料的安全性，可以啟用 SSL/TLS 加密功能，并采用通路控制機制來限制通路權限。

▌40歲老架構師尼恩的建議

尼恩都用過，目前建議是 高可用的nacos，也就是 nacos+mysql的版本

具體請參見尼恩的架構筆記

▌選擇和搭建統一配置中心

随着程式功能的日益複雜，程式的配置日益增多：各種功能的開關、降級開關，灰階開關，參數的配置、伺服器的位址、資料庫配置等等，除此之外，對背景程式配置的要求也越來越高：配置修改後實時生效，灰階釋出，分環境、分使用者，分cluster管理配置，完善的權限、稽核機制等等，在這樣的大環境下，傳統的通過配置檔案、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求，需要統一的、基礎的配置系統

統一配置系統是指在一個大型系統中，将所有的配置資訊集中管理，以便于對系統進行管理和維護。常見的統一配置系統架構包括以下幾個元件：

1. 配置中心：用于存儲和管理所有的配置資訊，提供配置查詢、修改、删除等功能。
2. 配置用戶端：用于從配置中心擷取配置資訊，并将其應用到系統中。
3. 配置釋出工具：用于将配置資訊釋出到配置中心，以便于配置用戶端擷取。
4. 配置管理工具：用于對配置資訊進行管理和維護，包括配置的新增、修改、删除等操作。
5. 配置監控工具：用于監控配置資訊的變化，及時發現并處理配置資訊的異常情況。

在實際應用中，可以選擇使用開源的配置中心工具，如 ZooKeeper、Etcd、Consul 、Nacos、Apollo等，也可以自己開發一套配置中心系統。

同時，還需要根據實際情況選擇合适的配置用戶端和配置釋出工具。在配置管理和監控方面，可以使用一些開源的工具或者自己開發一套系統。總之，統一配置系統的架構需要根據實際需求進行設計和選擇。

▌40歲老架構師尼恩的建議

尼恩都用過，目前建議是 高可用的nacos，也就是 nacos+mysql的版本

具體請參見尼恩的架構筆記

▌選擇和搭建高性能的緩存中間件

選擇和搭建高性能的緩存中間件需要考慮多個因素，包括性能、可靠性、可擴充性、易用性等。以下是一些常見的高性能緩存中間件：

1. Redis：Redis 是一個開源的高性能緩存和鍵值存儲系統，支援多種資料結構，包括字元串、哈希、清單、集合和有序集合等。Redis 通過将資料存儲在記憶體中來提高性能，同時支援資料持久化和cluster模式。
2. Memcached：Memcached 是一個開源的高性能分布式記憶體對象緩存系統，可以緩存任何可序列化的資料，如資料庫查詢結果、API 響應等。Memcached 可以通過多個節點組成的cluster來提高可擴充性和可靠性。
3. Hazelcast：Hazelcast 是一個開源的分布式記憶體資料網格系統，支援緩存、分布式資料結構和分布式計算等功能。Hazelcast 可以通過多個節點組成的cluster來提高可擴充性和可靠性。
4. Couchbase：Couchbase 是一個開源的分布式 NoSQL 資料庫和緩存系統，可以緩存任何類型的資料，包括 JSON 文檔、鍵值對和二進制資料等。Couchbase 支援多個節點組成的cluster和資料持久化等功能。

在搭建高性能緩存中間件時，需要考慮以下幾個方面：

1. 硬體配置：緩存中間件需要占用大量記憶體，是以需要配置足夠的記憶體和處理器資源。
2. 部署架構：需要考慮緩存中間件的部署架構，如單節點、主從複制、cluster等。
3. 資料持久化：需要考慮資料持久化的方式，如記憶體快照、AOF 日志、RDB 檔案等。
4. 安全性：需要考慮緩存中間件的安全性，如通路控制、資料加密等。
5. 監控和管理：需要考慮緩存中間件的監控和管理，如性能監控、故障診斷等。

總之，選擇和搭建高性能緩存中間件需要綜合考慮多個因素，根據具體需求和場景進行選擇和配置。

▌40歲老架構師尼恩的建議

尼恩都用過，目前建議是 高可用的redis cluster，具體請參見尼恩的架構筆記

要特别注意的是， redis 關系到系統的 高可用， 很容易出生産事故。

如果 redis 出現bigkey，在 高并發場景下， 很容易出現 系統癱瘓， 嚴重影響系統的可用性， 昨天有小夥伴來求助，他們的redis bigkey問題，導緻他們的系統癱瘓一小時， 經濟損失 幾百萬，間接損失 幾千萬。

我在社群裡邊說了一下這個問題之後，還有兩個小夥伴說，他們也遇到過，都是生産事故。

如果對big key 進行探測和解決，具體請參見尼恩的架構筆記

▌選擇和搭建高性能的消息中間件

消息中間件在背景系統中是必不可少的一個元件，一般我們會在以下場景中使用消息中間件：

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

業界消息中間件是一個非常通用的東西，大家在做選型時有使用開源的，也有自己造輪子的，甚至有直接用 MySQL 或 Redis 做隊列的，關鍵看是否滿足你的需求.

選擇合适的消息中間件需要考慮多個因素，包括但不限于：

• 需要處理的消息數量和頻率
• 消息的大小和格式
• 可用性和容錯性要求
• 資料安全性和加密需求
• 擴充性和靈活性要求

• 開發語言和技術棧的相容性

  常見的消息中間件包括RocketMQ、Kafka、 RabbitMQ、Kafka、ActiveMQ、Redis、NATS 等，每種中間件都有其特點和适用場景。

如果需要處理大量的消息并且需要高吞吐量和低延遲，可以考慮使用 Kafka。如果需要實時處理消息并且需要高可用性和容錯性，可以考慮使用 RabbitMQ。如果需要處理輕量級的消息，并且需要高性能和低延遲，可以考慮使用 Redis。

在選擇消息中間件時，需要根據具體的業務需求和技術棧進行綜合考慮，選擇最合适的中間件。

▌40歲老架構師尼恩的建議

尼恩都用過，目前建議 kafka + RocketMQ

具體請參見尼恩的架構筆記 , 以及尼恩的 穿透 RocketMQ 源碼和架構的 四部曲

▌選擇和搭建高性能的關系資料庫

關系資料庫分為兩種，一種是傳統關系資料，如 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 要使用分庫分表，邏輯開發比較複雜，擴充性不夠。

▌選擇和搭建高性能的NoSQL

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

常見 NoSQL 有4個類型：

• 鍵值，适用于内容緩存，适合混合工作負載并發高擴充要求大的資料集，其優點是簡單，查詢速度快，缺點是缺少結構化資料，常見的有 Redis，Memcache，BerkeleyDB 和 Voldemort 等等；
• 列式，以列簇式存儲，将同一列資料存在一起，常見于分布式的檔案系統，其中以 Hbase，Cassandra 為代表。Cassandra 多用于寫多讀少的場景，國内用得比較多的有 360，大概 1500 台機器的cluster，國外大規模使用的公司比較多，如 eBay，Instagram，Apple 和沃爾瑪等等；
• 文檔，資料存儲方案非常适用承載大量不相關且結構差别很大的複雜資訊。性能介于 kv 和關系資料庫之間，它的靈感來于 lotus notes，常見的有 MongoDB，CouchDB 等等；
• 圖形，圖形資料庫擅長處理任何涉及關系的狀況。社交網絡，推薦系統等。專注于建構關系圖譜，需要對整個圖做計算才能得出結果，不容易做分布式的cluster方案，常見的有 Neo4J，InfoGrid 等。

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

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

▌CICD釋出系統/部署系統的架構

軟體生産的層面看，代碼到最終服務的典型流程如圖2 所示：

圖2 流程圖

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

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

釋出系統內建了制品管理，釋出流程，權限控制，線上環境版本變更，灰階釋出，線上服務復原等幾方面的内容，是開發人員工作結晶最終呈現的重要通道。

CI/CD 釋出系統/部署系統的架構通常包括以下元件：

• 源代碼管理系統：例如 Git、SVN 等，用于管理代碼庫。
• 持續內建工具：例如 Jenkins、GitLab CI、Travis CI 等，用于自動化建構、測試和打包應用程式。
• 制品倉庫：例如 Docker Hub、Harbor、Aliyun Container Registry 等，用于存儲應用程式的鏡像。
• 部署工具：例如 Kubernetes、Docker Swarm、Mesos 等，用于自動化部署應用程式。

這些元件可以根據實際需求進行選擇群組合，形成一個完整的 CI/CD 釋出系統/部署系統。

其中，持續內建工具和部署工具是核心元件，它們負責自動化建構、測試、打包和部署應用程式，進而實作快速、可靠、可重複的軟體釋出流程。

項目初期可以內建 Jenkins + Gitlab + Harbor，以上方案基本包括制品管理，釋出流程，權限控制，線上環境版本變更，灰階釋出（需要自己實作），線上服務復原等功能。

▌代碼管理工具選型

代碼是項目的命脈之一，代碼管理很重要，常見的考量點包括兩塊：

安全和權限管理，将代碼放到内網并且對于關系公司命脈的核心代碼做嚴格的代碼控制和機器的實體隔離；

代碼管理工具，Git 作為代碼管理的不二之選，你值得擁有。

GitLab 是當今最火的開源 Git 托管服務端，沒有之一，雖然有企業版，但是其社群版基本能滿足我們大部分需求，結合 Gerrit 做 Code review，基本就完美了。

當然 GitLab 也有代碼對比，但沒 Gerrit 直覺。

Gerrit 比 GitLab 提供了更好的代碼檢查界面與主線管理體驗，更适合在對代碼品質有高要求的文化下使用。

▌持續內建工具選型

持續內建簡，稱 CI（continuous integration），是一種軟體開發實踐，即團隊開發成員經常內建他們的工作，每天可能會發生多次內建。

每次內建都通過自動化的建構（包括編譯，釋出，自動化測試）來驗證，進而盡早地發現內建錯誤。

持續內建為研發流程提供了代碼分支管理/比對、編譯、檢查、釋出物輸出等基礎工作，為測試的覆寫率版本編譯、生成等提供統一支援。

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

• Jenkins：Java 寫的有強大的插件機制，MIT 協定開源 （免費，定制化程度高，它可以在多台機器上進行分布式地建構和負載測試）。Jenkins 可以算是無所不能，基本沒有 Jenkins 做不了的，無論從小型團隊到大型團隊 Jenkins 都可以搞定。不過如果要大規模使用，還是需要有人力來學習和維護。
• TeamCity：TeamCity 與 Jenkins 相比使用更加友好，也是一個高度可定制化的平台。但是用的人多了，TeamCity就要收費了。
• Strider：Strider 是一個開源的持續內建和部署平台，使用 Node.js 實作，存儲使用的是 MongoDB，BSD 許可證，概念上類似 Travis 和Jenkins。

• GitLab CI：從GitLab 8.0開始，GitLab CI 就已經內建在 GitLab，我們隻要在項目中添加一個 .gitlab-ci.yml 檔案，然後添加一個 Runner，即可進行持續內建。并且 GitLab 與 Docker 有着非常好的互相協作的能力。

  免費版與付費版本不同可以參見這裡：https://about.gitlab.com/products/feature-comparison/。

• Travis：Travis 和 GitHub 強關聯；閉源代碼使用 SaaS 還需考慮安全問題；不可定制；開源項目免費，其它收費。
• Go：Go 是 ThoughtWorks 公司最新的 Cruise Control 的化身。除了 ThoughtWorks 提供的商業支援，Go 是免費的。它适用于 Windows，Mac 和各種 Linux 發行版。

▌自動化測試平台的架構

接下來，就是自動化測試平台的搭建。

搭建自動化測試平台需要考慮以下幾個方面：

1. 選擇合适的測試架構和工具：可以選擇一些流行的測試架構和工具，如Selenium、Appium、JMeter等，根據需要選擇适合自己的工具。
2. 搭建測試環境：需要搭建測試環境，包括測試伺服器、測試資料庫、測試資料等。可以使用虛拟機或者容器來搭建測試環境，以便進行測試。
3. 編寫測試用例：需要編寫測試用例，測試用例應該覆寫系統的各個功能點，以便發現潛在的問題。
4. 內建測試工具和測試用例：将測試工具和測試用例內建到自動化測試平台中，以便進行自動化測試。
5. 運作測試用例：編寫好測試用例後，需要運作測試用例，收集測試結果，并生成測試報告。
6. 定期維護和更新：自動化測試平台需要定期維護和更新，以保證測試環境的穩定性和測試用例的有效性。

以上是搭建自動化測試平台的一般步驟，具體實作方式還需要根據實際情況進行調整。

可以結合 SpringBoot + TestNG 測試架構，搭建自己的 自動化測試平台

TestNG 是一個開源自動化測試架構;

TestNG 靈感來自 JUnit 和 NUnit，但引入了一些新的功能，使其功能更強大，使用更友善。

TestNG表示下一代(Next Generation的首字母)。

TestNG類似于 JUnit (特别是 JUnit 4)，但它不是JUnit架構的擴充。它的目的是優于 JUnit ，尤其是在用于測試內建多類時。

TestNG的創始人是 Cedric Beust (塞德裡克·博伊斯特)。

TestNG消除了大部分的舊架構的限制，使開發人員能夠編寫更加靈活和強大的測試。 因為它在很大程度上借鑒了Java注解( JDK5.0引入的)來定義測試，它也可以顯示如何使用這個新功能在真實的 Java 語言生産環境中。

40歲老架構師尼恩提示，不用自己從0到1 去搭建自動化測試平台，可以基于開源的自動化測試平台進行改造。

下面的兩個 測試平台，就是非常好的 改造項目：

• 接口自動化測試架構（java httpClient + testNg）

  ChenSen5/api_autotest：https://github.com/ChenSen5/api_autotest

• 基于SpringBoot的高效模闆化自動化測試架構

  jinganglong123/jg-api-autotest：https://github.com/jinganglong123/jg-api-autotest

▌360度全方位監控和維護的架構

360度全方位監控和維護的架構包括

• 日志系統
• 監控系統

▌日志系統

日志系統一般包括打日志，采集，中轉，收集，存儲，分析，呈現，搜尋還有分發等。

一些特殊的如染色，全鍊條跟蹤或者監控都可能需要依賴于日志系統實作。

日志系統的建設不僅僅是工具的建設，還有規範群組件的建設，最好一些基本的日志在架構群組件層面加就行了，比如全連結跟蹤之類的。

對于正常日志系統ELK能滿足大部分的需求，ELK 包括如下元件：

ElasticSearch 是個開源分布式搜尋引擎，它的特點有：分布式，零配置，自動發現，索引自動分片，索引副本機制，RESTful 風格接口，多資料源，自動搜尋負載等。

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

Kibana 是一個開源和免費的工具，它可以為 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以幫助彙總、分析和搜尋重要資料日志。

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

因為免費的 ELK 沒有任何安全機制，是以這裡使用了 Nginx 作反向代理，避免使用者直接通路 Kibana 伺服器。

加上配置 Nginx 實作簡單的使用者認證，一定程度上提高安全性。

另外，Nginx 本身具有負載均衡的作用，能夠提高系統通路性能。

ELK 架構如圖3 所示：

圖3 ELK 流程圖

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

圖4 實時分析系統架構圖

其中：

Flume 是一個分布式、可靠、和高可用的海量日志采集、聚合和傳輸的日志收集系統，支援在日志系統中定制各類資料發送方，用于收集資料；同時，Flume 提供對資料進行簡單處理，并寫到各種資料接受方（可定制）的能力。

Kafka 是由 Apache 軟體基金會開發的一個開源流處理平台，由 Scala 和 Java 編寫。其本質上是一個“按照分布式事務日志架構的大規模釋出/訂閱消息隊列”，它以可水準擴充和高吞吐率而被廣泛使用。

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

▌監控系統

監控系統隻包含與背景相關的，這裡主要是兩塊，一個是作業系統層的監控，比如機器負載，IO，網絡流量，CPU，記憶體等作業系統名額的監控。

另一個是服務品質和業務品質的監控，比如服務的可用性，成功率，失敗率，容量，QPS 等等。

常見業務的監控系統先有作業系統層面的監控（這部分較成熟），然後擴充出其它監控，如 Zabbix，小米的 Open-Falcon，也有一出來就是兩者都支援的，如 Prometheus。

如果對業務監控要求比較高一些，在創業選型中建議可以優先考慮 Prometheus。

這裡有一個有趣的分布，如圖5 所示。

圖5 監控系統分布

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

Prometheus 是由 SoundCloud 開發的開源監控報警系統和時序列資料庫（TSDB）。

Prometheus 使用 Go 語言開發，是 Google BorgMon 監控系統的開源版本。

相對于其它監控系統使用的 push 資料的方式，Prometheus 使用的是 pull 的方式，其架構如圖6 所示：

圖6 Prometheus 架構圖

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

• Prometheus Server：主要負責資料采集和存儲，提供 PromQL 查詢語言的支援。
• Server：通過配置檔案、文本檔案、ZooKeeper、Consul、DNS SRV Lookup 等方式指定抓取目标。
• 根據這些目标會，Server 定時去抓取 metrics 資料，每個抓取目标需要暴露一個 http 服務的接口給它定時抓取。
• 用戶端 SDK：官方提供的用戶端類庫有 Go、Java、Scala、Python、Ruby，其他還有很多第三方開發的類庫，支援 Nodejs、PHP、Erlang 等。
• Push Gateway：支援臨時性 Job 主動推送名額的中間網關。
• Exporter Exporter：是 Prometheus 的一類資料采集元件的總稱。它負責從目标處搜集資料，并将其轉化為 Prometheus 支援的格式。
• 與傳統的資料采集元件不同的是，它并不向中央伺服器發送資料，而是等待中央伺服器主動前來抓取。
• Prometheus：提供多種類型的 Exporter 用于采集各種不同服務的運作狀态。目前支援的有資料庫、硬體、消息中間件、存儲系統、HTTP 伺服器、JMX 等。
• Alertmanager：是一個單獨的服務，可以支援 Prometheus 的查詢語句，提供十分靈活的報警方式。
• Prometheus HTTP API 的查詢方式，自定義所需要的輸出。
• Grafana：是一套開源的分析監視平台，支援 Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch 等資料源，其 UI 非常漂亮且高度定制化。

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

▌生産環境高并發高吞吐負載均衡部署架構

高并發高吞吐負載均衡鍊路架構,包括：

• DNS的選型和使用設計
• LB（負載均衡）的選型和使用設計
• CDN的選型和使用設計

▌DNS 的選型和使用設計

DNS 是一個很通用的服務，創業公司基本上選擇一個合适的雲廠商就行了，國内主要是兩家：

阿裡萬網：阿裡 2014 年收購了萬網，整合了其域名服務，最終形成了現在的阿裡萬網，其中就包含 DNS 這塊的服務；

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

如果你的業務是在國内，主要就是這兩家，選 一個就好，像今日頭條這樣的企業用的也是 DNSPod 的服務，除非一些特殊的原因才需要自建，比如一些 CDN 廠商，或者對區域有特殊限制的。

要實惠一點用阿裡最便宜的基礎版就好了，要成功率高一些，還是用 DNSPod 的貴的那種。

在國外還是選擇亞馬遜吧，阿裡的 DNS 服務隻有在日本和美國有節點，東南亞最近才開始部點， DNSPod 也隻有美國和日本，像一些出海的企業，其選擇的雲服務基本都是亞馬遜。

如果是線上産品，DNS 強烈建議用付費版，阿裡的那幾十塊錢的付費版基本可以滿足需求。如果還需要一些按省份或按區域調試的邏輯，則需要加錢，一年也就幾百塊，省錢省力。

如果是國外，優先選擇亞馬遜，如果需要國内外互通并且有自己的 APP 的話，建議還是自己實作一些容災邏輯或者智能排程，因為沒有一個現成的 DNS 服務能同時較好的滿足國内外場景，或者用多個域名，不同的域名走不同的 DNS 。

▌LB（負載均衡）的選型和使用設計

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

• 支援四層協定請求（包括 TCP、UDP 協定）；
• 支援七層協定請求（包括 HTTP、HTTPS 協定）；
• 集中化的證書管理系統支援 HTTPS 協定；
• 健康檢查；

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

▌CDN 的選型和使用設計

CDN 現在已經是一個很紅很紅的市場，基本上隻能掙一些辛苦錢，都是貼着成本在賣。國内以網宿為龍頭，他們家占據整個國内市場佔有率的 40% 以上，後面就是騰訊，阿裡。網宿有很大一部分是因為直播的興起而崛起。

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

國内出海的 CDN 廠商，更多的是為國内的出海企業服務，三家大一點的 CDN 服務商裡面也就網宿的節點多一些，但是也多不了多少。阿裡和騰訊還處于前期階段，僅少部分國家有節點。

就創業公司來說，CDN 用騰訊雲或阿裡雲即可，其相關系統較完善，能輕松接入，網宿在系統支援層面相對較弱一些，而且還貴一些。并且，當流量上來後，CDN 不能隻用一家，需要用多家，不同的 CDN 在全國的節點覆寫不一樣，而且針對不同的客戶雲廠商内部有些區分客戶cluster，并不是全節點覆寫（但有些雲廠商說自己是全網節點），除了節點覆寫的問題，多 CDN 也在一定程度上起到容災的作用。

▌說在最後：有問題可以找老架構取經

架構之路，充滿了坎坷

架構和進階開發不一樣 ， 架構的問題是open的，開發式的，沒有标準答案的

在做架構過程中，或者在轉型過程中，如果遇到複雜的場景，确實不知道怎麼做架構方案，确實找不到有底的方案，怎麼辦？

可以來找40歲老架構尼恩求助.

昨天一個小夥伴，他們要進行 電商網站的黃金鍊路架構， 開始找不到思路，但是經過尼恩 10分鐘語音指導，一下就豁然開朗。

▌技術自由的實作路徑 PDF 擷取：

▌實作你的架構自由：

• 《吃透8圖1模闆，人人可以做架構》PDF
• 《10Wqps評論中台，如何架構？B站是這麼做的！！！》PDF
• 《阿裡二面：千萬級、億級資料，如何性能優化？ 教科書級 答案來了》PDF
• 《峰值21WQps、億級DAU，小遊戲《羊了個羊》是怎麼架構的？》PDF
• 《100億級訂單怎麼排程，來一個大廠的極品方案》PDF
• 《2個大廠 100億級 超大流量 紅包 架構方案》PDF

… 更多架構文章，正在添加中

▌實作你的 響應式 自由：

• 《響應式聖經：10W字，實作Spring響應式程式設計自由》PDF
• 這是老版本 《Flux、Mono、Reactor 實戰（史上最全）》PDF

▌實作你的 spring cloud 自由：

• 《Spring cloud Alibaba 學習聖經》 PDF
• 《分庫分表 Sharding-JDBC 底層原理、核心實戰（史上最全）》PDF
• 《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關系（史上最全）》PDF

▌實作你的 linux 自由：

• 《Linux指令大全：2W多字，一次實作Linux自由》PDF

▌實作你的 網絡 自由：

• 《TCP協定詳解 (史上最全)》PDF
• 《網絡三張表：ARP表, MAC表, 路由表，實作你的網絡自由！！》PDF

▌實作你的 分布式鎖 自由：

• 《Redis分布式鎖（圖解 - 秒懂 - 史上最全）》PDF
• 《Zookeeper 分布式鎖 - 圖解 - 秒懂》PDF

▌實作你的 王者元件 自由：

• 《隊列之王： Disruptor 原理、架構、源碼 一文穿透》PDF
• 《緩存之王：Caffeine 源碼、架構、原理（史上最全，10W字 超級長文）》PDF
• 《緩存之王：Caffeine 的使用（史上最全）》PDF
• 《Java Agent 探針、位元組碼增強 ByteBuddy（史上最全）》PDF

▌實作你的 面試題 自由：

4000頁《尼恩Java面試寶典》PDF 40個專題

....

注：以上尼恩 架構筆記、面試題 的PDF檔案，請到【技術自由圈】公号擷取

還需要啥自由，可以告訴尼恩。 尼恩幫你實作.......