你好,我是姚秋辰。

在上一节课,我跟你介绍了Spring Cloud的发展背景以及各个组件库,此刻,你一定已经跃跃欲试想要立马开始动手编写实战项目了吧?别着急,今天咱先别忙着敲代码,让我先为你勾画出实战项目的全景蓝图。

这节课,我会跟你聊一聊我们这个优惠券平台项目的整体功能和模块,以及每个功能点的技术选型和背后的依据,让你从宏观的角度来了解一下我们整个项目的概貌和大致的走向,帮助你更轻松地学习后面的课程。首先,我来带你了解一下这个实战项目的业务功能。

优惠券平台项目介绍

相信你一定参与过双11或者618之类的电商大促活动,体验过各种眼花缭乱的优惠券和营销规则计算。而我们的实战项目,就是要搭建一个简化版的营销优惠计算系统,实现优惠券模板的创建、用户领取优惠券、下单核销优惠券和订单价格试计算等功能。

我曾经参与了一线电商新零售平台营销中心业务从0到1的搭建,与淘系营销优惠平台UMP对接过很多花式营销玩法。根据我过去的经验,如果我要实现一个“领取优惠券”的功能,那么我首先是要创建一个营销规则模板。这个模板就像是一个模具一样,每张优惠券都通过这个模具来铸造,并最终发放到用户手中。

使用模板的好处是可以对优惠券消费规则做一层抽象,比如满减类、打折类这些优惠券只是具体的优惠金额不同,但是玩法类似,我们把相类似的玩法功能抽象成一个模板,就可以简化具体优惠券的创建和核销流程。

在这个实战项目中,我也借鉴了之前的工作经验,把整个项目划分为了优惠券模板服务、计算服务、用户服务和平台类组件这四大模块。它们的功能是这样的:

从整体来看,优惠券模板服务和优惠计算服务是基础服务,用户服务是对用户开放的接口,它依赖于这两个基础服务来完成业务逻辑。而平台类组件则提供了横向的微服务特性支持,比如微服务网关、链路追踪功能等等,你可以把它们理解为“微服务中间件”。我们通过下面这幅图来看一下这四个模块之间的关联关系:

我们在开篇词中提到,为了帮你顺利过渡到Spring Cloud实战,我会先用Spring Boot搭建出这个优惠券平台的单体应用,然后在这个基础上做Spring Cloud改造。

Spring Boot实战项目规划

从项目实施的角度来看,Spring Boot阶段的任务相对简单。我们会用两节课搭建起优惠券平台的三个业务模块,并按照模块之间的先后依赖顺序进行改造。在第一节课中,我将带你搭建一个单体应用版的优惠券模板服务,在这个过程中我们会使用spring-data-jpa和spring-web实现系统搭建。其中,spring-data-jpa是用来实现数据库CRUD操作的组件,而spring-web是开发RESTFul风格的API接口所需要用到的组件。接着在第二节课中,我们将使用同样的技术搭建订单优惠计算服务和用户服务。

这里你要注意,在Spring Boot的阶段,用户服务是一个“超级单体应用”,我把优惠券模板服务和订单优惠计算服务都打包到了用户服务中,跨模块的服务调用都是通过本地方法完成的,因此你只用启动用户服务就可以执行所有模块的业务功能。

在搭建项目的过程中,我会带你重点掌握以下这三个技术点:

  1. 项目搭建:分层构建项目结构,并借助Maven实现依赖项管理;
  2. 数据操作:我会带你快速入门spring-data-jpa实战,分别通过接口声明、自定义SQL和JpaRepository三种方式实现数据库CRUD操作;
  3. 开放对外API:快速入门spring-web实战,通过注解对外暴露RESTful风格的API。

此外,我还会不断跟你分享一些我平时工作中积累的小技巧,比如防御型编程、如何借助插件自动生成代码和数据校验、JPA级联关系的误区、计算密集型服务的特点、模板设计模式的应用等等,相信这些内容可以给你一些工作上的启发。

Spring Boot的官方社区提供了一个非常简单的Hello World教程,如果你没有太多Spring Boot的使用经验,那么可以通过这个教程链接Spring Quickstart Guide来了解Spring Boot的搭建过程。

在Spring Boot阶段我们搭建好优惠券平台的单体应用后,接下来就可以进行Spring Cloud微服务化改造了。

Spring Cloud实战项目全景规划

我们先来看一下优惠券平台采用微服务架构,整体的技术方案规划和技术选型是怎样的。下面这张图里列举的技术框架都是目前一线广泛使用的开源组件。

看到图中的这些技术点,我想此刻的你一定很懵,不知道这些技术框架的用途,也不知道该从何处下手来做改造。那么,接下来让我跟你聊聊我如何设计Spring Cloud实战课程的技术选型以及总体的搭建流程,这样你就能做到心中有数,学起来也能得心应手了。

根据微服务学习的路径以及各个组件的难易程度,我把整个微服务框架由浅入深分为了三个不同的阶段:

第一阶段:搭建基础的微服务功能,实现微服务之间的通信

第二阶段:为各个模块构建服务容错分布式配置中心分布式链路追踪能力

第三阶段:进一步实现微服务网关消息驱动分布式事务

下面我们来看下每个阶段主要做些什么以及对应的技术选型。

第一阶段

在第一阶段,我们主要实现微服务之间的通信,将用户微服务、优惠券模板服务和订单优惠计算服务拆分为独立部署的业务系统,通过注册中心来实现服务注册和服务发现,让各个微服务之间可以互相调用。这个阶段涉及的关键技术是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. 链路追踪:这部分的重点是搭建分布式链路追踪与日志系统。

第三阶段

在第三阶段,我们的实战重点有三个:

这个阶段涉及的技术组件是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项目进行微服务化改造:

在学习专栏的过程中,我不建议你“跳章节”学习,正确的姿势是顺着专栏的各个阶段稳步推进。因为每一个阶段的内容都有前后关系,后一个技术组件或多或少都依赖于前面课程中用到的组件,如果跳跃了几个章节,很容易漏掉一些关键步骤的配置和搭建过程,导致项目无法启动。

学习过程中我们难免会碰到各种问题,需要求助于搜索引擎。你也许用得比较多的是国内的搜索引擎,但经常查到千篇一律的文章,又或者看一个解决方案还需要注册会员或者付费,体验相当不好。

因此,我推荐你偶尔尝试使用Google和stackoverflow两个网站来查询解决方案。这两个网站是对我的工作最有帮助的两位老师,不仅能帮助你解决问题,还可以锻炼你的英文阅读能力。要知道英文能力对技术人员来说还是相当重要的,尤其是当你想要了解一些前沿技术或者阅读一些论文的时候。所以,提高英文阅读能力要靠你平时的不断积累才行。

思考题

最后,请你思考一下,还有哪些微服务的技术点是你想了解的,你可以在留言区提出感兴趣的技术,在后期我可以把呼声比较高的技术点通过加餐的形式分享给你,让我们这个课程能够持续更新和演进。我在留言区等你。

好啦,这节课就结束啦。欢迎你把这节课分享给更多对Spring Cloud感兴趣的朋友。我是姚秋辰,我们下节课再见!

评论