《性能工程实战课》微服务电商项目技术全解析
项目介绍
7d-mall-microservice 是一套微服务电商，其是在开源电商项目 mall-swarm 上进行了改造，采用了 Spring Cloud Hoxton & Alibaba、Spring Boot 2.3、Oauth2、MyBatis、Docker、k8s、Elasticsearch 等核心技术。7d-mall-microservice在电商业务的基础集成了注册中心、配置中心、监控中心、网关等系统功能。。
项目地址：https://github.com/xncssj/7d-mall-microservice
整体结构
系统架构：
工程组织结构：
7d-mall
├── mall-common -- 工具类及通用代码模块
├── mall-mbg -- MyBatisGenerator生成的数据库操作代码模块
├── mall-auth -- 基于Spring Security Oauth2的统一的认证中心
├── mall-gateway -- 基于Spring Cloud Gateway的微服务API网关服务
├── mall-monitor -- 基于Spring Boot Admin的微服务监控中心
├── mall-member -- 会员系统服务
├── mall-order -- 订单系统服务
├── mall-cart -- 购物车系统服务
├── mall-admin -- 后台管理系统服务
├── mall-search -- 基于Elasticsearch的商品搜索系统服务
├── mall-portal -- 商城后台系统服务
├── mall-demo -- 微服务远程调用测试服务
└── config -- 配置中心存储的配置
主要技术栈：
预备知识
什么是 SpringCloud ？
构建分布式系统是复杂的，SpringCloud 对常见的分布式系统模式提供了简单易用的编程模型，帮助开发者构建弹性、可靠、协调的应用程序。SpringCloud 是在 SpringBoot 的基础上构建的，使开发者可以轻松入门并快速提高工作效率。SpringCloud 为开发人员提供了快速构建分布式系统架构的工具，例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁定，领导选举，分布式会话，集群状态等。
Spring 、SpringBoot 和 Spring Cloud 的关系
Spring 两大核心功能 Ioc 和 Aop 成就了 Spring，Spring 在这两大核心的功能上不断的发展，才有了 Spring 事务、Spring Mvc 等一系列伟大的产品，最终成就了 Spring 帝国，到了后期 Spring 几乎可以解决企业开发中的所有问题。
SpringBoot 是在强大的 Spring 帝国生态基础上面发展而来，发明 Spring Boot 不是为了取代 Spring ,是为了让人们更容易的使用 Spring 。所以说没有 Spring 强大的功能和生态，就不会有现在的 SpringBoot 火热, SpringBoot 使用约定优于配置的理念，重新重构了 Spring 的使用，让 Spring 后续的发展更有生命力。
Spring Cloud 是一系列框架的有序集合。它利用 SpringBoot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 SpringBoot 的开发风格做到一键启动和部署。
Spring 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 SpringBoot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud 是为了解决微服务架构中服务治理而提供的一系列功能的开发框架，并且 Spring Cloud 是完全基于 SpringBoot 而开发，Spring Cloud 利用 SpringBoot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。
综上所述，正是由于 Spring Ioc 和 Spring Aop 两个强大的功能才有了 Spring ，Spring 生态不断的发展才有了 SpringBoot ，使用 SpringBoot 让 Spring 更易用更灵活，Spring Cloud 是基于 SpringBoot 开发的一套微服务架构下的服务治理方案。
用一个简单的包含关系来表达它们之间的关系。
Spring Cloud Alibaba 和 Spring Cloud 的关系
在这几年 Netfilix Eureka 为代表的 SpringCloud 核心中间件纷纷停止更新，再加上许多组件设计老旧，在性能上已无法满足国内大厂的要求，我们迫切需要一套符合中国特色的微服务架构解决方案。
Spring Cloud Alibaba 就是在这种背景下诞生的，Spring Cloud Alibaba 是国产的微服务开发一站式解决方案，与原有 Spring Cloud 兼容的同时对微服务生态进行扩展，通过添加少量的配置注解，便可实现更符合国情的微服务架构。
相比 Spring Cloud，Spring Cloud Alibaba 提供了更完整的功能、更好用的 API，同时在中文的加持下让复杂的微服务架构变得不再高不可攀，目前 Spring Cloud Alibaba 已经是事实上的国内微服务技术标准。
下面是 Spring Cloud 与 Spring Cloud Alibaba 的对比表格：
将两者从不同维度进行比对，可以发现 Spring Cloud Alibaba 对服务注册、配置中心与负载均衡功能都整合进 Nacos，这样简化了微服务架构的复杂度，出问题的概率也会降低。原有的服务保护组件也调整为 Sentinel，功能更强大，使用也更加友好。最下方高亮处也可看到 Spring Cloud Alibaba 基于阿里云强大的能力提供了更多的商业组件，很多复杂的应用场景通过 结合阿里云便可实现。
核心组件介绍
Spring Cloud Alibaba：Nacos 注册和配置中心
注册中心是微服务架构最核心的组件。它起到新服务节点的注册与状态维护的作用。微服务节点在启动时会将自身的服务名称、IP、端口等信息在注册中心中进行登记，注册中心会定时检查该节点的运行状态。注册中心通常会采用心跳机制最大程度保证其持有的服务节点列表都是可用的。
现在微服务开发的主流技术是基于 Spring Boot 进行的，我们都知道 Spring Boot 默认配置文件为 application.yml 或者 application.properties。它保存了应用的主要配置信息，这些配置文件会随着应用发布被打包放入 Jar 文件，随着应用加载并运行。当我们的应用只有几个微服务时这些配置文件分散的存放在各个 Jar 中还没有问题。但是如果我们开发了大型应用，涉及几十个研发团队、上百台服务器、上千个服务实例时，运维团队就要面对因为数量级增加带来的挑战了，必须额外的引入“配置中心”这一组件。
配置中心的职责就是集中管理微服务架构中每一个服务实例的配置数据。当微服务架构引入配置中心后，微服务应用只需持有应用启动的最小化配置，在应用启动时微服务应用所需的其他配置数据，诸如数据库连接字符串、各种用户名密码、IP 等信息均从配置中心远程下载，不再本地保存。
Nacos 官方地址为：https://nacos.io/zh-cn/index.html
Nacos 阿里开源，官方定义为：
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
关键特性：
一图看懂 Nacos：
因为官网有完整的功能介绍，这里不再赘述。
Spring Cloud Ribbon：服务负载均衡
通常在微服务彼此调用时并不是直接通过 IP、端口直接访问，而是首先通过服务名在注册中心查询该服务拥有哪些可用节点，然后注册中心将可用节点列表返回给服务调用者，这个过程称为“服务发现”。因服务高可用的要求，服务调用者会接收到多个可用节点，必须要从中进行选择，因此在服务调用者一端必须内置负载均衡器，通过负载均衡策略选择适合的节点发起实质的通信请求。
Netfilx Ribbon 是 Netflix 公司开源的一个负载均衡组件，是属于客户端负载均衡器。目前 Ribbon 已被 Spring Cloud 官方技术生态整合，运行时以 SDK 形式内嵌到每一个微服务实例中，为微服务间通信提供负载均衡与高可用支持。
官网地址：https://github.com/Netflix/ribbon
关键特性：
- 负载均衡
- 容错
- 异步响应模型中支持多个协议(HTTP、TCP、UDP)
- 缓存和批处理
一般会使用 Feign 调用，并在消费者服务加上 Ribbon 负载均衡，配合 Nacos 手动可以调节权重，为了更容易理解，我们通过图说明 Ribbon 的执行流程：
Spring Cloud Fegin：服务通信
Netflix Feign 是 Netflix 设计的开源的声明式 WebService 客户端，用于简化服务间通信。Netflix Feign 采用“接口+注解”的方式开发，通过模仿 RPC 的客户端与服务器模式（CS），采用接口方式开发来屏蔽网络通信的细节。
官网地址：https://github.com/OpenFeign/feign
这是一张由 feign 提供的当前主要功能的地图：
Spring Cloud OpenFeign 底层是基于 Netflix Feign，在其基础上进行封装，结合原有 Spring MVC 的注解，对 Spring Cloud 微服务通信提供了良好的支持。使用 OpenFeign 开发的方式与开发 Spring MVC Controller 颇为相似。OpenFeign 技术大幅简化了服务间高可用通信处理过程。
入门教程：https://spring.io/projects/spring-cloud-openfeign
特征：声明式 REST 客户端：Feign 创建一个用 JAX-RS 或 Spring MVC 注释修饰的接口的动态实现。
示例代码如下：
@SpringBootApplication
@EnableFeignClients
public class WebApplication {
public static void main(String[] args) {
SpringApplication.run(WebApplication.class, args);
}
@FeignClient("name")
static interface NameService {
@RequestMapping("/")
public String getName();
}
}
Spring Cloud Gateway：服务网关
Spring Cloud Gateway 是 Spring 自己开发的新一代 API 网关产品。它基于 NIO 异步处理，摒弃了 Zuul 基于 Servlet 同步通信的设计，因此拥有更好的性能。同时，Spring Cloud Gateway 对配置进行了进一步精简，比 Zuul 更加简单实用。
官网地址：https://github.com/spring-cloud/spring-cloud-gateway
以下是 Spring Cloud Gateway 的关键特征：
-
基于 JDK 8+ 开发；
-
基于 Spring Framework 5 + Project Reactor + Spring Boot 2.0 构建；
-
支持动态路由，能够匹配任何请求属性上的路由；
-
支持基于 HTTP 请求的路由匹配（Path、Method、Header、Host 等）；
-
过滤器可以修改 HTTP 请求和 HTTP 响应（增加/修改 Header、增加/修改请求参数、改写请求 Path 等等）；
-
…
当下 Spring Cloud Gateway 已然是 Spring Cloud 体系上 API 网关标准组件。Spring Cloud Gateway 十分优秀，Spring Cloud Alibaba 也默认选用该组件作为网关产品。
Spring Cloud Gateway 的执行流程：
按执行顺序可以拆解以下几步：
- Gateway Client：发起请求
- Gateway Handler Mapping：确定请求与路由匹配
- Gateway Web Handler：
- 处理请求并经过一系列的Filter链
- 在Filter链中，通过虚线分割 Pre Filter 和 Post Filter。所有的 Pre 类型的 Filter 执行完毕之后，才会转发请求到被代理的服务处理。被代理的服务把所有请求完毕之后，才会执行 Post 类型的过滤器
自建ELFK：集中式日志管理
微服务架构默认将应用日志分散保存在每一个微服务节点上，当系统进行用户行为分析、数据统计时必须收集所有节点日志数据。那如何有效收集所有节点的运行日志，并对其进行分析汇总呢？
业内常见的方案有 ELK、EFK，通过搭建独立的日志收集系统，定时抓取增量日志形成有效的统计报表，为决策提供数据支撑。
ELK 即 Elasticsearch、Logstash、Kibana，组合起来可以搭建线上日志系统，本文主要讲解使用 ELK 来收集测试框架产生的日志。
ELK 中各个服务的作用：
- Elasticsearch：用于存储收集到的日志信息；
- Logstash：用于收集日志，测试框架应用整合了 Logstash 以后会把日志发送给 Logstash,Logstash再把日志转发给Elasticsearch；
- Kibana：通过Web端的可视化界面来查看日志。
SkyWalking：分布式链路追踪
一个复杂的业务流程可能需要连续调用多个微服务，我们需要记录一个完整业务逻辑涉及的每一个微服务的运行状态，再通过可视化链路图展现，帮助软件工程师在系统出错时分析解决问题。
随着微服务体系的不断完善，链路追踪已经不是什么新兴的概念与技术，很多厂商也提供了自己的链路追踪产品，例如 Spring Cloud Slueth、Zipkin、阿里鹰眼、大众点评 Cat、SkyWalking 等。但这些产品都有一个共同的名字：APM（Application Performance Management），即应用性能管理系统。
顾名思义这些产品的根本目的就是对应用程序单点性能与整个分布式应用进行监控，记录每一个环节程序执行状况，通过图表与报表的形式让运维人员随时掌握系统的运行状况，其中在这些著名的产品中我非常推荐各位掌握 SkyWalking 这款 APM 产品，理由很简单，它在简单易用的前提下实现了比 Zipkin 功能更强大的链路追踪、同时拥有更加友好、更详细的监控项，并能自动生成可视化图表。相比 Sleuth+Zipkin 这种不同厂商间混搭组合，SkyWalking 更符合国内软件业的“一站式解决方案”的设计理念，下面咱们来了解下 SKyWalking。
SkyWalking 是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。
提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。
官网地址：http://skywalking.apache.org/
关键特性：
- 多种监控手段，语言探针和 Service Mesh
- 多语言自动探针，Java，.NET Core和Node.JS
- 轻量高效，不需要大数据
- 模块化，UI、存储、集群管理多种机制可选
- 支持告警
- 优秀的可视化方案
整体结构：
整个架构，分成上、下、左、右四部分：
考虑到让描述更简单，我们舍弃掉 Metric 指标相关，而着重在 Tracing 链路相关功能。
- 上部分 Agent ：负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器。目前支持
SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是，SkyWalking Agent 收集SkyWalking Tracing数据，传递给服务器。 - 下部分
SkyWalking OAP：负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query)功能。 - 右部分 Storage ：Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2
多种存储器。而我们目前采用的是 ES ，主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。 - 左部分
SkyWalking UI：负责提供控台，查看链路等等
简单概况原理为下图：
为了能够让各位有个直观认识，我们通过表格对比，看不同产品的优劣。
| 对比项 | CAT | Sleuth+Zipkin | Pinpoint | Skywalking |
|---|---|---|---|---|
| 调用链可视化 | 有 | 有 | 有 | 有 |
| 报表 | 非常丰富 | 少 | 中 | 中 |
| ServerMap | 简单依赖图 | 简单 | 好 | 好 |
| 埋点方式 | 侵入 | 侵入 | 不侵入字节码增强 | 不侵入字节码增强 |
| 性能损耗 | 高 | 高 | 高 | 低 |
| Hearbeat支持 | 有 | 无 | 有 | 有 |
| Metric支持 | 有 | 无 | 无 | 有 |
| Java/.Net支持 | 有 | 有 | 只有Java | 有 |
| Dashboard中文支持 | 好 | 无 | 无 | 好 |
| 社区支持 | 好，文档较丰富，作者在携程点评 | 好，文档一般，暂无中文社区 | 一般，文档缺，无中文社区 | 好，文档丰富，中文社区活跃 |
| 调国内案例 | 携程、点评、陆金所 | 京东、阿里不开源 | 华为、小米、当当等 | 很多 |
| 源头祖先 | eBayCAL~Centralized Application Logging | Google Dapper | Google Dapper | Google Dapper |
Spring Cloud Alibaba：Sentinel 服务保护
在服务间通信过程中，如果某个微服务出现响应高延迟可能会导致线程池满载，严重时会引起系统崩溃。这里就需要引入服务保护组件实现高延迟服务的快速降级，避免系统崩溃。
在 Spring Cloud Alibaba 生态中有一个重要的流控组件 Sentinel。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
官网地址：https://sentinelguard.io/zh-cn/
Sentinel 具有以下特征:
- 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
- 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
- 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
- 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性：
Sentinel 的开源生态：
Sentinel 分为两个部分:
- 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
- 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。
Sentinel 工作主流程：
在 Sentinel 里面，所有的资源都对应一个资源名称以及一个 Entry。Entry 可以通过对主流框架的适配自动创建，也可以通过注解的方式或调用 API 显式创建；每一个 Entry 创建的时候，同时也会创建一系列功能插槽（slot chain）。这些插槽有不同的职责，例如:
- NodeSelectorSlot 负责收集资源的路径，并将这些资源的调用路径，以树状结构存储起来，用于根据调用路径来限流降级ee；
- ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息，例如该资源的 RT, QPS, thread count 等等，这些信息将用作为多维度限流，降级的依据；
- StatisticSlot 则用于记录、统计不同纬度的 runtime 指标监控信息；
- FlowSlot 则用于根据预设的限流规则以及前面 slot 统计的状态，来进行流量控制；
- AuthoritySlot 则根据配置的黑白名单和调用来源信息，来做黑白名单控制；
- DegradeSlot 则通过统计信息以及预设的规则，来做熔断降级；
- SystemSlot 则通过系统的状态，例如 load1 等，来控制总的入口流量；
总体的框架如下:
因为官网有完整的功能介绍，这里不再赘述。
消息队列：RabbitMQ
消息队列（Message Queue）简称 MQ，是一种跨进程的通信机制，通常用于应用程序间进行数据的异步传输，MQ 产品在架构中通常也被叫作“消息中间件”。它的最主要职责就是保证服务间进行可靠的数据传输，同时实现服务间的解耦。
在架构领域，很多厂商都开发了自己的 MQ 产品，最具代表性的开源产品有：
-
Kafka
-
ActiveMQ
-
ZeroMQ
-
RabbitMQ
-
RocketMQ
每一种产品都有自己不同的设计与实现原理，但根本的目标都是相同的：为进程间通信提供可靠的异步传输机制。RabbitMQ 是最受欢迎的开源消息中间件之一，在全球范围内被广泛应用。RabbitMQ 是轻量级且易于部署的，能支持多种消息协议。RabbitMQ 可以部署在分布式系统中，以满足大规模、高可用的要求。
官网地址：https://www.rabbitmq.com/
提供的功能：
核心特性：
-
可靠性：RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认
-
灵活的路由：在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange
-
消息集群：多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker
-
高可用：队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用
-
多种协议：RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等
-
多语言客户端：RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等
-
管理界面：RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面
-
跟踪机制：如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么
-
插件机制：RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件
-
…
整体结构：
- Broker：简单来说就是消息队列服务器实体。
- Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
- Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
- Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
- Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
- vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
- producer：消息生产者，就是投递消息的程序。
- consumer：消息消费者，就是接受消息的程序。
- channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。
Spring Cloud Alibaba：Seata 分布式事务
在微服务架构中由于全局数据一致性没法保证产生的问题就是分布式事务问题。简单来说，一次业务操作需要操作多个数据源或需要进行远程调用，分布式处理时无法通过单点数据库利用一个事务保证数据的完整性，我们必须引入某种额外的机制来协调多个事务要么全部提交、要么全部回滚，以此保证数据的完整性，这便是“分布式事务”的由来。
Alibaba Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
Seata 提供了多种分布式事务的解决方案，包含 AT 模式、TCC 模式、SAGA 模式以及 XA 模式。其中 AT 模式提供了最简单易用且无侵入的事务处理机制，通过自动生成反向 SQL 实现事务回滚。从 AT 模式入手使用，使我们理解分布式事务处理机制是非常好的学习办法。
因为官网有完整的功能介绍，这里不再赘述。
运行效果展示
部署架构图：
API文档：
调用链监控：
服务注册：
服务监控:
日志聚合：
配置管理：
系统保护：
总结
技术点很多，最后通过一张脑图做个总结：
参考资料：
- [1]：《SpringCloud Alibaba 实战》
- [2]：《高楼的性能工程实战课》
- [3]：https://github.com/macrozheng/mall-swarm
- 点赞
- 收藏
- 关注作者
评论（0）