一、項目簡介

1. 項目背景

市面上有5種常見的電商模式 B2B、B2C、C2B、C2C、O2O

• B2B 模式(Business to Business)，是指商家和商家建立的商業關系。如阿里巴巴
• B2C 模式(Business to Consumer)，就是我們經常看到的供應商直接把商品買個用戶，即 “商對客” 模式。也就是通常說的商業零售，直接面向消費銷售產品和服務，如蘇寧易購，京東，天貓，小米商城
• C2B 模式(Customer to Business)，即消費者對企業。先有消費者需求產生而后有企業生產，即先有消費者提出需求，后又生產企業按需求組織生產
• C2C 模式(Customer to Consumer) ，即客戶之間把自己的東西放到網上去賣，如淘寶、咸魚
• O2O 模式(Online To Offline)，也即將線下商務的機會與互聯網結合在一起，讓互聯網成為線下交易的前臺。線上快速支付，線上優質服務，如：餓了么，美團，淘票票，京東到家

谷粒商城是一個B2C模式的電商平臺，銷售自營商品給客戶，該項目具有以下特點：

• 前后分離開發，并開發基于vue的后臺管理系統
• SpringCloud全新的解決方案
• 應用監控、限流、網關、熔斷降級等分布式方案全方位涉
• 透徹講解分布式事務、分布式鎖等分布式系統的難點
• 分析高并發場景的編碼方式，線程池，異步編排等使用
• 壓力測試與性能優化
• 各種集群技術的區別以及使用
• CI/CD使用
• …

2. 分布式的基本概念

在具體介紹谷粒商城項目的完整架構之前，我們首先需要了解分布式的一些基本概念

1. 微服務

微服務架構風格，就像是把一個單獨的應用程序開發為一套小服務，每個小服務運行在自己的進程中，并使用輕量級機制通信，通常是Http API，這些服務圍繞業務能力來構建，并通過完全自動化部署機制來獨立部署。這些服務使用不同的編程語言書寫，以及不同數據存儲技術，并保持最低限度的集中式管理

簡而言之，拒絕大型單體應用，基于業務邊界進行展務微化拆分，各個服務抽立部署運行

2. 集群&分布式&節點

• 集群是個物理形態，分布式是個工作方式

  • 分布式 是指將不同的業務分布在不同的地方
  • 集群 指的是將幾臺服務器集中在一起，實現同一業務

• 分布式系統是若干獨立計算機的集合，這些計算機對于用戶來說就像單個相關系統

  分布式系統(distributed system)是建立在網絡之上的軟件系統

例如：京東是一個分布式系統，眾多業務運行在不同的機器，所有業務構成一個大型的業務集群。每一個小的業務，比如用戶系統，訪問壓力大的時候一臺服務器是不夠的。我們就應該將用戶系統部署到多個服務器，也就是每一個業務系統也可以做集群化。

• 分布式中的每一個節點，比如說用戶服務，都可以做集群，而集群并不一定就是分布式的
• 節點：集群中的一個服務器

3. 遠程調用

在分布式系統中，各個服務同能處于不同主機，但是服務之間不可避免的需要互相調用，我們稱為遠程調用

• SpringCloud中使用Http+Json的方式完應程調用

4. 負載均衡

分布式系統中，A服務需要調用B服務，B服務在多臺機器中都存在，A調用任意一個服務器均可完成功能。

為了使每一個服務器都不要太忙或者太閑，我們可以負載均衡的調用每一個服務器，提升網站的健壯性。

帶見的負載均衡算法：

• 輪詢：為第一個請求選擇健康池中的第一個后端服務器，然后按順序往后依次選擇，直到最后一個，然后循環。
• 最小連接：優先選擇連接數最少，也就是壓力最小的后端服務器，在會話較長的情況下可以考慮采取這種方式。
• 散列：根據請求源的IP的散列（hash）來選擇要轉發的服務器。這種方式可以一定程度上保證特定用戶能連接到相同的服務器如果你的應用需要處理狀態而要求用戶能連接到和之前相同的服務器，可以考慮采取這種方式。

