Java日知录

概述

在单体服务中我们需要查看日志只需直接在日志文件中 grep、awk 就可以获得自己想要的信息。

但是在微服务架构中，不同的服务模块一般会部署多个节点，日志散落在多个节点的日志文件中。一旦出现问题，我们就需要登录不同的服务节点分别查看日志，非常之繁琐。所以在微服务架构中，我们是需要建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。

现在目前主流的分布式日志解决方案还是基于ELK（ElasticSearch、Logstash、Kibana），今天我们就动手搭建一个单机版的ELK日志收集系统并将我们的日志文件集成进去。

在这个系列文章中曾经介绍过在SpringCloud体系下如何防止前端请求绕过网关直接到达后端微服务，今天我们要反其道而行之，介绍在SpringCloud体系中如何防止内部隐私接口被网关调用。

看到这里可能有的同学会有点晕，怎么还有这种业务场景呢，别急，咱们先回顾一下我们的业务场景。

在SpringCloud架构体系中，微服务间的通信是基于Feign调用。而在实际使用Feign的过程中我们大概率会面临下面几个问题：

• Feign客户端放在消费端还是独立一个api层？
• Feign调用的接口如何要不要进行包装？
• Feign如何抓取业务生产端的业务异常？

这篇文章我们就来一起探讨一下这几个问题，希望看完能对你有所帮助。

有一个看我SpringCloud alibaba系列文章的粉丝私下问我：如何处理jwt失效的问题？修改密码或退出登录后需要将之前的jwt token失效掉，不允许使用旧token登录系统。

我说：很简单呀，咱们直接 无为而治，用户退出或修改密码的时候前端直接删除这个token不就完了吗？后端啥都不用管，啥也不用做。

他说：别闹，你的每篇文章我都给你一键三连。

我当时就被感动了，既然是这样的好读者，我果断答应专门给他写篇文章来分享一下我这个不太成熟的做法，改造一下这个SpringCloud alibaba项目。

大家好，我是飘渺。

当我们在给数据库进行表设计时需要遵守一些基本的原则，比如你经常听见的“范式准则”。但范式准则过于理论，在真实业务中，你不必严格遵守三范式的要求。而且有时为了性能考虑，你还可以进行反范式的设计，比如在数据仓库领域。本节我们一起来了解这些内容，希望你学完这篇文章之后，能从更高一层的维度来看待 MySQL 数据库的表结构设计。

概述

在微服务开发中我们经常会引入消息中间件实现业务解耦，执行异步操作， 现在让我们来看看使用消息中间件的好处和弊端。

首先需要肯定是使用消息组件有很多好处，其中最核心的三个是：解耦、异步、削峰。

• 解耦：客户端只要讲请求发送给特定的通道即可，不需要感知接收请求实例的情况。
• 异步：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。
• 削峰：消息中间件在消息被消费之前一直缓存消息，消息处理端可以按照自己处理的并发量从消息队列中慢慢处理消息，不会一瞬间压垮业务。

当然消息中间件并不是银弹，引入消息机制后也会有如下一些弊端：

在日常数据库设计中，几乎每张业务表都带有一个日期列，用于记录每条记录产生和变更的时间。比如用户表会有一个日期列记录用户注册的时间、用户最后登录的时间。又比如，电商行业中的订单表（核心业务表）会有一个订单产生的时间列，当支付时间超过订单产生的时间，这个订单可能会被系统自动取消。

日期类型虽然常见，但在表结构设计中也容易犯错，比如很多开发同学都倾向使用整型存储日期类型，同时也会忽略不同日期类型对于性能可能存在的潜在影响。所以你有必要认真看看这篇文章，举一反三，在自己的业务中做好日期类型的设计。

概述

大家都知道在微服务架构下的一个请求会涉及多个服务，而服务本身可能也会依赖其他服务，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响，如果没有及时处理很有可能会造成整个系统崩溃。

面对以上情况，我们就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

本章内容我们来给我们的微服务集成SkyWalking监控，毕竟都2021年了，生产环境应该很少人使用zipkin来作为调用链监控吧。

通常架构师们为了提高系统及硬件资源的利用率引入了虚拟化技术。

虚拟化是一种资源管理技术，它可以把各种实体资源抽像后再分隔，从而打破实体结构的限制，最大程度的提高资源的利用率。
今天我们来聊一下传统虚拟化技术和以Docker为代表的容器技术。

虚拟化

虚拟化就是在一台物理服务器上，运行多台“虚拟服务器”。这种虚拟服务器，也叫虚拟机（VM，Virtual Machine）。

虚拟化出现的初衷主要是为了减少物理服务器的数量，提高服务器资源利用率。利用虚拟化技术将物理服务器隔离成多个小的虚拟服务器并提供部署能力。

简单来说，虚拟化可以为我们的工作带来以下几种便利：

在前面的文章中，我们已经多次使用到了 Service 这个 Kubernetes 里重要的服务对象。而 Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的，另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。

一个最典型的 Service 定义，如下所示：