服务器地址 19216856150
redis 安装目录在 /root/redis-505目录中，修改配置文件redisconf
配置完成启动redis服务
设置完成，重启配置中心服务
-在order项目工程中，新建一个接口类如：
访问接口 >最近有项目组同学问到为什么自己配置了nacos，但配置不生效？我简单看了下，发现问题出在相关配置的优先级模式不同。
spring-boot项目，有bootstrap、application两个配置文件，结合profile，和支持的文件格式properties、yaml，已经有6个配置文件了。然后使用了spring-cloud-starter-alibaba-nacos-config 后，又提供了三级配置。这些配置之间的组合关系，将在无形中影响配置的效果。很多同学只知道其中的一种，因此在无意识引入两种或以上的配置后，就会发现有奇怪的配置不生效问题发生。
spring-boot项目依赖bootstrapyml 用于应用程序上下文的引导阶段，由父Spring ApplicationContext加载，其工作的阶段为父ApplicationContext 被加载到使用applicationyml的之前。也就是说 bootstrap 加载优先于 applicaton。
bootstrap 主要用于从额外的资源来加载配置信息，还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境，它是任何Spring应用程序的外部属性的来源。bootstrap 里面的属性会优先加载，它们默认也不能被本地相同配置覆盖。
bootstrap 配置文件有以下几个应用场景：
由于spring-boot支持多种文件格式，所以多种格式之间，其优先级是平等的，只要找到了一个，就会被使用。一般有：properties、yaml、xml等格式。
应用级别的spring-boot配置文件，主要用于 Spring Boot 项目的自动化配置，其加载优先级低于bootstrapyaml。
nacos作为外部配置服务器，通过spring-boot的bootstrapyaml引入。但nacos本身，也提供了三级配置体系：主配置(只有一个，但会按照不同后缀名，去找到相关配置）、扩展配置、共享配置。
三级配置的优先级如下：主配置 > 扩展配置 > 共享配置
nacos提供的配置路径 springcloudnacosconfig 下，有一系列的属性用于定位主配置。基于 prefix（默认为 ${springapplicationname} 的值）、namespace、group（默认为字符串 DEFAULT_GROUP ）、file-extension（默认为字符串 properties ），按组装规则 ${prefix}-${springprofilesactive}${file-extension} 去找到一个配置。
在nacos的所有配置中，主配置（存在的情况下）具有最高的优先级，其同名配置值不能被扩展配置或共享配置中定义的同名属性所覆盖。
上述两类配置都支持三个属性： data-id 、 group （默认为字符串 DEFAULT_GROUP ）、 refresh （默认为 true ）。
实际上，nacos中并未对 extension-configs 和 shared-configs 的差别进行详细阐述。我们从他们的结构，看不出本质差别；除了优先级不同以外，也没有其他差别。那么，nacos项目组为什么要引入两个类似的配置呢我们可以从当初 该功能的需求（issue） 上找到其原始目的。
摘要其核心内容如下：
Spring Cloud是一系列框架的有序集合（框架集），他利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署。
SpringCloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
下面是Spring Cloud的整体架构图：
注册中心可以说是微服务架构中的“通讯录”，他记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到对应服务的地址，进行调用。
注册中心的主要作用
Ribbon是Netflix发布的一个负载均衡，有助于控制>1 Linux 服务器安装宝塔面板
2使用ssh root@ip 的方式远程连接
3安装Docker ,参考: >1、SpringCloud开发，本地启动多个微服务系统开销大
2、同事A启动User服务，同事B也在本地启动User服务。那么两个服务都注册到Nacos上，前端同事调试访问A的User服务，很容易出现访问到同事B启动的User服务（导致开发混乱，无法debug到自己的服务），还要考虑到如果有同事在本地debug服务，也会影响到别的同事。
1、在公共机器上启动Nacos服务，MySQL，Redis等公共服务，共同使用即可减少本地开销
2、同事A，同事B，都在本地启动Gateway服务，使用公共机器的Nacos服务（例如10218126:8848）本地 gateway的配置一定要配置ribbon 。因为负载均衡，会导致同事A想要访问自己本地启动的User服务，却访问到了同事B启动的User服务，又或者服务器上的User服务（这样无法开发）所以一定要做一些规则，负载均衡本地优先的规则。
效果： 只需要本地启动gateway和User服务。由于给gateway里的ribbon配置了优先本地，会先去调用本地的User服务，而不是公共机器或者其他同事的。（就算Feign调用，也是走网关，只要走了本地的网关，就是优先本地）
原理：
Gateway要获取Nacos下发的ip地址和服务名，做动态路由。
Gateway要集成ribbon，做负载均衡。
ribbon还得配置本地优先策略，以免服务冲突。
ip地址要在同一网段，否则无法通讯。
0 放前面
01 参考文档
02 maven配置
orgspringframeworkboot
spring-boot-starter-parent
152RELEASE
orgspringframeworkcloud
spring-cloud-dependencies
DalstonRELEASE
pom
import
orgspringframeworkcloud
spring-cloud-starter-config
orgspringframeworkcloud
spring-cloud-starter-eureka
03 简介
Spring Cloud发员提供快速构建布式系统些通用模式（例配置管理服务发现断路器智能路由微代理控制总线性令牌全局锁领导选举布式 群集状态） 布式系统协调引板模式（boiler plate patterns）并且使用Spring Cloud发员快速实现些模式启服务应用程序 任何布式环境工作包括发员自笔记本电脑裸机数据受管平台Cloud Foundry
Version: BrixtonSR7
1 特征
Spring Cloud专注于经典用例扩展机制提供良箱即用
布式/版本配置
服务注册与发现
路由选择
服务调用
负载均衡
熔断机制
全局锁
领导选举集群状态
布式消息
2 原云应用程序
原云应用程序发种风格鼓励持续交付价值驱领域佳实践
Spring Cloud特性基于Spring Boot更由两库实现：Spring Cloud Context and Spring Cloud Commons
21 Spring Cloud Context: 应用文服务
Spring Boot关于使用Spring构建应用硬性规定：通用配置文件固定位置通用管理终端监控任务建立基础Spring Cloud增加些额外特性
211 引导应用程序文
Spring Cloud创建bootstrap文主应用程序父文应配置文件拥高优先级并且默认能本配置文件覆盖应文件名bootstrapyml或bootstrapproperties
通设置springcloudbootstrapenabled=false禁止bootstrap进程
212 应用文层级结构
用SpringApplication或SpringApplicationBuilder创建应用程序文bootstrap文作父文添加进文继承父文属性
文配置信息覆盖父文配置信息
213 修改Bootstrap配置文件位置
springcloudbootstrapname（默认bootstrap）或者springcloudbootstraplocation（默认空）
214 覆盖远程配置文件值
springcloudconfigallowOverride=true
springcloudconfigoverrideNone=true
springcloudconfigoverrideSystemProperties=false
215 定制Bootstrap配置
/META-INF/springfactorieskeyorgspringframeworkcloudbootstrapBootstrapConfiguration定义Bootstrap启组件
主应用程序启前始Bootstrap文创建springfactories文件组件@Beans类型bean
216 定制Bootstrap属性源
关键点：springfactories、PropertySourceLocator
217 环境改变
应用程序通EnvironmentChangedEvent监听应用程序并做响应
218 Refresh Scope
Springbean@RefreshScope做特殊处理用于刷新bean配置信息
注意
需要添加依赖orgspringframeworkbootspring-boot-starter-actuator
目前我@Controller测试功
需要自发送POST请求/refresh
修改配置文件即
219 加密解密
Spring Cloud配置文件值进行加密
"Illegal key size"异需要安装JCE
2110 服务点
除Spring Boot提供服务点Spring Cloud提供些服务点用于管理注意都POST请求
/env：更新Environment、重新绑定@ConfigurationProperties跟志级别
/refresh重新加载配置文件刷新标记@RefreshScopebean
/restart重启应用默认用
命周期：/pause、/resume
22 Spring Cloud Commons:通用抽象
服务发现、负载均衡、熔断机制种模式Spring Cloud客户端提供通用抽象层
221 RestTemplate作负载均衡客户端
通@Bean跟@LoadBalanced指定RestTemplate注意URI需要使用虚拟域名（服务名能用域名）
：
@Configuration
public class MyConfiguration {
@LoadBalanced
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
public String doOtherStuff() {
String results = restTemplategetForObject("", Stringclass);
return results;
}
}
222 RestTemplate象
注意@Primary注解使用
@Configuration
public class MyConfiguration {
@LoadBalanced
@Bean
RestTemplate loadBalanced() {
return new RestTemplate();
}
@Primary
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
@Autowired
@LoadBalanced
private RestTemplate loadBalanced;
public String doOtherStuff() {
return loadBalancedgetForObject("", Stringclass);
}
public String doStuff() {
return restTemplategetForObject("", Stringclass);
}
}
223 忽略网络接口
忽略确定名字服务发现注册支持则表达式配置
3 Spring Cloud Config
Spring Cloud Config提供服务端客户端布式系统扩展配置支持同环境配置（发、测试、产）使用Git做默认配置端支持配置环境打版本标签
31 快速始
通IDE运行或maven运行
默认加载property资源策略克隆git仓库(at springcloudconfigservergituri')
>Ribbon是客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用
负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个 *** 作单元上进行运行,从而协同完成工作任务。 负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性
本文主要测试，在Springcloud + nacos + gateway基础上，如何实现负载平衡
前面我们已经整合了Springcloud + nacos + gateway，实现了，当启动3个provider时候，通过gateway,可以对该3个provider进行轮询
1 nocas负载均衡。
a nocas本身已集成了ribbon，默认使用轮询的方式
b 在nocas设置weight,实现权重的方式
c 自定rule(IRule实现类)
d 顺提，在权重的方式下，可使用先设置权重为0，再关闭单一服务的方式，优雅地下线服务
2 使用ribbon直连ip
a 使用ribbon提供的自动策略，轮询，随机等
b 健康检查
v 自定义rule
关掉其中一个provider，立即通过gateway进行轮询，发现gateway仍然会call已经down掉的provider，导致查询失败。但在大约5秒后，轮询恢复正常，不再call已经prodiver
gateway call provider首先经nacos注册中心，nacos心跳机制默认每5秒钟检查一次provider是否正常，因此就会出现上面现象。
1 在启动类，将配置类 将IRule 的实现类注册到spring容器中即可
2 分别测试轮询和随机，可正常按规则负载
1 增加gatewayriboonip模块
2 pom添加依赖spring-cloud-starter-gateway和spring-cloud-starter-netflix-ribbon
3 修改applicationyml，设置负载均衡
4 启动，测试可正常进行轮询
5 修改applicationyml 如下，可测试到从轮询方式变成了随机的方式
NFLoadBalancerRuleClassName: comnetflixloadbalancerRandomRule
这个时候down掉一个provider，然后轮询，到这个provider时候，会一直查询失败。我们需要增加一个健康检查处理，在服务down掉的时候，可感知到并将该服务从服务列表去除，在服务上线后，可检查到服务已上线
1 增加健康检查
provider模块增加rest接口HealthController
增加config类，产生RestTemplate
增加健康检查类HealthExamination implements IPing。继承IPing接口，判断服务是否可用。我们在微服务中增加heath接口，在gateway中调用该接口，如果返回正常则认为微服务可用。
修改applicationyml 增加Ping如下
NFLoadBalancerPingClassName: comroyspringnacosgatewayribboniploadBalanceHealthExamination
2 重启provider和gateway，进行测试
a 轮询成功
b down掉其中一个provider，轮询到该provider时候，查询失败
这里测试未能成功，使用RoundRobinRule还是一直出现查询失败，未能自动skip掉down掉的provider
但是自定义LoadBalancerRule的话，是能够成功skip掉down掉的provide的
1 增加MyRule extends AbstractLoadBalancerRule
2 重启后，测试成功按规则查询
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）