springcloud项目实例,Spring Cloud 微服务实战

springcloud项目实例,Spring Cloud 微服务实战详细介绍

本文目录一览： SpringCloud配置实战：演示和测试切换

SpringCloud配置实战：演示和测试切换。我们现在将实现注册中心和SpringCloud提供者配置信息从SpringCloud Config读取配置文件的方式
工具/材料 SpringCloud Config
Intellij idea
01 现在我们的Config服务端配置OK而且测试通过，我们可以从Config+GitHub进行配置修改并获得内容。 此时我们做一个eureka服务+一个Dept访问的微服务，将这两个微服务的配置统一又github获得实现统一配置分布式管理，完成多环境的变更。
02 在github本地仓库下新建文件microcloudservice-config-eureka-client.yml、microcloudservice-config-dept-client.yml文件。
03 把这两个文件上传到github服务器上。
04 新建项目microcloudservice-config-eureka-client-7001注册中心。
05 在pom文件中增加相关的依赖包。
06 修改主程序启动类。
07 在项目中新建bootstrap.yml、application.yml两个配置文件。
08 启动SpringCloud Config服务端，测试一下这个Eureka服务端配置是否成功。
09 新建项目microcloudservice-config-provider-dept-client-8001提供者。
10 在类路径下新增bootstrap.yml和application.yml配置文件。
11 启动项目主程序类，查看程序的配置是否正常。

关于Spring Cloud Alibaba，看这篇文章就够了！（附教程资料）

首先我们需要了解一下Spring Cloud，然后再来了解Spring Cloud Alibaba；
源自官方描述：
Spring Cloud为开发人员提供了一些工具用来快速构建分布式系统中的一些常见模式和解决一些常见问题（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、群集状态）。分布式系统的协调导致了很多样板式的代码（很多固定套路的代码），使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地运行，包括开发人员自己的笔记本电脑、裸机数据中心和云计算等托管平台；
Spring Cloud为分布式系统开发的典型应用场景提供良好的开箱即用的功能:
Spring Cloud Alibaba是Spring Cloud下的一个子项目，Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案，它包含开发分布式应用程序所需的所有组件，使您可以轻松地使用Spring Cloud开发应用程序，使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统；
Spring Cloud Alibaba 是阿里巴巴开源中间件跟 Spring Cloud 体系的融合:
动力节点的Spring Cloud Alibaba学习教程，将带你深入掌握基于Spring Cloud Alibaba技术栈的微服务开发技术，包括nacos、sentinel、seata、gateway、skywalking等，培养独立进行企业微服务项目架构的能力;
Spring Cloud Alibaba视频教程
https://www.bilibili.com/video/BV1nK4y
Spring Cloud Alibaba资料下载
http://www.bjpowernode.com/?toutiao
?001.视频导读
?002.Spring家族产品梳理
?003.What is Spring-Cloud-Alibaba？
?004.Nacos运行环境部署
?005.向Nacos注册中心注册服务
?006.从Nacos发现服务并负载均衡调用
?007.从Nacos发现服务并负载均衡调用
?008.Nacos客户端信息缓存
?009.Nacos客户端信息缓存
?010.Nacos Config配置中心启动读取外部配置
?011.Nacos Config配置中心自动刷新
?012.Nacos Config配置中心yaml配置
?013.Nacos Config配置中心多环境配置
?014.问答交流
?015.内容回顾-配置中心数据模型
?016.配置中心三层结构数据配置隔离
?017.配置中心三层结构数据配置隔离
?018.配置版本回滚-服务注册分组
?019.Nacos管控台用户权限管理
?020.Nacos数据持久化
?021.Nacos数据持久化
?022.Nacos集群环境部署
?023.Nacos集群环境测试
?024.Nacos集群统一入口Nginx
?025.快速回顾
?026.RestTemplate无参数Get调用返回String
?027.RestTemplate无参数Get调用返回User
?028.RestTemplate有参数Get调用返回User
?029.RestTemplate有参数Get调用返回User
?030.RestTemplate有参数Post调用返回User
?031.RestTemplate有参数Post调用返回User
?032.RestTemplate传输User对象参数Post调用返回User
?033.RestTemplate传输JSON参数Post调用返回User
?034.RestTemplate有参数Put调用
?035.RestTemplate有参数Delete调用
?036.RestTemplate方法调用梳理总结
?037.RestTemplate结合Ribbon实现负载均衡
?038.RestTemplate结合Ribbon实现负载均衡
?039.Ribbon负载均衡实现策略
?040.自定义Ribbon负载均衡实现策略
?041.更改Ribbon负载均衡实现策略
?042.Ribbon的核心接口组成
?043.Ribbon负载均衡策略个性化配置
?044.Ribbon结合Nacos实现权重负载均衡策略
?045.Ribbon结合Nacos负载均衡策优先调用同名集群
?046.Ribbon结合Nacos基于版本负载均衡策略
?047.Ribbon结合Nacos基于命名空间负载均衡策略
?048.What is Feign？
?049.Spring Cloud Alibaba基于Feign的远程调用
?050.Spring Cloud Alibaba基于Feign+Ribbon负载均衡远程调用
?051.Spring Cloud Alibaba基于Feign的相关配置
?052.脱离Ribbon的Feign的远程调用
?054.微服务的级联故障服务雪崩
?055.Spring Cloud Alibaba集成Sentinel
?056.Spring Cloud Alibaba基于Sentinel管理后台数据测试
?057.Spring Cloud Alibaba基于Sentinel实现限流
?058.Spring Cloud Alibaba基于Sentinel实现限流自定义返回结果
?059.Spring Cloud Alibaba基于Sentinel实现限流自定义跳转页面
?060.Spring Cloud Alibaba基于Sentinel线程数限流
?061.Spring Cloud Alibaba基于Sentinel资源关联限流
?062.Spring Cloud Alibaba基于Sentinel流控规则和流控效果
?063.问答交流
?064.快速回顾和演示环境预备
?065.Spring Cloud Alibaba Sentinel 服务降级RT
?066.Spring Cloud Alibaba Sentinel 服务降级异常比例和异常数
?067.Spring Cloud Alibaba Sentinel 热点参数规则
?068.Spring Cloud Alibaba Sentinel 热点参数规则小细节
?069.Spring Cloud Alibaba Sentinel 系统保护规则
?070.Spring Cloud Alibaba Sentinel 授权规则
?071.Spring Cloud Alibaba Sentinel Dashboard控制台通信原理
?072.Spring Cloud Alibaba Sentinel 对Controller请求url埋点
?073.Spring Cloud Alibaba Sentinel 手写代码实现埋点
?074.Spring Cloud Alibaba Sentinel 采用注解实现埋点
?075.Spring Cloud Alibaba Sentinel 对RestTemplate流控和熔断
?076.Spring Cloud Alibaba Sentinel 对Feign流控和熔断
?077.问答交流
?078.Sentinel规则持久化-拉模式持久化到本地文件
?079.Sentinel规则持久化-拉模式持久化到本地文件
?080.Sentinel规则持久化-推模式持久化到Nacos
?081.Sentinel规则持久化-推模式持久化到Nacos
?082.Spring Cloud Gateway 网关功能特性
?083.Spring Cloud Gateway 网关搭建
?084.Spring Cloud Gateway 网关服务调用
?085.Spring Cloud Gateway 网关谓词
?086.Spring Cloud Gateway 网关谓词
?087.Spring Cloud Gateway 网关谓词
?088.Spring Cloud Gateway 网关过滤器
?089.Spring Cloud Gateway 问答交流
?090.Spring Cloud Gateway自定义谓词
?091.Spring Cloud Gateway自定义谓词
?092.Spring Cloud Gateway自定义谓词不匹配404页面
?093.Spring Cloud Gateway自定义过滤器
?094.Spring Cloud Gateway全局过滤器
?095.Spring Cloud Gateway自定义全局过滤器
?096.Spring Cloud Gateway集成Ribbon实现负载均衡
?097.Spring Cloud Gateway集成Sentinel限流
?098.Spring Cloud Gateway集成Sentinel限流自定义错误页
?099.Spring Cloud Gateway集成Sentinel规则持久化到文件
?100.Spring Cloud Gateway集成Sentinel规则持久化到Nacos
?101.Spring Cloud Gateway内部执行流程源码分析
?102.Spring Cloud Gateway小结
?103.快速回顾
?104.Spring Cloud Gateway跨域CORS请求
?105.Spring Cloud Gateway跨域CORS请求
?106.What is SkyWalking？
?107.Skywalking运行环境部署
?108.SkyWalking Agent对微服务的链路追踪
?109.SkyWalking Agent对微服务链路追踪
?110.SkyWalking Agent加入IDEA中对微服务链路追踪
?111.SkyWalking 监控告警通知
?112.SkyWalking 监控告警通知
?113.SkyWalking 微服务链路追踪数据持久化MySQL
?114.SkyWalking 问答交流
?115.Skywalking持久化跟踪数据elasticsearch
?116.Skywalking持久化跟踪数据elasticsearch
?117.Skywalking对多个跨服务的链路跟踪
?118.Skywalking对多个跨服务的链路跟踪
?119.Skywalking自定义链路跟踪
?120.Skywalking集成logback输出traceId日志
?121.Skywalking UI界面-仪表盘
?122.Skywalking UI界面-拓扑图-追踪-性能剖析-告警
?123.Skywalking 基于nacos集群
?124.Skywalking 基于nacos集群
?125.Skywalking 基于nacos集群
?126.Skywalking 问答交流
?127.What is Seata？
?128.Seata分布式事务生命周期
?129.Seata TC Server运行环境部署
?130.Seata基于AT事务模式单体应用多数据源分布式事务
?131.Seata基于AT事务模式单体应用多数据源分布式事务
?132.Seata基于AT事务模式单体应用多数据源分布式事务
?133.Seata基于AT事务模式多个微服务分布式事务
?134.Seata基于AT事务模式多个微服务分布式事务
?135.Seata基于AT事务模式多个微服务分布式事务
?136.Seata基于AT事务模式执行机制
?137.Seata AT事务模式
?138.Seata AT事务模式写数据隔离
?139.Seata AT事务模式写数据隔离
?140.Seata AT事务模式读数据隔离
?141.Seata AT事务模式读数据隔离
?142.Seata TC Server集群环境部署
?143.Seata TC Server集群环境部署
?144.Seata TC Server集群环境集成测试
?145.Seata TC Server集群环境集成测试
?146.Seata TCC事务模式的运行机制
?147.Seata TCC事务模式SpringBoot单体应用案例
?148.Seata TCC事务模式SpringBoot单体应用案例
?149.Seata TCC事务模式SpringCloudAlibab微服务应用案例
?150.Seata TCC事务模式SpringCloudAlibab微服务应用案例
?151.What is Spring Cloud Stream
?152.Spring Cloud Stream的核心概念
?153.Spring Cloud Stream集成RocketMQ配置
?154.Spring Cloud Stream集成RocketMQ发送消息
?155.Spring Cloud Stream集成RocketMQ接收消息
?156.Spring Cloud Stream集成RocketMQ监听接收消息
?157.Spring Cloud Stream集成RocketMQ多种发送消息方式
?158.Spring Cloud Stream Starter代码分析
?159.Spring Cloud Stream集成RocketMQ发送事务消息
?160.Spring Cloud Stream集成RocketMQ对象标签消息
?161.Spring Cloud Stream问答交流

生产级基于SpringCloud微服务架构性能优化实战，建议收藏

本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。

一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。
所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。
tomcat参数说明：
maxThreads，acceptCount参数应用场景
场景一
场景二
场景三
maxThreads调优
一般说服务器性能要从两个方面说起：
1、cpu计算型指标
2、io密集型指标
所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。
另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。
maxThreads设置多大合适？
我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。
实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。
acceptCount设置多大合适？
尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

当使用URL进行路由时，则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。
请求连接的超时时间
请求处理的超时时间
对所有操作请求都进行重试
对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）
对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）
注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试
Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？
目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false
还有一种是官方提倡的是 设置超时时间。
在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。
另外，禁用hystrix，官方不推荐 。
hystrix超时设置原则
问题：一个http请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？
请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：
n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)
其中+1是代表ribbon本身默认的请求。
其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。

spring-cloud微服务项目实战（8）-log4j2集成sleuth

在Peter Deutsch的《The Eight Fallacies of Distributed Computing》中指出八个分布式计算的误区：

总结下上述问题，重点出在网路问题。网络常常十分脆弱，而我们部署了微服务，系统变多，网络传输增多，对我们排查问题提出了挑战。sleuth的作用就是解决这个问题，进行调用跟踪，形成调用链，方便快速找出问题所在。
sleuth有几个专业术语：

然后修改gateway项目中添加feign依赖，用于调用获取用户信息方法，添加对应service

最后在AuthorizationFilter中注入此AuthorizationService，并修改run方法

完工！

如何使用Spring Cloud

使用Spring Cloud构建实际的微服务架构。
　　基本概念:
　　使用Docker进行集成测试
　　混合持久化
　　微服务架构
　　服务发现
　　API网关
　　Docker
　　使用Docker对每一个服务进行构建和部署。使用Docker Compose在一个开发机上进行端到端的集成测试。
　　混合持久化
　　混合持久化其实就是说使用多种数据库来存储。不同的微服务实例都会使用它们自己的数据库，并通过REST服务或者消息总线来通信，举个例子，你可以使用基于以下数据库来构建微服务：
　　Neo4j(图形化)
　　MongoDB(文档化)
　　MySQL(关联)
　　微服务架构
　　这个例子演示了如何使用微服务创建一个新的应用。由于在项目中的每一个微服务只有一个单一的父项目。开发者为此得到的收益是可以在本机上运行和开发每一个微服务。添加一个新的微服务非常简单，当发现微服务时将会自动发现运行时的集群环境上。
　　Service Discovery
　　项目中包含两个发现服务，一个在Netflix Eureka，另一个使用了
　　Consul from Hashicorp。多种发现服务提供了多种选择，一个是使用(Consul)来做DNS服务集群，另一个是(Consul)基于代理的API 网关。
　　API 网关
　　每一个微服务都关联Eureka，在整个集群中检索API路由。使用这个策略，每一个在集群上运行的微服务只需要通过一个共同的API网关进行负载均衡和暴露接口，每一个服务也会自动发现并将路由请求转发到自己的路由服务中。这个代理技术有助于开发用户界面，作为平台完整的 API通过自己的主机映射为代理服务。
　　Docker 实例
　　下面的实例将会通过Maven来构建，使用Docker为每一个微服务构建容器镜像。我们可以很优雅的使用Docker Compose在我们自己的主机上搭建全部的微服务集群。
　
　　

Spring Cloud 微服务实战

阅读《Spring微服务实战》笔记

项目地址： https://gitee.com/liaozb1996/spring-cloud-in-action

配置管理原则：

Spring Cloud Config 后端存储：文件系统、Git

标注引导类：

配置服务器配置：

创建配置文件：

访问配置：

客户端配置：

spring-cloud-config-client 依赖

boostrap.properties

刷新属性：

服务发现至关重要的原因：

传统服务位置解析（DNS+负载均衡器）的缺点：

服务发现实现组件：

构建 Eureka 服务：

标注引导类：

单机模式配置 ：

每次注册服务都需要等待30秒，因为 eureka 需要连续接收 3 个心跳包才能使用该服务。

缓存注册表后，客户端每隔30秒会重新到 eureka 刷新注册表。

服务注册：

解决多网卡问题：

通过API获取注册表信息：（设置请求头 Accept:application/json ）

http://localhost:8761/eureka/apps

http://localhost:8761/eureka/apps/organization

与 Ribbon 交互的客户端：

当使用二方包时需要在引导类添加 @EntityScan ：

配置 RestTemplate：

DiscoveryClient：

支持 Ribbon 的 RestTemplate：

Feign：

OpenFeign 依赖：

Feign 会在运行时动态生成代理对象：

远程调用包括对远程资源和远程服务的调用。

远程调用会遇到两个问题：

四种客户端弹性模式：

为什么客户端弹性模式很重要：

客户端弹性模式提供了三种构建能力：

在引导类启动断路器：

配置属性手册： https://github.com/Netflix/Hystrix/wiki/Configuration

使用 Hystrix 默认配置对远程调用进行管理：

超时配置： execution.isolation.thread.timeoutInMilliseconds

配置后备策略：后备方法必须在同一类中并且具有相同的方法签名

配置舱壁：

Hystrix 断路的策略：

Hystrix 有三个级别的配置：

类级别配置：

Hystrix 有两个隔离策略：

