在进行查询操作的性能测试时，我们往往需要测试大数据量模式下的查询功能的性能，这时就需要我们去创造一些测试数据来填充数据库，来模拟真实环境。
制造数据的方式有很多种。可以使用 LoadRunner，JMeter 等压测工具压一些数据进去，但这样做效率不高。也可以用程序生成一个数据文件，再用 load data 加载，这样虽然快了但是又不够灵活。

本文介绍两种快速生成大量测试数据的方法，分别使用存储过程和临时数据表。

关于 RabbitMQ 的安装，本来应该是在学习 RabbitMQ 之前进行的，不过当时学习时为了快速上手，就直接用 Docker 来开始开启了一个 RabbitMQ 的实例。这篇部署笔记就是来还债的。

CentOS 7.3 + RabbitMQ 3.7.4

今天 Spring Cloud 的 Finchley 版本终于 Release Candidate 1 了（详见Spring Cloud Finchley.RC1 Has Been Released）。众所周知，Spring Cloud 服务间的调用方式是使用的 RESTful API，我们平时都是RestTemplate或Feign来调用的，这两种方式其实说到底都是同步的方式。

之前我们已经了解过了 Spring 5 的一个新特性——响应式编程。那么我们能不能在 Spring Cloud 的服务间调用的时候也用这种异步非阻塞的方式呢？随着 Spring Cloud Finchley 的发布，这一切均可以实现。

本文我们就用 WebFlux、Spring Data Reactive 从头到脚构建一个响应式的微服务。

对 Java 开发者来说，2017 年 9 月是个热闹的月份，Java SE 9、Java EE 8 相继发布，而 Spring 也在这段时间，发布了 5.0 正式版本。

身为 Java 开发者，对于 Spring 框架并不陌生。Spring 在 Rod Johnson 十几年前一个人单挑 J2EE 体系开始，到十年前开始大行其道至今，基本上已是 Java 开发领域的事实标准了。

Spring 5 中最重要改动是把反应式编程的思想应用到了框架的各个方面，Spring 5 的反应式编程以 Reactor 库为基础。Spring 5 框架所包含的内容很多，这里只重点介绍其中新增的 WebFlux 模块。我们可以使用 WebFlux 创建高性能的 Web 应用和客户端。本文对 WebFlux 模块进行了详细介绍，包括其中的 HTTP、服务器推送事件（SSE）和 WebSocket 支持。

WebFlux 简介

WebFlux 模块的名称是 spring-webflux，名称中的 Flux 来源于 Reactor 中的类 Flux。该模块中包含了对反应式 HTTP、服务器推送事件和 WebSocket 的客户端和服务器端的支持。
对于开发人员来说，比较重要的是服务器端的开发，这也是本文的重点。在服务器端，WebFlux 支持两种不同的编程模型：第一种是 Spring MVC 中使用的基于 Java 注解的方式；第二种是基于 Java 8 的 Lambda 表达式的函数式编程模型。这两种编程模型只是在代码编写方式上存在不同。它们运行在同样的反应式底层架构之上，因此在运行时是相同的。WebFlux 需要底层提供运行时的支持，WebFlux 可以运行在支持 Servlet 3.1 非阻塞 IO API 的 Servlet 容器上，或是其他异步运行时环境，如 Netty 和 Undertow。

Spring Boot 2 是基于 Spring 5 的，其中一个比较大的更新就在于支持包括 spring-webflux 和响应式的 spring-data 在内的响应式模块，下边的例子我们就用 Spring Boot 2 在进行搭建。

本文从三个方面对 WebFlux 进行介绍。首先是使用经典的基于 Java 注解的编程模型来进行开发，其次是使用 WebFlux 新增的函数式编程模型来进行开发，最后介绍 WebFlux 应用的测试。通过这样循序渐进的方式让读者了解 WebFlux 应用开发的细节。

随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。

现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最为广泛的开源实现是 Twitter 的 Zipkin，为了实现平台无关、厂商无关的分布式服务跟踪，CNCF 发布了布式服务跟踪标准 Open Tracing。国内，淘宝的 “鹰眼”、京东的 “Hydra”、大众点评的 “CAT”、新浪的 “Watchman”、唯品会的 “Microscope”、窝窝网的 “Tracing” 都是这样的系统。

Spring Cloud Sleuth 也为我们提供了一套完整的解决方案。在本章中，我们将详细介绍如何使用 Spring Cloud Sleuth + Zipkin 来为我们的微服务架构增加分布式服务跟踪的能力。

在上篇文章中我们了解了 Spring Cloud Zuul 作为网关所具备的最基本功能：路由（Router）。本文我们将关注 Spring Cloud Zuul 的另一核心功能：过滤器（Filter）。

Filter 的作用

