分布式基礎篇
一 項目簡介
1、項目背景
1.1 電商模式
市面上有 5 種常見的電商模式 B2B、B2C、C2B、C2C、O2O；
（1）B2B模式
B2B(Business to Business)，是指商家和商家建立的商業關系，如阿里巴巴
（2）B2C模式
B2C(Business to Consumer) 就是我們經常看到的供應商直接把商品賣給用戶，即 “商對客” 模式，也就是我們呢說的商業零售，直接面向消費銷售產品和服務，如蘇寧易購，京東，天貓，小米商城
（3）C2B模式
C2B (Customer to Business),即消費者對企業，先有消費者需求產生而后有企業生產，即先有消費者提出需求，后又生產企業按需求組織生產
（4）C2C模式
C2C (Customer to Consumer) 客戶之間把自己的東西放到網上去賣 。如淘寶、咸魚
（5）O2O模式
O2O 即 Online To Offline，也即將線下商務的機會與互聯網結合在一起，讓互聯網成為線上交易前台，線上快速支付，線上優質服務，如：餓了么，美團，淘票票，京東到家
1.2 谷粒商城
谷粒商城是一個 B2C 模式的電商平台，銷售自營商品給客戶。
2、項目架構圖
2.1項目微服務架構圖
前后分離開發，分為內網部署和外網部署，外網是面向公眾訪問的。
訪問前端項目，可以有手機APP，電腦網頁；內網部署的是后端集群，前端在頁面上操作發送請求到后端，在這途中會經過Nginx集群，Nginx把請求轉交給API網關(springcloud gateway)（網關可以根據當
前請求動態地路由到指定的服務，看當前請求是想調用商品服務還是購物車服務還是檢索服務），從路由過來如果請求很多，可以負載均衡地調用商品服務器中一台（商品服務復制了多份），當商品服務器出現問題也
可以在網關層面對服務進行熔斷或降級（使用阿里的sentinel組件），網關還有其他的功能如認證授權、限流（只放行部分到服務器）等。
到達服務器后進行處理（springboot為微服務），服務與服務可能會相互調用（使用feign組件），有些請求可能經過登錄才能進行（基於OAuth2.0的認證中心。安全和權限使用springSecurity控制）
服務可能保存了一些數據或者需要使用緩存，我們使用redis集群（分片+哨兵集群）。持久化使用mysql，讀寫分離和分庫分表。 服務和服務之間會使用消息隊列（RabbitMQ），來完成異步解耦，分布式事務的一致性。有些服務可能需要全文檢索，檢索商品信息，使用ElaticSearch。 服務可能需要存取數據，使用阿里雲的對象存儲服務OSS。 項目上線后為了快速定位問題，使用ELK對日志進行處理，使用LogStash收集業務里的各種日志，把日志存儲到ES中，用Kibana可視化頁面從ES中檢索出相關信息，幫助我們快速定位問題所在。 在分布式系統中，由於我們每個服務都可能部署在很多台機器，服務和服務可能相互調用，就得知道彼此都在哪里，所以需要將所有服務都注冊到注冊中心。服務從注冊中心發現其他服務所在位置（使用阿里Nacos作為注冊中心）。 每個服務的配置眾多，為了實現改一處配置相同配置就同步更改，就需要配置中心，也使用阿里的Nacos，服務從配置中心中動態取配置。 服務追蹤，追蹤服務調用鏈哪里出現問題，使用springcloud提供的Sleuth、Zipkin、Metrics，把每個服務的信息交給開源的Prometheus進行聚合分析，再由Grafana進行可視化展示，提供Prometheus提供的AlterManager實時
得到服務的警告信息，以短信/郵件的方式告知服務開發人員。 還提供了持續集成和持續部署。項目發布起來后，因為微服務眾多，每一個都打包部署到服務器太麻煩，有了持續集成后開發人員可以將修改后的代碼提交到github，運維人員可以通過自動化工具Jenkins Pipeline將github中獲取的代碼打 包成docker鏡像，最終是由k8s集成docker服務，將服務以docker容器的方式運行。
2.2 微服務划分圖
反映了需要創建的微服務以及相關技術。
前后分離開發。前端項目分為admin-vue（工作人員使用的后台管理系統）、shop-vue（面向公眾訪問的web網站）、app（公眾）、小程序（公眾） 商品服務：商品的增刪改查、商品的上下架、商品詳情 支付服務 優惠服務 用戶服務：用戶的個人中心、收貨地址 倉儲服務：商品的庫存 秒殺服務 訂單服務：訂單增刪改查 檢索服務：商品的檢索ES 中央認證服務：登錄、注冊、單點登錄、社交登錄 購物車服務 后台管理系統：添加優惠信息等
2.3 項目技術&特色
前后分離開發，並開發基於vue的后台管理系統
SpringCloud全新的解決方案
應用監控、限流、網關、熔斷降級等分布式方案，全方位涉及
透徹講解分布式事務，分布式鎖等分布式系統的難點
壓力測試與性能優化
各種集群技術的區別以及使用
CI/CD 使用
2.4 項目前置要求
熟悉SpringBoot以及常見整合方案
了解SpringCloud
熟悉 git maven
熟悉 linux redis docker 基本操作
了解 html，css，js，vue
熟練使用idea開發項目
二、分布式基礎概念
1、微服務
微服務架構風格，就像是把一個單獨的應用程序開發成一套小服務，每個小服務運行在自己的進程中，
並使用輕量級機制通信，通常是 HTTP API 這些服務圍繞業務能力來構建，
並通過完全自動化部署機制來獨立部署，這些服務使用不同的編程語言書寫，
以及不同數據存儲技術，並保持最低限度的集中式管理
簡而言之，拒絕大型單體應用，基於業務邊界進行服務微化拆分，每個服務獨立部署運行。
2、集群&分布式&節點
集群是個物理狀態，分布式是個工作方式
只要是一堆機器，也可以叫做集群，他們是不是一起協作干活，這誰也不知道。
《分布式系統原理與范型》定義：
分布式系統是若干獨立計算機的集合，這些計算機對於用戶來說像單個系統分布式系統 (distributed system) 是建立網絡之上的軟件系統
分布式是指根據不同的業務分布在不同的地方
集群指的是將幾台服務器集中在一起，實現同一業務
例如：京東是一個分布式系統，眾多業務運行在不同的機器上，所有業務構成一個大型的分布式業務集群，每一個小的業務，比如用戶系統，訪問壓力大的
時候一台服務器是不夠的，我們就應該將用戶系統部署到多個服務器，也就是每一個業務系統也可以做集群化
分布式中的每一個節點，都可以做集群，而集群並不一定就是分布式的
節點：集群中的一個服務器
3、遠程調用
在分布式系統中，各個服務可能處於不同主機，但是服務之間不可避免的需要互相調用，我們稱之為遠程調用
SpringCloud中使用HTTP+JSON的方式來完成遠程調用
4、負載均衡
分布式系統中，A 服務需要調用B服務，B服務在多台機器中都存在， A調用任意一個服務器均可完成功能
為了使每一個服務器都不要太忙或者太閑，我們可以負載均衡的調用每一個服務器，提升網站的健壯性
常見的負載均衡算法：
（1）輪詢：為第一個請求選擇健康池中的每一個后端服務器，然后按順序往后依次選擇，直到最后一個，然后循環
（2）最小連接：優先選擇鏈接數最少，也就是壓力最小的后端服務器，在會話較長的情況下可以考慮采取這種方式
（3）散列：根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式可以一定程度上保證特定用戶能連接到相同的服務器。
如果你的應用需要處理狀態而要求用戶能連接到和之前相同的服務器，可以考慮采取這種方式。
5、服務注冊/發現&注冊中心
A服務調用B服務，A服務不知道B服務當前在哪幾台服務器上有，哪些正常的，哪些服務已經下線，解決這個問題可以引入注冊中心
如果某些服務下線，我們其他人可以實時的感知到其他服務的狀態，從而避免調用不可用的服務
6、配置中心
每一個服務最終都有大量配置，並且每個服務都可能部署在多個服務器上，我們經常需要變更配置，我們可以讓每個服務在配置中心獲取自己的配置。
配置中心用來集中管理微服務的配置信息
7、服務熔斷&服務降級
在微服務架構中，微服務之間通過網絡來進行通信，存在相互依賴，當其中一個服務不可用時，有可能會造成雪崩效應，要防止這種情況，必須要有容錯機制來保護服務
rpc
情景：
訂單服務 --> 商品服務 --> 庫存服務 庫存服務出現故障導致響應慢，導致商品服務需要等待，可能等到10s后庫存服務才能響應。
庫存服務的不可用導致商品服務阻塞，商品服務等的期間，訂單服務也處於阻塞。一個服務不可用導致整個服務鏈都阻塞。
如果是高並發，第一個請求調用后阻塞10s得不到結果，第二個請求直接阻塞10s。
更多的請求進來導致請求積壓，全部阻塞，最終服務器的資源耗盡。導致雪崩 1、服務熔斷 設置服務的超時，當被調用的服務經常失敗到達某個閾值，我們可以開啟斷路保護機制，后來的請求不再去調用這個服務，本地直接返回默認的數據 2、服務降級 在運維期間，當系統處於高峰期，系統資源緊張，我們可以讓非核心業務降級運行，降級：某些服務不處理，
或者簡單處理【拋異常，返回NULL，調用 Mock數據，調用 FallBack 處理邏輯】
8、API網關
在微服務架構中，API Gateway 作為整體架構的重要組件，抽象服務中需要的公共功能，
同時它提供了客戶端負載均衡，服務自動熔斷，灰度發布，統一認證，限流監控，日志統計等豐富功能，幫助我們解決很多API管理的難題