5. 服務注冊/發現&注冊中心

A服務調用B服務，A服務并不知道B服務當前在哪幾臺服務器有，哪些正常的，哪些服務已經下線。解決這個問題可以引入注冊中心；

如果某些服務下線，我們其他人可以實時的感知到其他服務的狀態，從而避免調用不可用的服務

6. 配置中心

配置中心用來集中管理做服務的配置信息

每一個服務最終都有大量的配置，并且每個服務都可能部署在多臺機器上。我們經常需要變更配置，我們可以讓每個服務在配置中心獲取自己的配置。

7. 服務熔斷&服務降級

在微服務架構中，微服務之間通過網絡進行通信，存在相互依賴，當其中一個服務不可用時，有可能會造成雪崩效應。要防止這樣的情況，必須要有容錯機制來保護服務。

例如下游服務C因某些原因變得不可用，積壓了大量請求，服務B的請求線程也隨之阻塞。線程資源逐漸耗盡，使得服務B也變得不可用。緊接著服務A也變為不可用，整個調用鏈路被拖垮

服務熔斷：設置服務的超時，當被調用的服務經常失敗到達某個閾值，我們可以開啟斷路保護機制，后來的請求不再去調用這個服務。本地直接返回默認的數據

服務降級：在運維期間，當系統處于高峰期，系統資源緊張，我們可以讓非核心業務降級運行。降級：某些服務不處理，或者簡單處理（拋異常、返回NULL、調用Mock數據、調用Fallback處理邏輯）

8. API網關

在微服務架構中，API Gateway作為整體架構的重要組件，它抽象了微服務中部需要的公共功能，同時提供了客戶端負載均衡，服務自動熔斷，灰度發布，統一認證，限流流控，日志統計等豐富的功能，幫助我們解決很多API管理難題

3. 項目架構圖

接下來我們從微服務架構和微服務劃分兩個方面完整的介紹一下谷粒商城項目

1. 微服務架構圖

以上是谷粒商城對微服務架構圖，項目采用前后端分離開發，分為內網部署和外網部署：

• 外網部署就是部署前端項目，是面向公眾訪問的，比如手機APP，電腦網頁。
• 內網部署就是部署整個后臺的服務集群。

一個完整的請求調用鏈流程如下：

• 用戶通過任意客戶端發請求，請求首先經過Nginx集群。
• Nginx 把請求轉交給API網關，這里的網關使用 springcloud gateway。網關可以根據當前請求動態地路由到指定的服務，例如是想調用商品服務或購物車服務還是檢索服務，假如路由過來的請求很多，網關也可以負載均衡地調用業務集群服務器中一臺來處理路由，如果某些服務器出現問題也可以在網關層面對服務進行熔斷或降級，例如使用 springcloud alibaba 提供的 sentinel 組件，此外，網關還有其他的功能如認證授權、限流（只放行部分請求到后臺，防止服務器被壓垮）等等。
• 當請求通過網關最終到達業務集群后，服務器就對請求進行處理，這些服務都是采用springboot編寫的一個個微服務，服務與服務可能會相互調用，我們使用feign組件來實現服務間的調用問題。
• 有些請求可能經過登錄才能進行處理，所以我們還設立了一個基于OAuth2.0的認證中心，除了一般的登陸外，還整合了基于OAuth2.0的社交登陸。
• 整個后端中的安全和權限使用 springSecurity 進行控制。
• 此外，服務可能保存了一些數據，這里采用通過mysql集群做持久化存儲，可做讀寫分離，也可進行分庫分表；當然部分數據可能需要進行緩存處理，我們采用redis集群，可以是分片+哨兵的集群方式。
• 單個服務和服務之間我們也會使用消息隊列來完成異步解耦、分布式事務的一致性，這里采用 RabbitMQ。
• 另外，有些服務可能需要全文檢索，這里使用了 ElaticSearch 來實現。
• 而且有些服務在運行期間可能需要存取一些圖片、視頻等等數據，我們使用阿里云的對象存儲服務OSS。
• 當項目上線后，為了快速定位項目運行過程中出現的一些問題，我們采用ELK對日志進行處理，使用LogStash 收集業務里的各種日志然后存儲到 ES 中，然后用 Kibana 可視化頁面從 ES 中檢索出相關日志信息，幫助我們快速定位問題所在。
• 此外，在分布式系統中，由于每個服務都可能部署在很多臺機器，服務和服務可能相互調用，就得知道彼此都在哪里，所以需要將所有服務都注冊到注冊中心，然后服務可以從注冊中心發現其他服務所在位置，這里的注冊中心采用 springcloud alibaba 的 Nacos。
• 同樣，每個服務的配置眾多，為了實現改一處配置所有相同的配置同步更改，我們需要一個配置中心，這里也使用 springcloud alibaba 的 Nacos 作為配置中心，所有服務都從配置中心中動態取配置。
• 此外，服務在調用期間可能會出現問題，我們可以采用服務追蹤調用鏈看哪里出現問題，這里使用了 springcloud 提供的 Sleuth + Zipkin + Metrics，將每個服務的信息交給開源的 Prometheus 進行聚合分析，
  再由 Grafana 進行可視化展示，最后通過 Prometheus 提供的 AlterManager 實時得到服務的警告信息，這寫告警信息可以以短信/郵件的方式告知服務開發或運維人員。
