大纲

• Zuul 入门教程 - 基础篇
• Zuul 入门教程 - 中级篇
• Zuul 入门教程 - 高级篇

前言

版本说明

在本文中，默认使用的 Spring Cloud 版本是 Finchley.RELEASE，对应的 Spring Boot 版本是 2.0.3，Zuul 版本是 1.x，特别声明除外。

Zuul 多层负载

痛点场景

在 Spring Cloud 微服务架构体系中，所有请求的前门的网关 Zuul 承担着请求转发的主要功能，对后端服务起着举足轻重的作用。当业务体量猛增之后，得益于 Spring Cloud 的横向扩展能力，往往加节点、加机器就可以使得系统支撑性获得大大提升，但是仅仅加服务而不加网关是会有性能瓶颈的，单一 Zuul 节点的处理能力十分有限。因此扩张节点往往是微服务连带 Zuul 一起扩张，一般会部署一个 Zuul 集群来横向扩展微服务应用，然后再在请求上层加一层软负载，通常是使用 Nginx 均分请求到 Zuul 集群（如下图）。此时若其中一台 Zuul 服务挂掉了，由于从 Nginx 到 Zuul 其实是没有什么关联性，如果 Zuul 服务宕掉，Nginx 还是会把请求导向到 Zuul 服务，导致从 Nginx 到这 Zuul 节点的请求会全部失效，在 Nginx 没有采取相关应对措施的情况下，这是十分严重的问题。

大纲

• Zuul 入门教程 - 基础篇
• Zuul 入门教程 - 中级篇
• Zuul 入门教程 - 高级篇

前言

版本说明

在本文中，默认使用的 Spring Cloud 版本是 Finchley.RELEASE，对应的 Spring Boot 版本是 2.0.3，Zuul 版本是 1.x，特别声明除外。

Zuul Filter 链

工作原理

Zuul 的核心逻辑是由一系列紧密配合工作的 Filter 来实现的，它们能够在进行 HTTP 请求或者响应的时候执行相关操作。可以说，没有 Filter 责任链，就没有如今的 Zuul，更不可能构成功能丰富的” 网关 “，Zuul Filter 的主要特性有以下几点：

• Filter 的类型：Filter 的类型决定了此 Filter 在 Filter 链中的执行顺序，可能是路由动作发生前，可能是路由动作发生时，可能是路由动作发生后，也可能是路由过程发生异常时
• Filter 的执行顺序：同一种类型的 Filter 可以通过 filterOrder() 方法来设定执行顺序，一般会根据业务的执行顺序需求，来设定自定义 Filter 的执行顺序
• Filter 的执行条件：Filter 运行所需要的标准或条件
• Filter 的执行效果：符合某个 Filter 执行条件，产生的执行效果

大纲

• Zuul 入门教程 - 基础篇
• Zuul 入门教程 - 中级篇
• Zuul 入门教程 - 高级篇

Zuul 介绍

Zuul 是什么

Zuul 是由 Netflix 孵化的一个致力于 “网关” 解决方案的开源组件，在动态路由、监控、弹性、服务治理以及安全方面起着举足轻重的作用。从 2012 年 3 月以来，陆续发布了 Zuul 1.0 与 Zuul 2.0 版本，后经 Pivotal 公司将 Zuul 1.0 整合到 Spring Cloud 的生态系统中，即现在的 Spring Cloud Zuul。在 Netflix 官方的解释中，Zuul 是从设备和网站到后端应用程序所有请求的前门，为内部服务提供可配置的对外 URL 到服务的映射关系，基于 JVM 的后端路由器。其底层基于 Servlet 实现，本质组件是一系列 Filter 所构成的责任链，并且 Zuul 的逻辑引擎与 Filter 可用其他基于 JVM 的编程语言编写（比如 Groovy）。Zuul 默认集成了 Ribbon、Hystrix，其中 Zuul 2.x 版本改动相较 1.x 比较大，底层使用了 Netty。虽然 Netflix 已经在 2018 年 5 月开源了 Zuul 2.x，但由于 Zuul 2.x 在 Spring Cloud Gateway 孵化之前一直跳票发布，而且 Spring Cloud Gateway 目前已经孵化成功，相较于 Zuul 1.x 在功能以及性能上都有明显的提升。因此在 Spring Boot 2.0 以上版本中，并没有对 Zuul 2.0 以上最新高性能版本进行集成，仍然使用 Zuul 1.x 非 Reactor 模式（基于 Servlet 2.5 阻塞架构）的旧版本。更多介绍可参考：Zuul 项目、Zuul 官方英文教程、Spring Cloud Zuul 官方中文文档

