Disconf

一 配置中心介绍 1 微服务架构下关于配置文件的问题 a 配置文件相对分散 在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。 b 配置文件无法区分环境 微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。 c 配置文件无法实时更新 我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说非常不友好。 2 配置中心的思路 首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。 服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。 配置中心参数有更新时，能够通知到微服务实时同步最新的配置信息，使之动态更新。 二 常见配置中心 1 Apollo Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料也写的很详细。 2 Disconf Disconf是由百度开源的分布式配置中心。基于Zookeeper实现配置变更后实时通知和生效。 3 SpringCloud Config Spring Cloud的配置中心组件。和Spring无缝集成

我们知道，在几乎所有的应用开发中，都会涉及到配置文件的变更，比如说在web的程序中，需要连接数据库，缓存甚至是队列等等。而我们的一个应用程序从写第一行代码开始，要经历开发环境、测试环境、预发布环境只到最终的线上环境。而每一个环境都要定义其独立的各种配置。如果我们不能很好的管理这些配置文件，你的运维工作将顿时变的无比的繁琐。为此业内的一些大公司专门开发了自己的一套配置管理中心，如360的Qcon，百度的disconf等。kubernetes也提供了自己的一套方案，即ConfigMap。kubernetes通过ConfigMap来实现对容器中应用的配置管理。 创建ConfigMap 创建ConfigMap的方式有两种，一种是通过yaml文件来创建，另一种是通过kubectl直接在命令行下创建。 我们先来看第一种，在yaml文件中，配置文件以key-value键值对的形式保存，当然也可以直接放一个完整的配置文件，在下面的示例中，cache_hst、cache_port、cache_prefix即是key-value键值对，而app.properties和my.cnf都是配置文件： apiVersion : v1 kind : ConfigMap metadata : name : test-cfg namespace : default data : cache_host :

总体介绍 在互联网金融行业一百多亿其实也算不上大平台，也就是二级阵营吧，其实每次的架构升级都是随着业务重大推进而伴随的，在前一代系统架构上遇到的问题，业务开发过程中积累一些优秀的开发案例，在下一代系统开发中就会大力推进架构升级。一方面可以平滑过度，一方面公司资源可以大力支持，同时技术的小伙伴们可以使用到前沿的技术，更有开发的成就感，就这样我们大概也就是9个月就行系统架构一次升级，就到了我们现在的这套架构中。 很多网友经常会问，你们平台的TPS是多少呀，最大并发是多少呀，性能怎么样，说实话我们是一个小公司，最夸张也就上万人同时抢标，但是做为一个中型的互联网金融平台要做的事情也真的不少，远远不只是这些参数可以说的清楚；我们也不是什么高大上的平台，使用的技术也是目前比较主流开源产品，但在公司不断发展的过程中也遇到了很多的问题，也尽量去使用比较主流的、开源的、适合我们的一些解决方案来构建整个系统，在这里分享平台发展背后技术换代的变化，同时希望和大家多做一些交流，多提一些建议。 我们进行了四次大的架构变化，每代架构都用一句话来总结： 第一代架构特点：业务比较集中、功能满足投资理财需求、快速上线 第二代架构特点；分布式系统改造，平台化初具规模，各项垂直业务系统搭建上线、产品端极大丰富用户投资、大数据平台研究并使用 第三代架构特点；SOA治理，使用zookeeper作为注册中心

