在大型系统的分布式系统中，系统会被拆分成了许多模块。这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。 在这种架构中，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心，也就意味着这种架构形式也会存在一些问题： 针对上边的问题，网上大牛已给出解决思路：分布式链路追踪（Distributed Tracing）。

Spring Cloud 原先整合 Zuul 作为网关组件，Zuul 由 Netflix 公司提供的，现在已经不维护了。后面 Netflix 公司又出来了一个 Zuul2.0 网关，但由于一直没有发布稳定版本，所以 Spring Cloud 等不及了就自己推出一个网关，已经不打算整合 zuul2.0 了。 Spring Cloud Gateway 是 Spring 公司基于 Spring 5.0， Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。它的目标是替代 Netflix Zuul，其不

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。 由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应”，如下图：

之前写过一篇 《Mybatis 插件实现动态设置参数》 文章，介绍了 Mybatis 插件的扩展和使用。笔者在空闲时间梳理了一下 MyBatis 插件的工作原理，在此记录和分享其插件功能代码的演化过程。 我们简略 MyBatis 执行 SQL 的步骤，下边的原始代码是依靠 Executor 执行 SQL 语句。 假设，我们需要 Executor 在执行 SQL 语句的前后打印出当前时间戳（方法增强），那该如何操作？

在工作中时常会使用 Java Stream 对集合进行特殊操作，Stream 虽然能简化代码，但是书写以及阅读性不高。故在此记录常用的 Stream 案例以便在未来工作中查阅和使用（复制粘贴😅） Stream 是 Java8 中处理集合的关键抽象概念，它可以指定你希望对集合进行的操作，可以执行非常复杂的查找、过滤和映射数据等操作。 使用Stream API 对集合数据进行操作，就类似于使用 SQL 执行的数据库查询。也可以使用 Stream API 来并行执行操作。简而言之，Stream API 提供了一种高效且易于使用的处理数据的方式。

在任何一种数据库中，都会有各种各样的日志，记录着数据库工作的方方面面，以帮助数据库管理员追踪数据库曾经发生过的各种事件。MySQL 也不例外，在 MySQL 中，有 4 种不同的日志，分别是错误日志、二进制日志（BINLOG 日志）、查询日志和慢查询日志，这些日志记录着数据库在不同方面的踪迹。 错误日志是 MySQL 中最重要的日志之一，它记录了当 mysqld 启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时，可以首先查看此日志。 该日志是默认开启的，查看日志位置指令：

无论什么编程语言，其代码最终都会被编译解释成计算机可读取和运行的二进制数据。 其中，数字在二进制数据中可划分成原码、补码和反码。 原码：数值前面增加一位符号位

上篇介绍了数据库 分库分表 的基本概念以及演化过程，同时分库分表带来的繁琐问题。本篇就上篇的问题，来介绍和讲解这些问题的解决方案。 本篇的主角为 ShardingSphere-JDBC。 Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，优化迫在眉睫。原因在于关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到 1000W 或 100G 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。 解决上述问题通常有以下两种方案： 通过提升服务器硬件能力来提高数据处理能力，比如增加存储容量 、CPU 等，这种方案成本很高，并且如果瓶颈在 MySQL 本身那么提高硬件也是有很的

Ribbon 是基于 Netflix Ribbon 实现的一套客户端负载均衡器，它本身不属于 Spring Cloud Alibaba 提供的组件，而是 Spring Cloud 将其封装成 starter 供微服务使用。另外，笔者在之前的 文章 中也做过 Ribbon 相关的知识介绍，故本篇章只作为对 Ribbon 内容的补充。 Spring Cloud 底层对 Ribbon 做了二次封装，可以让我们使用 RestTemplate 的服务请求，同时搭配 @LoadBalanced 注解使用，从而实现客户端负载均衡的服务调用。 RestTemplate 提供两种方法 getForObject