设计的网站,建立什么船籍港,苏州网站优化,一级页面的网站怎么做的中间件middleware 内容管理 why use 配置中心配置中心feature配置中心develop主流配置中心Apollo浅谈 本文从理论上介绍一下服务化中服务治理系统中的配置中心的理论并浅析Apllo 配置在生产中是很关键的一个部分#xff0c;cfeng在work中遇到几次配置问题引发的问题#xff0…中间件middleware 内容管理 why use 配置中心配置中心feature配置中心develop主流配置中心Apollo浅谈 本文从理论上介绍一下服务化中服务治理系统中的配置中心的理论并浅析Apllo 配置在生产中是很关键的一个部分cfeng在work中遇到几次配置问题引发的问题如果没有一个方便快捷的配置修改方案那么不利于产品的快速迭代。 why use 配置中心
配置分离是一个基本的过程把开关写在代码里面是非常低级的行为。we接触SpringBoot的时候经常将配置写在yml文件中但是文件打包发布之后你如果再修改yml内容那么就需要再次部署。 可以直接在yml中利用${XXX}的方式将参数设置为变量进行管理不管是在K8s中配置还是在Potainer中配置都比较快捷 这就是配置管理的重要性。
配置Configuration是独立于程序的变量 首先就是配置独立程序不同的配置程序会有不同的行为。 常见的配置包括: DB Connection、 Thread Pool、 内存Buffer size… ② 配置贯穿应用的整个生命周期程序启动时读取配置进行初始化运行时根据配置进行行为的调整 ③配置有多种加载方式 常见的就是程序内部硬编码配置文件以及环境变量、启动参数、基于DB…
服务化架构下一个产品可能由多个不同的子系统组成产品性能的保证依靠所有子系统组成整体的配置的良好管理。 配置中心就是统一管理项目中所有配置的系统。
没有配置中心之前的配置管理
小的单体项目之前经常是静态化配置 项目中存在单独的配置文件比如log.properties、yml等但是正如所说参数修改不灵活有的甚至需要重启项目才行配置文件区分环境需要手动编写多个文件比如application.yml, application_test.yml, application_dev.yml手动维护可能会因为误操作导致一些问题 同时多个文件会显得非常分散不易管理配置修改不能追溯 也就是修改是没有记录的不会记录历史操作记录那么都不能进行配置回滚非常麻烦
上面几个痛点的解决就是配置中心
那么一个配置中心需要具有哪些特性来改善
1. 权限控制 因为配置会影响程序的行为配置修改属于敏感操作需要进行控制
2. 不同环境、集群配置管理 同一个程序不同环境、不同的集群对应不同的配置需要完善管理
3.兼容框架类组件配置管理 框架类组件配置如CAT客户端配置框架是产品的一部分这些配置作为产品配置一部分也需要管理起来
...配置中心feature
配置中心最基本支持的功能就应该是配置的CRUD 除了基本的配置治理需求之外对于分布式架构配置中心还需要具备一下特点
高可用
服务化系统需要考虑高可用问题配置是逻辑中非常重要的部分很大程度决定程序的行为为避免无法预期的结果会直接报错所以配置很关键需要保证HA
配置热发布
大多数场景下应用程序的重新发布重启代表业务中断这个会影响产品使用很多时候的版本迭代可能只是涉及到配置的修改这个时候如果能够支持热发布【程序运行时更新配置】那么就可以消除上述影响
不同环境、集群配置管理
公司一般会涉及到不同的环境比如开发、SIT、UAT、生产…以及不同的集群不同地域的机房…)如果手动的复制不同环境的配置文件会极大增加错误的风险 那么配置中心如果能够设置规则并且复制相关的相同的配置… 可以提高效率
权限管理操作审核
一些关键的配置会严重影响产品的使用对于一些配置的修改应该管控起来配置的更改应该具有一定的资质权限每次配置的修改都应该留存记录并且应当让产品的高权限者进行审核以此确保产品的正常发布
灰度发布
配置的重要性不言而喻cfeng之前work一般发布的时候都会有灰度验证步骤这是增加了一次试错机会。配置中心需要支持将配置应用到部分实例上 这样we可以观察配置在这些实例上生效之后的效果如果符合预期监控系统没有报错那么就可以将其应用到所有实例上
版本管理
配置中心的配置的每次修改都应该有记录并且配置记录具有版本的概念不同版本的发布应该对应不同的版本。以此支持版本回滚操作
监控多语言支持
配置中心应该具备监控功能这样才能更加保证配置中心的可靠性。配置中心对接的是不同的产品系统服务端代码当然是配置中心本身决定但是客户端耦合时需要支持多种语言支持方便不同语言编写的系统的接入一些产品可能go实现、java实现、C实现…
配置中心develop
随着业务的不断发展架构在不断变化各种新兴业务的接入配置中心也需要考虑新的困难。
容器化、Serverless、云原生
云原生架构当下是比较热门的cfeng 之前work中就是这种架构这种架构会要求无状态的应用程序不要依赖磁盘而是将数据放到有状态的系统上like 分布式存储系统和DB… 需要考虑在没有磁盘缓存的场景下如何保证配置中心的可用性…
并且在没有磁盘缓存的情况下如果需要扩容 ----- 将应用部署到新的机器上没有磁盘缓存如果配置中心服务端连接断开,怎么处理…
写配置HA
大多数场景都会实现配置中心的读配置的高可用因为配置变动非常低频【如果发生异常配置中心无法读取到新的配置原有的配置也是继续运行的不会导致服务中断】
但是写配置HA也需要保证 eg某个机房大量断电导致某个核心应用不能正常运行它依赖的一些其他的应用也不能运行短时间难以恢复。 那么这个时候的解决办法可能是应用负责人登录配置中心尝试更改配置切换URL部署到其他的机房机器上。 但是如果没有写配置HA那么这个时候写配置会提示DB错误不能正常修改无法达到效果
如何实现写配置HA也是需要考虑的一个问题…
敏感配置
敏感的配置信息比如数据库的数据源、账号密码不适合缓存在本地那么这些敏感数据在配置中心中应该如何正确的进行治理也是需要仔细考虑的一个问题…
主流配置中心
目前市面上流通的配置中心包括baidu开源的Disconf、 Spring Cloud生态中的Spring Cloud Config、 ctrip开源的Apollo、ali开源的Nacos 详细的对比解析这里不再具体展开Nacos不仅具有配置治理功能同时还具有注册中心的功能 Spring Cloud Config作为Spring Cloud生态中一员与Git紧密相关。
Apollo浅谈
Apollo是专业的配置治理中间件。 其分为MySQL、 Config Service、 Admin Service、 Portal入口四个模块。
MySQL: 用于存储Apollo元数据和相关的用户的配置数据Config Service 提供配置的读取、推送等功能客户端的请求直接落点Admin Service配置的修改、发布等功能Portal操作的服务就是对应该组件功能Portal 入口大屏提供给用户的配置界面 这是Apollo官网给出的时间比较久远的架构可以看到配置中心也是需要和类似Eureka的注册中心进行交互注册。
Apllo的apollo-client的AbstactConfigFile中
//AbstractConfigFile 这个类的成员包含ConfigRepository 获取配置文件需要从仓库中获取protected final ConfigRepository m_configRepository;//要初始化AbstractConfigFile需要从仓库中获取配置文件加入properies成员中
private void initialize () {...m_configProperties.set(m_configRepository.getConfig);...
}Repository在应用中经常见到就是抽象的本地存储从本地存储中获取config信息加入properties中使用
再看看具体的getConfig方法
public Properties getConfig() {...sync();...
}//再看看LocalConfigFileRepository类的实现in new FileInputStream(file);
properties new Properties();
properties.lodad(in); //可以看到这里就是读取file文件并且本地缓存不只是支持Properties这种类型文件在apllo/internals/PlainTextConfigFile中提供了文件支持Apllo的客户端和服务端之间会保持长连接这样当然是为了方便进行服务端的推送【配置更新主动推送到客户端】
//apollo-client/... /internals/RemoteConfigLongPollService//连接超时时间为90s
private static final int LONG_POLLING_READ_TIMOUT 90 * 1000; //设置读超时
HttpRequest request new HttpRequest(url);
request.setReadTimeout(LONG_POLLING_READ_TIMEOUT);//接收服务端配置更新推送
if(response.getStatusCode() 200 response.getBody() ! null) {updateNotifications(response.getBody());updateRemoteNotifications(response.getBody());notify(lastServiceDto, response.getBody());
}客户端发起一个readTimeout为90s的请求进行配置的推送。
详细的源码解析和简易demo的实现后续会详细展开