1. Disconf 2. UidGenerator 3. BRPC-Java 4. Spring Cloud Formula 5. JProtobuf 6. Jprotobuf-rpc-socket 7. BI 平台 BiPlatform 今儿 7 点一大早，早起群的死变态已经纷纷打卡起来学习了。 菜逼互啄群 吓得艿艿这个小帅胖，翻了一圈“年轮”，赶紧起来 = =。 点了一套煎饼果子，看到《百度开源的 71 款项目》文章，于是乎去百度的 https://github.com/baidu 愁一愁有哪些和 Java 相关的，还是有点东东的。。。 1. 分布式配置管理平台 Disconf https://github.com/knightliao/disconf Distributed ConfigurationManagement Platform(分布式配置管理平台)专注于各种 分布式系统配置管理 的通用组件/通用平台, 提供统一的配置管理服务。 目前已经不维护，建议采用 Apollo 或者 Nacos 作为配置中心。 2. 分布式 ID 生成器 UidGenerator https://github.com/baidu/uid-generator UidGenerator 是Java实现的, 基于Snowflake算法的唯一ID生成器。 UidGenerator

　　不多说，直接上干货！ 工作环境以及安装依赖软件 　　Zookeeper-3.4.8 　　Disconf 2.6.36 　　Nginx 1.9.9（见如下博文的phpstudy） 　　redis 　　JDK1.8.0_66 　　Tomcat7.0_69 　　MySQL 5.7.10（见如下博文的phpstudy） JDK的安装 Jdk 1.7*安装并配置 Jdk 1.8*安装并配置 Tomcat的安装 　　见 https: // archive.apache.org/dist/tomcat/tomcat-7/ https: // archive.apache.org/dist/tomcat/tomcat-8/ Tomcat *的下载（绿色版和安装版都适用） Tomcat *的安装和运行（绿色版和安装版都适用） MySQL 、Nginx 的安装 　　　　见 Windows里下载并安装phpstudy（图文详解） Zookeeper的安装 Windows里如何正确安装Zookeeper以服务运行（博主推荐）（图文详解） Redis的安装 Windows里如何正确安装Redis以服务运行（博主推荐）（图文详解） Windows下如何正确下载并安装可视化的Redis数据库管理工具（redis-desktop-manager)（图文详解） Disconf 的安装 　　本文以2.6.36为例

3 月，跳不动了？>>> 微服务日益流行的今天，除了本身微服务的设计，实现，其配置中心也变得越来越重要和迫切，否则将发挥不出微服务的威力。 现在配置中心核心需求： 交付件和配置分离：相较于docker的内容镜像、配置文件不可变，配置中心需要提供两者可以分离的功能； 抽象标准化：配置文件的格式、配置接口都由配置中心提供，用户只要关心内容； 集中式的管理：所有的业务团队，都可使用配置中心，统一方便管理； 高可用：微服务依赖于配置中心的高可用； 实时性：及时被应用读取配置内容，变更业务功能； 治理：权限控制，不同环境、集群配置管理，灰度发布、支持回退、日志等功能； 当前一线互联网使用的配置中心 阿里巴巴 Diamond(开源) NETFLIX Archaius(开源) 携程：Apollo(开源) 百度：Disconf(开源) Spring Cloud Config 后面讲介绍Apollo配置中心和Spring Cloud Config 配置一般分为静态配置、动态配置 静态配置：和环境相关，包括数据库、中间件的连接串等，以及用户名、密码、令牌、许可证等。 动态配置： 应用配置：超时时间、线程池、对列、缓存、日志级别、限流熔断阈值、黑白名单等； 功能开关：蓝绿发布、灰度开关、降级开关、HA高可用开关、DB迁移等； 业务配置：促销规则、贷款额度、利率等业务参数、A/B测试； 来源：

3 月，跳不动了？>>> 保证以root身份进入 sudo -i 设置远程连接ROOT身份登录 vi /etc/ssh/sshd_config 修改 PermitRootLogin ，将 no 改为为 yes ； 修改 passwordAuthentication ，将 no 改为 yes 按shift+alt+; 后输入wq退出编辑状态 设定ROOT登陆密码 passwd root 重启SSHD服务 service sshd restart Apache 在默认的 Debian 软件仓库中可用，安装非常简单。 首先更新软件包索引，然后 apache2 使用以下命令安装软件包： sudo apt update sudo apt install apache2 “sudo apt install apache2”后输入“Y” 安装并自动启动 Apache ，您可以使用以下命令检查 Apache 服务的状态： sudo systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Active: active (running) since

