關於微服務入門篇

一. 引言

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

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

二. 單體架構

2.1什麼是單體架構

簡單來講就是一個war包打天下，war包中就包含了各類功能和資源，好比JSP. JS. CSS，業務就是各個功能模塊，以下圖：

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單體架構和微服務架構的區別

單體架構擴展

併發增長，上集羣，硬件成本高

微服務架構擴展

併發增長，靈活擴展，下降硬件成本，但運維成本. 開發成本上升

數據存儲區別

單體架構：僅有一個數據庫
微服務架構：每一個微服務均可以有一個數據庫

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，開源的話本地限流配置是不能持久化的(能夠選擇付費，大佬能夠改源代碼來解決該問題)

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會包含不少子項目的版本就會給人形成混淆

• 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

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

五. 參考

• Spring
• 微服務

六. 最後

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