1. 首页
  2. 开发
  3. 列表

changs 2019-04-13 19:26:20 2258

继续说说生产环境的Nacos搭建,通过上一篇《Spring Cloud Alibaba基础教程:Nacos的数据持久化》的介绍,我们已经知道Nacos对配置信息的存储原理,在集群搭建的时候,必须要使用集中化存储,比如:MySQL存储。下面顺着上一篇的内容,继续下一去。通过本文,我们将完成Nacos生产环境的搭建。

java spring cloud alibaba 微服务 开发

changs 2019-04-13 19:26:20 2255

在之前的教程中,我们对于Nacos服务端自身并没有做过什么特殊的配置,一切均以默认的单机模式运行,完成了上述所有功能的学习。但是,Nacos的单机运行模式仅适用于学习与测试环境,对于有高可用要求的生产环境显然是不合适的。那么,我们是否可以直接启动多个单机模式的Nacos,然后客户端指定多个Nacos节点就可以实现高可用吗?答案是否定的。在搭建Nacos集群之前,我们需要先修改Nacos的数据持久化配置为MySQL存储。默认情况下,Nacos使用嵌入式数据库实现数据的存储。所以,如果启动多个默认配置下的Nacos节点,数据存储是存在一致性问题的。为了解决这个问题,Nacos采用了集中式存储的方式来支持集群化部署,目前只要支持MySQL的存储。

java spring cloud alibaba 微服务 开发

changs 2019-04-13 19:26:20 2311

对于Nacos作为配置中心的使用,通过之前的几篇博文,我们已经介绍了如何在Nacos中创建配置内容、Nacos配置内容与Spring应用配置之间的对应关系以及实战中多环境下的配置管理方案。但是,我们实际应用过程中还会经常碰到这样的问题:有时候我们会对应用的配置根据具体作用做一些拆分,存储在不同的配置文件中,除了归类不同的配置之外,也可以便于共享配置给不同的应用。对于这样的需求,Nacos也可以很好的支持,下面就来具体介绍一下,当使用Nacos时,我们如何加载多个配置,以及如何共享配置。

java spring cloud alibaba 微服务 开发

changs 2019-04-13 19:26:20 2301

在Nacos中,本身有多个不同管理级别的概念,包括:Data ID、Group、Namespace。只要利用好这些层级概念的关系,就可以根据自己的需要来实现多环境的管理。

java spring cloud alibaba 微服务 开发

changs 2019-04-13 19:26:20 2174

前情回顾:上一篇,我们学习了如何在Nacos中创建配置,以及如何使用Spring Cloud Alibaba的Nacos客户端模块来加载配置。在入门例子中,我们只配置了Nacos的地址信息,没有配置任何其他与配置加载相关的其他内容。所以,接下来准备分几篇说说大家问的比较多的一些实际使用的问题或疑问。

java spring cloud alibaba 微服务 开发

changs 2019-04-13 19:26:20 2249

Nacos除了实现了服务的注册发现之外,还将配置中心功能整合在了一起。通过Nacos的配置管理功能,我们可以将整个架构体系内的所有配置都集中在Nacos中存储。这样做的好处,在以往的教程中介绍Spring Cloud Config时也有提到,主要有以下几点:分离的多环境配置,可以更灵活的管理权限,安全性更高应用程序的打包更为纯粹,以实现一次打包,多处运行的特点(《云原声应用的12要素》之一)Nacos的配置管理模型与淘宝开源的配置中心Diamond类似,基础层面都通过DataId和Group来定位配置内容,除此之外还增加了很多其他的管理功能。

java spring cloud alibaba 微服务 开发

changs 2019-04-13 19:26:20 2184

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。

changs 2019-04-13 19:26:20 2535

这篇博文是临时增加出来的内容,主要是由于最近连载《Spring Cloud Alibaba基础教程》系列的时候,碰到读者咨询的大量问题中存在一个比较普遍的问题:版本的选择。其实这类问题,在之前写Spring Cloud基础教程的时候,就已经发过一篇《聊聊Spring Cloud版本的那些事儿》,来说明Spring Boot和Spring Cloud版本之间的关系。

changs 2019-04-13 19:26:20 2219

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

changs 2019-04-13 19:26:20 2267

昨晚Nacos社区发布了第一个生产级版本:0.8.0。由于该版本除了Bug修复之外,还提供了几个生产管理非常重要的特性,所以觉得还是有必要写一篇讲讲这次升级,在后续的文章中也都将以0.8.0版本为基础。

changs 2019-04-13 19:26:20 2175

