配置中心

为什么需要配置中心？

将应用程序配置数据直接写入代码中通常是有问题的，因为每次对配置进行更改时，应用程序都必须重新编译和重新部署。为了避免这种情况，开发人员会将配置信息与应用程序代码完全分离。这样就可以很容易的在不进行重新变异的情况下对配置进行更改。通严格，这样做也会引入复杂性，因为现在存在另一个需要与应用程序一起管理和部署的制品。

基于微服务的开发的配置中心要强调如下几点：

1. 应用程序的配置与正在不熟的实际代码完全分离

2. 构建服务器、应用程序以及一个不可变的镜像，他们在各个环境中进行提升永远不会发生变化

3. 在服务器启动时，需要通过环境变量注入应用程序配置信息，或者在微服务启动时通过集中式存储读取应用程序配置信息

配置文件散落在不同服务上的经历和思考

2018年09月13日 修改jdbcUrl总结

为了安全，要在今天进行数据库迁移，与之对应的jdbcUrl也需要修改。但是公司项目比较原始，并且年代久远，所以需要修改的jdbcUrl的数量也是比较多的。目前采取这样一种原始的方式：

1. 要修改的jdbcUrl大致分为两类：使用tomcat部署的web项目和japp项目

2. tomcat项目的配置文件比较统一，只可能出现在 properties 和 xml文件中，这部分的修改由运维统一修改

3. 而japp程序不太容易在服务器中更改，因为部分配置文件处于jar包内， 甚至写死在java类中，这部分将打包，交由我统一修改

在修改期间我总共遇到如下几个问题：

1. 如何搜索jar内的xml和properties文件内容？ 解压jar包，使用软件定位关键字，这里找到了一款比较强大的文本搜索工具： FileLocator

2. 如何修改jar内的xml和properties文件？ 使用压缩软件打开压缩包，提取单个文件；修改后，再拖进压缩包中即可。

3. 如何在jar：一堆class中查找关键字？

   1. 第一印象就是将class反编译为java文件，然后使用FileLocator定位，这种方式是可行的。

   2. 第一次我使用 jd-gui 工具打开jar，但是遗憾的是，该工具并未提供全局搜索的功能，我无法定位我所需的关键字，pass

   3. 第二次，同样使用jd-gui 工具打开jar ，选择 File->Save All Source 将jar反编译到一个zip文件中。这样做有两个致命的问题：1. 我要手动解压源码包， 2. jd-gui的导出速度是在是gui速。pass

   4. 第三次，使用 jad 工具替代jd-gui，是这篇文章给了我极大的帮助：http://inotgaoshou.iteye.com/blog/1089797 感谢博主 @inotgaoshou 。我将所有的jar包统一放置在一个文件夹中，将他们解压为class文件，然后对他们使用jad统一反编译到src目录下，并使用FileLocator软件进行检索，其中将class文件变为java文件，就大约花费了一个小时的时间。

   5. 在完成任务时，我又发现了一款可以替代jd-gui 和 jad的工具——jadx，可以全局搜索jar，功能比较强大，但是处理速度仍然比较慢，感兴趣的可以了解一下：<https://blog.csdn.net/Fisher_3/article/details/78654450 >

4. 如何修改替换class文件？

   1. 这是最棘手的问题，通常的思路是重新打jar。但是由于代码管理混乱，找到svn代码就已经是可能性几乎为0的事情了，所以搜索了一下，尝试使用反编译->修改->编译的方式。

   2. 经过一段时间的尝试，这类方法在第一步就遇到了很多困难，由于jar包比较大，反编译后输出出的java代码，会有很多的语法问题，根本无法通过编译 。

   3. 被迫更换方式： https://blog.csdn.net/hexin373/article/details/6669813 这种方式操作起来及其繁琐，但是通过它我找到了另一款比较好用的神器- http://www.cs.ioc.ee/~ando/jbe/ 可以直接修改字符串，总的来说完成了我的需求

所以这两天基本在找工具中度过，总的来说也算一点点的工作经验，下次在处理类似的情况下，不会这么被动。

反思：公司这次数据库迁移，从而导致大面积配置修改的情况引起了我的思考，如果下次再次发生类似的状况，是不是又要花费一两天的时间来做这些重复而没有意义的事情？

个人认为，共有以下几种方式，可以尽量减少这类问题：

1. 配置中心集中管理，配置中心还是我在学习spring-cloud中了解到的，配合cvs，配置的诸多问题都可以解决

2. 剔除可运行jar包内的有可能修改的配置：大量xml和properties文件被打包到jar内，甚至是写死到java代码中，造成了配置修改的困难。尽量将配置配置在外部文件中

公共配置集的作用

在多个服务中，可能存在相同的配置块，比如所有的服务引入的都是同一个redis连接。这个时候，即使配置文件已经被配置中心集中管理了，但是他的redis配置，仍然散落在配置中心的不同文件中。即使有100个服务需要更改redis配置，那么就需要更改100个配置文件。

所以就需要公共配置集，Nacos中就提供了公共配置集的功能：

1. 在Nacos中，可以创建一个特殊的分组，例如叫做common-configs或global-settings，用于存储所有服务共用的配置项。这个分组下的配置集（通过Data ID区分）应当包含所有服务共用的配置。

2. 在每个服务的配置管理中，除了服务特定的配置外，还可以通过Nacos客户端指定引用这个公共配置集。在Spring Cloud Alibaba项目中，可以通过在bootstrap.properties或application.properties中通过spring.cloud.nacos.config[0].shared-dataids指定公共配置文件的名称，spring.cloud.nacos.config[0].group来指定公共配置文件所属的GROUP。

使用公共配置集的注意事项

1. 动态更新与热刷新：一旦公共配置发生变化，Nacos配置中心会自动推送更新到所有订阅了这些配置的服务实例，实现了配置的即时生效和零停机更新。服务端无需重启，只需确保服务已配置好接收Nacos配置变更通知的机制，通常Spring Cloud Alibaba框架已内置此能力。

2. 版本控制：虽然可以共享配置，但也要注意配置的版本管理和回滚策略，防止因误操作导致大面积服务受影响。

3. 权限管理：公共配置由于影响广泛，应严格控制编辑权限，确保修改经过审核。

4. 命名规范：保持Data ID和Group命名的清晰规范，便于理解和管理。

哪些配置需要放到公共配置集中？

例如：

1. business-server-common-config.yml：服务端的通用配置，比如文件上传大小的限制、静态资源的映射等。

2. service-name-config.yml：在feign调用时，feign的api jar 由服务提供方提供，内部通常将服务名配置化，这是为了服务名称发生变化。这样不可避免的，所有服务消费方都需要配置服务名配置，可抽出公共配置。

3. file-common-config.yml：文件下载、文件缓存路径配置。

等其他配置，此外，一些中台、中间件是作为所有服务的基础设施提供的，可以考虑抽出单独的配置。比如，该项目下所有微服务共用一套redis集群，就可抽出公共配置，但是数据库连接通常不是公用的，就不需要抽取。