通过本教程的前两篇： 《Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现》 《Spring Cloud Alibaba基础教程：支持的几种服务消费方式（RestTemplate、WebClient、Feign）》 我们已经学会了，如何利用Nacos实现服务的注册与发现。同时，也介绍了在Spring Cloud中，我们可以使用的几种不同编码风格的服务消费方...

通过《Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现》一文的学习，我们已经学会如何使用Nacos来实现服务的注册与发现，同时也介绍如何通过LoadBalancerClient接口来获取某个服务的具体实例，并根据实例信息来发起服务接口消费请求。但是这样的做法需要我们手工的去编写服务选取、链接拼接等繁琐的工作，对于开发人员来说非常的不友好。所以接下来，我们再来...

昨晚Nacos社区发布了第一个生产级版本：0.8.0。由于该版本除了Bug修复之外，还提供了几个生产管理非常重要的特性，所以觉得还是有必要写一篇讲讲这次升级，在后续的文章中也都将以0.8.0版本为基础。 升级的理由如Nacos官方的发布文档中描述的那样，本版本将支持非常重要的三个特性： 第一，用户登录。在过去版本的Nacos中，用户是可以直接访问Nacos的页面的，我们需要通过网络或者代理...

难得可以一天都窝在家里写代码，没太注意朋友圈和群里的消息。下午出门打开微信，马上就被“拼多多被薅羊毛”的文章吸引了眼球。基本上把群里、朋友圈里以及各大新闻App刷了个遍，根据网上传言 + 官方回应基本就是这么个事儿： 微博爆料：拼多多出现重大Bug：100 无门槛券随便领，一晚上被薅200亿 官方回应：有黑灰产团队利用漏洞牟利，已报警处理。 官方辟谣：被薅200亿是谣言，实际损失或低于千万...

自Spring Cloud Alibaba发布第一个Release以来，就备受国内开发者的高度关注。虽然Spring Cloud Alibaba还没能纳入Spring Cloud的主版本管理中，但是凭借阿里中间件团队的背景，还是得到不少团队的支持；同时，由于Spring Cloud Alibaba中的几项主要功能都直指Netflix OSS中的重要组件，而后者最近频繁宣布各组件不在更新新特性...

应用场景我们在使用一些开源调度系统（比如：elastic-job等）的时候，对于任务的执行时间通常都是有规律性的，可能是每隔半小时执行一次，或者每天凌晨一点执行一次。然而实际业务中还存在另外一种定时任务，它可能需要一些触发条件才开始定时，比如：编写博文时候，设置2小时之后发送。对于这些开始时间不确定的定时任务，我们也可以通过Spring Cloud Stream来很好的处理。 为了实现开始时...

应用场景有的时候，我们对于同一通道中的消息处理，会通过判断头信息或者消息内容来做一些差异化处理，比如：可能在消息头信息中带入消息版本号，然后通过if判断来执行不同的处理逻辑，其代码结构可能是这样的： @StreamListener(value = TestTopic.INPUT)public void receiveV1(String payload, @Header("version") ...

应用场景之前我们已经通过《Spring Cloud Stream消费失败后的处理策略（一）：自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能。本文将介绍RabbitMQ的binder提供的另外一种重试功能：重新入队。 动手试试准备一个会消费失败的例子，可以直接沿用前文的工程，也可以新建一个，然后创建如下代码的逻辑： @EnableBinding(TestAppli...

应用场景前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略： 自动重试：对于一些因环境原因（如：网络抖动等不稳定因素）引发的问题可以起到比较好的作用，提高消息处理的成功率。 自定义错误处理逻辑：如果业务上，消息处理失败之后有明确的降级逻辑可以弥补的，可以采用这种方式，但是2.0.x版本有Bug，2.1.x版本修复。 那么如果代码本身存在逻辑错误，无论重试多...

应用场景上一篇《Spring Cloud Stream消费失败后的处理策略（一）：自动重试》介绍了默认就会生效的消息重试功能。对于一些因环境原因、网络抖动等不稳定因素引发的问题可以起到比较好的作用。但是对于诸如代码本身存在的逻辑错误等，无论重试多少次都不可能成功的问题，是无法修复的。对于这样的情况，前文中说了可以利用日志记录消息内容，配合告警来做补救，但是很显然，这样做非常原始，并且太过笨拙...