自Spring Cloud Alibaba发布第一个Release以来,就备受国内开发者的高度关注。虽然Spring Cloud Alibaba还没能纳入Spring Cloud的主版本管理中,但是凭借阿里中间件团队的背景,还是得到不少团队的支持;同时,由于Spring Cloud Alibaba中的几项主要功能都直指Netflix OSS中的重要组件,而后者最近频繁宣布各组件不在更新新特性,这使得Spring Cloud Alibaba关注度不断飙升,不少开发者或团队也开始小范围试水。笔者对此也进行了一段时间的调研与试水,接下来计划以《Spring Cloud Alibaba基础教程》为主题,为大家完成一套快速入门的免费内容,以支持开源社区的发展! ^_^

changs 2019-04-13 19:26:20 2180

问题:该问题可能在开发阶段不一定会发现,但是在线上部署多实例的时候,将会发现Consul中只有一个实例。

changs 2019-04-13 19:26:20 916

动态配置管理是 Nacos 的三大功能之一,通过动态配置服务,我们可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。

changs 2019-04-13 19:26:20 2541

Nacos作为注册中心和配置中心的基础教程,到这里先告一段落,后续与其他结合的内容等讲到的时候再一起拿出来说,不然内容会有点跳跃。接下来我们就来一起学习一下Spring Cloud Alibaba下的另外一个重要组件:Sentinel。

changs 2019-04-13 19:26:20 2332

在Spring Cloud Commons中提供了大量的与服务治理相关的抽象接口,包括DiscoveryClient、这里我们即将介绍的LoadBalancerClient等。对于这些接口的定义我们在上一篇介绍服务注册与发现时已经说过,Spring Cloud做这一层抽象,很好的解耦了服务治理体系,使得我们可以轻易的替换不同的服务治理设施。

changs 2019-04-13 19:26:20 2214

Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

changs 2019-04-13 19:26:20 2265

在之前的《Spring Cloud构建微服务架构:分布式配置中心》一文中,我们介绍的Spring Cloud Server配置中心采用了Git的方式进行配置信息存储。这一设计巧妙的利用Git自身机制以及其他具有丰富功能的Git服务端产品,让Spring Cloud Server在配置存储和管理的上避开了很多与管理相关的复杂实现,使其具备了配置中心存储配置和读取配置的基本能力;而更上层的管理机制,由于不具备普遍适用性,所以Spring Cloud Server并没有自己去实现这部分内容,而是通过Git服务端产品来提供一部分实现,如果还需要更复杂的功能也能自己实现与定义。即便如此,对于Spring Cloud Server默认使用Git来存储配置的方案一直以来还是饱受争议。所以,本文将介绍一下Spring Cloud Config从Edgware版本开始新增的一种配置方式:采用数据库存储配置信息。

changs 2019-04-13 19:26:20 2243

之前我们已经通过《Spring Cloud Stream消费失败后的处理策略(一):自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能。本文将介绍RabbitMQ的binder提供的另外一种重试功能:重新入队。

changs 2019-04-13 19:26:20 2226

前两天我们已经介绍了两种Spring Cloud Stream对消息失败的处理策略:

changs 2019-04-13 19:26:20 2261

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

changs 2019-04-13 19:26:20 2245

之前写了几篇关于Spring Cloud Stream使用中的常见问题,比如:

changs 2019-04-13 19:26:20 2276

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

changs 2019-04-13 19:26:20 2370

有的时候,我们对于同一通道中的消息处理,会通过判断头信息或者消息内容来做一些差异化处理,比如:可能在消息头信息中带入消息版本号,然后通过if判断来执行不同的处理逻辑,其代码结构可能是这样的:

changs 2019-04-13 19:26:20 2398

在上一篇《Spring Cloud Stream如何处理消息重复消费》中,我们通过消费组的配置解决了多实例部署情况下消息重复消费这一入门时的常见问题。本文将继续说说在另外一个被经常问到的问题:如果微服务生产的消息自己也想要消费一份,应该如何实现呢?

changs 2019-04-13 19:26:20 2190

之前我发过一篇《说说我为什么看好Spring Cloud Alibaba》,然后这两天有网友给我转了这篇文章《坑爹项目spring-cloud-alibaba,我们也来一个》,问我的看法是怎么样的,聊天时候简单说了一下。今天在家休息,抽空整理一下内容,逐点说一下我的看法,主要还是觉得这篇文章博眼球的成分高一些,因为这篇文章的解读与之前其他某些自媒体发布的《Eureka 2.0 开源工作宣告停止,继续使用风险自负》一文有异曲同工之“妙”,如果读者没有真正的理解Spring Cloud与Spring Cloud Alibaba,就很有可能会对它们有什么误解,然后产生这样的想法: