导读 | 本节主要是汇总一下,目前市面上主流应用的一些分布式配置中心框架。重点介绍下这4个框架,它们分别是: Apollo(携程 阿波罗) 、Spingcloud Config (springcloud)、Disconf (百度)、Diamod (阿里) 1 Apollo(阿波罗) https://github.com/ctripcorp/apollo Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并
只需要自己实现一个 apollo-client 即可,当配置发生更新时,拉取最新配置信息,然后将配置信息处理成软件所需的配置格式。
引入配置中心,需要考虑和现有项目的兼容性,以及是否引入额外的第三方组件。我们的java项目以SpringBoot为主,需要重点关注springboot支持性。
小亚,互联网金融公司应用运维主管,参与运维工作九年,涉及领域包含航空、金融、广告等。近两年主要负责金融业务运维的线上业务发布、维护等工作。
配置中心是集中管理配置信息的组件。它通常提供配置变更、配置推送、历史版本版本管理、灰度发布、配置变更审计等功能。通过这些功能可以降低分布式系统中管理配置信息的成本,降低因错误的配置信息变更带来可用性下降甚至发生故障的风险。
微服务必备的几样武器有了,才能独闯武林, 有哪几样呢? 注册中心(eureka, consul, zk, etcd) 配置中心 (Spring Cloud Config, disconf ) API网关 (Spring Cloud zuul, kong) 熔断器 (hystrix) 链路追踪 (sleuth) 统一日志管理 (ELK) 自动化部署 (jenkins + Docker) 今天我们主要讲下同样是非常重要的一项,配置中心,当然官方提供的解决方案就是Spring Cloud Config 它支持配置
传统应用打包部署, 会在不同的环境配置不同的包, 如Local环境, Dev环境, 测试环境, UAT环境, 生产环境分别制作不同的发布包,
我们都知道,在项目中比较繁琐的就是配置文件。有时候需要修改很多东西,特别是在不同配置和不同环境中。如果重新打包发布的话,需要耗费很多时间。于是很多人选择分布式配置中心。那么,分布式配置中心选型方案有哪些?为什么选择Apollo?这两个问题,我们在下文做一一介绍。
在微服务架构的系列文章中,前面已经通过文章《微服务架构之「服务网关 」》介绍过了在微服务中服务网关的原理和应用,今天这篇文章我们继续来聊一聊微服务中另外一个重要模块:「 配置中心 」。后面还会继续介绍 服务框架、服务监控、服务治理等。还是那句话,只有将这些基础设施弄清楚了,微服务实践的道路才能走的稳、走的远。
业务上的配置,功能开关,服务治理上对弱依赖的降级,甚至数据库的密码等,都可能用到动态配置中心。
分布式环境下的统一配置框架,已经有不少了,比如百度的disconf,阿里的diamand。今天来看下spring cloud对应的解决方案: 如上图,从架构上就可以看出与disconf之类的有很大不
这种方式仅适合于比较小的项目,例如只有一两台服务器,而且配置文件是可以直接修改的。例如 Spring mvc 以 war 包的形式部署,可以直接修改resources 中的配置文件。如果是 Spring boot 项目,还想用这种方式的话,就要引用一个外部可以编辑的文件,比如一个固定的目录,因为 spring boot 大多数以 jar 包部署,打到包里的配置文件没办法直接修改。如果是比较大的项目,最好还是用配置中心,例如携程的 Apollo、Consul 等。 原始方式 原始方式指的是每次要修改配置
关于配置的常规方案是将配置信息抽离写入 xml、properties文件中,然后随着应用一块打包发布。如果有开发、测试、预发、生产等多套环境,则通过配置各自独立的文件以区分不同的环境。具备一定的扩展性,但每次配置参数变更都要重新发布应用,灵活性较差。
开发一个项目,参数是必不可少的,规模越大参数越多。在不同的测试环境中部署,或者是依赖项目的信息发生了变化,你有没有想跳楼的感觉?如果有,恭喜你,你至少已经不是在开发玩具系统了。
Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持,使用Config Server,您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同,
本来这篇文章想谈一下zookeeper,现在已经家喻户晓了。结果看到江南白衣的文章
在一个分布式环境中,同类型的服务往往会部署很多实例。这些实例使用了一些配置,为了更好地维护这些配置就产生了配置管理服务。通过这个服务可以轻松地管理成千上百个服务实例的配置问题。
在ArchSummit深圳2019会议上,有幸参加了杨钦民架构师对唯品会微服务的分享,唯品会是对服务化走得比较彻底的公司,坚持微服务框架纯自研和彻底落地,所以在微服务问题域积累了非常多实践经验,目前也跟着业内趋势正在做微服务中台,以及整合k8s云平台和探索Service Mesh架构。
声明:信息来源 docker.io 分享主题:分布式配置中心架构与实战 分享主题:分布式配置中心架构与实战 声明 信息来源docker.io 今天的大规模微服务系统,集群规模动辄成百上千,其配置管理已经发生了革命性的变化。应运而生的分布式配置中心是微服务架构的关键组成部分,它是一个强一致性的系统,管理着规模庞大的微服务集群以及基础设施的配置数据。分布式配置中心如何更高效的管理大规模微服务集群的配置数据,如何实时下发配置变更,怎么做灰度发布?配置中心与 CI/CD 流程又该如何结合?本次分享从分布式配置
1.CartGroup(一个店铺一个CartGroup)2.CartPkg(一个订单就是一个包裹)3.一个订单里面就是一个List
在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力。这就像,既是参赛选手,又想做裁判,观众肯定是不买账的。
如果您对微服务配置中心的功能不是很了解,可以看下以下的背景介绍,若比较熟悉可以直接跳过。
首先,先说下服务治理的边界,本质上任何能提升服务可用性,性能,让服务更稳定等等,只要是能让服务运行的更好,都属于服务治理的范畴。服务治理比较常见的话题:服务发现,服务变更管理,服务监控,服务扩容缩容,服务自我保护,服务降级,服务授权防攻击,服务上线验证和灰度发布,服务问题定位和跟踪,服务负载,服务实例的调度等等。
正是基于配置的特殊性,所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台,目前提供了以下的特性:
Docker-Disconf是本人学习Docker后,尝试使用Docker解决Disconf打包和运行问题的作品。 Disconf是分布式配置管理平台(Distributed Configuration Management Platform)的简称,使用该平台提供的Web界面,可以统一管理多个应用,多个环境的所有配置。Disconf是一个GitHub上的开源项目,在https://github.com/knightliao/disconf可以找到相关的源码和文档。Disconf-web 是Disconf的
本文介绍了如何使用disconf实现配置中心,并通过一个简易的demo展示了disconf的配置效果。disconf能够实时推送配置变更,并提供配置信息给服务使用者,使得服务使用者能够实时感知和获取到配置信息。
本文介绍了如何使用Disconf在Java项目中进行配置管理,通过三种方式:基于注解、基于配置文件、基于动态脚本,将配置信息加载到Java程序中。同时介绍了Disconf的配置中心,包括如何使用注解、配置文件、动态脚本以及配置中心来加载配置信息。最后通过一个简单的示例展示了如何使用Disconf进行配置管理,并介绍了使用Disconf进行配置管理的注意事项。
本文介绍了如何使用disconf实现本地配置文件与部署在服务器上的配置文件进行交互,以及使用disconf-nginx实现文件代理,还通过一个demo展示了如何使用disconf进行配置下发,最后对全文进行了总结。
本文介绍了如何使用Docker搭建Disconf环境,包括极速搭建、本地快速构建以及详细分析三个步骤。首先介绍了如何使用Docker进行极速搭建,然后介绍了如何利用本地环境快速构建,最后对搭建过程进行了详细分析。
disconf是一个开源的分布式配置中心(https://github.com/knightliao/disconf),此外还有携程开源的Apollo(https://github.com/ctripcorp/apollo),Apollo要比disconf功能更为丰富、强大一些。disconf比较简单明了,已经能适用于大部分场景了,使用起来比较简单。
上一章介绍了disconf的安装预配置,这章主要介绍下disconf与spring集成
在上一篇中,我们在springboot项目中简单使用了disconf的配置功能,这一篇我们主要来详解一下disconf的配置文件的动态配置。
上一篇我们完成了disconf服务端的环境搭建,这一篇我们来看看客户端springboot如何继承disconf,最终在docker下运行。
很多人都在淘宝购买过东西,基本得流程都是一致的。 (一)订单 购物车 例如:jd分为自营和多家店铺的,它的购物车比较复杂些。 购物车如果保存在session中的话,用户量比较大的情况下,tomcat承
此时,当更新disconf-web管理台对应的remote.properties文件时,会重新在disconf/config目录下下载最新文件,RemoteServerConfig 中的属性值会对应更新,RemoteServiceUpdateCallback 中的reload函数会被回调。但是对于testXml.xml的更新,disconf不支持配置对象注入,可添加回调函数TestXmlConfigCallback 。
1、使用linux文件共享配置文件来实现,但是这个需要解决配置的权限分配问题,操作起来比较麻烦,并且无法解决问题2。
ps:因为后来编辑过一次,由于编辑器的原因,丢失了一大部分数据,所以下面很乱啊有木有,不过没关系,我已将difconf的服务配置以及使用的实例上上传到coding了,大家下载下来可以直接用(包括difconf,redis,zookeeper-3.3.6,nginx-1.9.12,apache-tomcat-7.0.68)等环境以及使用的demo
今天小伙伴跑过来说,搭建框架的时候出现disconf配置好的信息不能够及时注入到实体类中的情况。他通过实践发现,spring 加载Configuration 的时候,通过@Autowired注入的RedisProperties 实体类里面没有值。等到容器加载完成后,在Controller 层注入的RedisProperties是有数据的,搞了接近一天。我在他控制台看到了如下信息(简化):
https://github.com/knightliao/disconf.git 通过git或直接下载的方式,将源码下载下来
com.baidu.disconf.client.DisconfMgrBean:第一个加载的bean
Disconf服务依赖的环境除了前两篇博文描述的外,还需要一个java的servlet容器(tomcat),因为Disconf项目是前后的分离的,所以还需要一个httpweb服务器(推荐使用nginx),当然还需要数据持久化话数据库mysql还持久化我们的数据
整体的实现是用zk watch作为轻量级的实时推送。当配置更新时, disconf-web推送最新配置到zk上,disconf-client获取到zk事件通知时,由disconf-client 从 disconf-web下载最新配置。并重新在zk节点上注册watch事件,实现再次监听。为什么不从zk上获取配置信息呢?官方文档上的解释如下:
对于Web系统: 要实现统一读取,可以使用ThreadContext+AOP来实现。 ThreadContext的使用方式有以下几种:
本文从社区活跃度、产品特点、成功案例、产品缺点等维度,全方位对比Spring Cloud Config、Apollo、Nacos、Disconf、Spring Cloud Consul、Spring Cloud Zookeeper等几款Spring Cloud生态的配置服务器,帮助你选择合适的配置服务器。
spring-boot虽然不推荐使用xml文件做为配置文件,但是并没有把路堵死,所以与disconf的整合,仍旧可以沿用之前的xml方式来处理。 一、在Application类上用注解导入xml package com.example; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.sprin
领取专属 10元无门槛券
手把手带您无忧上云