如何從服務治理以及分布式發(fā)展史的角度剖析Service Mesh

這篇文章將為大家詳細講解有關如何從服務治理以及分布式發(fā)展史的角度剖析Service Mesh，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

   在軟負載的世界里，分布式是一個非常重要的領域，世界在變，軟負載領域也在變化。早在10年以前，技術大咖們基本都把精力集中在中間件領域，比如Spring、Mybatis、Struts等，根本不會考慮服務集群的統(tǒng)一管理和調度。Service Mesh目前之所以這么火，其實本質上與計算機、分布式、服務的發(fā)展有很大的關系的，也是技術發(fā)展必須要經歷的過程。

單機小型機時期

• 大而統(tǒng)一的巨無霸應用

• 單機應用垂直拆分

• 計算機摩爾定律-單機性能瓶頸

• 商用IBM機器成本太高

集群化時期

• 從高端的商用IBM機器切換到普通的PC

• 硬件負載均衡瓶頸

• 機器資源的最優(yōu)配置問題

• 軟件負載均衡

服務化時期

• 從應用到服務

• 遠程調用(RPC)

• 虛擬IP地址(通過VIP管理服務地址)

• 管理復雜的服務依賴關系

• 服務治理

  服務治理的軟負載產品，比如Duboo的ZooKeeper注冊中心，SpringCloud的Eureka注冊中心，服務治理主要維護提供者和消費者之間的映射關系(訂閱關系)。

• 旁路負載

微服務時期

• 服務細化

• 架構輕量級

     分布式架構的演進，微服務是一個分水嶺，此時工程師才真正的意識到分布式架構本身的復雜性，微服務化之前，分布式都是往做多做細方向發(fā)展，比如集群化、服務化、服務治理化等，都是架構擴展演進。然而微服務在細化的同時，首次提出輕量級，在微服務化之后，分布式架構進入架構收縮的過程，架構本身的復雜度針對業(yè)務工程師是無感知的。

服務網格(Service Mesh)新時期

• 多語言的差異性

• 指數級的系統(tǒng)架構的復雜度

• Sidecar設計(Linkerd)

• Docker助力Sidecar

• 第一代服務網格

  從數據邏輯層面上解決了微服務關系混亂的問題，但是并沒有實現配置控制，解決了Sidecar的連接性問題。

• 第二代服務網格

  增加了服務的配置控制功能，比如Istio

關于如何從服務治理以及分布式發(fā)展史的角度剖析Service Mesh就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。