如果使用 TREAD 策略，并且要将父线程的上下文传递到子线程中，需要自定义 HystrixConcurrencyStrategy

Zuul 提供的功能：路由映射、构建过滤器

依赖：zuul、eureka-client

标注引导类：

zuul 配置：

?

Zuul路由映射机制：

查询路由： http://localhost:8080/actuator/routes

调用服务： http://localhost:8080/license/license/1 （第一个 license 是服务ID，/license/1 是请求路径）

使用服务发现手动映射路由：

添加前缀：

手动配置静态路由：前面都是基于 eureka 上的服务id进行路由映射的，而这里是直接配置URL

Git + http://localhost:8080/actuator/refresh （POST）

Zuul 使用 Hystrix 和 Ribbon

Zuul 支持三种过滤器类型：前置过滤器、后置过滤器、路由过滤器

前置过滤器：向通过网关的请求添加 tracking-id

这里使用了 Zuul 的 RequestContext：

Zuul 不允许直接修改请求头部，这里通过 addZuulRequestHeader 添加头部信息，在调用远程服务会自动合并

为了方便应用获取 tracking-id，这里使用 Filter 获取请求头信息并映射到 UserContext 中：

为了在服务间调用传播 tracking-id 这里需要定义一个 和 RestTemplate：

项目中 license 会远程调用 orgnization，这里需要在两个微服务配置 Filter

「SpringCloud」（三十八）搭建ELK日志采集与分析系统

?一套好的日志分析系统可以详细记录系统的运行情况，方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式，那么日志记录下来，相关人员就需要对日志数据进行处理与分析，基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。
??作为微服务集群，必须要考虑当微服务访问量暴增时的高并发场景，此时系统的日志数据同样是爆发式增长，我们需要通过消息队列做流量削峰处理，Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列，但其各项功能显示不如单一实现的消息队列，所以通常情况下并不使用它的消息队列功能；Kafka的性能要优于RabbitMQ，通常在日志采集，数据采集时使用较多，所以这里我们采用Kafka实现消息队列功能。 ??ELK日志分析系统中，数据传输、数据保存、数据展示、流量削峰功能都有了，还少一个组件，就是日志数据的采集，虽然log4j2可以将日志数据发送到Kafka，甚至可以将日志直接输入到Logstash，但是基于系统设计解耦的考虑，业务系统运行不会影响到日志分析系统，同时日志分析系统也不会影响到业务系统，所以，业务只需将日志记录下来，然后由日志分析系统去采集分析即可，Filebeat是ELK日志系统中常用的日志采集器，它是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。
软件下载：
??因经常遇到在内网搭建环境的问题，所以这里习惯使用下载软件包的方式进行安装，虽没有使用Yum、Docker等安装方便，但是可以对软件目录、配置信息等有更深的了解，在后续采用Yum、Docker等方式安装时，也能清楚安装了哪些东西，安装配置的文件是怎样的，即使出现问题，也可以快速的定位解决。
Elastic Stack全家桶下载主页： https://www.elastic.co/cn/downloads/
我们选择如下版本：
Kafka下载：
??安装前先准备好三台CentOS7服务器用于集群安装，这是IP地址为：172.16.20.220、172.16.20.221、172.16.20.222，然后将上面下载的软件包上传至三台服务器的/usr/local目录。因服务器资源有限，这里所有的软件都安装在这三台集群服务器上，在实际生产环境中，请根据业务需求设计规划进行安装。 ??在集群搭建时，如果能够编写shell安装脚本就会很方便，如果不能编写，就需要在每台服务器上执行安装命令，多数ssh客户端提供了多会话同时输入的功能，这里一些通用安装命令可以选择启用该功能。
新建/usr/local/java目录
将下载的jdk软件包jdk-8u64-linux-x64.tar.gz上传到/usr/local/java目录，然后解压
配置环境变量/etc/profile
在底部添加以下内容
使环境变量生效
备注：后续可通过此命令停止elasticsearch运行
??新建kafka的日志目录和zookeeper数据目录，因为这两项默认放在tmp目录，而tmp目录中内容会随重启而丢失,所以我们自定义以下目录:
修改如下：
在data文件夹中新建myid文件，myid文件的内容为1（一句话创建：echo 1 > myid）
kafka启动时先启动zookeeper，再启动kafka；关闭时相反，先关闭kafka，再关闭zookeeper。 1、zookeeper启动命令
后台运行启动命令：
或者
查看集群状态：
2、kafka启动命令
后台运行启动命令：
或者
3、创建topic，最新版本已经不需要使用zookeeper参数创建。
参数解释: 复制两份 　　--replication-factor 2 创建1个分区 　　--partitions 1 topic 名称 　　--topic test
4、查看已经存在的topic（三台设备都执行时可以看到）
5、启动生产者：
6、启动消费者：
添加参数 --from-beginning 从开始位置消费，不是从最新消息
7、测试：在生产者输入test，可以在消费者的两台服务器上看到同样的字符test，说明Kafka服务器集群已搭建成功。
Logstash没有提供集群安装方式，相互之间并没有交互，但是我们可以配置同属一个Kafka消费者组，来实现统一消息只消费一次的功能。
??Filebeat用于安装在业务软件运行服务器，收集业务产生的日志，并推送到我们配置的Kafka、Redis、RabbitMQ等消息中间件，或者直接保存到Elasticsearch，下面来讲解如何安装配置：
1、进入到/usr/local目录，执行解压命令
2、编辑配置filebeat.yml ??配置文件中默认是输出到elasticsearch，这里我们改为kafka，同文件目录下的filebeat.reference.yml文件是所有配置的实例，可以直接将kafka的配置复制到filebeat.yml
后台启动命令
停止命令
2、测试logstash是消费Kafka的日志主题，并将日志内容存入Elasticsearch
自动新增的两个index，规则是logstash中配置的
数据浏览页可以看到Elasticsearch中存储的日志数据内容，说明我们的配置已经生效。
Gitee: GitEgg: GitEgg 是一款开源免费的企业级微服务应用开发框架，旨在整合目前主流稳定的开源技术框架，集成常用的最佳项目解决方案，实现可直接使用的微服务快速开发框架。 GitHub: https://github.com/wmz1930/GitEgg

