前言
當(dāng)前，微服務(wù)架構(gòu)在很多公司都已經(jīng)落地實(shí)施了，下面用一張圖簡(jiǎn)要概述下微服務(wù)架構(gòu)設(shè)計(jì)中常用組件。不能說(shuō)已經(jīng)使用微服務(wù)好幾年了，結(jié)果對(duì)微服務(wù)架構(gòu)沒有一個(gè)整體的認(rèn)知，一個(gè)只懂搬磚的程序員不是一個(gè)好碼農(nóng)!
流量入口Nginx
在上圖中可以看到，Nginx作為整個(gè)架構(gòu)的流量入口，可以理解為一個(gè)外部的網(wǎng)關(guān)，它承擔(dān)著請(qǐng)求的路由轉(zhuǎn)發(fā)、負(fù)載均衡、動(dòng)靜分離等功能。作為一個(gè)核心入口點(diǎn)，Nginx肯定要采用多節(jié)點(diǎn)部署，同時(shí)通過(guò)keepalived來(lái)實(shí)現(xiàn)高可用，從而保障整個(gè)平臺(tái)的高可用。
網(wǎng)關(guān)
網(wǎng)關(guān)是在Nginx后的另外一個(gè)核心組件。它承擔(dān)著請(qǐng)求鑒權(quán)，路由轉(zhuǎn)發(fā)，協(xié)議轉(zhuǎn)換，流量監(jiān)控等一系列功能，上圖中網(wǎng)關(guān)是采用spring Cloud Gateway來(lái)實(shí)現(xiàn)業(yè)務(wù)網(wǎng)關(guān)的功能，在網(wǎng)關(guān)選型中，我們還有其他的選擇，比如Zuul1,Zuul2,Kong等等，這些方案都有自己的優(yōu)勢(shì)和局限性，我們可以根據(jù)自己他們的特點(diǎn)來(lái)抉擇到底選用哪一個(gè)方案。對(duì)于網(wǎng)關(guān)的深入了解，可以參見之前的系列文章網(wǎng)關(guān)那點(diǎn)事，這里不做贅述。
上圖中，Spring Cloud Gateway下面有jwt和OAuth2，其實(shí)這兩個(gè)就是基于token的認(rèn)證鑒權(quán)，一般互聯(lián)網(wǎng)項(xiàng)目中，在登錄模塊都是支持微信或者qq登錄，這就是用到OAuth2的授權(quán)登錄。想深入了解Oauth2相關(guān)細(xì)節(jié)，可以參考之前的Oauth2.0客戶端服務(wù)端示例等系列文章。
業(yè)務(wù)組件
從上面的架構(gòu)圖中可以看到，網(wǎng)關(guān)之后就是我們的業(yè)務(wù)組件了，可以理解就是拆分之后的微服務(wù)了，比如電商平臺(tái)常見的賬號(hào)服務(wù)、訂單服務(wù)、發(fā)票服務(wù)、收銀臺(tái)服務(wù)等等。服務(wù)組件之間通過(guò)Feign來(lái)進(jìn)行http調(diào)用，F(xiàn)eign集成Ribbon來(lái)實(shí)現(xiàn)客戶端側(cè)負(fù)載均衡。具體的服務(wù)領(lǐng)域劃分，服務(wù)限界上下文的設(shè)定，這就另外的知識(shí)了，如果想做好服務(wù)劃分，DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)這塊可以深入了解下。
服務(wù)注冊(cè)中心
不管是基于Dubbo實(shí)現(xiàn)的SOA，還是基于Spring Cloud拆分的微服務(wù)架構(gòu)，服務(wù)注冊(cè)中心都是必須的，我們把所有的服務(wù)組件都注冊(cè)到注冊(cè)中心，進(jìn)而實(shí)現(xiàn)服務(wù)的動(dòng)態(tài)調(diào)用。常見能實(shí)現(xiàn)注冊(cè)中心功能的有Zookeeper,Eureka,Nacos,Zookeeper在Dubbo中使用比較多，目前公司服務(wù)微服務(wù)架構(gòu)是基于Eureka的，Eureka好像目前不維護(hù)了。一般新的平臺(tái)建議直接集成Nacos，Nacos除了能做注冊(cè)中心來(lái)使用，也可以作為分布式配置中心來(lái)使用，比Sping Cloud Config更好使。
緩存和分布式鎖
在圖中左下角，我們可以看到redis組件，我們可以把Redis作為緩存來(lái)使用，把一些查詢慢，使用率高的熱點(diǎn)數(shù)據(jù)做緩存處理，能快速提高接口響應(yīng)時(shí)間。同時(shí)redis在微服務(wù)中的一大使用場(chǎng)景就是分布式鎖，傳統(tǒng)的Sychronized和顯示Lock鎖顯然是不能解決分布式并發(fā)問(wèn)題。
為了保障Redis的高可用，可以采用哨兵部署，不是三個(gè)redis節(jié)點(diǎn)，一主二從，同時(shí)部署三個(gè)哨兵節(jié)點(diǎn)，來(lái)實(shí)現(xiàn)故障轉(zhuǎn)移，避免單點(diǎn)問(wèn)題，如果Redis存儲(chǔ)的數(shù)據(jù)量很大，達(dá)到了單節(jié)點(diǎn)的Redis的性能瓶頸，我們也可以用Redis集群模式來(lái)實(shí)現(xiàn)分布式存儲(chǔ)。
數(shù)據(jù)持久層
不管單體服務(wù)，還是微服務(wù)，數(shù)據(jù)持久層都是必須的，我們是選用互聯(lián)網(wǎng)項(xiàng)目經(jīng)常使用的MySQL作為DB，為了保證服務(wù)讀寫效率以及高可用性，我們主從分離模式，同時(shí)實(shí)現(xiàn)讀寫分離，來(lái)保障mysql的讀寫性能。
隨著業(yè)務(wù)量增長(zhǎng)，單表的數(shù)據(jù)量達(dá)到性能瓶頸之后，我們就要采用分庫(kù)分表來(lái)對(duì)數(shù)據(jù)庫(kù)表進(jìn)行水平拆分和垂直拆分了，具體如何進(jìn)行合理的拆分，以及技術(shù)選型，這些和項(xiàng)目現(xiàn)有的表結(jié)構(gòu)設(shè)計(jì)是息息相關(guān)的，要考慮后續(xù)的可拓展性，不能短期拆了一時(shí)爽，后續(xù)業(yè)務(wù)量增暴漲之后，服務(wù)器的性能不足以維持?jǐn)?shù)據(jù)庫(kù)的性能時(shí)，這時(shí)候要拆分服務(wù)器部署了。當(dāng)然，一般企業(yè)的數(shù)據(jù)量級(jí)達(dá)不到那樣的量級(jí)。
結(jié)構(gòu)型數(shù)據(jù)存儲(chǔ)
mysql比較擅長(zhǎng)存儲(chǔ)關(guān)系型數(shù)據(jù)，項(xiàng)目中有需要存儲(chǔ)結(jié)構(gòu)性數(shù)據(jù)的場(chǎng)景，比如存儲(chǔ)JSON字符串，這種場(chǎng)景通過(guò)mysql來(lái)存儲(chǔ)顯然事不合適的。一般我們會(huì)采用Elasticsearch或者M(jìn)angoDB來(lái)進(jìn)行存儲(chǔ)，如果業(yè)務(wù)中需要檢索功能，更建議使用Elasticsearch。Elasticsearch支持DSL，有比較豐富查詢檢索功能，甚至能實(shí)現(xiàn)GIS空間檢索功能。
消息中間件
前面說(shuō)到，微服務(wù)架構(gòu)中，服務(wù)之間同步調(diào)用是通過(guò)Feign來(lái)實(shí)現(xiàn)的，那服務(wù)間的異步解耦就要通過(guò)MQ來(lái)實(shí)現(xiàn)了。雖然我們可以通過(guò)多線程來(lái)實(shí)現(xiàn)異步調(diào)用，但是這種異步調(diào)用不支持持久化，可能會(huì)造成消息丟失，所以一般都集成RabbitMq或者RocketMq。
日志收集
在微服務(wù)架構(gòu)中，通過(guò)一個(gè)組件，比如說(shuō)訂單服務(wù)都是多節(jié)點(diǎn)分布式部署，每個(gè)節(jié)點(diǎn)的log日志都是存儲(chǔ)在節(jié)點(diǎn)本地，如果要查詢?nèi)罩荆覀冸y道要登錄到各個(gè)節(jié)點(diǎn)找到對(duì)應(yīng)的日志信息？這種查看日志肯定是不行的。所以一般會(huì)引入ELK來(lái)做日志收集，和可視化展示查詢。
- Logstash 用來(lái)做日志收集工作，通常在Logstash前會(huì)加一個(gè)Filebeat，由Filebeat來(lái)收集日志，Logstash做數(shù)據(jù)轉(zhuǎn)換工作。
- Elasticsearch做數(shù)據(jù)存儲(chǔ)，以及生成索引數(shù)據(jù)，便于Kibana做檢索。
- Kibana做數(shù)據(jù)的展示，以及查詢檢索功能，我們通過(guò)檢索關(guān)鍵詞就能快速的查詢到想要日志信息。
任務(wù)調(diào)度中心
項(xiàng)目中經(jīng)常會(huì)用到定時(shí)功能，單體應(yīng)用中，我們使用sping自帶的Schedule，或者使用Quartz即可，在分布式應(yīng)用中，我們就要集成分布式定時(shí)器，比如Quartz(Quartz配合數(shù)據(jù)庫(kù)表也是支持分布式定時(shí)任務(wù)的)，還有Elastic-Job、XXL-JOB等等。
Elastic-job 當(dāng)當(dāng)網(wǎng)基于quartz 二次開發(fā)的彈性分布式任務(wù)調(diào)度系統(tǒng)，功能豐富強(qiáng)大，采用zookeeper實(shí)現(xiàn)分布式協(xié)調(diào)，實(shí)現(xiàn)任務(wù)高可用以及分片。Elastic-Job是一個(gè)分布式調(diào)度的解決方案，由當(dāng)當(dāng)網(wǎng)開源，它由兩個(gè)相互獨(dú)立的子項(xiàng)目Elastic-Job-Lite和Elastic-Job-Cloud組成，使用Elastic-Job可以快速實(shí)現(xiàn)分布式任務(wù)調(diào)度。
XXL-JOB 是一個(gè)分布式任務(wù)調(diào)度平臺(tái)（XXL是作者徐雪里姓名拼音的首字母），其核心設(shè)計(jì)目標(biāo)是開發(fā)迅速、學(xué)習(xí)簡(jiǎn)單、輕量級(jí)、易擴(kuò)展。將調(diào)度行為抽象形成“調(diào)度中心”公共平臺(tái)，而平臺(tái)自身并不承擔(dān)業(yè)務(wù)邏輯，“調(diào)度中心”負(fù)責(zé)發(fā)起調(diào)度請(qǐng)求。將任務(wù)抽象成分散的JobHandler，交由“執(zhí)行器”統(tǒng)一管理，“執(zhí)行器”負(fù)責(zé)接收調(diào)度請(qǐng)求并執(zhí)行對(duì)應(yīng)的JobHandler中業(yè)務(wù)邏輯。因此，“調(diào)度”和“任務(wù)”兩部分可以相互解耦，提高系統(tǒng)整體穩(wěn)定性和擴(kuò)展性。
分布式對(duì)象存儲(chǔ)
項(xiàng)目中經(jīng)常會(huì)有文件上傳功能，比如圖片，音頻視頻。在分布式架構(gòu)中，我們將文件存儲(chǔ)在節(jié)點(diǎn)服務(wù)器上顯然是不行的，這時(shí)候，我們就需要引入分布式文件存儲(chǔ)。常見方案有MinIo、阿里的OSS（收費(fèi)），阿里FastDFS等等。
MinIO 是一款基于Go語(yǔ)言發(fā)開的高性能、分布式的對(duì)象存儲(chǔ)系統(tǒng)。客戶端支持JAVA?.NET、Python/ target=_blank class=infotextkey>Python、Javacript、Golang語(yǔ)言。
FastDFS是一個(gè)開源的輕量級(jí)分布式文件系統(tǒng)，它對(duì)文件進(jìn)行管理，功能包括：文件存儲(chǔ)、文件同步、文件訪問(wèn)（文件上傳、文件下載）等，解決了大容量存儲(chǔ)和的問(wèn)題。特別適合以文件為載體的在線服務(wù)，如相冊(cè)網(wǎng)站、視頻網(wǎng)站等等。
