微服務架構有哪些_微服務架構設計模式

微服務架構有哪些

小伙伴們知道常用的微服務架構框架有哪些嗎？上回我們介紹了一些常用的微服務架構設計模式，這次我們就來了解一下一些常用的微服務架構框架吧。

一、Dubbo

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

二、Dropwizard

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

三、Akka

Akka是一個用Scala編寫的庫，可以用在有簡化編寫容錯、高可伸縮性的Java和Scala的Actor模型，使用Akka能夠實現(xiàn)微服務集群。

四、Spring Boot

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

五、Spring Cloud

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

六、Node.js相關微服務框架

Seneca

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

Hapi/Restify/LoopBack

三種Node.js相關微服務框架，它們三個分工不同，前兩種適合開發(fā)簡單的微服務后端系統(tǒng)，第三種更適合用在大型復雜應用開發(fā)，還可以用在現(xiàn)有微服務上的構建。

七、Python相關微服務框架

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

微服務架構設計模式

1.聚合器微服務設計模式

這是一種最常見也最簡單的設計模式

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

2.代理微服務設計模式

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

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

3.鏈式微服務設計模式

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

在這種情況下，服務A接收到請求后會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。因此，服務調用鏈不宜過長，以免客戶端長時間等待。

4.分支微服務設計模式

這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈，如下圖所示

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

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

在這種情況下，部分微服務可能會共享緩存和數(shù)據(jù)庫存儲。不過，這只有在兩個服務之間存在強耦合關系時才可以。對于基于微服務的新建應用程序而言，這是一種反模式。

6.異步消息傳遞微服務設計模式

雖然 REST 設計模式非常流行，但它是同步的，會造成阻塞。因此部分基于微服務的架構可能會選擇使用消息隊列代替 REST 請求/響應，如下圖所示

責任編輯：YYX