前言 當前，微服務架構在很多公司都已經落地實施了，下麵用一張圖簡要概述下微服務架構設計中常用組件。不能說已經使用微服務好幾年了，結果對微服務架構沒有一個整體的認知，一個只懂搬磚的程式員不是一個好碼農。 流量入口Nginx 在上圖中可以看到，Nginx作為整個架構的流量入口，可以理解為一個外部的網關， ...
前言
當前，微服務架構在很多公司都已經落地實施了，下麵用一張圖簡要概述下微服務架構設計中常用組件。不能說已經使用微服務好幾年了，結果對微服務架構沒有一個整體的認知，一個只懂搬磚的程式員不是一個好碼農。
流量入口Nginx
在上圖中可以看到，Nginx作為整個架構的流量入口，可以理解為一個外部的網關，它承擔著請求的路由轉發、負載均衡、動靜分離等功能。作為一個核心入口點，Nginx肯定要採用多節點部署，同時通過keepalived來實現高可用，從而保障整個平臺的高可用。
推薦一個開源免費的 Spring Boot 實戰項目：
網關
網關是在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來做日誌收集，和可視化展示查詢。
- Logstash 用來做日誌收集工作，通常在Logstash前會加一個Filebeat，由Filebeat來收集日誌，Logstash做數據轉換工作。
- Elasticsearch做數據存儲，以及生成索引數據，便於Kibana做檢索。
- Kibana做數據的展示，以及查詢檢索功能，我們通過檢索關鍵詞就能快速的查詢到想要日誌信息。
任務調度中心
項目中經常會用到定時功能，單體應用中，我們使用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是一個開源的輕量級分散式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和的問題。特別適合以文件為載體的線上服務，如相冊網站、視頻網站等等。
來源：blog.csdn.net/qq_28165595/article/details/128169770
更多文章推薦：
2.2,000+ 道 Java面試題及答案整理(2024最新版)
3.免費獲取 IDEA 激活碼的 7 種方式（2024最新版）
覺得不錯，別忘了隨手點贊+轉發哦！
