若是咱們打開支付寶首頁,去看咱們的餘額,它會展現你的總資產,昨日收益、累計收益等信息。假如這個頁面所展現的信息,都來自各個不一樣的系統/應用,咱們經過各個接口把這些數據展現出來。若是咱們如今要在前端頁面展現這幾項數據的話,咱們應該怎麼去展現呢?前端
在這種狀況下,咱們不可能讓客戶端與6個不一樣的應用/系統都一一去通訊來去完成數據的展現。而是6個應用/系統之間進行彼此通訊來完成調用,最後客戶端只須要調用一個接口來獲取數據便可,而不是與每個應用/系統進行通訊。咱們的架構多是以下的樣子:後端
一個電商系統,好比淘寶,咱們在首頁會展現不少數據信息,例如:首頁信息、商品信息、我的信息、推送信息等等不少。若是首頁展現的數據來自100個不一樣的應用/系統,那麼經過如上架構,咱們在後端便會出現幾百個乃至上千個通訊的交互,那麼後端的結構就會變得很是的龐大和複雜。因此在這樣的架構下,咱們須要對上面結構做出一些調整 ,因此咱們就引入了SOA架構網絡
SOA(全稱:Service Oriented Architecture),中文意思爲 「面向服務的架構」,你能夠將它理解爲一個架構模型或者一種設計方法,而並非服務解決方案。其中包含多個服務, 服務之間經過相互依賴或者經過通訊機制,來完成相互通訊的,最終提供一系列的功能。一個服務一般以獨立的形式存在與操做系統進程中。各個服務之間經過網絡調用 。架構
跟 SOA 相提並論的還有一個 ESB(企業服務總線),簡單來講ESB就是一根管道,用來鏈接各個服務節點。爲了集成不一樣系統,不一樣協議的服務,ESB 能夠簡單理解爲:它作了消息的轉化解釋和路由工做,讓不一樣的服務互聯互通;微服務
咱們將各個應用之間彼此的通訊所有去掉,在中間引入一個ESB企業總線,各個服務之間,只須要和ESB進行通訊,這個時候,各個應用之間的交互就會變得更加的清晰,業務架構/邏輯等,也會變得很清楚。本來雜亂沒有規劃的系統,梳理成了一個有規劃可治理的系統,在這個過程當中,最大的變化,就是引入了ESB企業總線。組件化
SOA 所解決的核心問題操作系統
系統集成:站在系統的角度,解決企業系統間的通訊問 題,把原先散亂、無規劃的系統間的網狀結構,梳理成規整、可治理的系統間星形結構,這一步每每須要引入 一些產品,好比 ESB、以及技術規範、服務管理規範;這一步解決的核心問題是【有序】.net
系統的服務化:站在功能的角度,把業務邏輯抽象成可複用、可組裝的服務,經過服務的編排實現業務的快速再生。目的:把原先固有的業務功能轉變爲通用的業務服務,實現業務邏輯的快速複用;這一步解決的核心問題是【複用】設計
業務的服務化:站在企業的角度,把企業職能抽象成可複用、可組裝的服務;把原先職能化的企業架構轉變爲服務化的企業架構,進一步提高企業的對外服務能力;前面兩步都是從技術層面來解決系統調用、系統功能複用的問題。第三步,則是以業務驅動把一個 業務單元封裝成一項服務。這一步解決的核心問題是 【高效】code
微服務架構其實和SOA架構相似,微服務是在SOA上作的昇華。微服務架構重點強調的一個是"業務須要完全的組件化和服務化",原有的單個業務系統會拆分爲多個能夠獨立開發、設計、運行的小應用。這樣的小應用和其餘各個應用之間,相互去協做通訊,來完成一個交互和集成,這就是微服務架構。
組件化:組件表示一個能夠獨立更換和升級的單元,就以PC機爲例,PC中的 CPU、內存、顯卡、硬盤同樣,獨立更換升級而不影響其餘單元。若是咱們把PC做爲組件以服務的方式構建,那麼這臺PC只須要維護主板和一些必要的外部設備。CPU、內存、硬盤都是以組件方式提供服務,PC須要調用CPU作計算處理,只須要知道CPU這個組件的地址便可。
微服務的特徵
1. 經過服務實現組件化
2. 按業務能力來劃分服務和開發團隊
3. 去中心化
4. 基礎設施自動化(devops、自動化部署)
1. 微服務去中心化,去掉ESB企業總線。微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線,同時SOA的思想進入到單個業務系統內部實現真正的組件化
Docker容器技術的出現,爲微服務提供了更便利的條件,好比更小的部署單元,每一個服務能夠經過相似Node或者Spring Boot等技術跑在本身的進程中。
SOA注重的是系統集成方面,而微服務關注的是徹底分離
原文連接:https://blog.csdn.net/lzb348110175/article/details/96738781
更多信息請關注公衆號:「軟件老王」,關注不迷路,軟件老王和他的IT朋友們,分享一些他們的技術看法和生活故事。