Restful、SOAP、RPC、SOA、微服務之間的區別


什么是Restful

Restful是一種架構設計風格,提供了設計原則和約束條件,而不是架構,而滿足這些約束條件和原則的應用程序或設計就是 Restful架構或服務。

主要的設計原則:

  •   資源與URI
  •   統一資源接口(HTTP方法如GET,PUT和POST)
  •   資源的表述
  •   資源的鏈接
  •   狀態的轉移
總之,RESTful的核心就是后端將資源發布為URI,前端通過URI訪問資源,並通過HTTP動詞表示要對資源進行的操作。

什么是SOAP

簡單對象訪問協議是一種數據交換協議規范,是一種輕量的、簡單的、基於XML的協議的規范。SOAP協議和HTTP協議一樣,都是底層的通信協議,只是請求包的格式不同而已,SOAP包是XML格式的。
SOAP的消息是基於xml並封裝成了符合http協議,因此,它符合任何路由器、 防火牆或代理服務器的要求。
SOAP可以使用任何語言來完成,只要發送正確的soap請求即可,基於soap的服務可以在任何平台無需修改即可正常使用。

RPC

RPC 的全稱是 Remote Procedure Call 是一種進程間通信方式。
它允許程序調用另一個地址空間(通常是共享網絡的另一台機器上)的過程或函數,而不用程序員顯式編碼這個遠程調用的細節。即無論是調用本地接口/服務的還是遠程的接口/服務,本質上編寫的調用代碼基本相同。
比如兩台服務器A,B,一個應用部署在A服務器上,想要調用B服務器上應用提供的函數或者方法,由於不在一個內存空間,不能直接調用,這時候需要通過就可以應用RPC框架的實現來解決

  • RPC就是從一台機器(客戶端)上通過參數傳遞的方式調用另一台機器(服務器)上的一個函數或方法(可以統稱為服務)並得到返回的結果。
  • RPC 會隱藏底層的通訊細節(不需要直接處理Socket通訊或Http通訊)
  • RPC 是一個請求響應模型。客戶端發起請求,服務器返回響應(類似於Http的工作方式)
  • RPC 在使用形式上像調用本地函數(或方法)一樣去調用遠程的函數(或方法)。

4種典型RPC遠程調用框架

(1)RMI實現,利用java.rmi包實現,基於Java遠程方法協議(Java Remote Method Protocol)和java的原生序列化。
(2)Hessian,是一個輕量級的remoting onhttp工具,使用簡單的方法提供了RMI的功能。 基於HTTP協議,采用二進制編解碼。
(3)thrift是一種可伸縮的跨語言服務的軟件框架。thrift允許你定義一個描述文件,描述數據類型和服務接口。依據該文件,編譯器方便地生成RPC客戶端和服務器通信代碼。
(4)Dubbo是阿里巴巴公司開源的一個高性能優秀的服務框架,使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能,可以和 Spring框架無縫集成
(5)還有SpringCloud框架,微服務全家桶。為開發人員提供了快速構建分布式系統的一些工具,包括配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等。
微服務在本質上,就是rpc。rpc有基於tcp的,http的,mq的等等。spring cloud是基於spring boot的,spring boot 實現的是http協議的rpc,算是rpc的一個子集。

什么是SOA

SOA(Service-Oriented Architecture),中文全稱:面向服務的架構。
通俗點來講,SOA提倡將不同應用程序的業務功能封裝成“服務”並宿主起來,通常以接口和契約的形式暴露並提供給外界應用訪問(通過交換消息),達到不同系統可重用的目的。
SOA是一個組件模型,它能將不同的服務通過定義良好的接口和契約聯系起來。服務是SOA的基石。
 
業務系統分解為多個組件,讓每個組件都獨立提供離散,自治,可復用的服務能力
通過服務的組合和編排來實現上層的業務流程
作用:簡化維護,降低整體風險,伸縮靈活

微服務架構

  • 什么是微服務架構
    架構設計概念,各服務間隔離(分布式也是隔離),自治(分布式依賴整體組合)其它特性(單一職責,邊界,異步通信,獨立部署)是分布式概念

作用:各服務可獨立應用,組合服務也可系統應用(巨石應用[monolith]的簡化實現策略-平台思想)

微服務和SOA的區別

微服務是SOA架構演進的結果。兩者說到底都是對外提供接口的一種架構設計方式,隨着互聯網的發展,復雜的平台、業務的出現,導致SOA架構向更細粒度、更通過化程度發展,就成了所謂的微服務了。
總之,微服務是SOA發展出來的產物,它是一種比較現代化的細粒度的SOA實現方式。

SOA與微服務的區別在於如下幾個方面:

  •   微服務相比於SOA更加精細,微服務更多的以獨立的進程的方式存在,互相之間並無影響;
  •   微服務提供的接口方式更加通用化,例如HTTP RESTful方式,各種終端都可以調用,無關語言、平台限制;
  •   微服務更傾向於分布式去中心化的部署方式,在互聯網業務場景下更適合。
  •   SOA架構主要針對企業級、采用ESB服務(ESB企業服務總線),非常重,需要序列化和反序列化,采用XML格式傳輸。
  •  微服務架構主要互聯網公司,輕量級、小巧,獨立運行,基於Http+Rest+JSON格式傳輸。

為什么要使用微服務?

技術為業務而生,架構也為業務而出現,當然SOA和微服務也是因為業務的發展而出現。 https://www.cnblogs.com/wwct/p/12945230.html
平台隨着業務的發展從 All in One 環境就可以滿足業務需求(以Java來說,可能只是一兩個war包就解決了)。發展到需要拆分多個應用,並且采用MVC的方式分離前后端,加快開發效率;在發展到服務越來越多,不得不將一些核心或共用的服務拆分出來,其實發展到此階段,如果服務拆分的足夠精細,並且獨立運行,我覺得就可以將之理解為一個微服務了。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM