天天看點

SOA架構和微服務架構的差別是什麼?

SOA架構和微服務架構的差別

首先SOA和微服務架構一個層面的東西,而對于ESB和微服務網關是一個層面的東西,一個談到是架構風格和方法,一個談的是實作工具或元件。

1.SOA(Service Oriented Architecture)“面向服務的架構”:他是一種設計方法,其中包含多個服務, 服務之間通過互相依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在于作業系統程序中。各個服務之間 通過網絡調用。

2.微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的升華,微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”,原有的單個業務系統會拆分為多個可以獨立開發、設計、運作的小應用。這些小應用之間通過服務完成互動和內建。

微服務架構 = 80%的SOA服務架構思想 + 100%的元件化架構思想 + 80%的領域模組化思想

ESB和微服務API網關。

1.ESB(企業服務總線),簡單 來說 ESB 就是一根管道,用來連接配接各個服務節點。為了集 成不同系統,不同協定的服務,ESB 做了消息的轉化解釋和路由工作,讓不同的服務互聯互通;

SOA架構和微服務架構的差別是什麼?

2.API網關:API網關是一個伺服器,是系統的唯一入口。從面向對象設計的角度看,它與外觀模式類似。

API網關封裝了系統内部架構,為每個用戶端提供一個定制的API。它可能還具有其它職責,如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜态響應處理。為什麼微服務一定要有網關?這篇推薦你看下。

API網關方式的核心要點是,所有的用戶端和消費端都通過統一的網關接入微服務,在網關層處理所有的非業務功能。通常,網關也是提供REST/HTTP的通路API。服務端通過API-GW注冊和管理服務。

SOA架構和微服務架構的差別是什麼?
SOA架構和微服務架構的差別是什麼?

3.SOA架構特點:

系統內建:站在系統的角度,解決企業系統間的通信問 題,把原先散亂、無規劃的系統間的網狀結構,梳理成 規整、可治理的系統間星形結構,這一步往往需要引入一些産品,比如 ESB、以及技術規範、服務管理規範;這一步解決的核心問題是【有序】

系統的服務化:站在功能的角度,把業務邏輯抽象成 可複用、可組裝的服務,通過服務的編排實作業務的 快速再生,目的:把原先固有的業務功能轉變為通用 的業務服務,實作業務邏輯的快速複用;這一步解決 的核心問題是【複用】

業務的服務化:站在企業的角度,把企業職能抽象成 可複用、可組裝的服務;把原先職能化的企業架構轉變為服務化的企業架構,進一步提升企業的對外服務能力;“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步,則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】

微服務架構特點:

1.通過服務實作元件化

開發者不再需要協調其它服務部署對本服務的影響。

2.按業務能力來劃分服務和開發團隊

開發者可以自由選擇開發技術,提供 API服務

3.去中心化

每個微服務有自己私有的資料庫持久化業務資料

每個微服務隻能通路自己的資料庫,而不能通路其它服務的資料庫

某些業務場景下,需要在一個事務中更新多個資料庫。這種情況也不能直接通路其它微服務的資料庫,而是通過對于微服務進行操作。

資料的去中心化,進一步降低了微服務之間的耦合度,不同服務可以采用不同的資料庫技術(SQL、NoSQL等)。在複雜的業務場景下,如果包含多個微服務,通常在用戶端或者中間層(網關)處理。

4.基礎設施自動化(devops、自動化部署)

Java EE部署架構,通過展現層打包WARs,業務層劃分到JARs最後部署為EAR一個大包,而微服務則打開了這個黑盒子,把應用拆分成為一個一個的單個服務,應用Docker技術,不依賴任何伺服器和資料模型,是一個全棧應用,可以通過自動化方式獨立部署。

每個服務運作在自己的程序中,通過輕量的通訊機制聯系,經常是基于HTTP資源API,這些服務基于業務能力建構,能實作集中化管理(因為服務太多啦,不集中管理就無法DevOps啦)。

關注微信公衆号:Java技術棧,在背景回複:架構,可以擷取我整理的 N 篇最新架構教程,都是幹貨。

5.主要差別:

SOA架構和微服務架構的差別是什麼?

6.Dubbo服務的最佳實踐

分包

服務接口、請求服務模型、異常資訊都放在api裡面,符合重用釋出等價原則,共同重用原則

api裡面放入spring的引用配置。也可以放在子產品的包目錄下。

粒度

盡可能把接口設定成粗粒度,每個服務方法代表一個獨立的功能,而不是某個功能的步驟。否則就會涉及到分布式事務

服務接口建議以業務場景為機關劃分。并對相近業務做抽象,防止接口暴增

不建議使用過于抽象的通用接口泛型,接口沒有明确的語義,帶來後期的維護

版本

每個接口都應該定義版本,為後續的相容性提供前瞻性的考慮 version (maven-snapshot)

建議使用兩位版本号,因為第三位版本号表示的相容性更新,隻有不相容時才需要變更服務版本

當接口做到不相容更新的時候,先更新一半或者一台提供者為新版本,再将消費全部更新新版本,然後再将剩下的一半提供者更新新版本

預釋出環境

推薦用法

在provider端盡可能配置consumer端的屬性

比如timeout、retires、線程池大小、LoadBalance

配置管理者資訊

application上面配置的owner 、 owner建議配置2個人以上。因為owner都能夠在監控中心看到

配置dubbo緩存檔案

注冊中心的清單

服務提供者清單