1. 程式人生 > >2021升級版微服務教程—為什麼會有微服務?什麼是SpringCloud?

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. 覺得不錯的話,也可以關注 程式設計鹿 的個人公眾號看更多文章和講解視訊(感謝大家的鼓勵與支援