• 最后，項目還提供了持續集成和持續部署功能。項目發布起來后，由于微服務眾多，將每一個服務都打包部署到服務器太麻煩，而采用持續集成后，開發人員可以將修改后的代碼提交到 github，然后運維人員可以通過自動化工具 Jenkins Pipeline 從 github 中獲取代碼然后打包成docker鏡像，最終我們可以使用 k8s 集成docker服務，將服務以 docker 容器的方式運行。

2. 微服務劃分圖

以上是谷粒商城的微服務劃分圖，它反映了整個項目中需要劃分的微服務以及相關的技術組合。

項目基于前后端分離開發，前端項目分為：

• admin-vue：面向工作人員使用的后臺管理系統
• shop-vue：面向公眾訪問的web網站
• 也可以有面向公眾的的app端和小程序端（未實現）

后端服務大致分為：

• 商品服務：商品的增刪改查、商品的上下架、商品詳情

• 支付服務

• 優惠服務

• 用戶服務：用戶的個人中心、收貨地址

• 倉儲服務：商品的庫存、存在哪個倉庫

• 秒殺服務

• 訂單服務：訂單增刪改查、用戶訂單列表等等

• 檢索服務：商品的檢索

• 中央認證服務：登錄、注冊、單點登錄、社交登錄

• 購物車服務：購物車商品的增刪改查、結賬等等

• 后臺管理系統：針對工作人員使用

  這些服務運行期間會依賴一些三方服務，例如物流信息檢索、短信發送、金融相關的支付匯款退漲、用戶的身份認證，這些服務不是我們編寫的，我們調用三方的一些接口即可。

在以上這些眾多微服務運行期間，如何治理它們讓其能夠有條不紊的運行起來，我們還需搭配以下技術：

• 使用 Nacos 作為注冊中心、配置中心
• 使用 Seata 實現分布式事務
• 使用 Sentinel 實現服務容錯、降級、限流
• 使用 Feign 解決服務間的遠程調用和負載均衡問題
• 使用 API 網關進行過濾、路由等一系列操作
• 使用 Sleuth + Zipkin 實現服務等可視化追蹤
• 使用 Prometheus + Grafana 監控整個應用等狀態信息

最后，整個項目等數據支撐層采用了以下技術：

• 使用 Redis 做緩存
• 使用 MySQL 進行數據持久化，后續再通過 ShardingSphere 對 MySQL 進行分庫分表操作
• 使用 RabbitMQ 做消息隊列
• 使用 ElasticSearch 做全文檢索
• 使用阿里云 OSS 存儲圖片、視頻等等文件

總結

以上是生活随笔為你收集整理的谷粒商城学习笔记——第一期：项目简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。