大家好，我是DD！
近日，Spring Cloud Tencent 于6月14日正式对外开源，作为腾讯开源的一站式微服务框架，Spring Cloud Tencent 实现了 Spring Cloud 标准微服务 SPI ，开发者可以基于 Spring Cloud Tencent 快速开发 Spring Cloud 微服务架构应用。Spring Cloud Tencent 的核心依托腾讯开源的一站式服务发现与治理平台 Polarismesh ，实现各种分布式微服务场景。
张乐
腾讯云技术专家，Spring Cloud Tencent 社区负责人，腾讯云微服务引擎 TSE 核心研发。一直致力于微服务领域研发工作，例如配置中心、注册中心、服务治理等领域。
3月1日，Spring官方博客发布了一篇关于Spring Cloud Gateway的CVE报告。
其中包含一个高风险漏洞和一个中风险漏洞，建议有使用Spring Cloud Gateway的用户及时升级版本到3.1.1+、3.0.7+或采用其他缓解方法加强安全防护。
有涉及的小伙伴可以看看下面具体这两个漏洞的内容和缓解方法。
严重性：Critical
漏洞描述：使用Spring Cloud Gateway的应用程序在Actuator端点在启用、公开和不安全的情况下容易受到代码注入的攻击。攻击者可以恶意创建允许在远程主机上执行任意远程执行的请求。
在上一篇实现了Spring Cloud资源服务器的定制化，但是又发现了一个新的问题，Spring Cloud微服务调用的过程中需要令牌中继。只有令牌中继才能在调用链中保证用户认证信息的传递。今天就来分享一下如何在Feign中实现令牌中继。
令牌中继(Token Relay)是比较正式的说法，说白了就是让Token令牌在服务间传递下去以保证资源服务器能够正确地对调用方进行鉴权。
如果我们携带Token去访问A服务，A服务肯定能够鉴权，但是A服务又通过Feign调用B服务，这时候A的令牌是无法直接传递给B服务的。 这里来简单说下原因，服务间的调用通过Feign接口来进行。在调用方通常我们编写类似下面的Feign接口：
我在上一篇对资源服务器进行了简单的阐述，让大家对资源服务器的概念有了简单的认识，今天我将用实际例子来演示单体应用改造为Spring Cloud微服务时的资源服务器实现。
以Spring Security实战干货的DEMO为例子，原本它是一个单体应用，认证和授权都在一个应用中使用。改造为独立的服务后，原本的认证就要剥离出去（这个后续再讲如何实现），服务将只保留基于用户凭证（JWT）的访问控制功能。接下来我们将一步步来实现该能力。
前段时间Spring Boot发布了本年度最后一个重要更新版本：Spring Boot 2.4.0。
最近在社群里也开始有讨论关于Spring Boot 2.4的一些使用问题。我发现有很多Spring Cloud用户也急切着想要体验最新版本的Spring Boot，然后碰到了一些问题，其中被提出来最多的就是配置无法加载的问题。
我没有去深究这个问题如何去解决，因为之前，在发布说明中有提及过，在Spring Boot 2.4版本中对配置文件的处理做了较大的改动，如果你只是简单的使用application.properties或application.yaml，那么还能无缝衔接。但如果用了更为复杂的配置方式，很可能会失败。
今天在知乎上看到了这样一个问题：Spring Cloud 和 Dubbo哪个会被淘汰？看了几个回答，都觉得不在点子上，所以要么就干脆写篇小文瞎逼叨一下。
简单说说个人观点
我认为这两个框架大概率会长期都存在。
时至今日，这两个框架放到现在，已经不存在谁取代谁这一说了。由于Spring Cloud Alibaba的出现，Dubbo已经很好的融入到了Spring Cloud体系，所以围绕Spring Cloud生态的各种周边产品都是可以无缝整合到一起来玩的。
Dubbo无缝整合Spring Cloud生态是啥意思呢？主要两方面：
距离Spring Boot 2.2.0的发布已经有一个半月左右时间，由于与之匹配的Spring Cloud版本一直没有Release，所以在这期间碰到不少读者咨询的问题都是由于Spring Boot和Spring Cloud版本不匹配导致。
很多时候，我们在学习或重建系统的时候都喜欢直接选用最高版本来开发，但是在使用Spring全家桶的时候，这样的选择不一定是最佳选择。主要还是由于Spring全家桶中各项目之间还存在一定的依赖关系。尤其是在大版本迭代期间，是我们尤其要注意的。比如，这次Spring Framework、Spring Boot、Spring Cloud的升级，是一次整体的大版本的升级，涵盖了Spring Framework 5.2、Spring Boot 2.2、Spring Cloud Hoxton。
很早以前，在刚开始搞Spring Cloud基础教程的时候，写过这样一篇文章：《微服务架构的基础框架选择：Spring Cloud还是Dubbo？》，可能不少读者也都看过。之后也就一直有关于这两个框架怎么选的问题出来，其实文中我有明确的提过，Spring Cloud与Dubbo的比较本身是不公平的，主要前者是一套较为完整的架构方案，而Dubbo只是服务治理与RPC实现方案。
之前在写Spring Cloud Stream专题内容的时候，特地介绍了一下如何使用RabbitMQ的延迟消息来实现定时任务。最近正好因为开发碰到了使用过程中发现，延迟消息没有效果，消息直接就被消费了的情况。因此就继续深入研究了一下问题原因，在此记录下来，给碰到类似问题的童鞋们参考。
因为不是所有的消息都出现了没有延迟消息效果的因素，通过有问题的消息特征，大致猜测可能是延迟时间过长导致了消息延迟失败。为了验证这个原因，先拿之前文章中的例子，来测试一下延迟时间是否与问题直接相关。
