一張圖理解微服務架構設計

前言

當前，微服務架構在很多公司都已經落地實施了，下面用一張圖簡要概述下微服務架構設計中常用組件。不能說已經使用微服務好幾年了，結果對微服務架構沒有一個整體的認知，一個只懂搬磚的程序員不是一個好碼農。

流量入口 Nginx

在上圖中可以看到，Nginx 作爲整個架構的流量入口，可以理解爲一個外部的網關，它承擔着請求的路由轉發、負載均衡、動靜分離等功能。作爲一個核心入口點，Nginx 肯定要採用多節點部署，同時通過 keepalived 來實現高可用，從而保障整個平臺的高可用。

網關

網關是在 Nginx 後的另外一個核心組件。它承擔着請求鑑權，路由轉發，協議轉換，流量監控等一系列功能，上圖中網關是採用 spring Cloud Gateway 來實現業務網關的功能。

在網關選型中，我們還有其他的選擇，比如 Zuul1,Zuul2,Kong 等等，這些方案都有自己的優勢和侷限性，我們可以根據自己他們的特點來抉擇到底選用哪一個方案。對於網關的深入瞭解，可以參見之前的系列文章網關那點事，這裏不做贅述。

上圖中，Spring Cloud Gateway 下面有 jwt 和 OAuth2，其實這兩個就是基於 token 的認證鑑權，一般互聯網項目中，在登錄模塊都是支持微信或者 qq 登錄，這就是用到 OAuth2 的授權登錄。想深入瞭解 Oauth2 相關細節，可以參考之前的 Oauth2.0 客戶端服務端示例等系列文章。

業務組件

從上面的架構圖中可以看到，網關之後就是我們的業務組件了，可以理解就是拆分之後的微服務了，比如電商平臺常見的賬號服務、訂單服務、發票服務、收銀臺服務等等。

服務組件之間通過 Feign 來進行 http 調用，Feign 集成 Ribbon 來實現客戶端側負載均衡。具體的服務領域劃分，服務限界上下文的設定，這就另外的知識了，如果想做好服務劃分，DDD 領域驅動設計這塊可以深入瞭解下。

服務註冊中心

不管是基於 Dubbo 實現的 SOA，還是基於 Spring Cloud 拆分的微服務架構，服務註冊中心都是必須的，我們把所有的服務組件都註冊到註冊中心，進而實現服務的動態調用。

常見能實現註冊中心功能的有 Zookeeper,Eureka,Nacos,Zookeeper 在 Dubbo 中使用比較多，目前公司服務微服務架構是基於 Eureka 的，Eureka 好像目前不維護了。

一般新的平臺建議直接集成 Nacos，Nacos 除了能做註冊中心來使用，也可以作爲分佈式配置中心來使用，比 Sping Cloud Config 更好使。

緩存和分佈式鎖

在圖中左下角，我們可以看到 Redis 組件，我們可以把 Redis 作爲緩存來使用，把一些查詢慢，使用率高的熱點數據做緩存處理，能快速提高接口響應時間。同時 redis 在微服務中的一大使用場景就是分佈式鎖，傳統的 Sychronized 和顯示 Lock 鎖顯然是不能解決分佈式併發問題。

爲了保障 Redis 的高可用，可以採用哨兵部署，不是三個 redis 節點，一主二從，同時部署三個哨兵節點，來實現故障轉移，避免單點問題，如果 Redis 存儲的數據量很大，達到了單節點的 Redis 的性能瓶頸，我們也可以用 Redis 集羣模式來實現分佈式存儲。

數據持久層

不管單體服務，還是微服務，數據持久層都是必須的，我們是選用互聯網項目經常使用的 mysql 作爲 DB，爲了保證服務讀寫效率以及高可用性，我們主從分離模式，同時實現讀寫分離，來保障 mysql 的讀寫性能。

隨着業務量增長，單表的數據量達到性能瓶頸之後，我們就要採用分庫分表來對數據庫表進行水平拆分和垂直拆分了，具體如何進行合理的拆分，以及技術選型，這些和項目現有的表結構設計是息息相關的，要考慮後續的可拓展性，不能短期拆了一時爽，後續業務量增暴漲之後，服務器的性能不足以維持數據庫的性能時，這時候要拆分服務器部署了。當然，一般企業的數據量級達不到那樣的量級。

結構型數據存儲

mysql 比較擅長存儲關係型數據，項目中有需要存儲結構性數據的場景，比如存儲 JSON 字符串，這種場景通過 mysql 來存儲顯然事不合適的。一般我們會採用 Elasticsearch 或者 MangoDB 來進行存儲，如果業務中需要檢索功能，更建議使用 Elasticsearch。Elasticsearch 支持 DSL，有比較豐富查詢檢索功能，甚至能實現 GIS 空間檢索功能。

消息中間件

前面說到，微服務架構中，服務之間同步調用是通過 Feign 來實現的，那服務間的異步解耦就要通過 MQ 來實現了。雖然我們可以通過多線程來實現異步調用，但是這種異步調用不支持持久化，可能會造成消息丟失，所以一般都集成 RabbitMq 或者 RocketMq。

日誌收集

在微服務架構中，通過一個組件，比如說訂單服務都是多節點分佈式部署，每個節點的 log 日誌都是存儲在節點本地，如果要查詢日誌，我們難道要登錄到各個節點找到對應的日誌信息？這種查看日誌肯定是不行的。所以一般會引入 ELK 來做日誌收集，和可視化展示查詢。

任務調度中心

項目中經常會用到定時功能，單體應用中，我們使用 sping 自帶的 Schedule，或者使用 Quartz 即可，在分佈式應用中，我們就要集成分佈式定時器，比如 Quartz(Quartz 配合數據庫表也是支持分佈式定時任務的)，還有 Elastic-Job、XXL-JOB 等等。

Elastic-job 噹噹網基於 quartz 二次開發的彈性分佈式任務調度系統，功能豐富強大，採用 zookeeper 實現分佈式協調，實現任務高可用以及分片。Elastic-Job 是一個分佈式調度的解決方案，由噹噹網開源，它由兩個相互獨立的子項目 Elastic-Job-Lite 和 Elastic-Job-Cloud 組成，使用 Elastic-Job 可以快速實現分佈式任務調度。

XXL-JOB 是一個分佈式任務調度平臺（XXL 是作者徐雪裏姓名拼音的首字母），其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。將調度行爲抽象形成 “調度中心” 公共平臺，而平臺自身並不承擔業務邏輯，“調度中心”負責發起調度請求。將任務抽象成分散的 JobHandler，交由 “執行器” 統一管理，“執行器”負責接收調度請求並執行對應的 JobHandler 中業務邏輯。因此，“調度”和 “任務” 兩部分可以相互解耦，提高系統整體穩定性和擴展性。

分佈式對象存儲

項目中經常會有文件上傳功能，比如圖片，音頻視頻。在分佈式架構中，我們將文件存儲在節點服務器上顯然是不行的，這時候，我們就需要引入分佈式文件存儲。常見方案有 MinIo、阿里的 OSS（收費），阿里 FastDFS 等等。

MinIO 是一款基於 Go 語言發開的高性能、分佈式的對象存儲系統。客戶端支持 Java、Net、Python、Javacript、Golang 語言。

FastDFS 是一個開源的輕量級分佈式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和的問題。特別適合以文件爲載體的在線服務，如相冊網站、視頻網站等等。

作者：愛琴孩

來源：https://blog.csdn.net/qq_28165595/article/details/128169770

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QRn2HyY_TZL4oW_P57VRYw

猜你喜歡