一. 引言
本篇文章是整理筆者在學習微服務時的入門篇,將探討以下幾點:
- 什麼是單體架構及其優劣
- 什麼是微服務
- 什麼是微服務架構及其優劣
- 微服務和微服務架構的區別
- 單體架構與微服務架構的區別
- 微服務的適用場景
- 微服務架構所涉及的開發框架有哪些
- 如何選擇框架的不同版本
二. 單體架構
2.1什麼是單體架構
簡單來說就是一個war包打天下,war包中就包含了各種功能和資源,比如JSP. JS. CSS,業務就是各個功能模組,如下圖:
2.2單體架構優缺點
優點:
- 架構簡單,少了很多微服務中的問題(下文會講是哪些問題)
- 開發. 測試. 部署簡單,特別是部署
缺點:
- 隨業務擴充套件,程式碼量越來越多,由於開發人員水平不同,程式碼質量參差不齊,改動程式碼時牽一髮而動全身,開發人員如履薄冰
- 部署慢,由於程式碼量過多,每次部署可能需要幾分鐘甚至幾十分鐘
- 擴充套件成本高,根據單體架構圖,假若支付模組為CPU密集型,需要大量計算,即需要更好的CPU,若訂單模組為IO密集型,需要大量磁碟讀寫,即需要更好的記憶體和磁碟。單體架構又不支援單模組擴充套件,則我們就需要更好的CPU. 記憶體. 磁碟,那麼硬體成本就會飛速上漲
- 不利於新技術發展,想想老闆突然一天說我們把Struts2專案往Spring Boot上遷移...
三. 微服務與微服務架構
3.1 什麼是微服務
微服務的核心就是將傳統的單體架構拆分成單個服務,將業務間進行解耦,每個服務可以單獨部署. 可以擁有自己的資料庫這樣拆分出來的服務就叫做微服務。
就比如說,單體架構中有訂單. 支付. 物流. 積分等業務,拆分成微服務,訂單服務,支付服務,物流服務,積分服務
這樣拆分出來有什麼意義呢?
單體架構中若非核心模組出現重大Bug,比如記憶體溢位,就會導致整個專案當機
但若是拆分成微服務,則只是說積分服務不能使用,但核心服務並不會受到影響
3.2什麼是微服務架構
微服務架構是一種架構風格,包含如下幾個特點:
- 將一個單一應用程式開發為一組小型服務
- 每個服務執行在自己的程式中
- 服務之間通過輕量級的通訊機制(http rest api)
- 每個服務都能夠獨立的部署
- 每個服務甚至可以擁有自己的資料庫
3.3微服務與微服務架構的區別
微服務是服務的大小和對外提供的單一功能,微服務架構是指把一個個微服務管理起來,對外提供的一套完整服務
3.4微服務架構的優缺點
優點:
- 每個服務足夠小,內聚高,程式碼更易理解,相較於單體架構,修改幾行程式碼可能需要對整個系統邏輯都要理解
- 易開發,單個服務功能集中
- 單個服務可以由小團隊進行開發,效率高
- 擴充套件成本低,按需擴縮容
- 前後端分離,Java開發人員能更集中精力關心後端介面的安全性和效率
- 每個服務擁有獨立的資料庫,也可以多個服務使用一個資料庫
缺點:
- 增加運維人員工作量,可能會部署非常多的war包(k8s + Docker + Jenkis)
- 服務之間相互呼叫,增加通訊成本
- 資料一致性問題(分散式事務問題). 效能監控等
- 問題定位時間成本增加
3.5單體架構和微服務架構的區別
單體架構擴充套件
併發增加,上叢集,硬體成本高
微服務架構擴充套件
併發增加,靈活擴充套件,降低硬體成本,但運維成本. 開發成本上升
資料儲存區別
單體架構:僅有一個資料庫
微服務架構:每個微服務都可以有一個資料庫
3.6微服務的適用場景
適用於:
- 大型複雜專案(上百萬行程式碼的專案T_T)
- 快速迭代專案(一天一更,吐血QAQ)
- 高併發專案(考慮彈性擴縮容T~T)
不適用:
- 業務穩定,就修修BUG,改改資料
- 迭代週期長,釋出頻率按月來算的
四. 開發微服務的框架
4.1相關框架
- Spring Boot 快速開發微服務的Web框架
- Spring Cloud 微服務架構的一套工具集
- Spirng Cloud Alibaba 阿里提供的符合Spring Cloud標準的,一套微服務架構工具集
下圖便是Spirng Cloud Alibaba提供的一套工具集,注意雖然有些備註是開源,但只是部分開源,一些核心功能依舊需要付費才能使用,比如Sentinel,開源的話本地限流配置是不能持久化的(可以選擇付費,大佬可以改原始碼來解決該問題)
4.2如何選擇框架的版本
Spring Boot
以2.1.6.RELEASE版本為例
- 其中2:表示的主版本號,表示是我們的SpringBoot第二代產品
- 其中1:表示的是次版本號,增加了一些新的功能但是主體的架構是沒有變化的,是相容的
- 其中6:表示的是bug修復版
所以2.1.6合起來就是springboot的第二代版本的第一個小版本的 第6次bug修復版本 RELEASE:存在哪些取值呢?
- snapshot(開發版本)
- M1...M2(里程碑版本,在正式版釋出之前會出幾個里程碑的版本)
- release(正式版本)
所以選擇版本時請認準release
Spring Cloud
- 第一代版本:Angle
- 第二代版本:Brixton
- 第三代版本:Camden
- 第四代版本:Edgware
- 第五代版本:Finchley
- 第六代版本:GreenWich
- 第七代版本:Hoxton(還在醞釀中,沒正式版本)
- 這種釋出的版本是 以倫敦地鐵站發行地鐵的站
為什麼我們的SpringCloud會以這種方式來發布版本,因為假如我們傳統的5.1.5release這種釋出的而SpringCloud會包含很多子專案的版本就會給人造成混淆
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
總結:
- 打死不用 非穩定版本/ end-of-life(不維護)版本
- release版本先等等
- 推薦SR2以後的可以放心使用
Spring Boot. Spring Cloud. Spring Cloud Alibaba
這三個框架的版本關係,及推薦使用的版本如下:
五. 參考
六. 最後
若有不足,敬請指正
虛心若愚,求知若渴