2021升級版微服務教程—爲何會有微服務？什麼是SpringCloud？

2021升級版SpringCloud教程從入門到實戰精通「H版&alibaba&鏈路追蹤&日誌&事務&鎖」

教程全目錄「含視頻」：https://gitee.com/bingqilinpeishenme/Java-Wiki

微服務基本概念

架構的演變

爲何會有微服務？

假如回到10年前，一天張三入職了電商企業—並夕夕商城。

公司初創，人比較少，公司網站的用戶也不多，公司只有一個工程師

項目架構比較簡單

1.單體架構

image-20200317144318312

沒有想到的是，公司業務愈來愈好，網站用戶量愈來愈大，單體架構的問題就暴露出來了，隨着訪問量增長，項目常常宕機

問題：架構簡單 難以抗住高併發

因而，招人。對並夕夕商城進行升級優化。

分析升級的方向：

1. 數據庫 和 應用代碼要放在不一樣的服務器上
2. 增長應用負載能力【集羣】

因而增長負載均衡。

2.負載均衡

分佈式：一個系統 經過多臺服務器 協同完成系統功能

集羣：同一個系統放在了多臺服務器上 且每一個服務器上內容相同 複製了多份

image-20200317145056653

負載均衡的問題

1. 成本
2. Session

增長負載均衡以後，應用服務器再也不是系統的瓶頸了，能夠靈活的隨着訪問量增大的同時增長應用服務器集羣的數量。

隨着業務量不斷增長，數據量也在不斷增長，數據庫出現性能瓶頸。

招人

在多位同事努力之下，對項目進行進一步的優化—讀寫分離。

3.讀寫分離

image-20200317145753793

上述的架構看上去很是的完美，可是，隨着並夕夕商城業務量的不斷增長，新的問題暴露了出來。

問題：

1. 商品搜索使用數據庫模糊查詢不行，不精確，慢 【全文檢索】

   圖書查詢 模糊匹配

2. 不一樣模塊的數據訪問的頻率是不同的（熱度不一樣），首頁數據訪問量比較大，訂單數據的訪問量相比之下要小不少。全部的數據都去數據庫取，影響首頁訪問速度 【緩存】

招人

4.全文檢索緩存

全部的同事開始一塊兒優化項目，商品搜索使用全文檢索技術ES完成，而且引入緩存（Redis集羣），因而架構變成了這個亞子。

image-20200317150418119

隨着並夕夕商城不斷壯大，公司迎來了風投，風投兩個億，因而商城發展的更快了，新的問題出現了。

問題：

• 不一樣業務模塊之間的耦合過高，一個模塊出問題整個服務器宕機

• 維護困難，假如應用服務器集羣200臺，那麼項目上線意味着須要部署200臺服務器

  譬如：修改了訂單的代碼 訂單模塊要從新部署 意味着全部的服務器都須要從新部署一遍

• 冗餘，有些模塊沒有必要部署在全部的服務器上

招人：100我的的團隊，對項目進行新的優化和升級—服務化（SOA），根據業務模塊的不一樣，拆分爲不一樣的應用。

以上就是分佈式的架構

5.服務化

因而公司進入轟轟烈烈的服務化時代，可是有幾個問題須要被解決，以下

image-20200317151634243

每個模塊都是一個獨立的項目 均可以獨立啓動 這樣的作法 就叫作服務化 模塊變成項目以後咱們稱之爲服務 首頁模塊---》首頁服務

這就是服務化 這就是微服務，微服務是：特殊的分佈式架構【服務化】

• 首頁的訪問量比較大 就能夠部署五個
• 訂單的訪問量小 就能夠只部署一個

image-20210105104120083

問題：

1. 服務之間怎麼調用？例如：訂單服務須要調用商品服務的數據，怎麼調用？

2. 怎麼負載均衡？服務之間負載均衡？app訪問後臺怎麼負載均衡？

3. 服務怎麼被管理？例如：商品服務宕機了，怎麼即時的通知訂單服務？若是沒有通知訂單服務，訂單服務發的請求都會阻塞，形成訂單宕機，引起鏈式故障，整個項目崩潰

4. 服務之間的異常處理？

   ......

以上每個問題都須要一個新的技術解決，而引入的新技術就是微服務技術，SpringCloud（一套技術）

如何解決這幾個問題 又須要用到一些新的技術，這些技術就是所謂的微服務的技術（SpringCloud）

基於上面的問題，整個並夕夕商城團隊瘋狂的努力，找到了一些技術（SpringCloud），分別解決了上述問題，架構圖以下：

image-20200317153320482

到此爲止，並夕夕商城成爲了一個微服務的架構。

服務化 微服務主要的內容就是按照業務模塊拆分不一樣的應用服務，而且解決拆分以後遇到的問題

什麼是微服務

the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.【官方文檔】

• 每一個服務可獨立運行在本身的進程裏 每一個服務獨立部署啓動
• 一系列獨立運行的微服務共同構建起整個系統
• 每一個服務爲獨立的業務開發，一個微服務只關注某個特定的功能，例如訂單管理，用戶管理【按照服務拆分】
• 微服務之間經過一些輕量的通訊機制進行通訊，例如Restful API（HTTP）進行調用【訂單服務如何調用商品服務】
• 可使用不一樣的編程語言與數據存儲技術開發

官網連接：https://www.martinfowler.com/articles/microservices.html

什麼是SpringCloud

SpringCloud=分佈式微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶。Spring Cloud是一個含概多個子項目的開發工具集，集合了衆多的開源框架，他利用了Spring Boot開發的便利性實現了不少功能，如服務註冊，服務發現，負載均衡等。

• 服務管理 須要一個技術

• 服務調用 須要一個技術

• 負載均衡 須要一個技術

  .......

這些技術怎麼來？

1. 本身找，技術之間的整合沒有必定的技術實力搞不定
2. SpringCloud，SpringCloud官方找了一套解決微服務問題的技術，作了封裝和整合，讓用戶能夠直接使用，不須要關心技術整合的問題

開發微服務至關於買一臺電腦

1. 本身組裝，本身找微服務的技術至關於本身組裝電腦
2. 買品牌機，使用SpringCloud至關於直接買了一個聯想的電腦，CPU 顯卡等等都幫你處理好了

SpringBoot 和 SpringCloud有什麼關係

使用負載均衡須要不少的配置，寫配置

• 本身寫配置
• SpringBoot自動配置

SpringCloud 使用了 SpringBoot 做爲底層，經過SpringBoot的自動配置簡化分佈式的開發

若是你以爲這篇內容對你挺有有幫助的話

1. 點贊支持下吧，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓 -_-）

2. 歡迎在留言區與我分享你的想法，也歡迎你在留言區記錄你的思考過程。

3. 以爲不錯的話，也能夠關注 編程鹿 的我的公衆號看更多文章和講解視頻（感謝你們的鼓勵與支持🌹🌹🌹）