作者 | 董鹏 阿里巴巴技术专家 微服务 好处：实现跨团队的解耦，实现更高的并发（目前单机只能实现 c10k）不用再拷贝代码，基础服务可以公用，更好的支持服务治理，能够更好的兼容云计算平台。 RPC rpc：像调用本地方法一样调用远程函数； 客户端：一般利用动态代理生成一个接口的实现类，在这个实现类里通过网络把接口名称、参数、方法序列化后传出去，然后控制同步调用还是异步调用，异步调用需要设置一个回调函数； 客户端还需要维护负载均衡、超时处理、连接池管理等，连接池维护了和多个 server 的连接，靠此做负载均衡，当某个服务器宕机后去除该连接。请求上下文维护了请求 ID 和回调函数，超时的请求当回复报文到达后由于找不到请求上下文就会丢弃。 服务端：维护连接，网络收到请求后反序列化获得方法名称，接口名称，参数名称后通过反射进行调用，然后将结果在传回客户端； 序列化的方式：一种是只序列化字段的值，反序列化的时候重新构建对象再把值设置进去，另外一种方式直接将整个对象的结构序列化成二进制。 前者节省空间，后者反序列化速度快，目前的序列化框架也是在反序列化时间和占用空间之间权衡。有点类似哈夫曼编码，或者数据库怎么存储一行一行的数据。 注册中心 一般有 3 种模式： f5 做集中式代理； 客户端嵌入式代理例如 dubbo； 还有一种是综合上面两种，多个客户端共用一个代理

前有了解过disconf，也知道它是基于zookeeper来做的，特意写了文章记录下自己的见解。如有错误，欢迎指正。 1、disconf-web会在启动时，将自身的host和配置文件注册到zookeeper上。配置文件会在zk上生成node。 2、client 端启动时，会有一个BeanDefinitionRegistryPostProcessor的实现类DisconfMgrBean，该类主要你实现了扫描（firstScan，加载系统配置和配置文件，进行包扫描并入库，然后获取获取数据/注入/Watch。）、注册DisconfAspectJ（切面，判断是否启用了ENABLE_DISCONF注解，返回disconf仓库中对应的属性值） 和 bean属性注入（获取仓库中对应的属性值，通过setMethod.invoke或者field.set方法来设置值）。 3、disconf的配置动态更新借助于zk的watch机制（watch机制是zk 3大重要内容之一，其余两个是zk协议和node存储模型）实现的，初始化流程会中会对配置文件注册watch，这样当配置文件更新时，zk会通知到client，然后disconf-client再从disconf-web中获取最新的配置并更新到本地，这样就完成了配置动态更新。 小结：disconf更新配置 -> disconf-web保存配置到DB-

专注于各种 分布式系统配置管理 的 通用组件 / 通用平台 , 提供统一的 配置管理服务 。 主要目标： 部署极其简单：同一个上线包，无须改动配置，即可在 多个环境中(RD/QA/PRODUCTION) 上线 部署动态化：更改配置，无需重新打包或重启，即可 实时生效 统一管理：提供web平台，统一管理 多个环境(RD/QA/PRODUCTION)、多个产品 的所有配置 项目信息 CLIENT 端： Java: 目前唯一支持语言 python：打算支持 PHP：暂未支持 WEB 管理端： Java SpringMvc 实现，前后端分离 实现方式(基于Spring 4.1.7.RELEASE) java client disconf.git branches and Maven version: dev(develop branch): 2.6.28-SNAPSHOT master(stable branch)：2.6.27 更新日志 在Maven Central Repository里查看 com.baidu.disconf Java Client Elegant Usage Preview 注解式分布式配置使用方式 XML配置式分布式配置方式 当前版本功能特点 支持配置（配置项+配置文件）的分布式化管理 配置发布统一化 极简的使用方式（注解式编程 或 XML无代码侵入模式）