微服务框架之Spring Cloud简介

在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：

对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。
Spring Cloud 所提供的核心功能包含：
Spring Cloud架构图

Spring Cloud子项目
Spring Cloud 旗下的子项目大致可以分为两类：
如下：
1. Spring Cloud 与 Spring Boot
Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。
2. Spring Cloud 与服务治理( Eureka )
服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。
Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。
在 Eureka 的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。
3. Spring Cloud 与客户端负载均衡( Ribbon )
Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。
Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。
4. Spring Cloud 与微服务容错、降级( Hystrix )
为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。
Hystrix 是根据“断路器”模式而创建。当 Hystrix 监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。
而 Hystrix 的仪表盘项目（ Dashboard ）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。
5. Spring Cloud 与服务网关( Zuul )
Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务网关功能，提供对请求的路由和过滤两个功能
路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。
过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。
通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 服务器进行整合，自动从 Eureka 服务器中获取所有注册的服务并进行路由映射，实现 API 服务网关自动配置。
6. Spring Cloud 与消息中间件( Stream )
Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。
Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。
比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。
7. Spring Cloud 与分布式配置中心( Config )
针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言独立等特性。
在 Config 子项目中将微服务应用分为两种角色：配置服务器（ Config Server ）和配置客户端（ Config Client ）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。
8. Spring Cloud 与微服务链路追踪( Sleuth )
Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路追踪。
Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。
因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。
9. Spring Cloud 与微服务安全( Security )
Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。
Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。
10. Spring Cloud 的其他子项目

如何利用Spring Cloud构建起自我修复型分布式系统

