目錄
- 一. 谷粒商城專案簡介
- 二. 專案背景
- 1. 電商模式
- (1) B2B模式
- (2) B2C模式
- (3) C2B模式
- (4) C2C模式
- (5) O2O模式
- 2. 專案技術與特色
- 3. 技術要求
- 三. 分布式基本概念
- 1. 微服務
- 2. 集群&分布式&節點
- 3.遠程呼叫
- 4.負載均衡
- 5.服務發現與注冊中心
- 6.配置中心
- 7.服務的熔斷與降級
- 8.API網關
- 附錄：
- 專案微服務劃分圖
一. 谷粒商城專案簡介
尚硅谷谷粒商城專案分成分布式基礎篇章，分布式高級篇章以及高可用集群篇章，基于真實企業流水線構建的專案值得大家學習，專案使用后端技術SpringBoot+SpringCloud+Docker和前端Vue和ElementUI前后端分離開發，專案從環境的搭建，編碼測驗以及最后的集群部署，增強全堆疊的能力，專案中的集群技術就包括MySql集群，Redis集群等，專案架構圖如下所示：
除了一般的邏輯業務需求之外，進行服務遠程呼叫使用的是Feign,網關使用Spring Cloud Gateway,鏈路追蹤使用Sleuth+Zipkin，服務的注冊與配置中心使用nacos,線上監控系統則使用Prometheus和Grafana,還有整套的預警系統AlterManager，日志的ELK日志分析系統，存盤使用Redis集群和Mysql的主從分片，RabbitMq訊息佇列以及配合ElasticSearch的全文檢索功能,最后將寫完的代碼從GitHub上自動化拉取打包成docker鏡像，再使用JenkinsPipeline的整個流水線加入引數化構建手動確認后將專案部署到K8S集群中，完成一個完整的專案
二. 專案背景
1. 電商模式
常見的模式B2B，B2C，C2B，C2C，O2O
(1) B2B模式
B2B (Business To Business)， 是指商家與商家建立的商業關系， 如:1688網站，商戶與商戶的批發
(2) B2C模式
B2C(Business To Consumer)，就是我們經常看到的供應商直接把商品賣給用戶，即“商對客”模式，也就是通常說的商業零售， 直接面向消費者銷售產品和服務，如:蘇寧易購、京東、天貓、小米商城，
(3) C2B模式
C2B(Customer To Business)，即消費者對企業，先有消費者需求產生而后有企業生產，即先有消費者提出需求，后有生產企業按需求組織生產
(4) C2C模式
C2C(Customer To Consumer)，客戶之間自己把東西放上網去賣，如:淘寶，閑魚，
(5) O2O模式
O2O即Online To Offline，也即將線下商務的機會與互聯網結合在了一起，讓互聯網成為線下交易的前臺，線上快速支付，線下優質服務，如:餓了么，美團，淘票票，京東到家
谷粒商城是B2C模式
2. 專案技術與特色
- 前后分離開發，基于vue的后臺管理系統
- SpringCloud 全新的解決方案
- 應用監控、限流、網關、熔斷降級等分布式方案全方位涉及
- 透徹講解分布式事務、分布式鎖等分布式系統的難點
- 分析高并發場景的編碼方式，執行緒池，異步編排等使用
- 壓力測驗與性能優化
- 各種集群技術的區別
- 以及使用 CI/CD 使用
3. 技術要求
- 熟悉SpringBoot以及常見的整合方案
- 了解過SpringCloud
- 熟悉Git,Maven
- 了解過Html Css JavaScript
- 熟練使用IDEA開發專案
三. 分布式基本概念
1. 微服務
將大型的單體應用拆分成各個獨立運行的小模塊，模塊與模塊之間獨立部署運行
2. 集群&分布式&節點
集群是物理狀態，分布式是個作業方式；
分布式系統是若干獨立計算機的集合，這些計算機對于用戶來說就像單個相關系統，分布式系統是建立在網路上的網路系統，分布式是指將不同的業務分布在不同的地方，集群就是指將幾臺機器集中在一起，實作同一業務，
例如:京東是一個分布式系統,眾多業務運行在不同的機器，所有業務構成一個大型的業務集群，每一個小的業務，比如用戶系統，訪問壓力大的時候一-臺服務器是不夠的，我們就應該將用戶系統部署到多個服務器，也就是每一個業務系統也可以做集群化;
分布式中的每一個節點，都可以做集群，而集群并不一定就是分布式的
節點：集群中的一個服務器
3.遠程呼叫
分布式系統中，各個服務可能處于不同的主機，但是服務之間需要的是互相的呼叫，稱為遠程呼叫
對于SpringCloud是使用的是HTTP+JSON進行遠程呼叫
4.負載均衡
分布式系統中，A服務要呼叫B服務，B服務在多個機器中存在，A呼叫任意一個都能成功；為了使每個機器上的服務不閑置和過于忙碌，使用負載均衡的呼叫每個服務器，提升網站的健壯性
常見的負載均衡的演算法：
-
輪詢
為每一個請求選擇健康池中的第一個后端服務器，然后按順序往后依次選擇，直到最后一個，一次回圈
-
最小連接數
優先選擇連接數數最少，也就是壓力最小的后端服務器，在會話較長的情況下考慮這種方式
5.服務發現與注冊中心
A服務呼叫B服務，A服務不知道B服務在哪幾臺服務器有，哪些服務是正常的還是下線狀態的，這個時候就引入了注冊中心，如果某些服務下線，就會感知到其他服務的狀態，從而避免呼叫不可用的服務
6.配置中心
每個服務都可能有大量的配置，并且每個服務都可能部署在多臺服務器上，我們經常需要更改服務的配置，我們可以讓每個服務在配置中心獲取自己的配置
7.服務的熔斷與降級
微服務之間通過網路進行通信，存在相互依賴，當其中一個服務不可用時，有可能會造成雪崩效應，要防止這樣的情況，必須要有容錯機制來保護服務
-
服務熔斷
設定服務的超時，當被呼叫的服務經常失敗到達某個閾值，可以開啟斷路保護機制，后來的請求不再去呼叫這個服務，本地直接回傳默認的資料
-
服務降級
在運維期間，當系統處于高峰期，系統資源緊張，我們可以讓非核心業務降級運行，降級：某些服務不處理，或者簡單處理（拋例外，回傳NULL,呼叫Mock資料，呼叫Fallback處理邏輯）
8.API網關
在微服務架構中，API Gateway（API網關）作為整體架構的重要組件，它抽象了徼服務中都需要的公共功能，同時提供了客戶端負載均衡，服務自動熔斷，灰度發布，統—認證，限流流控，日志統計等豐富的功能，幫助我們解決很多API管理難題，
附錄：
專案微服務劃分圖
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/279228.html
標籤：其他
下一篇：Vue.js 組件化開發