微服務架構組件分析,看這篇就夠了

前言

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

流量入口Nginx

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

網關

網關是在Nginx后的另外一個核心組件。它承擔著請求鑒權，路由轉發(fā)，協(xié)議轉換，流量監(jiān)控等一系列功能，上圖中網關是采用spring Cloud Gateway來實現(xiàn)業(yè)務網關的功能，在網關選型中，我們還有其他的選擇，比如Zuul1,Zuul2,Kong等等，這些方案都有自己的優(yōu)勢和局限性，我們可以根據自己他們的特點來抉擇到底選用哪一個方案。對于網關的深入了解，可以參見之前的系列文章網關那點事，這里不做贅述。

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

業(yè)務組件

從上面的架構圖中可以看到，網關之后就是我們的業(yè)務組件了，可以理解就是拆分之后的微服務了，比如電商平臺常見的賬號服務、訂單服務、發(fā)票服務、收銀臺服務等等。服務組件之間通過Feign來進行http調用，F(xiàn)eign集成Ribbon來實現(xiàn)客戶端側負載均衡。具體的服務領域劃分，服務限界上下文的設定，這就另外的知識了，如果想做好服務劃分，DDD領域驅動設計這塊可以深入了解下。

服務注冊中心

不管是基于Dubbo實現(xiàn)的SOA，還是基于Spring Cloud拆分的微服務架構，服務注冊中心都是必須的，我們把所有的服務組件都注冊到注冊中心，進而實現(xiàn)服務的動態(tài)調用。常見能實現(xiàn)注冊中心功能的有Zookeeper,Eureka,Nacos,Zookeeper在Dubbo中使用比較多，目前公司服務微服務架構是基于Eureka的，Eureka好像目前不維護了。一般新的平臺建議直接集成Nacos，Nacos除了能做注冊中心來使用，也可以作為分布式配置中心來使用，比Sping Cloud Config更好使。

緩存和分布式鎖

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

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

數據持久層

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

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

結構型數據存儲

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

消息中間件

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

日志收集

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

Logstash 用來做日志收集工作，通常在Logstash前會加一個Filebeat，由Filebeat來收集日志，Logstash做數據轉換工作。

Elasticsearch做數據存儲，以及生成索引數據，便于Kibana做檢索。

Kibana做數據的展示，以及查詢檢索功能，我們通過檢索關鍵詞就能快速的查詢到想要日志信息。

任務調度中心

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

Elastic-job 當當網基于quartz 二次開發(fā)的彈性分布式任務調度系統(tǒng)，功能豐富強大，采用zookeeper實現(xiàn)分布式協(xié)調，實現(xiàn)任務高可用以及分片。Elastic-Job是一個分布式調度的解決方案，由當當網開源，它由兩個相互獨立的子項目Elastic-Job-Lite和Elastic-Job-Cloud組成，使用Elastic-Job可以快速實現(xiàn)分布式任務調度。

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

分布式對象存儲

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

MinIO 是一款基于Go語言發(fā)開的高性能、分布式的對象存儲系統(tǒng)?？蛻舳酥С?a href="http://srfitnesspt.com/v/tag/852/" target="_blank">Java、Net、Python、Javacript、Golang語言。

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

編輯：黃飛

?