Zuul 的特性

主要特性包括：认证和鉴权、压力控制、动态路由、负载削减、静态响应处理、主动流量管理、金丝雀测试

两个依赖注入注解的区别

在 Spring 中，@Autowired 和 @Resource 注解都可以用来实现依赖注入，两者的不同点如下：

大纲

• Hystrix 入门教程 - 基础篇

服务雪崩效应

服务雪崩概述

微服务之间进行 RPC 或者 HTTP 调用时，一般都会设置 调用超时，失败重试等机制来确保服务的成功执行，这看上去很美好，但如果不考虑服务的熔断和限流，它就是造成服务雪崩的元凶。假设有两个访问量比较大的服务 A 和 B，这两个服务分别依赖 C 和 D，其中 C 和 D 服务都依赖 E 服务（如下图），这就是所谓的扇出。A 和 B 不断地调用 C 和 D，处理客户请求和返回需要的数据；当 E 服务不能提供服务的时候，C 和 D 的 超时和重试机制会被执行；由于新的请求不断的产生，会导致 C 和 D 对 E 服务的调用大量的积压，产生大量的调用等待和重试调用，会慢慢耗尽 C 和 D 的系统资源（CPU 或者内存等），然后 C 和 D 服务跟着也 down 掉。A 和 B 服务会重复 C 和 D 的遭遇，导致系统资源耗尽，然后服务也 down 掉了，最终整个服务都不可访问，造成了服务雪崩。

大纲

• OpenFeign 入门教程 - 基础篇（2018 年）
• OpenFeign 入门教程 - 基础篇（2024 年）

OpenFeign 介绍

Feign 的概述

在使用 Spring Cloud 开发微服务应用时，各个服务提供者都是以 HTTP 接口的形式对外提供服务，因此在服务消费者调用服务提供者时，底层通过 HTTP Client 的方式访问。此时可以使用 JDK 原生的 URLConnection、Apache 的 HTTP Client、Netty 的异步 HTTP Client 或者 Spring 的 RestTemplate 去实现服务间的调用。但是最方便、最优雅的方式是通过 Feign 进行服务间的调用。Feign 是由 Netflix 开发的一个声明式的 Web 服务客户端，它的出现使开发 Web 服务客户端变得很简单。Feign 同时也是一款声明式、模板化的 HTTP 客户端。更多介绍可参考：Feign 项目。

OpenFeign 的概述

Spring Cloud OpenFeign 对 Feign 进行了二次封装，使得在 Spring Cloud 中使用 Feign 的时候，可以做到使用 HTTP 请求访问远程服务，就像调用本地方法一样的，开发者完全感知不到这是在调用远程访问，更感知不到在访问 HTTP 请求。Spring Cloud OpenFeign 增强了 Feign 的功能，使 Feign 有限支持 Spring MVC 的注解，如 @RequestMapping 等。OpenFeign 的 @FeignClient 注解可以解析 Spring MVC 的 @RequestMapping 注解下的接口，并通过 AOP 中的动态代理来产生实现类，在实现类中做负载均衡并调用其他服务，同时默认集成了 Ribbon 与 Hystrix。OpenFeign 基本上就是当前微服务之间调用的事实标准。更多介绍可参考：Spring Cloud OpenFeign 项目、Spring Cloud OpenFeign 官方文档、Spring Cloud OpenFeign 官方中文教程

大纲

• Java 常见设计模式使用教程之一
• Java 常见设计模式使用教程之二

前言

本文将介绍 Java 常用设计模式的使用，包括代理模式、观察者模式、建造者模式、外观模式、原型模式。

Spring Boot 配置

