背景：学习材料《227-Spring Cloud 微服务项目实战》

227-Spring Cloud 微服务项目实战

简介

在上面这幅图中，我们可以看到有几个 Spring Boot Apps 的应用集群，这就是经过拆分
后的微服务。Spring Cloud 和 Spring Boot 达成了一种默契的配合：Spring Boot 主内，
通过自动装配和各种开箱即用的特性，搞定了数据层访问、RESTful 接口、日志组件、内
置容器等等基础功能，让开发人员不费吹灰之力就可以搭建起一个应用；Spring Cloud 主
外，在应用集群之外提供了各种分布式系统的支持特性，帮助你轻松实现负载均衡、熔断
降级、配置管理等诸多微服务领域的功能。
从 Spring Boot 和 Spring Cloud 的分工中我们可以看出，Spring Boot 忙活的是底层的
柴米油盐酱醋茶，Spring Boot 后勤保障做得好，才能让 Spring Cloud 毫无顾虑地投身于
微服务的星辰大海，两者合二为一完整构建了微服务领域的全家桶解决方案。

组件历史

在我们开始了解 Spring Cloud 组件库之前，我得先介绍在 Spring Cloud 历史上举足轻重
的两家公司 Netflix 和 Alibaba，以及它们的恩怨情仇。这两家公司分别为开源社区贡献了
Spring Cloud Netflix 组件库和 Spring Cloud Alibaba 组件库。

Netflix 是一家美国的流媒体巨头，它靠着自己强
大的技术实力，开发沉淀了一系列优秀的组件，这些组件经历了 Netflix 线上庞大业务规模
的考验，功能特性和稳定性过硬。如 Eureka 服务注册中心、Ribbon 负载均衡器、
Hystrix 服务容错组件等。后来发生的故事可能你已经猜到了，Netflix 将这些组件贡献给
了 Spring 开源社区，构成了 Netflix 组件库。可以这么说，在 Spring Cloud 的早期阶
段，是 Netflix 打下了的半壁江山。
 
Spring Cloud Alibaba 是由 Alibaba 贡献的组件库，随着阿里在开源路线上的持续投入，
近几年阿里系在开源领域的声音非常响亮。Spring Cloud Alibaba 凝聚了阿里系在电商
领域超高并发经验的重量级组件，保持了旺盛的更新活力，成为了 Spring Cloud 社区的
一股新生代力量，逐渐取代了旧王 Netflix 的江湖地位。

Spring Cloud 全家桶组件库

03 | 初窥门径：我们要搭建一个怎样的微服务实战项目？

上图是优惠券的微服务模块

下图是使用的相关组件

根据微服务学习的路径以及各个组件的难易程度，我把整个微服务框架由浅入深分为了三
个不同的阶段：
第一阶段：搭建基础的微服务功能，实现微服务之间的通信；
第二阶段：为各个模块构建服务容错、分布式配置中心、分布式链路追踪能力；
第三阶段：进一步实现微服务网关、消息驱动和分布式事务。

第一阶段

在第一阶段，我们主要实现微服务之间的通信，将用户微服务、优惠券模板服务和订单优
惠计算服务拆分为独立部署的业务系统，通过注册中心来实现服务注册和服务发现，让各
个微服务之间可以互相调用。这个阶段涉及的关键技术是 Nacos 注册中心、
Loadbalancer 客户端负载均衡组件和 OpenFeign 服务间调用组件。
我们知道，微服务之间的服务通信有一个前提条件，就是你要知道将要调用的服务器地址
是什么。这个寻址的任务是交由 Nacos 注册中心和 Loadbalancer 负载均衡器共同来完成
的。
Nacos 是 Alibaba 出品的服务治理组件，它作为一个注册中心组件，负责收集所有服务节
点的地址信息并维护服务注册表，所有服务上线之后都会向它汇报状态。Loadbalancer 则
承担了负载均衡的任务，在客户端发起服务调用的时候，它会负责从 Nacos 的注册表中挑
选一台目标服务器。而 OpenFeign 组件是一个“锦上添花”的组件，它能够简化基于
HTTP 的远程服务调用，让我们就像使用本地接口一样方便地发起远程服务调用。
为什么我会选择 Nacos+Loadbalancer 作为选型方案呢？其实，在早期版本的 Spring
Cloud 微服务架构选型中，Eureka + Ribbon 是一个使用最为广泛的组合，它们是
Netflix 公司贡献给 Spring Cloud 项目的服务治理 + 负载均衡组件。
我们在上节课中讲过，Netflix 正在退出 Spring Cloud 的历史舞台。Eureka 和 Ribbon 已
经进入了维护状态。其中，Ribbon 更是在 Spring Cloud I 版之后，就从官方组件库中被
移除了。这意味着 Eureka 和 Ribbon 已经进入了“暮年”，不会再有重大的功能更新，

如果你在项目中使用 Netflix 组件库，那么在未来将无法享受 Spring Cloud 社区发布的新
功能。
因此，在考虑技术选型的时候，我选择了后劲更足、功能更为强大的 Nacos 和 Spring
Cloud 官方开源的 Loadbalancer 组件。大致来讲，在第一阶段，我会分为三个部分来带
你搭建起微服务之间的通信：