　　利用Netflix所打造的组件及各类大家熟知的工具，我们完全可以顺利应对由微服务以及分布式计算所带来的技术挑战。
　　在过去一年当中，微服务已经成为软件架构领域一个炙手可热的新名词，而且我们也能轻松举出由其带来的诸多比较优势。然而，我们必须清醒意识到的
是，一旦开始遵循微服务思路而对现有架构体系进行拆分，就意味着我们将不可避免地进入分布式系统领域。在之前的文章中我们曾经探讨过分布式计算的八大认识
误区*，由此可见此类系统本身充满着风险，而且一旦犯下这八种错误中的任何一种、我们都将面对灾难性的后果。
　　在我个人看来，如果要将这些误区总结成一句观点，那就是：对于一套分布式系统来说，任何关于一致性或者可靠性的表达都毫无保障可言。我们需要假
定系统当中的各种行为以及组件位置始终处于不断变化状态。由此产生的后果主要有两点：组件有时候会导致糟糕的服务质量甚至令服务直接离线，我们则只能将其
统称为“故障”、而很难具体阐明到底是哪里出了问题。一旦没能得到妥善处理，此类故障将引中断与停机，这意味着系统将无法按照既定设计方案为用户提供服务
项目。
　　有鉴于此，为了享受微服务所带来的诸多优势(包括松散耦合、自治服务、分散化治理以及易于持续交付等等)，我们必须避免由单一故障依次递进而最
终导致系统崩溃的恐怖状况。关于这一点，Erlang语言之父Joe
Armstrong曾经在题为《如何构建永远运行、自我修复且可扩展的系统》一文中作出过透彻的表述。在他看来，此类系统看起来与我们所说的微服务架构非
常相近，但其着重强调的是其作为自我修复系统的容错能力。那么对我们来说，如何才能建立起这样一套坚实可靠的系统方案?
　　Netflix公司在微服务架构的实施与推动方面一直扮演着先行者的角色。作为其业务构建的原则性方针之一，Netflix公司认为系统方案必
须要能够承受任意组件的突发性故障，而整体系统仍能继续正常运转(这意味着我们仍然能够在该平台上观看电影，而Netflix也可以继续记录用户的观看喜
好)。在尝试建立这样一套系统时，我们遭遇到以下这些常见的技术挑战：
　　由于需要将系统拆分成多个分布式进程，我们要如何在保证一致性与可靠性的前提下将这些配置分发至这些进程当中?
　　当这些配置方案需要加以修改时，我们该如何在无需重新部署全部进程的前提下对配置内容进行更新?
　　在这样一套系统当中，特别是对于部署于云环境内的系统，各个进程不仅内容经常变动、所在位置亦会不断转换(特别是在进行故障转移的情况下)。我们要如何准确判断那些需要进行协同的进程的具体位置?
　　一旦我们检测到了当前进程关联性的几种可能位置，我们该如何选择接下来要进行通信的进程实例?
　　假设在选定一个进程实例并与该实例进行通信的过程当中该实例出现了故障，我们该如何防止由此引发的连锁故障?
　　在系统综合运作行为不断给自治服务带来演进拓扑结构的情况下，我们要如何对其状态保持可视化监控、从而作出有针对性的准确调整?
　　事实上，大家可以部署多种样板模式及开源工具来解决上述技术挑战。Netflix公司就构建出多种组件且加以开源，并在生产环境中进行了一系列
测试。从理论角度讲，我们能够利用这些工具来建立起有能力“永远运行、自我修复且实现规模化扩展”的系统。对刚刚着手建立分布式系统的朋友们来说，我们目
前的第一要务在于理解这些实现模式、掌握Netflix组件并加以应用，而后将这些组件部署、管理并集成至自己的系统当中。由于采取任何新的技术依赖关系
都会给软件工程方案带来前所未见的复杂性元素，因此我们建议大家最好直接采用Netflix的堆栈来尽可能减少此类潜在摩擦。
　　Spring工程技术团队从建立之初至今一直在努力打造出足以应对Java复杂性的强大武器。我们的早期关注重点在于消除J2EE给企业级应用
程序开发者带来的生产效率影响。而着眼于最近一段时间，我们的主要精力则转移到了实现云-本地应用程序构建身上，而且这方面的大部分工作成果都被纳入或者
围绕着Spring Cloud项目所展开。
　　Spring
Cloud项目的既定目标在于为Spring开发人员提供一整套易于使用的工具集，从而保证其轻松构建起自己需要的分布式系统方案。为了实现这一目
标，Spring Cloud以Netflix
OSS堆栈为基础将大量实现堆栈加以整合并打包。这些堆栈而后可以通过大家所熟知的各类基于注释的配置工具、Java配置工具以及基于模板的编程工具实现
交付。下面就让我们一起了解Spring Cloud当中的几类常见组件。
　　Spring Cloud Config Server
　　Spring Cloud Config
Server能够提供一项具备横向扩展能力的集中式配置服务。它所使用的数据被保存在一套可插拔库层当中，后者目前能够支持本地存储、Git以及
Subversion。通过利用一套版本控制系统作为配置存储方案，开发人员能够轻松实现版本与审计配置的内容调整。
　　
　　图一：Spring Cloud Config Server
　　配置内容会以Java属性或者YAML文件的形式体现。该Config
Server会将这些文件合并为环境对象，其中包含易于理解的Spring属性模型以及作为REST
API存在的配置文件。任何应用程序都能够直接调用该REST API当中所包含的配置数据，但我们也可以将智能客户端绑定方案添加到Spring
Boot应用程序当中，并由后者自动将接收自Config Server的配置信息分配至任意本地配置当中。
　　Spring Cloud Bus
　　Spring Cloud Config
Server是一套强大的配置分发机制，能够在保障一致性的前提下将配置内容分发到多个应用程序实例当中。然而根据其设计思路的限定，我们目前只能在应用
程序启动时对其配置进行更新。在向Git中的某一属性发送新值时，我们需要以手动方式重启每个应用程序进程，从而保证该值被切实纳入应用当中。很明显，大
家需要能够在无需重启的前提下完成对应用程序配置内容的更新工作。
　　
　　图二: 配备Spring Cloud Bus的Spring Cloud Config Server
　　Spring Cloud
Bus的任务正是为应用程序实例添加一套管理背板。它目前依靠将一套客户端绑定至一组AMQP交换与队列当中来实现，但这一后端在设计上也实现了可插拔特
性。Spring Cloud
Bus为我们的应用程序带来了更多管理端点。在图二中，我们可以看到一个面向greeting属性的值被发送至Git当中，而后一条请求被发送至应用A中
的/bus/refresh端点。该请求会触发以下三个事件：
　　应用A从Config Server处请求获取最新版本的配置内容。任意注明了@RefreshScope的Spring Bean都会被重新初始化并载入新的配置内容。
　　应用A向AMQP交换机制发送一条消息，表明其已经收到更新指示。
　　通过监听AMQP队列而被纳入Cloud Bus的应用B与应用C会获取到上述消息，并以与应用A同样的方式实现配置更新。
　　现在我们已经有能力在无需重启的情况下对应用程序配置进行更新了。
　　Spring Cloud Netflix
　　Spring Cloud Netflix针对多种Netflix组件提供打包方案，其中包括Eureka、Ribbon、Hystrix以及Zuul。接下来我将分别对它们作出讲解。
　　Eureka是一套弹性服务注册实现方案。其中服务注册属于服务发现模式的一种实现机制(如图三所示)。
　　
　　图三：利用服务注册实现服务发现
　　Spring Cloud
Netflix通过直接将spring-cloud-starter-eureka-server关联性添加到Spring
Boot应用程序、随后将该应用程序的配置类与@EnableEurekaServer相整合的方式病嵌入式Eureka服务器的部署工作。
　　应用程序能够通过添加spring-cloud-starter-eureka关联性并将其配置类与
@EnableDiscoveryClient相整合的方式加入到服务发现流程当中。通过整合，我们能够将经过配置的适合DiscoveryClient
实例注入至任意Spring
Bean内。在我们所列举的实例中，DiscoveryClient作为服务发现的一种抽象机制恰好可以通过Eureka实现，不过大家也可以将其与
Consul等其它备选堆栈相集成。DiscoveryClient能够通过服务的逻辑标识符提供位置信息(例如网络地址)以及其它与已注册至
Eureka的服务实例相关的元数据。
　　Eureka提供的负载均衡机制仅支持单循环条件。而Ribbon提供的客户端IPC库则更为精巧，其同时具备可配置负载均衡机制与故障容错能
力。Ribbon能够通过获取自Eureka服务器的动态服务器列表进行内容填充。Spring Cloud
Netflix通过将spring-cloud-starter-ribbon关联性添加至Spring
Boot应用程序的方式实现与Ribbon的集成。这套额外库允许用户将经过适当配置的LoadBalancerClient实例注入至Spring
Bean当中，从而实现客户端负载均衡(如图四所示)。
　　
　　图四：使用客户端负载均衡机制
　　在此类任务当中，我们可以利用Ribbon实现额外负载均衡算法，包括可用性过滤、加权响应时间以及可用域亲和等。
　　Spring Cloud Netflix还通过自动创建能够被注入至任意Spring
Bean的Ribbon强化型RestTemplate实例的方式进一步改进了Spring开发者的Ribbon使用方式。在此之后，开发人员能够轻松将
URL所提供的逻辑服务名称递交至RestTemplate：
　　@Autowired @LoadBalanced private RestTemplate restTemplate;
@RequestMapping("/") public String consume() { ProducerResponse response
= restTemplate.getForObject("http://producer", ProducerResponse.class);
return String.format("{\"value\": %s}", response.getValue()); }
　　Hystrix能够为断路器以及密闭闸门等分布式系统提供一套通用型故障容错实现模式。断路器通常会被作为一台状态机使用，具体如图五所示。
　　
　　图五：断路器状态机
　　断路器能够介于服务及其远程关联性之间。如果该电路处于闭合状态，则所有指向该关联性的调用通常将直接通过。如果某一调用失败，则故障将被计入
计数。而一旦失败次数达到可配置时间区间内的阈值，该电路将被跳闸至断开。在处于断开状态时，调用将不再被发往该关联，而由此产生的结果将可自行定制(包
括报告异常、返回虚假数据或者调用其它关联等等)。
　　该状态机会定期进入所谓“半开”状态，旨在检测关联性是否处于健康运作状态。在这种状态下，请求一般仍将继续得以通过。当请求成功通过时，该设备会重新回归闭合状态。而如果请求失败，则该设备会重新回归断开状态。
　　Spring
Cloud应用程序能够通过添加spring-cloud-starter-hystrix关联性并将其配置类与
@EnableCircuitBreaker相整合的方式利用Hystrix。在此之后，大家可以通过与@HystrixCommand整合的方式将断路
器机制纳入到任意Spring Bean方法内：
　　@HystrixCommand(fallbackMethod = "getProducerFallback") public
ProducerResponse getValue() { return
restTemplate.getForObject("http://producer", ProducerResponse.class); }
以上实例中指定了一个名为getProducerFallback的备用方法。当该断路器处于断开状态时，此方法将替代getValue接受调用：
private ProducerResponse getProducerFallback() { return new
ProducerResponse(42); }
　　除了实现状态机机制之外，Hystrix还能够提供来自各断路机制的重要遥测指标流，具体包括请求计量、响应时间直方图以及成功、失败与短路请求数量等(如图六所示)。
　　
　　图六：Hystrix仪表板
　　Zuul能够处理全部指向Netflix边缘服务的输入请求。它能够与Ribbon以及Hystrix等其它Netflix组件相结合，从而提供一个灵活且具有弹性的Netflix服务路由层。
　　Netflix公司在Zuul当中加载动态过滤机制，从而实现以下各项功能：
　　验证与安全保障: 识别面向各类资源的验证要求并拒绝那些与要求不符的请求。
　　审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。
　　动态路由: 以动态方式根据需要将请求路由至不同后端集群处。
　　压力测试: 逐渐增加指向集群的负载流量，从而计算性能水平。
　　负载分配: 为每一种负载类型分配对应容量，并弃用超出限定值的请求。
　　静态响应处理: 在边缘位置直接建立部分响应，从而避免其流入内部集群。
　　多区域弹性: 跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。
　　除此之外，Netflix公司还利用Zuul的功能通过金丝雀版本实现精确路由与压力测试。
　　Spring
Cloud已经建立起一套嵌入式Zuul代理机制，从而简化常见用例当中UI应用需要将调用代理至一项或者多项后端服务处的对应开发流程。这项功能对于要
求将用户界面代理至后端服务的用例而言极为便捷，其避免了管理CORS(即跨域资源共享)以及为全部后端进行独立验证等复杂流程。Zuul代理机制的一类
重要应用在于实现API网关模式(如图七所示)。
　　
　　图七：API网关模式
　　Spring Cloud对嵌入式Zuul代理进行了强化，从而使其能够自动实现文件上传处理。而与Spring Cloud
Security配合之后，其能够轻松实现OAuth2
SSO以及将令牌传递至下游服务等工作。Zuul利用Ribbon作为其客户端与全部出站请求的负载均衡机制。Ribbon的动态服务器列表内容通常由
Eureka负责填充，但Spring Cloud也能够通过其它来源填充该列表。Spring Cloud
Lattice项目就已经能够通过轮询Cloud Foundry Diego的Receptor API填充Ribbon的服务器列表。
　　跨入微服务领域的决定意味着我们将正式迎接分布式系统所带来的诸多挑战，而分布式系统绝不是那种能够“凑合使用”的方案。因此，我们必须假设系
统内各组件的行为及位置始终处于不断变化当中，甚至经常表现出不可预知状态。在今天的文章中，我们已经谈到了几种能够帮助大家解决此类挑战的现成模式，而
且这些模式已经在Netflix OSS与Spring
Cloud得到切实验证。我个人建议大家在着手建立理想中的“永远运行、自我修复且具备可扩展能力”的系统方案之前，首先对它们进行一番尝试与体验。
　　*备注：这八大误区分别为：
　　1.网络环境是可靠的
　　2.延迟水平为零
　　3.传输带宽是无限的
　　4.网络环境是安全的
　　5.拓扑结构不会变化
　　6.总会有管理员帮助解决问题
　　7.流量成本为零
　　8.网络内各组成部分拥有同质性
http://www.chinacloud.cn/show.aspx?id=20273&cid=12
利用Spring Cloud构建起自我修复型分布式系统：
Spring Cloud Config Server
Spring Cloud Config Server能够提供一项具备横向扩展能力的集中式配置服务。它所使用的数据被保存在一套可插拔库层当中，后者目前能够支持本地存储、Git以及Subversion。通过利用一套版本控制系统作为配置存储方案，开发人员能够轻松实现版本与审计配置的内容调整。
Spring Cloud Bus
Spring Cloud Config Server是一套强大的配置分发机制，能够在保障一致性的前提下将配置内容分发到多个应用程序实例当中。然而根据其设计思路的限定，我们目前只能在应用程序启动时对其配置进行更新。在向Git中的某一属性发送新值时，我们需要以手动方式重启每个应用程序进程，从而保证该值被切实纳入应用当中。很明显，大家需要能够在无需重启的前提下完成对应用程序配置内容的更新工作。
Spring Cloud Netflix
Spring Cloud Netflix针对多种Netflix组件提供打包方案，其中包括Eureka、Ribbon、Hystrix以及Zuul。接下来我将分别对它们作出讲解。
Eureka是一套弹性服务注册实现方案。其中服务注册属于服务发现模式的一种实现机制。