邮件发送失败问题

在本地开发环境测试，Spring Boot 能够正常发送邮件，但部署到阿里云 ECS 服务器以后，一直没有收到邮件，部分关键日志信息如下：

1
2
3
4
5
6
7
8

org.springframework.mail.MailSendException: Mail server connection failed; nested exception is com.sun.mail.util.MailConnectException: Couldn't connect to host, port: smtp.163.com, 25; timeout -1;
  nested exception is:
        java.net.ConnectException: 连接超时 (Connection timed out). Failed messages: com.sun.mail.util.MailConnectException: Couldn't connect to host, port: smtp.163.com, 25; timeout -1;
  nested exception is:
        java.net.ConnectException: 连接超时 (Connection timed out)
        at org.springframework.mail.javamail.JavaMailSenderImpl.doSend(JavaMailSenderImpl.java:447)
        at org.springframework.mail.javamail.JavaMailSenderImpl.send(JavaMailSenderImpl.java:322)
        at org.springframework.mail.javamail.JavaMailSenderImpl.send(JavaMailSenderImpl.java:311)

从现有情况看，跟程序运行环境有关，查看相关资料，发现在阿里云 ECS 服务器上，默认禁用了 25 端口，所以在通过 25 端口去连接邮件服务器时，无法连上，就报超时了。官方建议使用 465 端口，而 456 端口是 SSL 协议的，所以不仅要换端口，还需要进行 SSL 协议替换。下面是在 application.properties 进行的邮件发送相关配置，经过这样配置后，在阿里 ECS 上就能够正常发送邮件了

大纲

• Ribbon 入门教程 - 基础篇

Ribbon 介绍

Ribbon 是什么

Ribbon 是 Netflix 公司开发的一个负载均衡组件，诞生于 2013 年 1 月，一直是 Netflix 活跃度较高的项目，由 Pivotal 公司将其整合进 Spring Cloud 生态。Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡工具，通过 Spring Cloud 的封装，可以轻松地将面向服务的 REST 模板请求自动转换成客户端负载均衡的服务调用。 此外，Ribbon 拥有丰富的负载均衡策略、重试机制、支持多协议的异步与响应式模型、容错、缓存与批次处理等功能。Ribbon 虽然只是一个工具类框架，它不像服务注册中心、配置中心、API 网关那样需要独立部署，但是它几乎存在于每一个 Spring Cloud 构建的微服务和基础设施中。 因为微服务间的调用，API 网关的请求转发等内容实际上都是通过 Ribbon 来实现的，Feign、Zuul 已经集成了 Ribbon，更多介绍可参考：Ribbon 项目、Ribbon 官方英文文档、Spring Cloud Ribbon 官方中文文档

Ribbon 与负载均衡

负载均衡（Load Balance），即利用特定方式将流量分摊到多个操作单元上的一种手段，它对系统吞吐量与系统处理能力有着质的提升，当今极少企业没有用到负载均衡器或是负载均衡策略。常见的负载均衡实现有 Nginx 与 LVS，且不管它们的使用方式，工作在什么层次，本质还是对流量的疏导。业界对于负载均衡有不少分类，最常见的有软负载与硬负载，代表产品是 Nginx 与 F5；还有一组分类最能体现出 Ribbon 与传统负载均衡的差别，那就是集中式负载均衡与进程内负载均衡。集中式负载均衡指位于因特网与服务提供者之间，并负责把网络请求转发到各个提供单位，这时候 Nginx 与 F5 就可以归为一类，也可以称是服务端负载均衡。进程内负载均衡是指从一个实例库选取一个实例进行流量导入，在微服务的范畴内，实例库一般存储在 Zookeeper、Eureka、Consul、etcd 这样的注册中心，而此时的负载均衡器就是类似 Ribbon 的 IPC（Inter-Process Communication，进程间通信）组件，因此进程内负载均衡也叫做客户端负载均衡。

大纲

• Java 常见设计模式使用教程之一
• Java 常见设计模式使用教程之二

前言

本文将介绍 Java 常用设计模式的使用，包括工厂模式、策略模式、模板方法模式、单例模式。