谷粒商城学习笔记——第一期：项目简介

Posted 2022-11-11 Baret-H

一、项目简介

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 存储图片、视频等等文件