阿里P8架構師談：Restful、SOAP、RPC、SOA、微服務之間的區別（轉載）

轉載來源：https://youzhixueyuan.com/the-difference-between-restful-soap-rpc-soa-and-micro-service.html

 

內容大綱：

1.介紹Restful、SOAP、RPC、SOA以及微服務

2.重點談談SOA與微服務的區別

3.以及爲何要使用微服務架構

什麼是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就是從一臺機器（客戶端）上經過參數傳遞的方式調用另外一臺機器（服務器）上的一個函數或方法（能夠統稱爲服務）並獲得返回的結果。

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框架。

（5）還有SpringCloud框架，微服務全家桶。爲開發人員提供了快速構建分佈式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等。

微服務在本質上，就是rpc。rpc有基於tcp的，http的，mq的等等。spring cloud是基於spring boot的，spring boot 實現的是http協議的rpc，算是rpc的一個子集。

 

什麼是SOA

SOA（Service-Oriented Architecture），中文全稱：面向服務的架構。

通俗點來說，SOA提倡將不一樣應用程序的業務功能封裝成「服務」並宿主起來，一般以接口和契約的形式暴露並提供給外界應用訪問（經過交換消息），達到不一樣系統可重用的目的。

SOA是一個組件模型，它能將不一樣的服務經過定義良好的接口和契約聯繫起來。服務是SOA的基石。

微服務和SOA的區別

微服務是SOA架構演進的結果。二者說到底都是對外提供接口的一種架構設計方式,隨着互聯網的發展，複雜的平臺、業務的出現，致使SOA架構向更細粒度、更經過化程度發展，就成了所謂的微服務了。

總之，微服務是SOA發展出來的產物，它是一種比較現代化的細粒度的SOA實現方式。

SOA與微服務的區別在於以下幾個方面：

1.  微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並沒有影響；
2.  微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各類終端均可以調用，無關語言、平臺限制；
3.  微服務更傾向於分佈式去中心化的部署方式，在互聯網業務場景下更適合。

爲何要使用微服務？

技術爲業務而生，架構也爲業務而出現，固然SOA和微服務也是由於業務的發展而出現。出現SOA和微服務框架與業務的發展、平臺的壯大密不可分，下面借用dubbo的網站架構發展圖和說明：

•  單一應用架構
•  當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
•  此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
•  垂直應用架構
•  當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
•  此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
•  分佈式服務架構
•  當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
•  此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
•  流動計算架構
•  當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
•  此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

平臺隨着業務的發展從 All in One 環境就能夠知足業務需求（以Java來講，可能只是一兩個war包就解決了）。

發展到須要拆分多個應用，而且採用MVC的方式分離先後端，加快開發效率；在發展到服務愈來愈多，不得不將一些核心或共用的服務拆分出來，其實發展到此階段，若是服務拆分的足夠精細，而且獨立運行，我以爲就能夠將之理解爲一個微服務了。