前言

Kubernetes 系统的各组件需要使用 TLS 证书对通信进行加密，可以使用 CloudFlare 的 PKI 工具集 CFSSL 来生成 Certificate Authority（CA）和其它证书。使用到证书的 Kubernetes 组件如下：

1、前言

• Knife4j Github 项目
• Knife4j 官方示例代码
• Knife4j 官方中文文档 - 最新
• Knife4j 官方中文文档 - 旧版

1.1、Knife4j 简介

Knife4j 是为 Java MVC 框架集成 Swagger 生成 Api 文档的增强解决方案，前身是 swagger-bootstrap-ui，致力于 springfox-swagger 的增强 UI 实现。knife4j 为了契合微服务的架构发展，由于原来 swagger-bootstrap-ui 采用的是后端 Java 代码 + 前端 UI 混合打包的方式，在微服务架构下显的很臃肿，因此项目正式更名为 knife4j，更名后主要专注的方面如下：

• 后端 Java 代码以及前端 UI 模块进行了分离，在微服务架构下使用更加灵活
• 提供专注于 Swagger 的增强解决方案，不同于只是单纯增强前端 UI 部分

1.2、Knife4j 模块

JWT 的概述

JWT（JSON Web Token）是目前最流行的跨域身份验证解决方案。

传统的身份验证

• 用户向服务器发送用户名和密码
• 验证服务器后，相关数据（如用户角色，登录时间等）将保存在当前会话中
• 服务器向用户返回 session_id，Session 信息都会写入到用户的 Cookie 中
• 用户的每个后续请求都将通过在 Cookie 中取出 session_id 并传递给服务器
• 服务器收到 session_id 并对比之前保存的数据，确认用户的身份

这种模式最大的问题是，没有分布式架构，无法支持横向扩展。如果使用一个服务器，该模式完全没有问题。但是，如果它是服务器群集或面向服务的跨域体系结构的话，则需要一个统一的 Session 数据库（Redis）来保存会话数据实现共享，如果保存 Session 的数据库（Redis）挂掉，整个认证体系都会挂掉。

大纲

• Redis 缓存与分布式锁
• Redisson 分布式锁使用教程
• Redis 分布式锁中 Lua 脚本的使用
• Java 基于 MySQL 实现分布式锁
• 基于 ZooKeeper 原生 API 实现分布式锁

前言

学习资源

• Redisson 官网
• Redisson 官方文档
• Redisson GitHub 仓库

Redisson 简介

Redisson 是架设在 Redis 基础上的一个 Java 驻内存数据网格（In-Memory Data Grid）。充分地利用了 Redis 键值数据库提供的一系列优势，基于 Java 实用工具包中的常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。Redisson 的宗旨是促进使用者对 Redis 的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。值得一提的是，Redisson 底层采用的是 Netty 框架。支持 Redis 2.8 以上版本，支持 Java 1.6+ 以上版本。

大纲

• Redis 缓存与分布式锁
• Redisson 分布式锁使用教程
• Redis 分布式锁中 Lua 脚本的使用
• Java 基于 MySQL 实现分布式锁
• 基于 ZooKeeper 原生 API 实现分布式锁

Lua 简介

从 Redis 2.6.0 版本开始，通过内置的 Lua 解释器，可以使用 EVAL 命令对 Lua 脚本进行求值。Redis 使用单个 Lua 解释器去运行所有脚本，并且 Redis 也保证脚本会以原子性 (atomic) 的方式执行。当某个脚本正在运行的时候，不会有其他脚本或 Redis 命令被执行。这和使用 MULTI / EXEC 包围的事务很类似。在其他别的客户端看来，脚本的效果 (effect) 要么是不可见的 (not visible)，要么就是已完成的 (already completed)。在 Lua 脚本中，可以使用 redis.call () 函数来执行 Redis 命令。

Lua 在 Reids 中的使用方式

