开篇词 为什么你要学习微服务架构?
你好,我是萧然,长期从事分布式系统的构建和优化工作,负责过大型电商以及健康类系统的设计和开发,曾带领团队完成大规模微服务架构建设,在基于 Spring Cloud 进行微服务开发和治理方面积累了丰富的实践经验。
在当下的互联网应用中,业务体系不断发展变化,用户体量和性能要求远非传统行业所能比拟。以我所经历的电商、健康类应用为例,它们背后所承载的业务功能的复杂度、用户访问的并发量,以及快速迭代的开发要求,已远远超出了传统单体系统的设计和开发要求。如何高效地实现系统扩展性、伸缩性,以及维护性,成为一个非常现实且亟待解决的难题。
面对这样的挑战,业界普遍做法是引入服务拆分和集成的设计理念。而微服务架构通过将传统的单体应用按照业务边界划分为小型的、可以独立部署的服务单元,然后通过遵循轻量级的交互协议进行集成,成为这一理念下事实上的标准开发模式和最佳实践。
如何让微服务架构真正落地?
我们知道,服务拆分和集成的理念比较简单,但要真正实现却十分困难。因为一旦将一个单体系统拆分成多个服务,这时候我们面对的就是一个分布式系统。以电商系统为例,分布式系统构建方式的结构图如下所示:
分布式系统构建方式结构图
可以看到,在分布式系统中,我们可以根据业务边界拆分出一批独立的服务,这些独立的服务就相当于一个个单体系统。但这在缓解系统扩展性、伸缩性和维护性上的一系列问题的同时,也引入了系统的复杂性。除了跨进程通信所带来的网络传输三态性和异构性等固有特性,我们还不得不考虑如下所示的种种典型问题。
-
服务实例太多怎么办:当系统中存在大量独立服务时,如何有效识别和管理这些服务的实例?这将成为一大挑战!分布式系统,一定要能够实时对这些服务实例进行治理。
-
服务调用关系太杂乱怎么办:服务数量所衍生的另一个问题,是服务调用之间的关系会变得混乱,客户端与各个服务之间也会存在较高的耦合度,分布式系统需要提供简洁而明确的入口供客户端访问。
-
服务访问出错了怎么办:分布式环境下的调用,与单体系统中的方法级调用不同。服务间的跨进程调用可能出现各种意想不到的问题,这就需要在服务访问出错时进行合理的容错处理。
-
配置信息散落在各个服务中怎么办:一旦系统被拆分成多个独立服务,分布式系统就需要确保分散在每个服务中的配置信息,以及所有服务在开发、测试和生产等环境中的配置信息得到统一管理。
-
服务调用链路太长怎么办:服务远程调用的另一个问题是调用链路可能会很长,需要对整个调用链路进行监控和跟踪,从而高效发现服务调用过程中的异常场景和性能问题。
微服务架构本质上也是一种分布式系统,但它在具备通用分布式系统的功能特性之外,还包含了一些特有组件,这些特有组件能够解决分布式系统所面临的上述问题。典型的微服务组件以及解决的问题如下所示。
-
服务治理:为了有效管理分布式系统中存在的大量服务实例,微服务架构引入了服务发现和服务注册机制,使得服务实例的管理变得自动化、透明化。
-
API 网关:为了降低服务客户端与服务提供者之间的耦合度,更好地简化调用过程,微服务架构专门提供了一个 API 网关,用来优化面向客户端的 API 设计。
-
服务容错:为了解决服务访问出错问题,微服务架构中提供了服务隔离、服务熔断和服务回退等面向服务调用端的有效容错机制。
-
配置中心:为了更好地组织和管理散落在各个服务中的配置信息,微服务架构提供了一个配置中心来集中化管理。
-
链路跟踪:为了高效监控服务调用的健康状态以及全链路的数据流转,微服务架构提供了链路跟踪机制,来对各个服务之间的调用过程进行统一管理。
微服务架构的真正落地需要对应的框架和工具,而基于 Spring Boot 的 Spring Cloud 框架就内置了上述这些组件。自 2017 年后,Spring Cloud 在国内开始走红,越来越多的企业选择 Spring Cloud 作为微服务系统开发框架,Spring Cloud 俨然已经成为当下 Java 工程师所必须熟练掌握的技能。
你为什么需要学习这门课?
虽然 Spring Cloud 框架提供了开发友好性,但要真正落地却不容易。一方面,Spring Cloud 包含的技术组件非常多,每个组件又都有自己的应用场景和使用方式,组件与组件之间还存在着关联关系,需要有系统化、案例驱动的学习过程,才能有效地应用到工作中。另一方面,Spring Cloud 的底层实现机制也比较复杂,内部集成了很多第三方框架,只有通过由浅入深、源码级别的理解,才能避免在使用过程中踩坑。
无论公司基于何种业务,无论公司规模和人员如何,但凡涉及服务化拆分和集成场景,就需要使用微服务架构。如何根据业务边界对系统进行合理地拆分?如何基于 Spring Cloud, 从零开始构建一个完整的微服务系统?如何高效地掌握 Spring Cloud 中这些技术组件的使用方法以及实现原理?
以上种种已经成为很多架构师和开发人员需要规划和落实的一大课题,这也是各大互联网公司高薪诚聘的岗位需求。下面这些职位,都需要使用到 Spring Cloud 框架工具,既是我们应聘时重要的实力条件,也从侧面上拉开了入职薪资水平。
(以上职位信息来源:拉勾网)
我们从拉勾网的岗位信息可以看出,行业的高端人才需求量非常大,而市面上掌握 Spring Cloud 技术体系的开发人才却非常短缺。想要从事微服务系统的开发,就需要对微服务架构的设计和开发对应的应用场景有所了解,普通的开发人员对微服务架构的设计理念和相关实现技术了解不够全面,缺乏市场竞争力。
更为重要的是,大多数开发人员对用于构建微服务架构的 Spring Cloud 理解不够深入,只停留在应用层面而没有掌握其内部运行机制。一旦系统出现问题,无法从根本上分析问题和解决问题,无法往架构设计等高层次的优质人才发展。
课程设计
为了帮助更多的开发人员解决学习和实践问题,我总结过往经验,和拉勾教育一起输出了这次课程。
本课程整体分两大部分来讲解微服务架构设计:
-
基础篇。这部分介绍微服务架构的基本要素和技术体系,并正式引入 Spring Cloud 开源框架和介绍其功能特性,最后提供一个精简但足够完整的案例系统 SpringHealth,后续课程中所需要用到的 Spring Cloud 技术案例都会在其中有所体现。
-
实践篇。合计 8 个模块,全面介绍如何基于 Spring Cloud 实现注册中心、API 网关、服务容错、配置中心、事件驱动架构、服务访问安全、链路跟踪等各大微服务技术体系。这些技术体系构成了一套完整的微服务解决方案,方便你基于这套解决方案思考如何构建主流的微服务系统。
通过这个课程,我希望你不仅能够通过完整的案例了解各个组件的应用方式和方法,以及能够直接应用于日常开发的实战技巧,而且能够深入理解微服务组件的实现原理,做到知其然而知其所以然,打牢在工作中不断精进的地基。
此外,课程中涉及的各个 Spring Cloud 核心组件,都会基于完整的案例分析给出详细的代码实现方案,方便你学习、改造,课程配套代码可在 https://github.com/tianyilan12/springcloud-demo 下载。
讲师寄语
技术的发展日新月异,随着中台架构等设计理念的普及,合理构建微服务架构将是大部分软件系统面临的一大挑战,类似 Spring Cloud 的微服务系统开发框架也将迈向一个新的发展时期,并在更多企业中得到应用。希望这个课程能够让你学好 Spring Cloud 框架,并且能够更好地应用到日常开发过程中。
最后,欢迎你在留言区分享微服务系统和架构设计方面的经历和经验,或者不妨在留言区给自己立个 Flag,学完整个课程后再来回顾你的收获。
01 追本溯源:究竟什么样的架构才是微服务架构?
本节课,让我们一起来了解些有关微服务架构的基本要素。
微服务架构是一种架构模式,区别于其他系统架构的构建方式和技术方案,微服务架构具有其固有特点。微服务架构的提出者 Martin Fowler 在其文章Microservices中定义了包括服务组件化、去中心化、基础设施自动化在内的多个微服务架构特点。正是这些特点,为我们在使用微服务架构进行系统设计的过程,提供了主要的切入点。在本课程中,我基于这些特点提炼出构建微服务架构三大要素,即如下图所示的业务建模、技术体系和研发过程。
微服务三要素示意图
微服务架构的第一要素:业务建模
微服务架构设计首要的切入点为服务建模。为什么我们首先需要考虑的是这个要素呢?因为微服务架构与传统 SOA 等技术体系有本质区别,就是其服务的粒度和服务本身的面向业务和组件化特性。针对服务建模,我们首先需要明确服务的类别,以及服务与业务之间的关系,尽可能明确领域的边界。
那么如何开展开发服务建模工作呢?针对服务建模,推荐使用领域驱动设计(Domain Driven Design,DDD)方法,通过识别领域中的各个子域、判断这些子域是否独立、考虑子域与子域的交互关系,从而明确各个界限上下文(Boundary Context)之间的边界。
对于领域的划分,业界主流的分类方法认为,系统中的各个子域可以分成核心子域、支撑子域和通用子域三种类型,其中系统中的核心业务属于核心子域,专注于业务某一方面的子域称为支撑子域,可以作为某种基础设施的功能可以归到通用子域。下图就是一个典型的领域划分示例,来自电商系统:
电商系统的典型领域划分示意图
另一方面,服务建模本质上是一个为了满足业务需求,并通过技术手段将这些业务需求转换为可实现服务的过程。服务围绕业务能力建模,而业务能力往往体现的是一种分层结构。
按照我的经验,我们可以把业务体系中的服务分成如下几种类型:基础服务、通用服务、定制服务和其他服务等。这里,我们同样给出基于电商场景的业务服务分层示例图,如下所示:
电商系统的业务服务分层示例图
每个行业、每个公司具有不同的业务体系和产品形态,我无意对业务建模的应用场景做过多展开。但在课程的后续内容中,我们会基于 DDD 设计思想,并通过一个具体的案例来介绍如何完成对系统的业务建模,以帮助你在日常开发过程中掌握如何使用 DDD 来完成对业务系统的领域建模的系统方法。
微服务架构的第二要素:技术体系
微服务架构的第二大块内容就是它的技术体系,这也是我们学习微服务架构的主体内容。同样,不同的开发技术和框架都会基于自身的设计理念,给出各自的技术体系类型及其实现方式。
微服务架构相关的技术体系比较繁杂,在对其进行学习的过程中,你需要抓住重点。在本课程中,我也基于目前业界主流的微服务实现技术提炼了八大技术体系,包括服务通信、服务治理、服务路由、服务容错、服务网关、服务配置、服务安全和服务监控,如下图所示:
微服务架构八大技术体系图
上图中的每个技术体系都非常重要,下面来对它们分别展开介绍。
1. 服务通信
网络通信是任何分布式系统的基础组件。网络通信本身涉及面很广,对于微服务架构而言,我们关注的是网络连接模式、I/O 模型和服务调用方式。
服务通信的关注点
我们知道基于TCP 协议的网络连接有两种基本方式,也就是通常所说的长连接和短连接。长连接和短连接的产生在于客户端和服务器端采取的关闭策略,具体的应用场景采用具体的策略。例如 Dubbo 框架就采用的是长连接,而本课程中要介绍的 Spring Cloud 则采用了短连接。不过鉴于篇幅关系,关于长连接、短连接的适用场景我就不展开介绍了,感兴趣的同学可以课下多去搜索了解下相关资料。
服务之间通信的另一个关注点是 I/O 模型。I/O 模型也有阻塞式 I/O 和非阻塞式 I/O 等多种实现方式。阻塞式 I/O 实现简单,而非阻塞式 I/O 的性能更好。在微服务架构中,以服务网关而言,像Netflix 的 Zuul就是阻塞式 I/O,而Spring 自研的 Spring Cloud Gateway则采用的是非阻塞式 I/O。
服务通信的另一个主题是调用方式,这方面同样存在同步调用和异步调用两大类实现机制,这两大类机制对于开发人员使用开发框架的方式有很大影响。为了简化开发人员的使用过程,通常都会采用异步转同步的实现机制,也就是说开发人员使用同步的方式进行方法调用,而框架本身会基于 Future 等机制实现异步的远程处理。
2.服务治理
在微服务架构中,服务治理可以说是最为关键的一个技术组件,因为各个微服务需要通过服务治理实现自动化的注册和发现。
你可以想象一下,如果系统中服务数量不是很多,那么我们有很多办法可以获取这些服务的 IP 地址、端口等信息,管理起来也不是很复杂。但当服务数量达到一定量级时,可能连开发人员自己都不知道系统中到底存在多少个服务,也不知道系统中当前到底哪些服务已经变得不可用。这时候,我们就需要引入独立的媒介来管理服务的实例,这个媒介一般被称为服务注册中心。
服务注册中心的作用
服务注册中心是保存服务调用所需的路由信息的存储仓库,也是服务提供者和服务消费者进行交互的媒介,充当着服务注册和发现服务器的作用。诸如 Dubbo、Spring Cloud 等主流的微服务框架都基于 Zookeeper、Eureka 等分布式系统协调工具构建了服务注册中心。
3.服务路由
我们现在已经通过注册中心构建了一个多服务的集群化环境中,当客户端请求到达集群,如何确定由哪一台服务器进行请求响应呢?这就是服务路由问题。可以认为负载均衡是最常见的一种路由方案,常见的客户端/服务器端负载均衡技术都可以完成服务路由。Spring Cloud 等主流的微服务框架也都内置了 Ribbon 等客户端负载均衡组件。
注册中心与负载均衡结构示意图
另一方面,负载均衡的出发点更多的是提供服务分发而不是解决路由问题,常见的静态、动态负载均衡算法也无法实现精细化的路由管理。这时候我们就可以采用路由规则。路由规则常见的实现方案是白名单或黑名单,即把需要路由的服务地址信息(如服务 IP)放入可以控制是否可见的路由池中进行路由。同样,路由规则也是微服务开发框架的一项常见功能。
4.服务容错
对于分布式环境中的服务而言,服务在自身失败引发生错误的同时,还会因为依赖其他服务而导致失败。除了比较容易想到和实现的超时、重试和异步解耦等手段之外,我们需要考虑针对各种场景的容错机制。
服务容错常见技术
业界存在一批与服务容错相关的技术组件,包括以失效转移 Failover 为代表的集群容错策略,以线程隔离、进程隔离为代表的服务隔离机制,以滑动窗口、令牌桶算法为代表的服务限流机制,以及服务熔断机制。而从技术实现方式上看,在 Spring Cloud 中,这些机制部分包含在下面要介绍的服务网关中,而另一部分则被提炼成单独的开发框架,例如专门用于实现服务熔断的 Spring Cloud Circuit Breaker 组件。
5.服务网关
服务网关也叫 API 网关,封装了系统内部架构,为每个客户端提供一个定制的 API。在微服务架构中,服务网关的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。
服务网关的功能
在功能设计上,服务网关在完成客户端与服务器端报文格式转换的同时,它可能还具有身份验证、监控、缓存、请求管理、静态响应处理等功能。另一方面,也可以在网关层制定灵活的路由策略。针对一些特定的 API,我们需要设置白名单、路由规则等各类限制。在本课程中,我们会基于 Netflix Zuul 和 Spring Cloud Gateway 这两种网关对这些功能分别展开介绍。
6.服务配置
在微服务架构中,考虑到服务数量和配置信息的分散性,一般都需要引入配置中心的设计思想和相关工具。与注册中心一样,配置中心也是微服务架构中的基础组件,其目的也是对服务进行统一管理,区别在于配置中心管理的对象是配置信息而不是服务的实例信息。
配置中心与注册中心结构示意图
为了满足以上要求,配置中心通常需要依赖分布式协调机制,即通过一定的方法确保配置信息在分布式环境中的各个服务中能得到实时、一致的管理。可以采用诸如 Zookeeper 等主流的开源分布式协调框架来构建配置中心。当然,像 Spring Cloud 也提供了专门的配置中心实现工具 Spring Cloud Config。
7.服务安全
在对微服务架构的学习过程中,服务安全是一块非常重要但又容易被忽视的内容。一般意义上的访问安全性,都是围绕认证和授权这两个核心概念来展开的。也就是说我们首先需要确定用户身份,然后再确定这个用户是否有访问指定资源的权限。站在单个微服务的角度讲,我们系统每次服务访问都能与授权服务器进行集成以便获取访问 Token。站在多个服务交互的角度讲,我们需要确保 Token 在各个微服务之间的有效传播。另一方面,服务内部,我们可以使用不同的访问策略限制服务资源的访问。
基于 Token 机制的服务安全结构图
在实现微服务安全访问上,我们通常使用 OAuth2 协议来实现对服务访问的授权机制,使用 JWT 技术来构建轻量级的认证体系。Spring 家族也提供了 Spring Security 和 Spring Cloud Security 框架来完整这些组件的构建。
8.服务监控
在微服务架构中,当服务数量达到一定量级时,我们难免会遇到两个核心问题。一个是如何管理服务之间的调用关系?另一个是如何跟踪业务流的处理过程和结果?这就需要构建分布式服务跟踪机制。
分布式服务跟踪机制的建立需要完成调用链数据的生成、采集、存储及查询,同时也需要对这些调用链数据进行运算和可视化管理。这些工作不是简单一个工具和框架能全部完成,因此,在开发微服务系统时,我们通常会整合多个开发框架进行链路跟踪。例如,在 Spring Cloud 中,就提供了 Spring Cloud Sleuth 与 Zipkin 的集成方案。
微服务架构的第三要素:研发过程
微服务架构的第三个要素是研发过程,这点怎么理解?实际上,过程转变与技术体系建设有密切关联,所以对于微服务架构而言,最后一个要素就是研发过程。Martin Fowler 在介绍微服务架构时,同样也提出了围绕“业务功能”组织团队的研发管理理念。
当寻找把一个大的应用程序进行拆分的方法时,研发过程通常都会围绕产品团队、项目管理、大前端和服务器端团队而展开,这些团队也就是通常所说的职能团队。任何一个需求,无论大小,都将导致跨团队协作,从而增加沟通和协作成本。而微服务架构则倾向围绕业务功能的组织来分割服务,而不是面向某项技术能力。因此,团队是跨职能的特征团队,每个服务都围绕着业务进行构建,并且能够被独立部署到生产环境。这部分内容并不是本课程的重点,我们不做进一步展开。
小结与预告
微服务架构是目前构建互联网系统的主流架构体系,需要从业务建模、技术体系和研发过程三个维度入手进行理解和掌握。在本课程中,我的重点是介绍其中的技术体系。我基于目前流行的微服务开发框架提取了八大技术体系,并介绍了每个技术体系的结构和作用。
这里给你留一道思考题:你能简要描述微服务架构中所涉及的各个技术体系的作用吗?
在下一课时中,我们将引入 Spring Cloud 这款 Spring 家族中的微服务开发框架展开讨论,看看它如何通过提供一系列功能组件来实现今天讨论的技术体系。
02 顶级框架:Spring Cloud 是一款什么样的微服务开发框架?
实现微服务架构的第一步是进行技术选型,也就是选择一个合适的开发框架来实现上一课时中所介绍的各个微服务技术体系。目前市面上并没有一个严格意义上的微服务架构开发工具,但还是存在一些可供参考的框架。本课程将使用 Spring Cloud 作为实现微服务的主体框架。
从 Spring Boot 到 Spring Cloud
Spring Cloud 具备一个天生的优势,因为它是 Spring 家庭的一员,而 Spring 在 Java EE 开发领域的强大地位,给 Spring Cloud 起到很好的推动作用。同时,Spring Cloud 所基于的 Spring Boot,已经成为 Java EE 领域中最流行的开发框架,用来简化 Spring 应用程序的框架搭建和开发过程。
在微服务架构中,我们将通过 Spring Boot 来开发单个微服务。同样作为 Spring 家族的新成员,Spring Boot 提供了令人兴奋的特性,这些特性主要体现在开发过程的简单化,包括支持快速构建项目、不依赖外部容器独立运行、开发部署效率高,以及与云平台天然集成等。而在微服务架构中,Spring Cloud 构建在 Spring Boot 之上,继承了 Spring Boot 的多项功能特性,使得开发微服务变得简单而高效。
在设计思想上,Spring Boot 充分利用约定优于配置(Convention over Configuration)的自动化配置机制。与传统的 Spring 应用程序相比, Spring Boot 在启动依赖项自动管理、简化部署并提供应用监控等方面对开发过程做了优化。关于 Spring Boot 的全面介绍不是课程的重点,我们会在后续的课程中结合案例分析来穿插介绍相关的各项功能特性。
Spring Cloud 中的核心组件
技术组件的完备性是我们选择 Spring Cloud 的主要原因。Spring Cloud 中包含了开发一个完整的微服务系统所需的几乎所有技术组件,包括服务注册和发现、API 网关、配置中心、消息处理、负载均衡、熔断器、数据监控等常见技术组件都可以基于 Spring Boot 快速集成到业务系统中。
在对微服务的各项技术组件进行设计和实现的过程中,Spring Cloud 也有自己的一些特色。一方面,它对微服务架构开发所需的技术组件进行了抽象,提供了符合开发需求的独立组件,包括用于配置中心的 Spring Cloud Config、用于 API 网关的 Spring Cloud Gateway 等。另一方面,Spring Cloud 也非常崇尚博采众长,它将目前各家公司现有的适合于微服务系统开发的多款服务框架组合起来,通过 Spring Boot 开发风格进行了封装和优化。这部分主要指的是 Spring Cloud Netflix 组件,其中集成了 Netflix OSS 的 Eureka 注册中心、Zuul 网关、Hystrix 熔断器等工具,如下图所示:
Spring Cloud、Spring Cloud Netflix 与 Netflix OSS之间的关系
Spring Cloud 中的组件非常多,我们无意对所有组件都进行详细展开,而是梳理了开发一个微服务系统所必需的八大核心组件,如下图所示:
Spring Cloud 核心功能组件
接下来,我们对上图中的 Spring Cloud 核心技术组件进行一一展开。
1. Spring Cloud Netflix Eureka 与服务治理
Spring Cloud Netflix 基于 Spring Boot 集成了 Netflix OSS 中的诸多核心组件,与服务治理相关的除了用于服务注册和发现的 Eureka 之外,实际上还有用于实现客户端负载均衡的 Ribbon:
服务治理组件交互示意图
在服务治理场景下,这些组件构成了一个完整的从服务注册、服务发现到服务调用的流程。
2. Spring Cloud Gateway 与服务网关
针对服务网关,Spring Cloud 中提供了 Spring 家族自建的 Spring Cloud Gateway。Spring Cloud Gateway 构建在最新版本的 Spring 5 和响应式编程框架 Project Reactor 之上,提供了非阻塞的 I/O 通信机制。通过提供一系列的谓词(Predicate) 和过滤器(Filter) 的组合,我们可以通过 Spring Cloud Gateway 实现灵活的服务路由。同时,Spring Cloud Gateway 也可以集成前面介绍的 Netfix Hystrix 熔断器,以及服务限流等常见的服务容错机制。
Spring Cloud Gateway 结构示意图
当然,我们也可以使用 Netflix 中的 Zuul 来构建服务网关,这是 Spring Cloud 中集成的另一种常见的网关实现机制。
3. Spring Cloud Circuit Breaker 与服务容错
Spring Cloud Circuit Breaker 是对熔断器实现方案的一种抽象。在该组件的内部,Spring Cloud Circuit Breaker 集成了Netfix Hystrix、Resilience4J、Sentinel、Spring Retry这四种熔断器实现工具。
Spring Cloud Circuit Breaker 中的四种熔断器实现机制
对外,它提供了一个一致的 API 供应用程序使用,允许开发人员选择最适合应用程序需求的熔断器实现。熔断器在 Spring Cloud 框架中应用广泛,尤其是在与 Spring Cloud Gateway 等服务网关的集成过程中。
4. Spring Cloud Config 与配置中心
微服务架构中,我们通常需要构建一个集中化的配置仓库来保存各种配置信息。同时,我们也需要构建一个配置服务器来访问配置仓库并提供对外的访问入口,如下图所示。
配置中心结构示意图
在 Spring Cloud 中,集中化配置中心服务器的实现依赖于 Spring Cloud Config,而配置仓库的实现方案除了本地文件系统之外,还支持Git、SVN等常见的版本控制工具。
5. Spring Cloud Stream 与事件驱动
Spring Cloud 中的 Spring Cloud Stream 对整个消息发布和消费过程做了高度抽象,并提供了 Source/Sink、Channel 和 Binder 等一系列核心组件,如下图所示。
Spring Cloud Stream 结构示意图
Spring Cloud Stream 中的 Source 组件是真正生成消息的组件,然后消息通过 Channel 传送到 Binder,这里的 Binder 是一个中间层组件,通过 Binder 可以与特定的消息中间件进行通信。在 Spring Cloud Stream 中,目前已经内置集成的消息中间件包括 RabbitMQ 和 Kafka。消息消费者则同样通过 Binder 从消息传递系统中获取消息,消息通过 Channel 将流转到 Sink 组件。
6. Spring Cloud Security 与服务安全
我们知道在 Spring 中存在一个用来应对安全需求的Spring Security 框架。对应的,在 Spring Cloud 中也提供了 Spring Cloud Security 专门处理微服务环境下的服务安全访问需求。
微服务架构的安全性本质上是服务访问的安全性,作为 Spring Cloud 中的一员,Spring Cloud Security 是对微服务架构中所面临的安全性问题进行抽象并实现的工具。Spring Cloud Security 具备众多特点,包括基于流行的OAuth2 协议的授权机制,以及基于 Token的资源访问保护机制。
基于 OAuth2 协议的服务访问安全控制示意图
7. Spring Cloud Sleuth 与链路跟踪
Spring Cloud Sleuth 是 Spring Cloud 的组成部分之一,对于分布式环境下的服务调用链路,我们可以通过Spring Cloud Sleuth自动完成服务调用链路的构建。任何通过 HTTP 端点接收到的请求或使用 RestTemplate 发出的请求都可以被 Spring Cloud Sleuth 自动收集日志,同时它也能无缝支持通过由 API 网关 Zuul 发送的请求,以及基于 Spring Cloud Stream 等消息传递技术发送的请求。并且,正如我们已经了解到的,Spring Cloud Sleuth 也兼容了 Zipkin、HTrace 等第三方工具的应用和集成,从而实现对服务依赖关系、服务调用时序,以及服务调用数据的可视化,如下图所示。
Spring Cloud Sleuth 与 Zipkin 集成示意图
8. Spring Cloud Contracts 与服务测试
作为 Spring Cloud 中我们将要介绍的最后一个核心组件,服务测试本质上不属于微服务架构的技术组件,而只是一种辅助工具。但对于软件中的任何功能,我们都需要进行测试。对于微服务而言,测试是一个难点,也是经常被忽略的一点,这也是本课程专门把服务测试作为一个专题来讲解的原因所在。通常,我们会使用单元测试和集成测试来分别对一个类的内部,以及数据访问等涉及多个类交互的场景分别进行测试。而在微服务架构中,当不同服务之间进行交互和集成时,测试的关注点就变成如何确保服务定义和协议级别的正确性和稳定性,也就是所谓的端到端测试。
Spring 框架本身就提供了Spring Test 模块来满足单元测试与集成测试的实施需求。但对微服务架构而言,我们将重点介绍特有的消费者驱动的契约测试框架,这种测试解决方案能够有效应对服务与服务之间交互场景下的端到端测试需求。在 Spring Cloud 中,满足这种端到端测试需求的就是 Spring Cloud Contract 框架。Spring Cloud Contract 框架采用了服务桩(Stub) 实现机制来确保特定服务版本的各个服务之间交互过程的正确性,如下所示:
基于 Spring Cloud Contract 的端到端测试方案
小结与预告
从本课时开始,我们正式引入了 Spring 家族中的微服务开发框架 Spring Cloud,我们明确了 Spring Cloud 是构建在 Spring Boot 之上,且提供了一系列的核心组件用来满足微服务系统的开发需求。
这里给你留一道思考题:你能简要描述 Spring Cloud 中有哪些核心组件以及对应的功能吗?
在接下来的课程中,我们将逐一对 Spring Cloud 中提供的各个技术组件进行详细的展开。但在此之前,我们希望能有一个完整的案例来演示这些技术组件的使用方法,这就是下一课时要讨论的内容。