微服務 | Spring Cloud(一):從單體SSM 到 Spring Cloud

雙鬼帶單發表於2020-10-10

系列文章目錄

微服務 | Spring Cloud(一):從單體SSM 到 Spring Cloud



前言

在微服務如火如荼的情況下,越來越多的專案開始嘗試改造成微服務架構,微服務即帶來了專案開發的方便性,又提高了運維難度以及網路不可靠的概率.

在說微服務的優缺點時,一定要對比一下單體式機構,有對比才會更加明顯。

首先說一下單體式結構

單體式架構

在單體式架構中,系統通常採用分層架構模式(MVC),持久化層、表示層,業務邏輯層。架構主要存在以下問題:

  1. 系統內部互相訪問,耦合緊密導致難以維護;
  2. 各業務領域需要採用相同的技術棧,難以快速應用新技術(例如使用SSH很難向SSM改造);
  3. 對系統的任何修改都必須整個系統一起重新部署/升級;
  4. 在系統負載增加時,難以進行水平擴充套件;
  5. 當系統中一處出現問題,會影響整個系統;

在參加第一份工作的時候,因為專案比較小, 使用者也比較小,所有的功能寫在同一個專案裡面,部署的時候也只部署一個例項。簡化了開發中遇到的併發問題,同時也完美的命中了上面的一些問題,每次功能上線都需要專案重啟。

在常見的方案中,我們可以對服務進行拆分,通過配置域名來進行兩個服務間的通訊,這樣也能減小單個專案的規模,配置域名這種方式費事費力每增加一個服務例項都需要手動配置 Nginx 配置,每增加一個專案,又需要進行域名配置,配置繁瑣且容易出錯

為了克服以上缺點,微服務架構應運而生。微服務,又叫微服務架構。微服務就是一些協同工作的小而自治的服務.

微服務架構

優點

1. 技術異構性

在不同的服務中,可以使用不同的技術來各自開發,只要保證服務間能相互協作即可

2. 彈性

當微服務中的某一個服務不可用時,不會影響整個系統,只會影響相關功能不可用

3. 擴充套件

易於擴充套件,使用小的多個服務,更加易於擴充套件新的功能

4. 簡化部署

某個服務的更新部署,不需要重新部署整個應用

5. 可組合

通過組合多個服務,可以提供一些新的功能

6. 可替代

因為每個微服務都比較小,重新實現某一個服務或者直接刪除該服務都是可操作的

缺點

1. 複雜度高

微服務間通過REST、RPC等形式互動,相對於單體模式,需要考慮被呼叫方故障、過載、訊息丟失等各種異常情況,程式碼邏輯更加複雜。

對於微服務間的事務性操作,因為不同的微服務採用了不同的資料庫,將無法利用資料庫本身的事務機制保證一致性,需要引入二階段提交等技術。

同時,在微服務間存在少部分共用功能但又無法提取成微服務時,各個微服務對於這部分功能通常需要重複開發,或至少要做程式碼複製,以避免微服務間的耦合,增加了開發成本。

2. 運維複雜

在採用微服務架構時,系統由多個獨立執行的微服務構成,需要一個設計良好的監控系統對各個微服務的執行狀態進行監控。運維人員需要對系統有細緻的瞭解才對夠更好的運維繫統。

3. 影響效能

相對於單體架構,微服務的間通過REST、RPC等形式進行互動,通訊的時延會受到較大的影響。

服務發現與彈性擴充套件

正如前面介紹單體式架構的那樣,當我們想擴充套件專案的時候,我們可以在單個專案上繼續新增功能程式碼,也可以根據功能建立一個新的專案,並對專案配置域名,然後通過域名來回撥用

未完待續

參考

  1. 微服務設計(Sam Newman)

白色兔子公眾號圖片

相關文章