一、項目簡介

1. 項目背景

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

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

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

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

2. 分布式的基本概念

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

1. 微服務(wù)

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

簡而言之，拒絕大型單體應(yīng)用，基于業(yè)務(wù)邊界進(jìn)行展務(wù)微化拆分，各個服務(wù)抽立部署運行

2. 集群&分布式&節(jié)點

• 集群是個物理形態(tài)，分布式是個工作方式

  • 分布式 是指將不同的業(yè)務(wù)分布在不同的地方
  • 集群 指的是將幾臺服務(wù)器集中在一起，實現(xiàn)同一業(yè)務(wù)

• 分布式系統(tǒng)是若干獨立計算機(jī)的集合，這些計算機(jī)對于用戶來說就像單個相關(guān)系統(tǒng)

  分布式系統(tǒng)(distributed system)是建立在網(wǎng)絡(luò)之上的軟件系統(tǒng)

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

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

3. 遠(yuǎn)程調(diào)用

在分布式系統(tǒng)中，各個服務(wù)同能處于不同主機(jī)，但是服務(wù)之間不可避免的需要互相調(diào)用，我們稱為遠(yuǎn)程調(diào)用

• SpringCloud中使用Http+Json的方式完應(yīng)程調(diào)用

4. 負(fù)載均衡

分布式系統(tǒng)中，A服務(wù)需要調(diào)用B服務(wù)，B服務(wù)在多臺機(jī)器中都存在，A調(diào)用任意一個服務(wù)器均可完成功能。

為了使每一個服務(wù)器都不要太忙或者太閑，我們可以負(fù)載均衡的調(diào)用每一個服務(wù)器，提升網(wǎng)站的健壯性。

帶見的負(fù)載均衡算法：

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

5. 服務(wù)注冊/發(fā)現(xiàn)&注冊中心

A服務(wù)調(diào)用B服務(wù)，A服務(wù)并不知道B服務(wù)當(dāng)前在哪幾臺服務(wù)器有，哪些正常的，哪些服務(wù)已經(jīng)下線。解決這個問題可以引入注冊中心；

如果某些服務(wù)下線，我們其他人可以實時的感知到其他服務(wù)的狀態(tài)，從而避免調(diào)用不可用的服務(wù)

6. 配置中心

配置中心用來集中管理做服務(wù)的配置信息

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

7. 服務(wù)熔斷&服務(wù)降級

在微服務(wù)架構(gòu)中，微服務(wù)之間通過網(wǎng)絡(luò)進(jìn)行通信，存在相互依賴，當(dāng)其中一個服務(wù)不可用時，有可能會造成雪崩效應(yīng)。要防止這樣的情況，必須要有容錯機(jī)制來保護(hù)服務(wù)。

例如下游服務(wù)C因某些原因變得不可用，積壓了大量請求，服務(wù)B的請求線程也隨之阻塞。線程資源逐漸耗盡，使得服務(wù)B也變得不可用。緊接著服務(wù)A也變?yōu)椴豢捎?#xff0c;整個調(diào)用鏈路被拖垮

服務(wù)熔斷：設(shè)置服務(wù)的超時，當(dāng)被調(diào)用的服務(wù)經(jīng)常失敗到達(dá)某個閾值，我們可以開啟斷路保護(hù)機(jī)制，后來的請求不再去調(diào)用這個服務(wù)。本地直接返回默認(rèn)的數(shù)據(jù)

服務(wù)降級：在運維期間，當(dāng)系統(tǒng)處于高峰期，系統(tǒng)資源緊張，我們可以讓非核心業(yè)務(wù)降級運行。降級：某些服務(wù)不處理，或者簡單處理（拋異常、返回NULL、調(diào)用Mock數(shù)據(jù)、調(diào)用Fallback處理邏輯）

8. API網(wǎng)關(guān)

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

3. 項目架構(gòu)圖

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

1. 微服務(wù)架構(gòu)圖

以上是谷粒商城對微服務(wù)架構(gòu)圖，項目采用前后端分離開發(fā)，分為內(nèi)網(wǎng)部署和外網(wǎng)部署：

• 外網(wǎng)部署就是部署前端項目，是面向公眾訪問的，比如手機(jī)APP，電腦網(wǎng)頁。
• 內(nèi)網(wǎng)部署就是部署整個后臺的服務(wù)集群。

一個完整的請求調(diào)用鏈流程如下：

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

2. 微服務(wù)劃分圖

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

項目基于前后端分離開發(fā)，前端項目分為：

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

后端服務(wù)大致分為：

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

• 支付服務(wù)

• 優(yōu)惠服務(wù)

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

• 倉儲服務(wù)：商品的庫存、存在哪個倉庫

• 秒殺服務(wù)

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

• 檢索服務(wù)：商品的檢索

• 中央認(rèn)證服務(wù)：登錄、注冊、單點登錄、社交登錄

• 購物車服務(wù)：購物車商品的增刪改查、結(jié)賬等等

• 后臺管理系統(tǒng)：針對工作人員使用

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

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

• 使用 Nacos 作為注冊中心、配置中心
• 使用 Seata 實現(xiàn)分布式事務(wù)
• 使用 Sentinel 實現(xiàn)服務(wù)容錯、降級、限流
• 使用 Feign 解決服務(wù)間的遠(yuǎn)程調(diào)用和負(fù)載均衡問題
• 使用 API 網(wǎng)關(guān)進(jìn)行過濾、路由等一系列操作
• 使用 Sleuth + Zipkin 實現(xiàn)服務(wù)等可視化追蹤
• 使用 Prometheus + Grafana 監(jiān)控整個應(yīng)用等狀態(tài)信息

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。