關於微服務入門篇

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

五. 參考

六. 最後

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

相關文章