微服務(wù)架構(gòu)有哪些

小伙伴們知道常用的微服務(wù)架構(gòu)框架有哪些嗎？上回我們介紹了一些常用的微服務(wù)架構(gòu)設(shè)計(jì)模式，這次我們就來(lái)了解一下一些常用的微服務(wù)架構(gòu)框架吧。

一、Dubbo

Dubbo框架是由阿里巴巴開(kāi)發(fā)的開(kāi)源式的分布式服務(wù)化治理框架，它會(huì)通過(guò)RPC請(qǐng)求方式訪問(wèn)。Dubbo是在阿里巴巴的電商平臺(tái)中逐漸探索演進(jìn)所形成的，經(jīng)歷過(guò)復(fù)雜業(yè)務(wù)的高并發(fā)挑戰(zhàn)，現(xiàn)在許多大企業(yè)都使用的都是Dubbo。

二、Dropwizard

Dropwizard框架集中了Java生態(tài)系統(tǒng)中各個(gè)問(wèn)題域里最好的組件集成于一身，它能夠極快的打造一個(gè)Rest風(fēng)格的后臺(tái)，還可以整合Dropwizard核心以外的項(xiàng)目。與Spring Boot相較，Dropwizard在輕量化上更有優(yōu)勢(shì)。

三、Akka

Akka是一個(gè)用Scala編寫的庫(kù)，可以用在有簡(jiǎn)化編寫容錯(cuò)、高可伸縮性的Java和Scala的Actor模型，使用Akka能夠?qū)崿F(xiàn)微服務(wù)集群。

四、Spring Boot

Spring Boot的設(shè)計(jì)目的是簡(jiǎn)化新Spring應(yīng)用初始搭建以及開(kāi)發(fā)過(guò)程，可以說(shuō)是目前大眾中最受歡迎的微服務(wù)開(kāi)發(fā)框架。利用Spring Boot開(kāi)發(fā)的便捷度簡(jiǎn)化分布式系統(tǒng)基礎(chǔ)設(shè)施的開(kāi)發(fā)，比如像配置中心、注冊(cè)、負(fù)載均衡等方面都可以做到一鍵啟動(dòng)和一鍵部署。

五、Spring Cloud

Spring Cloud不是一個(gè)單獨(dú)框架，它是一整個(gè)系列的框架合計(jì)，它是基于HTTP（s）的RETS服務(wù)構(gòu)建服務(wù)體系的。Spring Cloud能夠幫助架構(gòu)師構(gòu)建一整套完整的微服務(wù)架構(gòu)技術(shù)生態(tài)鏈。

六、Node.js相關(guān)微服務(wù)框架

Seneca

Seneca是Node.js的微服務(wù)框架開(kāi)發(fā)工具，適用于編寫可用于產(chǎn)品環(huán)境的代碼。

Hapi/Restify/LoopBack

三種Node.js相關(guān)微服務(wù)框架，它們?nèi)齻€(gè)分工不同，前兩種適合開(kāi)發(fā)簡(jiǎn)單的微服務(wù)后端系統(tǒng)，第三種更適合用在大型復(fù)雜應(yīng)用開(kāi)發(fā)，還可以用在現(xiàn)有微服務(wù)上的構(gòu)建。

七、Python相關(guān)微服務(wù)框架

Python相關(guān)微服務(wù)架構(gòu)較少，一般使用較多的都是Nameko。Nameko使得微服務(wù)實(shí)現(xiàn)變得更加簡(jiǎn)單，同時(shí)也提供了非常多的功能，如負(fù)載均衡、服務(wù)發(fā)現(xiàn)及依賴自動(dòng)注入等，使用起來(lái)非常方便，但美中不足的有限速、超時(shí)和權(quán)限機(jī)制不完善等缺點(diǎn)。

微服務(wù)架構(gòu)設(shè)計(jì)模式

1.聚合器微服務(wù)設(shè)計(jì)模式

這是一種最常見(jiàn)也最簡(jiǎn)單的設(shè)計(jì)模式

聚合器調(diào)用多個(gè)服務(wù)實(shí)現(xiàn)應(yīng)用程序所需的功能。它可以是一個(gè)簡(jiǎn)單的 WEB 頁(yè)面，將檢索到的數(shù)據(jù)進(jìn)行處理展示。它也可以是一個(gè)更高層次的組合微服務(wù)，對(duì)檢索到的數(shù)據(jù)增加業(yè)務(wù)邏輯后進(jìn)一步發(fā)布成一個(gè)新的微服務(wù)，這符合DRY原則。另外，每個(gè)服務(wù)都有自己的緩存和數(shù)據(jù)庫(kù)。如果聚合器是一個(gè)組合服務(wù)，那么它也有自己的緩存和數(shù)據(jù)庫(kù)。聚合器可以沿X軸和Z軸獨(dú)立擴(kuò)展。

2.代理微服務(wù)設(shè)計(jì)模式

這是聚合模式的一個(gè)變種，如下圖所示

在這種情況下，客戶端并不聚合數(shù)據(jù)，但會(huì)根據(jù)業(yè)務(wù)需求的差別調(diào)用不同的微服務(wù)。代理可以僅僅委派請(qǐng)求，也可以進(jìn)行數(shù)據(jù)轉(zhuǎn)換工作。

3.鏈?zhǔn)轿⒎?wù)設(shè)計(jì)模式

這種模式在接收到請(qǐng)求后會(huì)產(chǎn)生一個(gè)經(jīng)過(guò)合并的響應(yīng)，如下圖所示

在這種情況下，服務(wù)A接收到請(qǐng)求后會(huì)與服務(wù)B進(jìn)行通信，類似地，服務(wù)B會(huì)同服務(wù)C進(jìn)行通信。所有服務(wù)都使用同步消息傳遞。在整個(gè)鏈?zhǔn)秸{(diào)用完成之前，客戶端會(huì)一直阻塞。因此，服務(wù)調(diào)用鏈不宜過(guò)長(zhǎng)，以免客戶端長(zhǎng)時(shí)間等待。

4.分支微服務(wù)設(shè)計(jì)模式

這種模式是聚合器模式的擴(kuò)展，允許同時(shí)調(diào)用兩個(gè)微服務(wù)鏈，如下圖所示

5.數(shù)據(jù)共享微服務(wù)設(shè)計(jì)模式

自治是微服務(wù)的設(shè)計(jì)原則之一，就是說(shuō)微服務(wù)是全棧式服務(wù)。但在重構(gòu)現(xiàn)有的“單體應(yīng)用（Monolithic Application）”時(shí)，SQL 數(shù)據(jù)庫(kù)反規(guī)范化可能會(huì)導(dǎo)致數(shù)據(jù)重復(fù)和不一致。因此，在單體應(yīng)用到微服務(wù)架構(gòu)的過(guò)渡階段，可以使用這種設(shè)計(jì)模式，如下圖所示

在這種情況下，部分微服務(wù)可能會(huì)共享緩存和數(shù)據(jù)庫(kù)存儲(chǔ)。不過(guò)，這只有在兩個(gè)服務(wù)之間存在強(qiáng)耦合關(guān)系時(shí)才可以。對(duì)于基于微服務(wù)的新建應(yīng)用程序而言，這是一種反模式。

6.異步消息傳遞微服務(wù)設(shè)計(jì)模式

雖然 REST 設(shè)計(jì)模式非常流行，但它是同步的，會(huì)造成阻塞。因此部分基于微服務(wù)的架構(gòu)可能會(huì)選擇使用消息隊(duì)列代替 REST 請(qǐng)求/響應(yīng)，如下圖所示

責(zé)任編輯：YYX