上篇 - Config 入门教程（基础篇）

• Config 入门教程 - 基础篇

前言

版本说明

在下面的的教程中，使用的 Spring Cloud 版本是 Finchley.RELEASE，对应的 Spring Boot 版本是 2.0.3，特别声明除外。

Config 使用技巧

本地参数覆盖远程参数

在某些时候需要使用当前系统的环境变量或者是应用本身设置的参数而不是使用远程拉取的参数，此时 Config Client 可以使用如下配置：

官方 Bug 解决方案：

• https://github.com/spring-cloud/sprmg-cloud-config/issues/651
• https://github.com/spring-cloud/spring-cloud-config/issues/359

1
2
3
4
5
6

spring:
  cloud:
    config:
      overrideNone: true
      allowOverride: true
      overrideSystemProperties: false

• overrideNone：当 allowOverride 为 true 时，overrideNone 设置为 true，代表外部配置的优先级更低，而且不能覆盖任何已存在的属性源，默认为 false
• allowOverride：标识 overrideSystemProperties 属性是否启用，默认为 true，设置为 false 表示禁止用户的个性化设置
• overrideSystemProperties：用来标识外部配置是否能够覆盖系统属性，默认为 true

配置中心介绍

什么是配置中心

在集中式开发时代，配置文件已经基本足够了，因为那时配置的管理通常不会成为一个很大的问题。但是在互联网时代，应用都是分布式系统，部署在 N 台服务器上，想要去线上一台台地重启机器肯定不靠谱，并且维护成本也很高，所以配置中心应运而生。配置中心被用作集中管理不同环境（Dev、Test、Stage、Prod）和不同集群配置，以及在修改配置后将实时动态推送到应用上进行刷新。配置中心应具备的功能如下：

• Open API
• 业务无关性
• 高可用集群
• 配置生效监控
• 配合灰度与更新
• 一致性 K-V 存储
• 统一配置实时推送
• 配置全局恢复、备份与历史

上篇 - 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 入门教程 - 基础篇

前言

版本说明

在本文中，默认使用的 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 是由 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 的特性

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

服务雪崩效应

服务雪崩概述

微服务之间进行 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 掉了，最终整个服务都不可访问，造成了服务雪崩。

Spring Cloud OpenFeign 介绍

Feign 概述

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

Spring Cloud OpenFeign 概述

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

前言

SpringBoot 配置文件中的数据库账户、密码等敏感数据不能明文展示，否则代码泄露的话，数据库的数据会被恶意利用。

加密算法

• Jasypt Spring Boot 2.x 默认使用的加密算法是 PBEWithMD5AndDES，其中的 IV 生成器是 org.jasypt.iv.NoIvGenerator
• Jasypt Spring Boot 3.x 默认使用的加密算法是 PBEWITHHMACSHA512ANDAES_256，其中的 IV 生成器是 org.jasypt.iv.RandomIvGenerator

添加 Maven 坐标

1
2
3
4
5

<dependency>
    <groupId>com.github.ulisesbocchio</groupId>
    <artifactId>jasypt-spring-boot-starter</artifactId>
    <version>3.0.4</version>
</dependency>

前言

官方教程

• ELK Stack 中文指南

ELK 介绍

ELK 简介

ELK 是 Elasticsearch + Logstash + Kibana 的简称。

• Elasticsearch 是一个分布式的搜索和分析引擎，可以用于全文检索、结构化检索和分析，并能将这三者结合起来。Elasticsearch 基于 Lucene 开发，现在是使用最广的开源搜索引擎之一。
• Logstash 简单来说就是一根具备实时数据传输能力的管道，负责将数据信息从管道的输入端传输到管道的输出端，与此同时这根管道还可以根据不同的需求在中间加上滤网，Logstash 提供了很多功能强大的滤网以满足各种应用场景。
• Kibana 是一个开源的分析与可视化平台，设计出来用于和 Elasticsearch 一起使用的。开发者可以使用 Kibana 搜索、查看、交互存放在 Elasticsearch 索引里的数据，并使用各种不同的图标、表格、地图显示，Kibana 能够很轻易的展示高级数据分析与可视化。

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，进程间通信）组件，因此进程内负载均衡也叫做客户端负载均衡。