Spring Cloud（十六）：Spring Cloud Gateway（续）
本文主要介绍 Spring Cloud Gateway 的路由熔断、路由重试和高可用。 路由熔断在前面学习 Hystrix 的时候，我们知道 Hystrix 有服务降级的能力，即如果服务调用出现了异常，则执行指定的 fallback 方法。Spring Cloud Gateway 也融合了 Hystrix，可以为我们提供路由层面服务降级。我们就来看看如何来做。
好一则博
Spring Cloud（十五）：Spring Cloud Gateway（限流）
绝境长城（冰与火之歌） 在高并发的应用中，限流是一个绕不开的话题。限流可以保障我们的 API 服务对所有用户的可用性，也可以防止网络攻击。 一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如 nginx 的 limit_conn 模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如 Guava 的 RateLimiter、nginx 的 li
Spring Cloud（十四）：Spring Cloud Gateway（过滤器）
在上一篇文章中，我们了解了 Spring Cloud Gateway 作为网关所具备的基础功能：路由。本篇我们将关注它的另一个功能：过滤器。 Spring Cloud Gateway 已经内置了很多实用的过滤器，但并不能完全满足我们的需求。本文我们就来实现自定义过滤器。虽然现在 Spring Cloud Gateway 的文档还不完善，但是我们依旧可以照猫画虎来定制自己的过滤器。
Spring Cloud（十三）：Spring Cloud Gateway（路由）
本篇文章主要介绍了什么是 Spring Cloud Gateway，并基于 Spring Cloud Gateway 的 Finchley.RC1 版本编写一个 Spring Cloud Gateway 的入门案例，即基本代理的路由转发配置。
Lombok 与 JDK 10
Update at 2018-06-21:Lombok 的 v1.16.22 版本已经解决了这个问题。以下内容仅做记录。 Lombok 这个工具很好用，从去年了解之后我编码的时候已经几乎离不开它了。今天在写 Log4j2 的 Demo 的时候，也顺手就加上了@Log4j2，但是意想不到的情况出现了：找不到符号。 因为我已使用 Lombok 多时，看到这个报错还是挺意外的，更意外的是这个错误的根源竟
Log4j2 将不同线程不同级别日志输出到不同的文件中
在多线程编程中，如果不做特殊的设置，那么多个线程的日志会输出到同一个日志文件中，这样在查阅日志的时候，会带来诸多不便。很自然地，我们想到了让不同的线程输出日志到不同的文件中，这样不是更好吗？ 本篇文章我们利用 Log4j2 来将不同线程的不同级别的日志打印到不同的文件中，并使用异步的方式来大大的提高日志输出的性能。
MySQL 优化之 Covering Index
在网上随便搜搜，就能找到大把的关于 MySQL 优化的文章，不过里面很多都不准确，说个常见的： 1SELECT a FROM ... WHERE b = ... 一般来说，很多文章会告诫你类似这样的查询，不要在 “a” 字段上建立索引，而应该在 “b” 上建立索引。这样做确实不错，但是很多时候这并不是最佳结果。为什么这样说？这还得先从索引来说起。
MySQL 优化原理（三）
聊聊 MySQL 配置。 大多数开发者可能不太会关注 MySQL 的配置，毕竟在基本配置没有问题的情况下，把更多的精力放在 schema 设计、索引优化和 SQL 优化上，是非常务实的策略。这时，如果再花力气去优化配置项，获得的收益通常都比较小。更多的时候，基于安全因素的考量，普通开发者很少能够接触到生产环境的 MySQL 配置。正是这样，导致开发者（包括我）对 MySQL 的配置不甚了解，希望本
MySQL 优化原理（二）
如果有同学看完上一篇关于 MySQL 文章，文末留有两个很开放的问题，如有兴趣可以在脑袋里想想。本文也会试着回答这两个问题，希望能给你一些参考。现在可以思考一个问题，如果数据量非常大的情况下，您根据业务选择了合适的字段，精心设计了表和索引，还仔细的检查了所有的 SQL，并确认已经没什么问题，但性能仍然不能满足您的要求，该怎么办呢？还有其他优化策略吗？答案是肯定的。接下来继续和您讨论一些常用的 My
MySQL 优化原理（一）
说起 MySQL 的查询优化，相信大家收藏了一堆奇技淫巧：不能使用SELECT *、不使用 NULL 字段、合理创建索引、为字段选择合适的数据类型……你是否真的理解这些优化技巧？是否理解其背后的工作原理？在实际场景下性能真有提升吗？我想未必。因而理解这些优化建议背后的原理就尤为重要，希望本文能让你重新审视这些优化建议，并在实际业务场景下合理的运用。
MySQL 轻松创建千万级测试数据
在进行查询操作的性能测试时，我们往往需要测试大数据量模式下的查询功能的性能，这时就需要我们去创造一些测试数据来填充数据库，来模拟真实环境。制造数据的方式有很多种。可以使用 LoadRunner，JMeter 等压测工具压一些数据进去，但这样做效率不高。也可以用程序生成一个数据文件，再用 load data 加载，这样虽然快了但是又不够灵活。 本文介绍两种快速生成大量测试数据的方法，分别使用存储过程
RabbitMQ 安装笔记
关于 RabbitMQ 的安装，本来应该是在学习 RabbitMQ 之前进行的，不过当时学习时为了快速上手，就直接用 Docker 来开始开启了一个 RabbitMQ 的实例。这篇部署笔记就是来还债的。 CentOS 7.3 + RabbitMQ 3.7.4
Spring Cloud 与响应式微服务
今天 Spring Cloud 的 Finchley 版本终于 Release Candidate 1 了（详见Spring Cloud Finchley.RC1 Has Been Released）。众所周知，Spring Cloud 服务间的调用方式是使用的 RESTful API，我们平时都是RestTemplate或Feign来调用的，这两种方式其实说到底都是同步的方式。 之前我们已经了解
使用 Spring 5 的 Webflux 开发 Reactive 应用
对 Java 开发者来说，2017 年 9 月是个热闹的月份，Java SE 9、Java EE 8 相继发布，而 Spring 也在这段时间，发布了 5.0 正式版本。 身为 Java 开发者，对于 Spring 框架并不陌生。Spring 在 Rod Johnson 十几年前一个人单挑 J2EE 体系开始，到十年前开始大行其道至今，基本上已是 Java 开发领域的事实标准了。 Spring 5
Spring Cloud（十二）：分布式链路跟踪 Sleuth 与 Zipkin【Finchley版】
随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。 现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed
Spring Cloud（十一）：服务网关 Zuul（过滤器）【Finchley 版】
在上篇文章中我们了解了 Spring Cloud Zuul 作为网关所具备的最基本功能：路由（Router）。本文我们将关注 Spring Cloud Zuul 的另一核心功能：过滤器（Filter）。 Filter 的作用我们已经能够实现请求的路由功能，所以我们的微服务应用提供的接口就可以通过统一的 API 网关入口被客户端访问到了。但是，每个客户端用户请求微服务应用提供的接口时，它们的访问权限
Spring Cloud（十）：服务网关 Zuul（路由）【Finchley 版】
通过之前几篇 Spring Cloud 中几个核心组件的介绍，我们已经可以构建一个简略的微服务架构了，可能像下图这样： 我们使用 Spring Cloud Netflix 中的 Eureka 实现了服务注册中心以及服务注册与发现；而服务间通过 Ribbon 或 Feign 实现服务的消费以及均衡负载；通过 Spring Cloud Config 实现了应用多环境的外部化配置以及版本管理。为了使得
MyBatis 中 # 与 $ 的区别
MyBatis 其实老早就用过，后来因为业务的关系，就又把之前学的东西都给还回去了。现在在新公司又要用 MyBatis，就再复习一下。 MyBatis 中使用 parameterType 向 SQL 语句传参，parameterType 后的类型可以是基本类型 int，String，HashMap 或 Java 自定义类型。在 SQL 中引用这些参数的时候，可以使用两种方式： #{paramet