我们已经能够实现请求的路由功能，所以我们的微服务应用提供的接口就可以通过统一的 API 网关入口被客户端访问到了。
但是，每个客户端用户请求微服务应用提供的接口时，它们的访问权限往往都需要有一定的限制，系统并不会将所有的微服务接口都对它们开放。然而，目前的服务路由并没有限制权限这样的功能，所有请求都会被毫无保留地转发到具体的应用并返回结果。
为了实现对客户端请求的安全校验和权限控制，最简单和粗暴的方法就是为每个微服务应用都实现一套用于校验签名和鉴别权限的过滤器或拦截器。不过，这样的做法并不可取，它会增加日后的系统维护难度，因为同一个系统中的各种校验逻辑很多情况下都是大致相同或类似的，这样的实现方式会使得相似的校验逻辑代码被分散到了各个微服务中去，冗余代码的出现是我们不希望看到的。所以，比较好的做法是将这些校验逻辑剥离出去，构建出一个独立的鉴权服务。在完成了剥离之后，有不少开发者会直接在微服务应用中通过调用鉴权服务来实现校验，但是这样的做法仅仅只是解决了鉴权逻辑的分离，并没有在本质上将这部分不属于业余的逻辑拆分出原有的微服务应用，冗余的拦截器或过滤器依然会存在。

对于这样的问题，更好的做法是通过前置的网关服务来完成这些非业务性质的校验。由于网关服务的加入，外部客户端访问我们的系统已经有了统一入口，既然这些校验与具体业务无关，那何不在请求到达的时候就完成校验和过滤，而不是转发后再过滤而导致更长的请求延迟。同时，通过在网关中完成校验和过滤，微服务应用端就可以去除各种复杂的过滤器和拦截器了，这使得微服务应用的接口开发和测试复杂度也得到了相应的降低。

为了在 API 网关中实现对客户端请求的校验，我们将需要使用到 Spring Cloud Zuul 的另外一个核心功能：过滤器。

Zuul 允许开发者在 API 网关上通过定义过滤器来实现对请求的拦截与过滤，实现的方法非常简单。

通过之前几篇 Spring Cloud 中几个核心组件的介绍，我们已经可以构建一个简略的微服务架构了，可能像下图这样：

我们使用 Spring Cloud Netflix 中的 Eureka 实现了服务注册中心以及服务注册与发现；而服务间通过 Ribbon 或 Feign 实现服务的消费以及均衡负载；通过 Spring Cloud Config 实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用 Hystrix 的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。似乎一个微服务框架已经完成了。

我们还是少考虑了一个问题，外部的应用如何来访问内部各种各样的微服务呢？在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个 API 网关根据请求的 URL，路由到相应的服务。当添加 API 网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

MyBatis 其实老早就用过，后来因为业务的关系，就又把之前学的东西都给还回去了。现在在新公司又要用 MyBatis，就再复习一下。

MyBatis 中使用 parameterType 向 SQL 语句传参，parameterType 后的类型可以是基本类型 int，String，HashMap 或 Java 自定义类型。
在 SQL 中引用这些参数的时候，可以使用两种方式：

• #{parameterName}
• ${parameterName}

#与$的都可以起到变量替换的作用，但是二者的使用效果却是截然不同的。

网上有关这两个符号的文章挺多的，但没有一致的说法，这里我就用代码来测试一下。

我们在 Spring Cloud（七）：配置中心（Git、Refresh） 中讲到，如果需要客户端获取到最新的配置信息需要执行refresh，我们可以利用 Webhook 的机制每次提交代码发送请求来刷新客户端，当客户端越来越多的时候，需要每个客户端都执行一遍，这种方案就不太适合了。使用 Spring Cloud Bus 可以完美解决这一问题。

Spring Cloud Bus

Spring Cloud Bus 通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其他的消息指令。Spring Bus 的一个核心思想是通过分布式的启动器对 Spring Boot 应用进行扩展，也可以用来建立一个多个应用之间的通信频道。目前唯一实现的方式是用 Amqp 消息代理作为通道，同样特性的设置（有些取决于通道的设置）在更多通道的文档中。

Spring Cloud Bus 被国内很多都翻译为消息总线，也挺形象的。大家可以将它理解为管理和传播所有分布式项目中的消息既可，其实本质是利用了 MQ 的广播机制在分布式的系统中传播消息，目前常用的有 Kafka 和 RabbitMQ。利用 Bus 的机制可以做很多的事情，其中配置中心客户端刷新就是典型的应用场景之一，我们用一张图来描述 Bus 在配置中心使用的机制。

本文接之前的《Spring Cloud（七）：配置中心（Git、Refresh）》，继续来说说 Spring Cloud Config 的使用。

先来回顾一下，在前文中我们完成了什么：

• 构建了 config-server，连接到 Git 仓库
• 在 Git 上创建了一个 config-repo 目录，用来存储配置信息
• 构建了 config-client，来获取 Git 中的配置信息
• 在 config-client 中开启了 Refresh，动态刷新配置信息

在本文中，我们继续来看看 Spring Cloud Config 的一些其他能力。