1. 程式人生 > >Spring Cloud系列教程 | 第一篇:微服務架構演進

Spring Cloud系列教程 | 第一篇:微服務架構演進

架構的演變過程: 單體架構——>垂直架構——>soa面向服務架構——>微服務架構

我們為什麼要使用Spring Cloud?

單體架構 在網站開發的前期,專案面臨的流量相對較少,單一應用可以實現我們所需要的功能,從而減少開發、部署和維護的難度。這種用於簡單的增刪改查的資料訪問框架(ORM)十分的重要。

垂直應用架構 當用戶訪問量不斷的提升,單一應用需要不斷的增加伺服器來應對,同時將單一的應用拆分成多個應用用來處理提升效率。這種用於加速Web前端載入的Web框架(MVC)起到了關鍵性的作用。 在這一階段往往會將系統分為不同的層級,每個層級有對應的職責,UI層負責和使用者進行互動、業務邏輯層負責具體的業務功能、資料庫層負責和上層進行資料交換和儲存。 在這裡插入圖片描述

在這裡插入圖片描述 特點: ①.以單體架構為單位進行系統的劃分,劃分成一個個系統. ②.專案與專案之間存在資料冗餘,耦合度高. ③.專案是以介面呼叫為主,存在資料同步問題. 優點: ①.專案架構簡單,前期開發的成本低,週期短,小型企業首先. ②.垂直架構進行mvc分層設計,針對分層做相應的處理做到叢集(10~1000) ③.不同的專案採用不同的技術實現. 缺點: ①.全部的功能都集中在一個專案中完成,對於大型專案來說,開發難度高,不容易開發及擴充套件和維護. ②.叢集擴充套件有瓶頸叢集(10~1000)針對分層做了優化.

SOA 服務化架構 伴隨著企業服務量的不斷提升,MVC框架的部署導致系統的負重越來越多,無法滿足併發的要求,系統間資料、報文的傳輸會出現頻繁的丟失。這時候我們需要考慮服務化的架構(SOA)。SOA表示面向服務的架構。將應用根據不同的職責劃分成不同的模組(類似於企業劃分不同的事業部),不同的模組使用特定的呼叫協議(RPC)和介面進行互動。 這樣使整個系統切分成很多單個元件服務來完成請求,當流量過大時通過水平擴充套件相應的元件來支撐,所有的元件通過互動來滿足整體的業務需求。 SOA服務化的優點是,它可以根據需求通過網路對鬆散耦合的粗粒度應用元件進行分散式部署、組合和使用。 服務層是SOA的基礎,可以直接被應用呼叫,從而有效控制系統中與軟體代理互動的人為依賴性。 服務化架構是一套鬆耦合的架構,服務的拆分原則是服務內部高內聚,服務之間低耦合。 在這裡插入圖片描述

在這裡插入圖片描述

特點: ①.基於soa服務思想進行功能的抽取(重複程式碼問題解決),以服務為中心來管理專案. ②.各個系統之間要進行呼叫,所以出現ESB來管理專案(可以使用各種技術實現:webservice,rpc等) ③.ESB是作為系統與系統之間橋樑,很難進行統一管理. 優點: ①.重複程式碼進行了抽取,提高了開發效率,提高了系統的可維護性. ②.可以針對某個系統進行擴充套件,做叢集更容易. ③.採用ESB來管理服務元件,有利於降低企業開發專案難度 缺點: ①.系統與服務的界限模糊的,不利於設計. ②.ESB是作為系統與系統之間橋樑,沒有統一標準,種類很多,不利於維護. 在這個階段可以使用WebService或者dubbo來服務治理。 抽取專案的粒度大,系統與服務之間解耦問題.

微服務架構 在這裡插入圖片描述 特點: ①.把系統的服務層完全獨立出來,有利於資源的重複利用,提高開發效率. ②.微服務遵守單一原則 ③.微服務與微服務之間的呼叫使用restful輕量級呼叫. 優點: ①.微服務拆分更細,有利於資源的重複利用,提高開發效率 ②.可以更加精準針對某個服務做方案 ③.微服務去中心化,使用restful輕量級通訊協議比使用ESB企業服務匯流排更容易維護 ④.適應市場更容易,產品迭代週期更短. 缺點: ①.微服務量多,服務治理成本高,不利於系統維護. 微服務架構算是SOA架構的一種拓展,主要關注的是服務個體的獨立性、拆分粒度更小。相對於SOA架構來說,微服務擁有以下優勢: 微服務強調更深層次的元件化和服務化,每個微服務都可以擁有獨立的執行空間,確保每一個服務元件可以作為單獨的產品進行釋出。 微服務拋棄了傳統SOA笨重的企業服務匯流排,對外發布強調使用HTTP REST API的介面釋出形式。 微服務的切分粒度大。

瞭解了架構的發展過程,我們來認識一下Spring Cloud。 Spring Cloud來源於Spring,利用Spring Boot進行快捷開發。由於目前Spring Cloud社群的維護和支援的人員數量眾多,相信Spring Cloud會有很好的發展。而且Spring Cloud基本上都是使用了現有的開源框架進行的整合,學習的難度和部署的門檻就比較低,對於中小型企業來說,更易於使用和落地。

Spring Cloud主要解決了什麼問題?

對於企業級的SOA框架來說,服務與服務間的解耦是一項巨大的難題,隨著功能服務的不斷增加,多服務間的相互呼叫頻繁,呼叫過程就像一個雜亂無章的毛線球,很容易導致牽一髮而動全身的情況,經常會由於在服務更新的過程中,沒有合理通訊,導致資料的丟失。 這時候就應該進行服務治理,將服務之間的直接依賴轉化為服務對服務中心的依賴。Spring Cloud 核心元件Eureka就是解決這類問題。 關於Eureka請看下一篇 :Spring Cloud系列教程 | 第二篇:SpringCloud服務發現註冊Eureka +Ribbon + Feign