技术干货｜恕我直言，你们真的懂Java框架吗？
技术干货｜恕我直言，你们真的懂Java框架吗？
就IT行业而言，技术的更新与迭代虽然时刻都在进行，加上大部分互联网公司而言，他们追求的都是低成本、高效益，需要的更是能直接进入工作状态的人才。所以当万事都开始追求极速与简洁的时候，身为程序员的我们更应该与时俱进，了解框架的使用！-----------------------------------------学习过程产生的问题Java框架----------------------------------------Q：Java中涉及到一些固定死的知识。例如Spring的配置我个人感觉每个项目都只有一两次配置，之后就落实到具体的代码实现。把时间花费在记忆这些基本固定死的东西上会不会显得有些死板。这个问题我觉得在我们编程中是常常需要取舍这些固定的知识是要交给搜索引擎还是留容量本就不高的大脑里。另外一个问题我也想请教大家回答一些，由于我面试次数并不多，面试官在面试时会特别注意这些细节上固定死的知识吗？答：刚入这一行需要记死的东西可能是少不掉的，因为这个时候很难有能力掌握这些【死的东西】背后是要做什么，和什么原理能对得上。面试官会视你工作时间长短，如果没有工作经验，可能会问框架的使用，或者问框架的流程等，因为这个时候他愿意招你基本上是要你进公司就能干活的。除非你表现的能力很强，这时可能会继续探测你能力的上限。等工作一段时间，需要自我感觉不好，代码的逻辑、结构其实不好，这时就有动力去探寻一下框架【死的知识】背后，如果你一直自我感觉良好那就麻烦了。探寻完了会发现，无非也就是那么回事，如果你自己搞个框架，难道就不让别人记【死的东西】了？一样的，这个是框架本身的规则。 关于记这个【死的知识】，我建议好记性不如烂笔头，用思维导图一类的，可以把相关知识串起来。Q：向大家请教一下，做框架迁移比如从hibernate迁移到mybatis，应该怎么准备，实施中有什么需要注意的以及会有什么坑答：最重要的是做好回归测试，最重要的是做好回归测试，最重要的是做好回归测试。 一定是在hibernate上进行过的完整的测试用例全部要留存，无论单元测试还是结合测试，做好版本控制，这么大的变更要有分支，万不得一可回退，所有之前在hibernate上做过的测试要在迁移后全部都能通过，当然，这也不能保证万无一失，这是要看原本的测试用例的质量的！Q：学完javaweb基础学习阶段（javase、servlet、jsp等等），现在学框架，可以先跳过struts2、hibernate即ssh，直接学spring、spring-mvc、mybatis（ssm）吗？？？答：这个没什么讲究，最重要的是学的过程中多考虑：这些框架和以前学过的知识有什么联系，比如你说的servlet。Q：大学本科学的软件开发JAVA方向，当时不仅学了ssh，还有ejb，这两年框架的风好像刮得挺快的，ssm，springmvc，spring boot，现在企业的开发框架比较倾向于哪一种？其他用户解答：springmvc是主流，其实我个人认为各种框架都是大同小异，用的技术都是很基础的，比如反射，多线程，泛型，注解等，优秀的框架在于优秀的设计思想，单例，抽象工厂，等都是常见的。工作中以及招聘的时候，我偏向于解决问题能力和应变能力而不是对方会多少框架。答：1楼说的好，万变不离其宗，基础的东西，框架是逃不掉的，主要是看：1、你现在面临什么问题？2、什么框架能完全的或者更多的解决你的问题？3、如果框架没有完全解决问题，基于这个框架的可扩展如何？ 无论是流行框架还是企业内部框架都一样，而且这个框架要有人在持续维护。企业的倾向要看企业是老的还是新的、企业文化是什么样的、企业的规模等等，这些因素会决定企业是保持原来太多的积淀不想乱动、还是勇于创新、还是反正是新公司，可以大胆的尝试新的东西、还是觉得企业规模太小，没必要这样折腾，并不能带来太多的好处，还要付出高昂的成本。 现在看慕课上Spring boot相关的课多起来了，后面应该还会有Spring cloud，但最终还是要看企业对利益的权衡。Q：我刚学完JSP和Servlet，准备学习框架，但是在网上的框架视频，像Spring，完全听不懂配置，是不是有什么东西我还需要先学习么？答：先弄清楚框架所解决的问题再学，我换句话说：你已经会jsp和Servlet了，不是也能做点东西了吗？这样有什么问题吗？如果你觉得有问题，那问题在哪？这个框架能帮你解决吗？Q：6月拿到毕业证了，大专学历，实习公司转正6k，找到一家开7.5k的公司，不过找到的公司是做政府项目的，需要外派的那种，技术用 struts+spring+hibernate的。我现在的实习转正公司用Spring 、 SpringMVC 和 Mybatis、spring boot。求老师给点建议，去薪资高的还是留下转正技术方向好的？ssh是不是太传统对以后发展不好，是不是这样的呢？求老师给点建议，也是考虑在技术框架上答：因为大部分同学都是停留在【会使用】的基础上、并且都是希望从工作的内容上吸取到更多的养分，才会有这样的问题，所以一味的考量公司在用什么，能给我带来什么。其实更多的应该考虑，我能为公司做什么，我不是在给鸡汤，也不是在讲多么伟大的理想，是事实：1、公司准备让我做的事是不是苦力活？我有没有办法在这个岗位上突破，把苦力活自动化，为公司解决问题的同时也留出更多的时间来学习。2、当我有一定能力积累，并且发现公司的一些问题的时候，我能不能推动这些问题的解决？能力从哪来？把第1件事做好再谈这个。3、如果公司不能提供这样的机会来发挥我所学，再考虑换工作。当然，不要搞到最后发现不是公司不给机会，是自己能力不够，那还要再来。这个时候你会发现，新框架也罢，老框架也罢，你具备的是什么？【解决问题的能力】，这玩意，什么框架都代替不了。通过学习框架来提高【解决问题的能力】只是一种方式，并不是目的。Q：请问在生成开发环境中有那些框架是主流的呢？我只学习了ssm框架，感觉有好多地方问题用这框架难以解决。源老师，能给我们列表一些现在的那些主流框架分别解决那些问题吗？答：你有这种感觉就对了，本来这些框架就不是为了【你的问题】而生的，要根据你的问题去找，看有没有可以解决这个问题并能很容易融进来的框架，或者是自己写代码解决，很多企业不是经常这样吗，基于流行框架，甚至不基于任何框架，封装一套解决自己企业独特问题的框架。这要根据情况来，核算一下如何做是较小的成本。Q：我现在找工作，问道公司是用到传统技术ssh框架的，我就没打算聊下去，因为自己刚出来，想找个技术氛围的平台，以后跳槽也有好的优势，我这样做可以吗？答：对于工作时间较短且没有自制力的同学来说，好的氛围确实会对人有影响，但我没明白【传统技术ssh框架】和【技术氛围的平台】有什么必然联系吗？我知道有的公司是不用任何框架的，JDK就够了，自己有专门的部门来打造、维护自己公司独特的框架，这样的算是有【技术氛围的平台】还是算没有呢？你不用急着解释，如果你确实发现这个公司不符合你的要求，可以做出这样的选择。但是我最后说一句最重要的，靠人不如靠自己，无论在什么样的环境，你把事情做到极致，注意，一定要做到【极致】，这对你的功力有相当高的要求，如果你一直这样来看待问题并且照做，就算没做到【极致】，但能力提升我想是杠杠的，这时再看在什么样的环境重要吗？可能连收入都不是问题了吧？想去哪，已经完全在于你怎么选，而不是公司要不要你。Q：想问一下，如何去看 框架的源码，点击进去， 一个方法接着一个方法，需要每个方法都看懂吗， 应该怎么才能知道框架中这个方法是如何实现的，如何逻辑清晰的读懂源码，知道这个源码的大体架构答：点击进去，一个方法接着一个方法，这样看源码不是好办法，追踪源码解决问题的时候会这么干，但要了解框架的大体架构不能先看细节，那样就被困在里面了。 要通过官方文档、或者其他网站上的技术文档去找，框架结构的那种图，包括结构、层次关系、关键接口、流程和功能描述等，用这种方法把整个框架大概的给描绘出来，了解一下我们平时使用一个功能时，这个功能在这种图里是由哪几个关键接口支撑了这个功能，整个过程是什么样的，然后再去找这些接口以及实现类，再去研究细节。Q：我是菜鸟，我想问一下， 比如说练习题拿过来的时候 按道理说都应该知道步骤 和怎样去写代码才能实现 但是我 一点思路都没有， 拿过练习题，跟傻子一样按照图就开始写。答：思路是什么？并不是写代码，思路是可以看是写伪代码的过程： 就是先干嘛，后干嘛，再干嘛，最后干嘛。这和生活中要做某件事，该如何考虑，并没有什么区别，如果你连这个都没办法思考，那不应该的。我举个最简单的例子，如何根据年份来判断是不是闰年，这最先的考虑，根本不是代码的问题，而是你的常识问题，这个你要先解决了，根据你的常识，是如何描述这个问题以及解决的伪代码，然后再把伪代码转成真正代码，那是另一回事，确定一下问题出在哪个环节了。Q：我刚好有一个Java基础的问题搞不懂，找好多人问了，他们也答不上来，关于Java泛型。Q1 : public static &T& void sort(List&T& list, Comparator&? super T& c)Collections.sort()方法的Comparator参数，它的泛型使用了super通配符。我理解不了这里为什么要用super。我能理解Collections.copy()方法中的两个参数的通配符，从src拷贝到dest中，src的extends表示数据全都可以视作T类型，dest的super表示List作为T类型的父类型，确保可以放入任何T类型对象。同样的问题出现在我看RxJava源码时，public final &R& Observable&R& map(Function&? super T, ? extends R& mapper)操作符中，为什么会用&? super T&来表示被转换对象？我大概知道一点PECS原则，可是我没有办法把这个原则用在理解这几个泛型通配符上。Q2：假如我有一个类声明了泛型，如public class ResponseBase&T&{}，在这个类中，我要怎样取得T的class对象？比如使用Gson解析Json的时候，调用方法时需要传入一个class对象。有办法能直接根据泛型取到class对象，而不用在构造方法中传入一个Class&T&的对象吗？答：Q1：Collections.sort()方法是一个重载的方法，有一个参数的，两个参数的，一个参数，是需要List&T&中的这个T要已经实现了Comparable接口，才可以直接排序，否则就要再加一个参数，就是一个比较器，这个方法目的很明显，按正常来说，排序方法只用Collections.sort(List&T& list)这个方法难道不够用吗？够用了，那为什么还要再多一个方法，加入第二个参数？是让我们自己写的比较规则可以复用，这个比较器是基于T的父类来实现的，也就是说，基本上都是在用父类的一些属性来决定排序规则，当这些规则同样也适用于子类时，那不就能用Collections.sort(List&T& list, Comparator&? super T& c)这个方法来完成了吗？这样，T类（这里的T不止一种）不用实现比较规则，都用Comparator来完成比较规则，Comparator里是T的父类，Comparator可以用于N个像T这样的类的比较，来完成排序，这N个T这样的类，都是Comparator里实现的那个类的子类，然后这里的比较器要求&? super T&，必须是T的父类才能完成这个比较过程，这不是很合理吗？只有是T的父类才能完成共通的比较器规则，因为T的父类用到的属性，T类也继承过来了，是可以用的，如果&? super T&写成&T&，那这个比较器，只能用于T自身，那和不加这个参数也没什么区别，如果写成&? extends T&更是扯淡，子类的比较器是不能用于父类的，子类的比较器用到的一些属性，父类可不一定有。希望我这样说能说的明白！！Q2：看下jackson的实现方式的源码，字符串转成指定java对象，如何解决java对象的class传入问题，甚至是带泛型的class，就是这行代码的背后源码，你好好体会一下：mapper.readValue(&json字符串&,new TypeReference&List&Map&String,自定义类型&&&() {});你看看这里要转换的目标java类型：List&Map&String,自定义类型&&，你用class怎么表示这样用泛型表示的嵌套复杂类型？jackson不也照样能正确的帮我们序列化成目标的java类型吗？是怎么做到的？去看看源码，很有意思，这样的问题如果能解决，你说的不传入class对象，而转成泛型指定的class对象，就不是问题了是吧？Q：麻烦问下，学习ssh框架之前是不是一定要先学习servlet、jsp知识的？答：必须的，那是根本，而且不止这些，否则你将会陷入一个又一个框架的使用规则的记忆中，而毫无感觉，并知道这些框架为什么要这样，这样做有什么好处，如果你不想做一个【使用者】的角色，而想做一个【主导者】的角色，先学java语言的基础和java web基础，JVM也可以看一看，使用框架时多提出好的问题然后自己找到答案，比如：这些框架和我之前学的基础到底有什么联系？一Java技术交流群：
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
百家号 最近更新：
简介: 科学奇迹带你去科学和科学。
作者最新文章关注51Testing
SpringCloud分布式配置
发表于： 13:42 &作者：张建斌 & 来源：博客园
推荐标签：
　　前言　　在单体式应用中，我们通常的做法是将配置文件和代码放在一起，这没有什么不妥。当你的应用变得越来越大从而不得不进行服务化拆分的时候，会发现各种provider实例越来越多，修改某一项配置越来越麻烦，你常常不得不为修改某一项配置而重启某个服务所有的provider实例，甚至为了灰度上线需要更新部分provider的配置。这个时候有一套配置文件集中管理方案就变得十分重要，SpringCloudConfig和SpringCloudBus就是这种问题的解决方案之一，业界也有些知名的同类开源产品，比如的disconf。　　相比较同类产品，SpringCloudConfig最大的优势是和Spring无缝集成，支持Spring里面Environment和PropertySource的接口，对于已有的Spring应用程序的迁移成本非常低，在配置获取的接口上是完全一致，结合SpringBoot可使你的项目有更加统一的标准（包括依赖版本和约束规范），避免了应为集成不同开软件源造成的依赖版本冲突。　　一. 简介　　SpringCloudConfig就是我们通常意义上的配置中心，把应用原本放在本地文件的配置抽取出来放在中心服务器，从而能够提供更好的管理、发布能力。SpringCloudConfig分服务端和客户端，服务端负责将git（svn）中存储的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的/refresh。　　SpringCloudBus通过一个轻量级消息代理连接分布式系统的节点。这可以用于广播状态更改（如配置更改）或其他管理指令。SpringCloudBus提供了通过POST方法访问的endpoint/bus/refresh，这个接口通常由git的钩子功能调用，用以通知各个SpringCloudConfig的客户端去服务端更新配置。　　下图是SpringCloudConfig结合SpringCloudBus实现分布式配置的流　　注意：这是工作的流程图，实际的部署中SpringCloudBus并不是一个独立存在的服务，这里单列出来是为了能清晰的显示出工作流程。　　二. SpringCloudConfig 　　SpringCloudConfig提供基于以下3个维度的：　　· 应用　　这个比较好理解，每个配置都是属于某一个应用的　　·&环境　　每个配置都是区分环境的，如dev, test, prod等　　·&版本　　这个可能是一般的配置中心所缺乏的，就是对同一份配置的不同版本管理　　Spring Cloud Config提供版本的支持，也就是说对于一个应用的不同部署实例，可以从服务端获取到不同版本的配置，这对于一些特殊场景如：灰度发布，A/B测试等提供了很好的支持。　　2.1 ConfigServer 配置　　服务端要在pom中依赖spring-cloud-config-server、spring-cloud-starter-bus-kafka&dependency&&groupId&org.springframework.cloud&/groupId&&artifactId&spring-cloud-config-server&/artifactId&&/dependency&&dependency&&groupId&org.springframework.cloud&/groupId&&artifactId&spring-cloud-starter-bus-kafka&/artifactId&&/dependency&&dependency&&groupId&org.springframework.cloud&/groupId&&artifactId&spring-cloud-config-monitor&/artifactId&&/dependency&　　application.properties中要配置仓库描述和消息队列地址，如果是私有项目还需要配置用户名密码spring.cloud.config.server.git.uri=/seagrape/SpringCloudConfig.gitspring.cloud.config.server.git.searchPaths=alan-config-repo#spring.cloud.config.server.git.username=sihan2#spring.cloud.config.server.git.password=MYPASSWORDspring.cloud.stream.kafka.binder.brokers=10.79.96.52:9092spring.cloud.stream.kafka.binder.zk-nodes=10.79.96.52:2182　　启动类中要有@EnableConfigServer注解@SpringBootApplication@EnableConfigServerpublic class ConfigServerApplication {public static void main(String[] args) {SpringApplication.run(ConfigServerApplication.class, args);}}　　2.2 ConfigServer 启动　　Server端启动后，提供了如下的接口地址，参数说明　　· application：应用名　　·&profile：环境　　·&label：版本/{application}/{profile}[/{label}]/{application}-{profile}.yml/{label}/{application}-{profile}.yml/{application}-{profile}.properties/{label}/{application}-{profile}.properties　　NOTE：是配置文件的名字一般是有两部分组成，举个例子感受下，alan-provider-data-config-dev.properties，其中alan-provider-data-config是第一部分，这部分建议通过命名规则能让你知道是哪一个项目的配置，并且客户端要配置spring.cloud.config.name=alan-provider-data-config，才能让客户端知道自己要去服务端找哪一个配置文件。dev是第二部分，这部分用以区别配置文件应用的场景，是开发环境、环境或者生产环境　　接口返回样例 curl http://localhost:8888/alan-provider-data-config/dev/master{"name": "alan-provider-data-config","profiles": ["dev"],"label": "master","version": "78dce2b8e11ef0d004ffa8d26bd1","propertySources": [{"name": "/seagrape/SpringCloudConfig.git/alan-config-repo/alan-provider-data-config-dev.properties","source": {"spring.datasource.driver-class-name": "com.mysql.jdbc.Driver","spring.datasource.username": "username","spring.datasource.password": "password","spring.datasource.url": "jdbc:mysql://DEVIP:PORT/DBNAME?characterEncoding=UTF-8"}}]}　　接口返回样例 curl http://localhost:8888/alan-provider-data-config-dev.properties　　spring.datasource.driver-class-name: com.mysql.jdbc.Driver　　spring.datasource.password: password　　spring.datasource.url: jdbc:mysql://DEVIP:PORT/DBNAME?characterEncoding=UTF-8　　spring.datasource.username: username　　2.3 ConfigServer 文件系统　　GIT做文件系统，文件都会被clone到本地文件系统中，默认这些文件会被放置到以config-repo-为前缀的系统临时目录，在 linux 上应该是 /tmp/config-repo-目录，如果你遇到了不可预知的问题出现，你可以通过设置spring.cloud.config.server.git.basedir参数值为非系统临时目录。　　Config Server中,还有一种从本地classpath 或文件系统中加载配置文件的方式，可以通过spring.cloud.config.server.native.searchLocations进行设置。但如果你连GIT环境都没有，你还是回去喝奶吧......　　三. SpringCloudConfig Client　　3.1 ConfigClient 配置　　客户端要在pom中依赖spring-cloud-starter-config、spring-cloud-starter-bus-kafka&dependency&&groupId&org.springframework.cloud&/groupId&&artifactId&spring-cloud-starter-config&/artifactId&&/dependency&&dependency&&groupId&org.springframework.cloud&/groupId&&artifactId&spring-cloud-starter-bus-kafka&/artifactId&&/dependency&&dependency&&groupId&org.springframework.boot&/groupId&&artifactId&spring-boot-starter-web&/artifactId&&/dependency&&dependency&&groupId&org.springframework.boot&/groupId&&artifactId&spring-boot-starter-actuator&/artifactId&&/dependency&　　bootstrap.properties中配置配置中心地址和消息队列地址　　1.特别注意 配置中心的地址一定要放在bootstrap.properties中，这个配置文件是由“根”上下文优先加载，可以保证程序启动之初就感知到远程配置中心的存在，并从远程获取配置，随后继续启动系统，这点十分重要。 2.而application.properties是由子上下文加载，加载顺序低于前者，如果配置中心地址放在这里，并且你远程配置了一些启动相关的必要参数，那么，你的程序很可能由于缺少参数而启动失败。 3.下面这段代码，最关键的是第一行，第二行如果不配置系统默认读取spring.application.name，第三行如果不配置，系统默认default，即：${spring.application.name}.properties 4.我们一般的做法是，在系统启动的时候，用命令行传入--spring.cloud.config.profile=dev|prod|test的方式，因为在启动的时候，我们是明确知道我要获取哪套配置的。 5.bus相关的配置（本例中用的kafka）完全可以放在远程。spring.cloud.config.uri=http://127.0.0.1:${config.port:8888}spring.cloud.config.name=alan-provider-data-configspring.cloud.config.profile=${config.profile:dev}spring.cloud.stream.kafka.binder.brokers=10.79.96.52:9092spring.cloud.stream.kafka.binder.zk-nodes=10.79.96.52:2182　　引用配置的类要加@RefreshScope注解@SpringBootApplication@RestController@RefreshScopepublic class ConfigClientApplication {@Value("${spring.datasource.username}")String name = "World";@RequestMapping("/")public String home() {System.out.println(name);}public static void main(String[] args) {SpringApplication.run(ConfigClientApplication.class, args);}}　　3.2 RefreshScope 注解　　我们知道Spring原生提供了一些scope，如singleton，prototype，request等。 为了实现配置更新后，已经注入bean的值也能更新的目的，Spring Cloud提供了一个新的scope - RefreshScope。　　Spring Cloud对RefreshScope的定义如下：　　A Scope implementation that allows for beans to be refreshed dynamically at runtime (see refresh(String) and refreshAll()). If a bean is refreshed then the next time the bean is accessed (i.e. a method is executed) a new instance is created.　　所以，对于那些有注入值的bean，我们可以把它们标记为RefreshScope，这样当运行时发现有配置更新的时候，通过调用RefreshScope.refresh(beanName)或RefreshScope.refreshAll()，从而下次这些bean被使用时会被重新初始化，进而会被重新注入值，所以也就达到了更新的目的。　　3.3 ConfigClient 启动顺序　　ConfigClient最好要在ConfigServer之后启动，Spring加载配置文件是有顺序的，靠前的配置文件会覆盖靠后的配置文件中相同键的值，如果ConfigServer先启动可以保证ConfigClient将远程的配置文件加载到最前面，如果使用中没有注意到这一点，有可能导致你本地的配置文件先于远程的加载，导致本地的配置覆盖远程配置。当然，你也可以让本地配置和远程配置完全不重复，这样也可以避免键/值覆盖的问题。　　后面会进一步说明这部分相关的知识点。　　四. 背景知识　　4.1 Spring中的Environment和PropertySource　　· Environment　　Spring的ApplicationContext会包含一个Environment　　Environment自身包含了很多个PropertySource　　·&PropertySource　　属性源　　可以理解为很多个Key - Value的属性配置　　在运行时的结构形如：　　需要注意的是，PropertySource之间是有优先级顺序的，如果有一个Key在多个property source中都存在，那么在前面的property source优先。所以对上图的例子：　　·&env.getProperty(“key1”) -& value1　　·&env.getProperty(“key2”) -& value2　　·&env.getProperty(“key3”) -& value4　　在ConfigClient启动阶段，从ConfigServer获取配置，然后组装成PropertySource并插入到第一个,在随后的获取配置过程中，来自Config Server的配置和其它本地的配置对使用者而言是没有任何差别的，从而实现了无缝集成。　　需要注意的是，如果ConfigServer在ConfigClient之后启动，那远程配置将被加载到最后，这点在使用中需要特别注意。 下图是可以看到远程配置被优先加载　　4.2 /env　　/env 是 spring-boot-starter-actuator提供的一个接口，GET方法调用可以查看系统环境变量，POST调用可以更改环境变量的值，并且通过这种方式修改的变量值具有最最高优先级。通过观察了解这个接口数据的变化，对学习SpringCloudConfig有帮助。　　curl -X POST http://localhost:8080/env -d spring.datasource.username=wsh　　如果要使上述修改生效，还需要利用/refresh重新载入所有@RefreshScope修饰的bean类。　　curl -X POST http://localhost:8080/refresh　　如果要重置这些修改　　curl -X POST http://localhost:8080/env/reset　　4.3 /refresh　　使@RefreshScope修饰的bean类在下次调用时重新载入配置。　　4.4 /bus/env　　作用同/env，区别是会对所有节点生效　　curl -X POST http://localhost:8888/bus/env -d spring.datasource.username=wsh　　4.5 /bus/refresh　　作用同/refresh，区别是会对所有节点生效　　向消息broker发送一条信息，所有监听这个broker的应用会获得上述消息，并各自开始更新配置。每个SpringCloudBus的节点都有这个接口，并且这些接口是等效的，调用任何一个都可以起到相同的效果。但通常我们会调用在ConfigServer上配置的Bus，这样从流程上更符合人们的理解习惯。　　curl -X POST http://localhost:8888/bus/refresh　　五. SpringCloudBus　　SpringCloudBus并不是一个独立的服务，他配置在每个ConfigClient，并通过消息队列使所有节点感知到状态变化。SpringCloudConfig没有直接集成bus的功能是有好处的，bus是可插拔设计并且目前并不完美，如果有个性需求完全可以用自己的方案替换bus，这个剥离bus成本几乎等于零。　　目前Bus有两种实现spring-cloud-starter-bus-amqp或spring-cloud-starter-bus-kafka，官网的例子是基于amqp，需要运行RabbitMQ，本文的例子用的是Kafka。　　现在我们已经有能力在无需重启的情况下对应用程序配置进行更新了。　　六. 项目代码　　SpringCloudConfig GitHub　　七. 问题　　当代码仓库访问速度慢的时候，读取配置的速度也会慢，要考虑代码仓库的可用性　　为了增强Config Server 的高可靠性,需要按比例增加Config Server的数量　　[待完善，随时补充......]
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道