面向服務的體系架構(SOA)理論基礎

1、RPC

1)名詞解釋

  • Remote Process Call,遠程過程調用;
  • 將原來的本地調用轉變爲調用遠程的服務器上的方法;
  • RPC的實現包括客戶端和服務端,服務的調用方與服務的提供方。

在這裏插入圖片描述

  1. 一次RPC調用:服務調用方發送RPC請求到服務提供方,服務提供方根據調用方提供的參數執行請求方法,將執行結果返回給調用方。

  2. 調用參數及響應結果的序列化和反序列操作;

  3. 服務提供方的壓力增加,服務需要擴容;

  4. 服務的路由和負載均衡:隨着服務提供者的增加,不同的服務之間需要進行分組,以隔離不同的業務,避免互相影響;

  5. 服務消費者通過獲取服務提供者的分組信息和地址信息進行路由,服務提供者爲一個集羣,需要根據相應的負載均衡策略選取其中一臺進行調用。

在這裏插入圖片描述

  1. 對象的序列化:任何類型的數據都需要轉換成二進制流在網絡上進行傳輸。將對象轉換爲二進制流的過程是序列化;將二進制流恢復爲二進制流的過程稱爲對象的反序列化。

  2. HTTP:採用HTTP1.1;屬於應用層協議;無狀態協議

  3. JSON:JavaScript Object Notation,輕量級的數據交換格式。

  4. XML:Extensible Markup Language,可擴展標記語言;

  5. RESTful:Resource Representational State Transfer,後端將資源發佈爲URI,前端通過URI訪問資源,並通過HTTP動詞表示要對資源進行的操作。

  6. SOAP:簡單對象訪問協議是一種數據交換協議規範,是一種輕量的、簡單的、基於XML的協議的規範。SOAP協議和HTTP協議一樣,都是底層的通信協議,只是請求包的格式不同而已,SOAP包是XML格式的。

    SOAP的消息是基於xml並封裝成了符合http協議,因此,它符合任何路由器、 防火牆或代理服務器的要求。

    SOAP可以使用任何語言來完成,只要發送正確的soap請求即可,基於soap的服務可以在任何平臺無需修改即可正常使用。

  7. SOA(Service-Oriented Architecture),中文全稱:面向服務的架構。

    通俗點來講,SOA提倡將不同應用程序的業務功能封裝成“服務”並宿主起來,通常以接口和契約的形式暴露並提供給外界應用訪問(通過交換消息),達到不同系統可重用的目的。

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

  8. 微服務和SOA的區別

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

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

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

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

2、服務的路由和負載均衡

  1. 服務的路由:在SOA架構中,服務消費者通過服務名稱,在衆多服務中找到要調用的服務的地址列表。

  2. 服務的負載均衡:負載較高的服務通常對應着多臺服務器組成的集羣。在請求到來時,爲了將請求均衡地分配到後端服務器,負載均衡程序將從服務對應的地址列表中,通過相應的負載均衡算法和規則,選取一臺服務器進行訪問;

  3. 服務配置中心:動態註冊和獲取服務信息,統一管理服務名稱和其對應的服務器列表信息;

  4. 負載均衡算法:

    1. 輪詢(round robin):將請求按順序輪流地分配到後端服務器上;
    2. 隨機(random):根據後端服務器列表的大小值來隨機選取其中一臺進行訪問;
    3. 源地址哈希(hash):獲取客戶端訪問的IP地址值,通過哈希函數計算得到一個數值,用該數值對服務器的列表的大小進行取模,得到的就是要訪問的服務器的序號;
    4. 加權輪詢(weight round robin):將請求順序且按照權重分配到後端;
    5. 加權隨機(weight random)
    6. 最小連接數(least connections):根據後端服務器當前的連接情況,動態地選取其中當前積壓連接數最少的一臺服務器來處理當前請求;
  5. 動態配置規則:groovy腳本實現

  6. Zookeeper

    1. zk集羣通過zab(zookeeper atomic broadcast)協議來保持數據的一致性;

在這裏插入圖片描述

  1. zab協議包括:leader selection和atomic broadcast階段;

  2. zk實現了一個層次命名空間的數據模型,每個結點znode,當結點發生變化時,watch機制會發出相應的通知給訂閱其狀態的客戶端;

  3. 結點類型:持久,臨時、持久順序、臨時順序;

  4. zkClient解決watcher一次性註冊問題;

在這裏插入圖片描述
本文僅僅用於作者學習與總結,若有不妥之處,敬請指出!

參考資料:
《大型分佈式網站架構設計與實踐》 提取碼:n4gh
《阿里P8架構師談:Restful、SOAP、RPC、SOA、微服務之間的區別 》
《Dubbo與註冊中心Zookeeper的交互過程》

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章