在跟我学SpringCloud（Finchley版）-02-构建分布式应用一文中，已编写好两个微服务；在跟我学SpringCloud（Finchley版）-04-服务注册与服务发现-原理剖析一文中详细剖析了服务发现的原理。如果对这块知识有疑问，可先行复习一下。本文探讨如何将跟我学SpringCloud（Finchley版）-02-构建分布式应用一节中的应用注册到Nacos上。准备工作在pom.xm
前文构建的都是单节点的ConfigServer，本节来讨论如何构建高可用的ConfigServer集群，包括ConfigServer的高可用依赖Git仓库的高可用以及RabbitMQ的高可用。先来讨论Git仓库的高可用。Git仓库的高可用由于配置内容存储在Git仓库中，所以要想实现ConfigServer的高可用，必须有一个高可用的Git仓库。有两种方式可以实现Git仓库的高可用。使用第三方Git
Kubernetes的安装部署是难中之难，每个版本安装方式都略有区别。笔者一直想找一种支持多平台、相对简单、适用于生产环境的部署方案。经过一段时间的调研，有如下几种解决方案进入笔者视野：部署方案优点缺点Kubeadm官方出品部署较麻烦、不够透明Kubespray官方出品、部署较简单、懂Ansible就能上手不够透明RKE部署较简单、需要花一些时间了解RKE的cluster.yml配置文件不够透明手
1月前后开始为SpringCloudAlibaba系列博客攒稿，成果如下图所示，今天开始发布。如图的排序可能还不是很合理，发布之前会再整理下，尽量降低学习曲线，给读者提供一个更佳舒适的学习体验。之前的SpringCloud系列也会继续连载。更新节奏：SpringCloud系列每周至少2篇，SpringCloudAlibaba系列每周至少1篇。放心，两个系列都不会烂尾的。Nacos是阿里开源的易于构
先解释下为什么突然断更半个月：正月初三-正月十二：父亲肺气肿住院；母亲肺炎，也要挂水，故请假照顾。正月十四-正月二十：奶奶摔了一跤，突然离世…老家有守夜、办丧的习俗，请假事丧。总之，2019开局很不顺利……Anyway，今天开工，今天恢复更新。配置刷新三要素依赖中有spring-boot-starter-actuator添加如下配置，暴露/actuator/refresh端点：management
本文探讨如何安装RabbitMQ，包括Windows环境下的安装（其他操作系统安装过程类似）以及Docker方式的安装。Windows操作系统安装RabbitMQ安装Erlang/OTP19.2RabbitMQ依赖ERlang，先来安装ERlang。通过官方下载页面：http://www.erlang.org/downloads，获取exe安装包，双击打开，按照提示即可完成安装。安装RabbitM
前文都是将配置明文存储在Git仓库中，但在实际项目中，敏感的配置属性（例如数据库账号、密码等），都应加密存储，从而提高安全性。ConfigServer为配置内容的加密与解密提供了支持。安装JCEJava6JCE地址：https://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.htmlJava7JCE地
在跟我学SpringCloud（Finchley版）-19-配置中心-SpringCloudConfig一节中，已实现使用Git仓库作为ConfigServer的后端存储，本节详细探讨如何配置Git仓库。一、占位符支持ConfigServer的占位符支持{application}、{profile}和{label}。示例：server:port:8080spring:application:nam
经过前文讲解，至此，微服务架构已经日趋完善——现在已经可以做一个大型的应用了！然而，随着项目的迭代，微服务数目往往与日俱增，如何高效地管理配置成为我们必须解决的问题。本节来讨论如何使用SpringCloudConfig管理配置。为什么要使用配置中心集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务，因此集中管理配置是非常有必要的；不同环境，不同配置。例如，数据源配置在不同的环境（
本文从社区活跃度、产品特点、成功案例、产品缺点等维度，全方位对比SpringCloudConfig、Apollo、Nacos、Disconf、SpringCloudConsul、SpringCloudZookeeper等几款SpringCloud生态的配置服务器，帮助你选择合适的配置服务器。一、SpringCloudConfigGitHub地址https://github.com/spring-c
本节探讨Zuul的高级特性。TIPS：笔者已经写过很多Zuul相关的文章，对于已经写过的内容，就不再啰嗦一遍了，直接贴地址吧。过滤器详解过滤器是Zuul的核心，Zuul大多功能都是基于过滤器实现的。详见：SpringCloudZuul过滤器详解，文章着重探讨了Zuul过滤器的生命周期、如何自定义过滤器、如何禁用指定过滤器等。内置过滤器详解Zuul内置了很多过滤器，这些过滤器帮助我们实现各种能力，来
本文对Hystrix、Resilience4j、Sentinel进行对比，并探讨如何使用一行代码将Hystrix迁移到Sentinel。作者：洛夜，校对：周立在本博客首发，欢迎转载。前段时间，Netflix宣布Hystrix进入维护模式，详见Hystrix停止开发，我们该何去何从？，而SpringCloud亦宣布SpringCloudNetflix进入维护状态，后续不再进行更新已成为事实。作为开发
上一节（跟我学SpringCloud（Finchley版）-16-Zuul）中，已经实现用Zuul转发到Eureka上的微服务。默认的路由规则是：访问$ZUUL_URL/指定为服务/**会被转发到指定微服务的/**。但在实际项目中，往往需要自己定义路由规则，Zuul的路由配置非常灵活、简单，本节详细讲解Zuul的路由配置。一、自定义指定微服务的访问路径配置zuul.routes.指定微服务的ser
Hystrix提供了监控HystrixCommand的能力，本节来详细探讨。监控端点与数据应用整合Hystrix，同时应用包含spring-boot-starter-actuator依赖，就会存在一个/actuator/hystrix.stream端点，用来监控HystrixCommand。当被@HystrixCommand注解了的方法被调用时，就会产生监控信息，并暴露到该端点中。当然，该端点默认
Feign默认已经整合了Hystrix，本节详细探讨Feign使用Hystrix的具体细节。服务降级加配置，默认Feign是不启用Hystrix的，需要添加如下配置启用Hystrix，这样所有的FeignClient都会受到Hystrix保护！feign:hystrix:enabled:true提供Fallback：@FeignClient(name="microservice-provider-
本节详细讲解使用Hystrix的通用方式。简介Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。包裹请求使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用到了设计模式中的“命
至此，我们已实现服务发现、负载均衡，同时，使用Feign也实现了良好的远程调用——我们的代码是可读、可维护的。理论上，我们现在已经能构建一个不错的分布式应用了，但微服务之间是通过网络通信的，网络可能出问题；微服务本身也不可能100%可用。如何提升应用的可用性呢？这是我们必须考虑的问题——举个例子：某大型系统中，服务A调用服务B，某个时刻，微服务B突然崩溃了。微服务A中，依然有大量请求在请求B，如果
本文总结Feign常见问题及解决方案。一、FeignClient接口如使用@PathVariable，必须指定value属性代码示例：@FeignClient("microservice-provider-user")publicinterfaceUserFeignClient{@RequestMapping(value="/simple/{id}",method=RequestMethod.GE
上一节（跟我学SpringCloud（Finchley版）-09-Feign）讲了Feign的入门姿势并深入对比了RestTemplate，本节来深入探讨Feign的高级特性。总的来说，Feign是一个相对简单的组件，但细节还是比较多的，一不小心就可能入坑，注意点我会以WARINING的形式标记出来，便于读者查阅。Feign配置自定义【细粒度配置】方式一、代码配置方式SpringCloudNetf
经过前文讲解，我们已使用Eureka实现服务发现；使用Ribbon实现了负载均衡这种听起来很高端的东西。我们的架构已经初具雏形，但依然存在很多问题，下面不妨来分析下前文的代码——@GetMapping("/users/{id}")publicUserfindById(@PathVariableLongid){//这里用到了RestTemplate的占位符能力Useruser=this.restTe
JDK 12即将在2019年3月19日发布，下面列出JDK的版本迭代时间表
上一节讲了Ribbon的入门姿势，本节深入探讨Ribbon的高级特性。内置负载均衡规则负载均衡规则是Ribbon的核心，下面来看一下Ribbon内置的负载均衡规则。AvailabilityFilteringRule：过滤掉一直连接失败的被标记为circuittripped的后端Server，并过滤掉那些高并发的后端Server或者使用一个AvailabilityPredicate来包含过滤serv
经过前文讲述，我们已经实现了服务发现。本节来解决跟我学SpringCloud（Finchley版）-02-构建分布式应用提到的如下问题：负载均衡如何考虑？难道得在电影微服务和用户微服务之间加个NGINX做负载均衡吗？听起来是可行的，但如果有10000+服务（这并不夸张，我司的微服务数目是这个数字乘以N，N>=m，哈哈哈）那这个NGINX的配置得有多复杂……一般来说，提到负载均衡，大家一般很容
在跟我学SpringCloud（Finchley版）-05-服务注册与服务发现-Eureka入门一节中，已经编写了一个EurekaServer，并将服务提供者与消费者都注册到了EurekaServer上。本节，来深入探讨Eureka的高级特性。Eureka原理本节来探讨Eureka的原理。Region&AvailabilityZone下面分析一下Eureka原理，在分析原理前，先来了解一下
本节讲解基于Eureka的服务发现。Eureka简介Eureka是Netflix开源的服务发现组件，本身是一个基于REST的服务，包含Server和Client两部分，SpringCloud将它集成在子项目SpringCloudNetflix中。拓展阅读Eureka的GitHub：https://github.com/Netflix/EurekaNetflix是一家在线影片租赁提供商。Eureka
第2节（跟我学SpringCloud（Finchley版）-02-构建分布式应用）说过：地址硬编码问题——电影微服务中将用户微服务的地址写死，如果用户微服务地址发生变化，难道要重新上线电影微服务吗？本节来解决该问题。不妨先思考一下，怎样才能让服务消费者总能找到服务提供者呢？或者说，怎样才能让服务消费者感知到服务提供者地址的变化呢？TIPS目前市面上把服务消费者找到服务提供者的这种机制称为服务发现，
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