1 服务治理：服务治理的重点是搭建基础的跨服务调用功能。我会把用户服务、优惠计算
服务和订单服务改造成可以独立启动的微服务，并借助 Nacos 的服务发现功能，通过
Webflux 组件中的 WebClient 实现基于 HTTP 的跨服务间的调用；
2.负载均衡：在这部分，我们将在服务治理的基础上，引入 Loadbalancer 组件为跨服务
调用添加负载均衡的能力。除此之外，我会对 Loadbalancer 组件的扩展接口做自定义
开发，实现一个金丝雀测试的负载均衡场景；
3.简化服务调用：我将使用 OpenFeign 组件对用户服务进行改造，将原先复杂的
WebClient 调用替换为简洁的 OpenFeign 调用。 

第二阶段

在第二阶段，我们的实战重点有三个：

利用服务容错提高微服务架构的可用性；
搭建全链路的分布式链路追踪能力；
实现统一的配置管理和动态属性推送

这个阶段涉及的技术组件是 Nacos Config、Sentinel、Sleuth+Zipkin+ELK。
在微服务架构中，服务容错是保障服务高可用的一个重要手段。在这个项目中，我们选择
用 Sentinel 作为服务容错组件，它也是 Alibaba 贡献给 Spring Cloud 的。Sentinel 秉承
了阿里系“大而全”的传统，只这一款组件就可以实现降级、熔断、流量整形等多种服务
容错途径。
链路追踪也是微服务架构中一个很重要的功能，线上异常排查全靠它提供线索。我使用了
Spring Cloud 官方开源的 Sleuth 实现了日志打标功能，使用全局唯一标记将一次跨微服
务调用链上的各个环节全部串联起来。 

光打标还没用，我还结合了 Zipkin 组件实现调用链的可视化检索，将调用链上各个阶段的
请求按顺序显示在页面上，这样，我们就可以一目了然定位到线上异常发生在哪个环节。
另外，我使用了目前业界主流的 ELK 组合（Elastic Search + Logstash + Kibana）作为
日志检索系统。
在配置项管理的技术选型方面，我使用了 Nacos Config 作为最终方案。借助 Nacos
Config 我们可以轻松实现配置项的远程获取和动态推送，在配置项的应用隔离和环境隔离
方面 Nacos 也是一把好手，我将会在配置管理的实战环节讲述更多的配置项花式玩法。相
比较 Spring Cloud 的另一款配置管理组件 Spring Cloud Config 来说，Nacos 的搭建更
加容易且更易于上手，而且可以更好地支持“配置项”回滚的功能。
在后面的课程中，我将按照下面的顺序来实现这些能力：

1.配置管理：配置管理的重点是将三个微服务应用接入到 Nacos Config 配置中心，使用
远程配置中心存储部分配置项。
2.服务容错：搭建 Sentinel Dashboard 控制台，通过控制台将降级规则和流量整形规则
应用到业务埋点中。
3. 链路追踪：这部分的重点是搭建分布式链路追踪与日志系统。

第三阶段

在第三阶段，我们的实战重点有三个：

搭建微服务网关作为统一流量入口；
使用消息驱动组件对接 RabbitMQ；
通过分布式事务保证数据一致性。
 

这个阶段涉及的技术组件是 Gateway、Stream 和 Seata。
微服务网关是架设在外部网关（如 Ngnix）和内部微服务之间的一座桥梁，我选用 Spring
Cloud Gateway 作为网关组件。Gateway 不光担任了路由转发的重任，同时它提供了丰
富的谓词组合实现复杂的路由判断逻辑。除此以外，你还可以在网关层定义拦截器，对来
访请求执行一段特殊的业务逻辑。 

曾经微服务网关的头把交椅是 Netflix 贡献的 Zuul 组件，但 Zuul 2.0 的开源发布一拖再
拖，且性能并未达到预期效果。Spring Cloud 官方迫不得已，还没等到 Zuul 2.0 发布，
就自己发布了一款开源网关组件 Spring Cloud Gateway。基于这些原因，Gateway 当之
无愧成为了网关层的不二选择。
消息队列和消息驱动是老牌技术了，它并不是微服务特有的功能，我之所以在课程中加入
了消息驱动这个内容，主要有两个原因。一是我想让你了解 Spring Cloud 开源的消息驱
动组件“Stream”，它可以大幅降低应用系统和消息组件之间的对接流程。二是消息组件
在如今有非常丰富的使用场景，我希望将“消息组件的应用场景”作为一个知识拓展点，
帮助你开阔眼界。
分布式事务是微服务环境下保证事务一致性的终极手段。在课程中我将主要介绍两种比较
有代表性的 Seata 分布式事务解决方案，一种是没有代码侵入的 Seata AT 方案，另一种
是蚂蚁金服贡献的资源锁定 + 补偿型的 Seata TCC 方案。 

总结

在整个项目中，我们先通过 Spring Boot 快速落地了优惠券平台的三个业务模块，然后，
在 Spring Cloud 实战阶段，我们分为三个阶段对 Spring Boot 项目进行微服务化改造：

第一个阶段使用 Nacos、Loadbalancer 和 OpenFeign 实现了跨服务的调用；
第二阶段使用 Sentinel、Nacos Config 和 Sleuth 实现了服务容错、配置管理和分布式
链路追踪；
第三阶段使用 Gateway、Stream 和 Seata 实现了微服务网关、消息事件驱动和分布式
事务。