​Redis 中内嵌了 Lua 脚本的解释器，并提供了执行 Lua 脚本的入口 eval 命令，格式为 eval script numkeys key [key ...] arg [arg...]。其中 eval 为命令，script 为执行的命令脚本，numkeys 为脚本中共涉及到的 key 的数量，后续接收若干个 key 的输入和若干个 arg 的输入。​在 Lua 脚本中使用 KEYS[index]， 和 ARGV[index] 来获取实际输入的参数，这有点类似于 SQL 的占位符。另外一层原因由于 Redis 集群的固有模式导致 EVAL 命令在集群中涉及多个 KEY 的操作时，要求所有的 KEY 都在同一个 Hash Solt 上。在集群环境中调用 EVAL 命令，Redis 会对脚本先做一个的校验。KEYS[1] KEYS[2] 是要操作的键，可以指定多个，在 Lua 脚本中可以通过 KEYS[1]、KEYS[2] 获取 Key 的值。特别注意，这些键要在 Redis 中存在，不然就获取不到对应的值。ARGV[1] ARGV[2] 参数在 Lua 脚本中可以通过 ARGV[1]、ARGV[2] 获取值。

大纲

• Redis 缓存与分布式锁
• Redisson 分布式锁使用教程
• Redis 分布式锁中 Lua 脚本的使用
• Java 基于 MySQL 实现分布式锁
• 基于 ZooKeeper 原生 API 实现分布式锁

缓存

缓存使用

为了系统性能的提升，一般都会将部分数据放入缓存中，加快业务服务的处理速度，而数据库则承担数据落盘的工作。

比如在电商类应用中，商品分类，商品列表等数据适合缓存，并加一个失效时间 (根据数据更新频率来决定)，后台如果发布一个商品，买家需要 5 分钟后才能看到新的商品，这一般还是可以接受的。

Crontab 安装

Crontab 安装（CentOS 7）

1

# yum instal crontabs

Crontab 安装（Debian 9）

1

# apt-get install cron

大纲

• SpringBoot 整合 Dubbo 3 案例
• SpringBoot 整合 Dubbo 2 案例
• Spring 与 SpringMVC 整合 Dubbo 2 案例
• Spring Cloud Alibaba 整合 Dubbo 2 综合案例

前言

Spring Cloud 是一套较为全面的微服务框架集，集成了如服务注册发现、配置中心、消息总线、负载均衡、断路器、API 网关等功能实现。而在网上经常会发现 Spring Cloud 与阿里巴巴的 Dubbo 进行选择对比，这样做其实不是很妥当，前者是一套较为完整的微服务架构方案，而 Dubbo 只是服务治理与 RPC 实现方案。Dubbo 在国内有着非常大的用户群体，但是其周边设施与组件相对来说并不那么完善。很多开发者用户又很希望享受 Spring Cloud 的生态，因此也会有一些 Spring Cloud 与 Dubbo 一起使用的案例与方法出现，但是一直以来大部分 Spring Cloud 整合 Dubbo 的使用方案都不完善，直到 Spring Cloud Alibaba 的出现，才得以解决这样的问题。

前言

本文主要介绍 SpringBoot 读取 YML 配置文件的几种写法。

第一种写法

添加 @Configuration 注解到 Bean 定义类，并使用 @Value 注解指定 YML 配置文件中的 Key。

1
2
3
4
5
6

shop:
  wechat:
    app-id: ''
    app-secret: ''
    encoding-token: ''
    encoding-aes-key: ''

前言

由于不蒜子统计不对普通用户提供后台管理的功能，当站点的域名更换后，网站以前的所有统计数据都会重置为零。下面将介绍如何使用抓包工具来分析不蒜子统计的 API，进而实现不蒜子统计数据的更改。

Fiddler 下载

这里使用了 Fiddler，它是一款流行的抓包工具，可以将网络传输发送与接受的数据包进行截获、重发、编辑、转存等操作。本质上，Fiddler 是通过改写 HTTP 代理，让数据从它那里通过，来监控并且截取到网络数据。

• Fiddler 官网下载地址 ：https://www.telerik.com/download/fiddler
• Fiddler 离线下载地址：https://pan.baidu.com/s/1bpnp3Ef   提取码：5skw

抓包分析

1）启动 Fiddler 后，打开本地的浏览器访问博客的 URL，此时在 Fiddler 的界面上可以看到有关不蒜子的请求

1

https://busuanzi.ibruce.info/busuanzi?jsonpCallback=BusuanziCallback_195655659654