Apollo配置中心的安装_Apollo配置中心api

1.k8s cronjob 启动顺序

2.nacos简介以及作为注册/配置中心与Eureka、apollo的选型比较

3.spring读取配置文件的方式(spring如何读取配置文件)

因为新公司没有用独立的配置中心,每次修改配置参数只能通过手动修改配置文件的方式,然后再重启重启重启,而且机器又是多台,这种方式无疑是非常低下的,而且极容易出错,所以才有了下面的配置中心选型。

其实自己开发一个简单的配置中心也是非常容易的,基于redis+DB就能简单实现。但是要设计一个合格的配置中心还需要考虑如下几点:

所以要自己开发一个独立的配置中心,还是要考虑得比较全面的。而且项目还是以业务为主,也没有足够人力来重新开发一套配置中心,所以就打算借助于开源的力量来满足目前的使用场景。

因为现在的配置中心还是有一些开源实现的。像百度的Disconf,阿里的Diamond,携程的Apollo,还有基于Github的pull模式来实现。我为什么选择Disconf,主要有下面几个点的考量:

Disconf是百度的一个分布式配置中心,目前已经开源。而且它是基于ja实现的,有简单的配置页面，而且官方还提供了一个相对完善的 文档 .开发者只需按照它上面的步骤来即可安装,但是的安装文档比较扯淡,总结起来就是如下几点:

然后启动Nginx.

Disconf主要是依靠zookeeper的Watch机制来做配置实时修改的,我们都知道ZK是通过目录挂载的方式来做服务的自动注册与发布。客户端启动时注册了一个回调接口,当zk目录发生变化时会回调所有客户端节点,从而做到"实时"更新配置的目的。

在配置中心添加的配置数据都被持久化到了DB中,每次客户端启动的时候会调用Disconf的Http接口获取最新的配置数据,如果网络不通,默认会重试三次,如果还不通,则抛出异常。如果第一次拉取配置就有问题,作为配置中心来讲是肯定是无解的,需要客户端去解决（一般这种情况是网络问题或者配置中心服务不可用导致）。

我们这里不需要考虑第一次加载配置就失败的情况.那么问题来了：

答案:不会,因为disconf会单独起一个线程做重连操作。

答案:没有做这方面的保证。因为客户端连接到配置中心上以后会将机器名挂载到zk目录下,可以通过界面查看配置使用的机器数。

所以要使用一个开源产品,还是要尽可能的掌握它,如果有太多未知因素在里面的话,出了问题很难被发现,对自己也是一个提升。

k8s cronjob 启动顺序

spring boot 应用以容器的方式运行在 k8s 集群上面是非常方便的，但是不同的环境需要不同的配置文件，我们可以使用外部的配置中心，比如 nacos 、 apollo 。 k8s 也提供了 configMap 用来将环境配置信息和容器镜像解耦，便于应用配置的修改。本文主要从以下几个方面介绍 spring boot 使用 k8s 的 configMap 作为外部配置的使用方法：

当应用程序启动时，Spring Boot 会自动从以下位置查找并加载 lication.properties 和 lication.yaml 文件。

配置文件优先级从高到底的顺序如下：

高优先级配置会覆盖低优先级配置

如果我们运行时想指定运行哪个环境的配置文件，可以有三种方式：

ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时 pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。

创建 configMap 的几种方式：

从前面的介绍我们可以知道，spring boot 加载配置文件的最高优先级是 项目根路径下的 /config 子目录 ，所以可以将 configMap 中的配置文件挂载到容器中的项目根路径下的 config 子目录中。

当卷中使用的 configMap 被更新时，所投射的键最终也会被更新。 kubelet 组件会在每次周期性同步时检查所挂载的 configMap 是否为最新。 不过，kubelet 使用的是其本地的高速缓存来获得 configMap 的当前值。 高速缓存的类型可以通过 KubeletConfiguration 结构 的 ConfigMapAndSecretChangeDetectionStrategy 字段来配置。

configMap 既可以通过 watch 操作实现内容传播（默认形式），也可实现基于 TTL 的缓存，还可以直接经过所有请求重定向到 API 服务器。 因此，从 configMap 被更新的那一刻算起，到新的主键被投射到 Pod 中去，这一 时间跨度可能与 kubelet 的同步周期加上高速缓存的传播延迟相等。 这里的传播延迟取决于所选的高速缓存类型 （分别对应 watch 操作的传播延迟、高速缓存的 TTL 时长或者 0）。

以环境变量方式使用的 configMap 数据不会被自动更新，更新这些数据需要重新启动 Pod。

参考文档：

k8s

spring boot

nacos简介以及作为注册/配置中心与Eureka、apollo的选型比较

