目录
2.2 为什么集成 Nacos 必须用到 bootstrap 配置文件
平时的开发中,你的配置信息是放到哪里的呢?在 Spring Boot 应用中,我们习惯于使用传统的配置管理方式,将各种配置项都维护在 application.yml 或 application.properties 文件中。从完成业务逻辑的角度来看,这样做是没问题的。但在微服务架构中,我们可以采取一种更“优雅”的方式组织配置文件,实现高效灵活的配置管理。
我们通常可以采用4种方式来指定配置,分别是硬编码、配置文件、环境 / 启动变量、数据库动态获取,我们来了解下这四种配置管理方式是如何实现的。
- 硬编码:最简单粗暴的方式,在 Bean 初始化的上下文中,直接通过在代码中 hardcode 的方式指定配置信息;
- 配置文件:使用 application 和 bootstrap 配置文件来设置配置项,这是目前比较“优雅”常用的方式;
- 环境 / 启动变量:通过操作系统的环境变量,或者启动命令中的 -D 参数传入配置项;
- 数据库 / 缓存动态获取:将配置项保存在数据库里,每次执行一个 select 语句实现动态查询。
从职责分离的角度来讲,硬编码无法将“业务逻辑”与“配置管理”拆分开来。
从灵活性的角度来讲,无论用的是硬编码、配置文件还是环境 / 启动变量的方式,只要需要对配置项进行变更,就必须对代码 / 启动命令进行修改,然后重新打包并部署应用,无法做到在运行期灵活变更配置项。
数据库 / 缓存动态获取的方式和上面几种相比,具备了一定的灵活性。但从版本控制的角度来看,配置项也是一种“代码资源”,采用数据库 / 缓存控制并不能很好地实现配置版本的控制和历史版本回滚。而面对高并发场景时,如果我们采用数据库方案,还要时刻关注 DB 的性能指标,以免被流量打崩。
今天来讲解微服务的配置中心,再来看下微服务的组件图,主要讲解 Nacos,包括集成案例、一致性协议、动态配置实现等内容。
一、分布式配置中心
在微服务架构中,我们会使用一个中心化的分布式配置中心作为配置文件的管理者。
在应用程序端,我们只将一些必要的配置项添加到配置文件中,而大部分的配置项都保存在配置中心集群里。客户端在启动的时候从配置中心获取所有的配置项,用于各个组件的初始化。
分布式配置中心具有如下特性
- 高可用性:微服务组件的高可用性是首要目标。配置中心并不是一个中心化的单点应用,而是通过一个集群对外提供服务,在一致性算法的基础上,集群中各节点间相互同步数据。即便有节点挂掉,配置中心仍然能对外提供服务。
- 环境隔离:Nacos 支持通过 Namespace 属性指定环境,将各个环境进行隔离。
- 多格式支持:Nacos 支持多种文件格式,包括JSON、XML、YAML、Proterties、Text多种文件格式。
- 访问控制:Nacos 实现了权限管理,可以再控制台创建不同的账户,然后分配不同的权限(读写、只读),通过这种方式来保护敏感信息。
- 职责分离:配置项从代码中分离出来,修改配置无需修改代码打包部署,完全实现了代码与配置隔离。
- 版本控制与审计:配置项也是一种代码,而且配置 bug 往往比代码中的 bug 造成的影响更大。因此在微服务架构中需要确保配置中心具备完善的版本控制和审计功能。