SpringCloud Alibaba 实战，来自尚硅谷电商项目理解

电商项目常见解决技术搭配方案：
SpringCloud Alibaba --nacos：注册中心
SpringCloud Alibaba --nacos：配置中心
SpringCloud --Ribbon：负载均衡
SpringCloud Alibaba --Sentinel：服务容错（限流、降级、熔断）
SpringCloud --Gateway：API网关（webflux编程模式）
SpringCloud --Sleuth（调用链监控）
SpringCloud Alibaba --Seata：分布式事务解决方案
作用：因为都会用到springcloud alibaba，所以将 放到公共服务中，统一管理版本
Nacos 文档地址： https://nacos.io/zh-cn/docs/quick-start.html
Nacos 下载地址：https://github.com/alibaba/nacos/releases
第一步：在需要注册到nacos的服务pom文件中添加相应的nacos依赖
作用：将我们的服务注册到注册中心中，同时也可以从注册中心中发现其他服务
第二步：将 Nacos 服务器地址配置添加到 /src/main/resources/application.properties 文件中，
给当前服务命名
第三步：使用@EnableDiscoveryClient 注解开启服务注册和发现
启动 Nacos 服务器
下载 Nacos Server下载页面
将下载的文件解压，进入nacos/bin文件夹()，并根据操作系统的实际情况
Linux/Unix/Mac , 执行 sh startup.sh -m standalone
Windows , 执行 cmd startup.cmd
查询服务
http://127.0.0.1:8848/nacos
用户名和密码默认都是nacos
如：member会员服务需要调用coupon优惠券服务的方法
1.在member服务和coupon服务的pom文件中引入feign依赖
2.开启feign功能，在member服务上开启
@FeignClient("gulimall-coupon")：其中gulimall-coupon为nacos注册的被调用的服务名，@RequestMapping("/coupon/coupon/member/list")路径为gulimall-coupon服务中membercoupons()方法的调用全路径（添加上controller上的请求路径）
对应的在gulimall-coupon服务中有membercoupons()方法的具体实现
第一步：引入 Nacos Config 进行配置管理
第二步：在需要管理配置的服务下，添加bootstrap.properties
第三步：需要给配置中心添加数据集（Data Id）gulimall-coupon.properties
第四步：给 应用名.properties 添加任何配置
第五步：在需要读取配置的类上添加注解@RefreshScope，实时刷新获取配置文件内容
@RefreshScope：动态获取并刷新配置
@Value("${配置项的名}")
细节部分：
1.命名空间：主要用来做配置隔离
默认是public(保留空间)；默认新增的所有配置都在public空间
a：开发、测试、生产：利用命名空间来做环境隔离
b：每一个微服务之间互相隔离配置，每一个微服务都创建自己的命名空间，只加载自己命名空间下的所有配置
2.配置集
一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配
置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级
别等配置项。
3.配置集ID
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组
织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有
意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名
规则保证全局唯一性。此命名规则非强制。
4.配置组
Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或
Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个
配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置
分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置好
MQ_topic 配置。
加载多配置文件:
官方文档：https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D
项目地址：https://github.com/alibaba/Sentinel
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，
从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
什么是熔断降级
除了流量控制以外，降低调用链路中的不稳定资源也是关键 Sentinel 的使命之一。由于调用关系的复杂性，如果调用链路中的某个资源出现了不稳定，最终会导致请求发生堆积。
Sentinel 和 Hystrix 的原则是一致的: 当检测到调用链路中某个资源出现不稳定的表现，例如
如请求响应时间长或异常比例升高的时候，则对这个资源的调用进行限制，让请求快速失败，
避免影响到其它的资源而导致级联故障。
熔断降级设计理念
在限制的手段上，Sentinel 和 Hystrix 采取了完全不一样的方法。
Hystrix 通过 线程池隔离 的方式，来对依赖（在 Sentinel 的概念中对应 资源）进行了隔
离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成
本（过多的线程池导致线程数目过多），还需要预先给各个资源做线程池大小的分配。
Sentinel 对这个问题采取了两种手段
a.通过并发线程数进行限制
b.通过响应时间对资源进行降级
步骤：
1、引入依赖
2、使用 Nacos 注册中心
3、定义 fallback 实现
在服务消费者中，实现 feign 远程接口，接口的实现方法即为调用错误的容错方法
4、定义 fallbackfactory 并放在容器中
5、改造 fallback 类接受异常并实现容错方法
6、远程接口配置 feign 客户端容错
7、开启 sentinel 代理 feign 功能；在 application.properties 中配置
测试熔断效果。当远程服务出现问题，会自动调用回调方法返回默认数据。