apollo

0104 代码方式刷新logback日志配置 背景 日志是一个系统或者说一个产品技术架构中重要组成部分。 常见的日志框架如下： 日志框架 说明 跟slf4j集成所需依赖 slf4j 日志门面，具体实现由程序决定 jcl commons-logging <br />jcl-over-slf4j jul jdk-logging slf4j-api<br />jul-to-slf4j<br />slf4j-jdk14 log4j log4j slf4j-api<br />log4j-over-slf4j<br />slf4j-log4j12 log4j2 log4j-api,log4j-core slf4j-api<br />log4j-slf4j-impl logback logback-core,logback-classic slf4j-api slf4j-logback的启动过程 一般使用slf4j来操作日志： private static final Logger LOGGER = LoggerFactory.getLogger(LogbackAppenderExample.class); public static void main(String[] args) { LOGGER.trace("trace log"); LOGGER.debug("debug log");

亲爱的儿子： 当你打开这封信的时候，我已经离开波士顿回到加州了，你也已经结束自己最后一个暑假，去往自己非常喜欢的公司。 虽然你我都是程序员，但是你却很少向我咨询过技术相关的问题，咱们上一次一起写代码，也是你高考结束那个暑假了。不过前几天你问了我一个问题，你说，如果让你写一封信，跟当初刚刚成为程序员的自己说一些话，你会说什么呢？ 我在想，我会说些什么呢？我想说的太多了，可是如果说了，他能听进去多少呢，就算听进去了，他又会用到多少呢？我想起了瑞·达利欧的《原则》，如果我把我这几年的经历、收获，总结成几条原则，是不是会好一些。 以下，是我总结的几条原则。 1.权威精神 对于某一项具体技术来说： 官方文档、白皮书、论文，比博客更权威； 由此引申出： 谷歌比百度更权威，因为谷歌的搜索结果，权威的资料靠前，而百度，靠前的多是博客； 大多数时候，英文文档比中文文档更权威，因为官方文档、白皮书、论文，大多数是英文的； 如果你想向别人解释一项技术，那么请向他们展示权威的资料，而非一些网络上的博客； 为什么这么强调权威精神？ 《禅与摩托车维修艺术》里，作者和朋友骑摩托车去沙漠，车坏了，朋友依靠直觉和经验，尝试了各种办法，就是修不好，而作者找到了他购买摩托车时配套的指导手册，照着上面的步骤排查，很快找到了导致车子故障的原因，换了个零部件，车子就好了。 数学、物理的很多研究，都是基于定理之上

本文假设读者已阅读过 《Apollo 官方 wiki 文档》 ，只对Client响应ConfigServer配置发布的细节进行分析。详情请前往 《Apollo 官方 wiki 文档》 响应发布大致流程如下图，下面将从 客户端响应ConfigServer配置发布 和 client启动Apollo监听 两个模块讲解Apollo热发布原理。 1:当配置中心发布配置时，客户端响应流程 1:RemoteConfigLongPollService感知配置发布 RemoteConfigLongPollService通过长轮训(结合Spring DeferredResult)迅速感知配置发布，其通知RemoteConfigRepository到ConfigServer拉取最新配置。 1: 感知有配置发布 2:通知RemoteConfigRepository，向configServer发起同步配置请求 此处引入RemoteConfigLongPollService长轮训个人觉得是为了实现配置推送模式，apollo并不是使用消息来实现配置发布的推送 2:RemoteConfigRepository同步配置信息 RemoteConfigRepository相当于一个Apollo中的namespace。他即会定期主动到ConfigServer同步配置信息

Apollo（阿波罗）[参考附录1]是携程框架部研发并开源的一款生产级的配置中心产品，它能够集中管理应用在不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。 Apollo目前在国内开发者社区比较热，在Github上有超过5k颗星，在国内众多互联网公司有落地案例，可以说Apollo是目前配置中心产品领域Number1的产品，其成熟度和企业级特性要远远强于Spring Cloud体系中的Spring Cloud Config产品。 Apollo采用分布式微服务架构，它的架构有一点复杂，Apollo的作者宋顺虽然给出了一个架构图，但是如果没有一定的分布式微服务架构基础的话，则普通的开发人员甚至是架构师也很难一下子理解。为了让大家更好的理解Apollo的架构设计，我花了一点时间把Apollo的架构按我的方式重新剖析了一把。只有完全理解了Apollo的架构，大家才能在生产实践中更好的部署和使用Apollo。另外，通过学习Apollo的架构，大家可以深入理解微服务架构的一些基本原理。 二、架构和模块 下图是Apollo的作者宋顺给出的架构图： Apollo架构图by宋顺 如果没有足够的分布式微服务架构的基础，对携程的一些框架产品(比如Software Load Balancer(SLB))不了解的话

参考Apollo官方文档https://github.com/ctripcorp/apollo/wiki/Java%E5%AE%A2%E6%88%B7%E7%AB%AF%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97 进入Apollo控制台，点击创建项目按钮，创建项目 需要重点说明的是应用ID。等一会在客户端中要配置的。 创建一个Java项目，即客户端。 项目结构 pom.xml配置依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.2.RELEASE</version> </parent> <groupId>test</groupId> <artifactId>SpringBoot-Apollo</artifactId> <version>1.0-SNAPSHOT</version> <name>SpringBoot-Apollo</name> <!-- FIXME change it to the project's website --> <url>http://www.example.com</url> <properties> <project.build

zuul集成apollo实现路由配置的动态刷新 import com.ctrip.framework.apollo.model.ConfigChangeEvent; import com.ctrip.framework.apollo.spring.annotation.ApolloConfigChangeListener; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.beans.BeansException; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.cloud.context.environment.EnvironmentChangeEvent; import org.springframework.cloud.netflix.zuul.RoutesRefreshedEvent; import org.springframework.cloud.netflix.zuul.filters.RouteLocator; import org.springframework.context.ApplicationContext;

学习Apollo服务配置中心，与SpringBoot整合 通过spring-boot搭建的业务系统，可以通过Apollo提供远程的配置服务，以达到集群环境统一使用一套动态配置的目的。 1.关于NameSpace https://github.com/ctripcorp/apollo/wiki/Apollo%E6%A0%B8%E5%BF%83%E6%A6%82%E5%BF%B5%E4%B9%8B%E2%80%9CNamespace%E2%80%9D 1.1 namespace的使用场景 提供一份全公司默认的配置且可动态调整 RPC客户端项目可以自定义某些配置项且可动态调整 1.2 apollo的注解在java中配置 @EnableApolloConfig要和@Configuration一起使用。 想把日志配置也放阿波罗里，那么要把阿波罗的加载顺序提前，但是如此一来，阿波罗的启动就没日志了。 2. 注解 1.@ApolloConfig 自动注入Apollo对象 2.@ApolloConfigChangeListener 自动注册ConfigChangeListener事件 3.@ApolloJsonValue 转换配置的json字符串 3. 使用实践 3.1 单元测试 1.单元测试的时候用的是mockdata+{namespace}.properties 2