關於微服務入門篇

MO_or發表於2020-05-12
微服務

一. 引言

本篇文章是整理筆者在學習微服務時的入門篇，將探討以下幾點：

  1. 什麼是單體架構及其優劣
  2. 什麼是微服務
  3. 什麼是微服務架構及其優劣
  4. 微服務和微服務架構的區別
  5. 單體架構與微服務架構的區別
  6. 微服務的適用場景
  7. 微服務架構所涉及的開發框架有哪些
  8. 如何選擇框架的不同版本

二. 單體架構

2.1什麼是單體架構

簡單來說就是一個war包打天下，war包中就包含了各種功能和資源，比如JSP. JS. CSS，業務就是各個功能模組，如下圖：
單體架構.png

2.2單體架構優缺點

優點：

  1. 架構簡單，少了很多微服務中的問題(下文會講是哪些問題)
  2. 開發. 測試. 部署簡單，特別是部署

缺點：

  1. 隨業務擴充套件，程式碼量越來越多，由於開發人員水平不同，程式碼質量參差不齊，改動程式碼時牽一髮而動全身，開發人員如履薄冰
  2. 部署慢，由於程式碼量過多，每次部署可能需要幾分鐘甚至幾十分鐘
  3. 擴充套件成本高，根據單體架構圖，假若支付模組為CPU密集型，需要大量計算，即需要更好的CPU，若訂單模組為IO密集型，需要大量磁碟讀寫，即需要更好的記憶體和磁碟。單體架構又不支援單模組擴充套件，則我們就需要更好的CPU. 記憶體. 磁碟，那麼硬體成本就會飛速上漲
  4. 不利於新技術發展，想想老闆突然一天說我們把Struts2專案往Spring Boot上遷移...

三. 微服務與微服務架構

3.1 什麼是微服務

微服務的核心就是將傳統的單體架構拆分成單個服務，將業務間進行解耦，每個服務可以單獨部署. 可以擁有自己的資料庫這樣拆分出來的服務就叫做微服務。

就比如說，單體架構中有訂單. 支付. 物流. 積分等業務，拆分成微服務，訂單服務，支付服務，物流服務，積分服務

這樣拆分出來有什麼意義呢？

單體架構中若非核心模組出現重大Bug，比如積分模組記憶體溢位，就會導致整個專案當機
但若是拆分成微服務，則只是說積分服務不能使用，但核心服務並不會受到影響

3.2什麼是微服務架構

微服務架構是一種架構風格，包含如下幾個特點：

  1. 將一個單一應用程式開發為一組小型服務
  2. 每個服務執行在自己的程式中
  3. 服務之間通過輕量級的通訊機制(http rest api)
  4. 每個服務都能夠獨立的部署
  5. 每個服務甚至可以擁有自己的資料庫

3.3微服務與微服務架構的區別

微服務是服務的大小和對外提供的單一功能，微服務架構是指把一個個微服務管理起來，對外提供的一套完整服務

3.4微服務架構的優缺點

優點：

  1. 每個服務足夠小，內聚高，程式碼更易理解，相較於單體架構，修改幾行程式碼可能需要對整個系統邏輯都要理解
  2. 易開發，單個服務功能集中
  3. 單個服務可以由小團隊進行開發，效率高
  4. 擴充套件成本低，按需擴縮容
  5. 前後端分離，Java開發人員能更集中精力關心後端介面的安全性和效率
  6. 每個服務擁有獨立的資料庫，也可以多個服務使用一個資料庫

缺點：

  1. 增加運維人員工作量，可能會部署非常多的war包(k8s + Docker + Jenkis)
  2. 服務之間相互呼叫，增加通訊成本
  3. 資料一致性問題(分散式事務問題). 效能監控等
  4. 問題定位時間成本增加

3.5單體架構和微服務架構的區別

單體架構擴充套件

併發增加，上叢集，硬體成本高

單體架構擴充套件.png

微服務架構擴充套件

併發增加，靈活擴充套件，降低硬體成本，但運維成本. 開發成本上升
微服務架構擴充套件.png

資料儲存區別

單體架構：僅有一個資料庫
微服務架構：每個微服務都可以有一個資料庫
decentralised-data.png

3.6微服務的適用場景

適用於：

  1. 大型複雜專案(上百萬行程式碼的專案T_T)
  2. 快速迭代專案(一天一更，吐血QAQ)
  3. 高併發專案(考慮彈性擴縮容T~T)

不適用：

  1. 業務穩定，就修修BUG，改改資料
  2. 迭代週期長，釋出頻率按月來算的

四. 開發微服務的框架

4.1相關框架

  • Spring Boot 快速開發微服務的Web框架
  • Spring Cloud 微服務架構的一套工具集
  • Spirng Cloud Alibaba 阿里提供的符合Spring Cloud標準的，一套微服務架構工具集

下圖便是Spirng Cloud Alibaba提供的一套工具集，注意雖然有些備註是開源，但只是部分開源，一些核心功能依舊需要付費才能使用，比如Sentinel，開源的話本地限流配置是不能持久化的(可以選擇付費，大佬可以改原始碼來解決該問題)
Spring Cloud Alibaba.png

4.2如何選擇框架的版本

Spring Boot

以2.1.6.RELEASE版本為例

  • 其中2：表示的主版本號，表示是我們的SpringBoot第二代產品
  • 其中1:表示的是次版本號，增加了一些新的功能但是主體的架構是沒有變化的，是相容的
  • 其中6:表示的是bug修復版

所以2.1.6合起來就是springboot的第二代版本的第一個小版本的 第6次bug修復版本

RELEASE:存在哪些取值呢？

  1. snapshot(開發版本)
  2. M1...M2(里程碑版本,在正式版釋出之前會出幾個里程碑的版本)
  3. release(正式版本)

所以選擇版本時請認準release

Spring Cloud

  • 第一代版本:Angle
  • 第二代版本:Brixton
  • 第三代版本:Camden
  • 第四代版本:Edgware
  • 第五代版本:Finchley
  • 第六代版本:GreenWich
  • 第七代版本:Hoxton(還在醞釀中，沒正式版本)
  • 這種釋出的版本是 以倫敦地鐵站發行地鐵的站

為什麼我們的SpringCloud會以這種方式來發布版本，因為假如我們傳統的5.1.5release這種釋出的而SpringCloud會包含很多子專案的版本就會給人造成混淆
Spring Cloud子專案.png

  • SNAPSHOT：快照版本，隨時可能修改
  • M：MileStone，M1表示第1個里程碑版本，一般同時標註PRE，表示預覽版版
  • RC：版本英文版名字叫Release Candidate（候選版本）一般標註PRE表示預覽版
  • SR：Service Release，SR1表示第1個正式版本，一般同時標註GA：(GenerallyAvailable)，表示穩定版本，比如還有一種RELEASE版本（正式版本）

比如Greenwich版本順序：Greenwich.release----->發現bug----->Greenwich.SR1------>發現bug---->Greenwich.SR2

總結：

  1. 打死不用 非穩定版本/ end-of-life（不維護）版本
  2. release版本先等等
  3. 推薦SR2以後的可以放心使用
Spring Boot. Spring Cloud. Spring Cloud Alibaba

這三個框架的版本關係，及推薦使用的版本如下：

框架間版本關係.png

五. 參考

六. 最後

若有不足，敬請指正
虛心若愚，求知若渴

相關文章