k8s cronjob 启动顺序如下：

在K8S部署中，有时候容器启动顺序因为我们业务需要是有要求的，比如业务服务可能需要在 配置中心、注册的中心 启动后才启动。

通过 initContainer 来阻塞启动，如下以业务服务需要在apollo配置中心启动后才启动需求为例：

my-namespace为配置中心所在命名空间的名称。svc.cluster.local为固定写法。6166为我的配置中心的端口号。

/info为配置中心启动后可以正常访问的一个URL地址，这个根据你自己实际需求填写，比如 /actuator/metrics 等等。

spring读取配置文件的方式(spring如何读取配置文件)

Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。

Nacos主要提供以下四大功能：

Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。

nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面 的一些投入（比如通过动态配置来启停线程池等操作）。

初步结论为：使用Nacos代替Eureka和apollo，主要理由为：

相比与Eureka：

(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。

(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护

(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 实现 Service Mesh，是未来微服务的趋势

(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。

(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo

(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。

(2) apollo容器化较困难，Nacos有的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则

(3)性能方面，Nacos读写tps比apollo稍强一些

结论：使用Nacos代替Eureka和apollo

系统模块架构

Nacos提供DNS-F功能

DNS-F落地的技术价值

阿里巴巴、虎牙直播、中国工商银行、爱奇艺、中国平安、平安科技、浙江农信、贝壳、丰巢、百世快递、汽车之家等

完整列表： s://github/alibaba/nacos/issues/273

springboot中获取apollo或者nacos里的配置文件

nacos在springboot启动的时候已经把所有配置文件都注入到了spring里。

此时，需要在bootstrap.yml中添加springcloud配置：（至于为什么是bootstrap.yml而不是lication.yml，这又是另一个问题了）有了上面的配置，程序启动后，就能正常的从nacos配置中心获取配置了。

在lication.yaml配置文件中指定nacos中配置的DataID不会生效，需要通过注解@NacosPropertySource指定才能生效。

nacos-config这个依赖就相当于SpringCloudConfig，nacos-discovery这个依赖就相当于Eureka。

共享配置-扩展配置-当前应用配置，当后面加载有相同配置的时候，直接覆盖之前的配置。共享跟扩展设置值set的方法已经废弃不用了。

NacosConfigBootstrapConfiguration是@BootstrapConfiguration的配置类，在bootstrap的SpringApplication创建的过程中，会加载这个类。这个Configuration类包括两个Bean，分别是NacosConfigManager，NacosPropertySourceLocator。

springboot配置文件读取

1、nacos在springboot启动的时候已经把所有配置文件都注入到了spring里。

2、idea中，为了我们本地方便开发测试，我们在此处创建一个config目录，然后把lication.properties放进去，项目正常运行。jar包会自动生成在target目录下。

3、则只会根据classloader的classpath列表，选取第一个出现的文件。因为springboot加载配置文件时最底层是使用的下面的方法：这两个方法只会获取classloader类的ucp属性里面第一个匹配到的值。

Spring加载配置文件的方式

1、首先手动加载Spring配置文件有两个类，分别是ClassPathXmlApplicationFileSystemXmlApplicationContext；两个类的区别。然后就是“classpath：”是可以缺省的。

2、首先，Spring加载配置文件是在refresh#oainFreshBeanFactory方法中进行的。逻辑是在loadBeanDefinitions方法中进行的，Spring对loadBeanDefinitions方法做了很多重载。

3、更新方案：在springboot启动时，先从远端获取配置文件，并将其加载进Environment对象中，其余的，就都交给Spring了。

4、编写配置类，使用@Configuration注解，并使用@ImportResource注解指定需要扫描的配置文件，这样他就能自动加入SpringContext。这样，就能将配置文件加载到全局的Context，将ProdcuctBean交给Spring去管理。

Ja中spring读取配置文件的几种方法

常见的读取配置的方式有三种：第@Value注解，比较常用的一种方式。

BeanFactory允许InputStream作为构造函数的参数，也可以org.springframework.core.io.Resource接口。

ja读取配置文件的几种方法如下：方式一：用ServletContext读取，读取配置文件的realpath，然后通过文件流读取出来。

注释注入（Annotation-basedInjection）是通过Ja5的注解来代替XML配置文件，在Ja类中添加相应的注解，Spring将会读取该注解并注入到相应的Bean中。

配置文件SpringBoot使用一个全局的配置文件lication.propertieslication.yml配置文件的作用：修改SpringBoot自动配置的默认值，SpringBoot在底层都给我们自动配置好。

通过spring的databinding机制将request请求中的参数自动转换为对应的jabean实例。对command或formobjects值的校验结果。此参数必须紧跟在需校验的command或formobject参数后面。