「java统一配置中心」java配置中心都有哪些
今天给各位分享java统一配置中心的知识，其中也会对java配置中心都有哪些进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、能运行Java的电脑的最低配置
- 2、Disconf原理及分布式配置中心的一般实现思路
- 3、Spring Cloud Config（统一配置中心）
- 4、微服务架构实践 - 你只懂docker与spring boot就够了吗？
- 5、SpringCloud Alibaba组件
能运行Java的电脑的最低配置
我以前刚刚学JAVA的时候，用的myeclipse6.0+oracle9i+tomcat，电脑配置是512MB内存，单核CPU（2.4GHZ），偶尔有点卡，但是整体还是运行流畅，我想这就是最低配置了吧。主要是内存和CPU一般的就可以了，随便来来个双核+1G内存条，毫无压力了。
Disconf原理及分布式配置中心的一般实现思路
因为新公司没有采用独立的配置中心,每次修改配置参数只能通过手动修改配置文件的方式,然后再重启重启重启,而且机器又是多台,这种方式无疑是非常低下的,而且极容易出错,所以才有了下面的配置中心选型。
其实自己开发一个简单的配置中心也是非常容易的,基于redis+DB就能简单实现。但是要设计一个合格的配置中心还需要考虑如下几点:
所以要自己开发一个独立的配置中心,还是要考虑得比较全面的。而且项目还是以业务为主,也没有足够人力来重新开发一套配置中心,所以就打算借助于开源的力量来满足目前的使用场景。
因为现在的配置中心还是有一些开源实现的。像百度的Disconf,阿里的Diamond,携程的Apollo,还有基于Github的pull模式来实现。我为什么选择Disconf,主要有下面几个点的考量:
Disconf是百度的一个分布式配置中心,目前已经开源。而且它是基于java实现的,有简单的配置页面，而且官方还提供了一个相对完善的 文档 .开发者只需按照它上面的步骤来即可安装,但是官网的安装文档比较扯淡,总结起来就是如下几点:
然后启动Nginx.
Disconf主要是依靠zookeeper的Watch机制来做配置实时修改的,我们都知道ZK是通过目录挂载的方式来做服务的自动注册与发布。客户端启动时注册了一个回调接口,当zk目录发生变化时会回调所有客户端节点,从而做到"实时"更新配置的目的。
在配置中心添加的配置数据都被持久化到了DB中,每次客户端启动的时候会调用Disconf的Http接口获取最新的配置数据,如果网络不通,默认会重试三次,如果还不通,则抛出异常。如果第一次拉取配置就有问题,作为配置中心来讲是肯定是无解的,需要客户端去解决（一般这种情况是网络问题或者配置中心服务不可用导致）。
我们这里不需要考虑第一次加载配置就失败的情况.那么问题来了：
答案:不会,因为disconf会单独起一个线程做重连操作。
答案:没有做这方面的保证。因为客户端连接到配置中心上以后会将机器名挂载到zk目录下,可以通过界面查看配置使用的机器数。
所以要使用一个开源产品,还是要尽可能的掌握它,如果有太多未知因素在里面的话,出了问题很难被发现,对自己也是一个提升。
Spring Cloud Config（统一配置中心）
pom.xml
Application.java
application.yml
测试访问：
pom.xml
bootstrap.yml
注意：如果Eureka端口被修改，则eureka.client的配置不能放到git远端
Server端和Client端的pom.xml加上
测试启动成功后在RabbitMQ上查看bus是否创建了消息队列
docker安装RabbitMQ -
暴露bus-refresh接口，在Server端application.yml加上
在需要刷新配置的地方加上注解@RefreshScope，例如：
测试发送post请求刷新配置：
开源中国gitee的WebHooks目前和SpringCloud Config组件不兼容，所以只能用github的WebHooks
url必须为外网地址，可以使用netapp.cn获取免费隧道
SpringCloud Config组件提供了用于WebHooks的路由叫做monitor
微服务架构实践 - 你只懂docker与spring boot就够了吗？
背景
随着公司一年多的成长，我们已经开发了数十个项目了，后台有JAVA的有PHP的，为了更好地提升开发与管理效率，各技术大牛小牛们时常进行激烈的PK，碰撞出了许许多多爱的火花，比如其中之一：微服务实践
设计
只需要有一套BASE微服务，BASE微服务生成业务系统微服务实例，供各个业务系统调用；业务系统不直接调用BASE，只能调用微服务INSTANCE。
这是运维的问题，让运维去解决，运维使用工具，实际也不算困难，反正执行的都是脚本，不需要手工操作。
单点故障影响全局，我们选择了稳定更重要；另外saas的话，为了应对不同行业，会存在过度设计的嫌疑；私有化更容易。
调用逻辑
设计理念
非模块化，谈不上微服务，比如我们上面的用户微服务、产品微服务、地址微服务等，都需要先模块化，为了更好地落实开发，你可能不得不，边模块化边微服务，模块化的时候要注意，不能有关联查询，包要完全独立，到时候微服务才能拆开。
松耦合表示我们模块之间不直接依赖，无状态，可以单独地为外界提供服务；
强内聚是指，我们虽然要拆分成一个个小的微服务，但是也要考虑某些功能的强关联性，比如一个凳子是由四个脚与一个板组成，我们不能把四个脚与板分开售卖，就没有意义了。
开发
spring-boot :较springmvc更加简约了，springmvc有一大零的配置文件，比如spring-servlet、spring-mybatis、spring.xml与web.xml，这些在spring-boot都不需要了，只需要强大的注解功能即可，boot更合适微服务。
spring-cloud :里面有比较多组件，用于支持微服务，比如spring cloud config统一配置中心，用于多环境的配置文件配置，大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了；spring cloud eureka用于服务注册与发现，下面有单独介绍；其它的组件大家可以去官网看看，这里不一一介绍，总之如果JAVA平台，尽量使用spring体系的内容。
我们采用mysql，因为我们是应用多，但数据量单表并不算大，多则不超过百万，mongodb也实验过，开发非常快，也非常灵活，但因为不是关系型数据库，维护成本较高。
RESTFUL ：URL的资源与操作解耦，让URL更加符合语义，上百个接口也非常好管理，网上有很多文章讲得非常透彻，这玩意不是特别好理解，要多领悟，在项目中实践，就有矛塞盾开的感觉，这里不做详细介绍。
接口文档swagger ：比起传统全手工写接口文档，swagger有统一的输出格式，不管是几个人写的；swagger采用写代码的方式来写接口文档，以前修改了代码，还必须打开wiki手工修改接口文档，现在只需要修改一下代码即可，程序员更愿意修改了，成本更低了，前端与其它调用者不会天天吼着，你这接口咋又变了，新加的字段是啥意思呀。
RocketMQ：一直纠结kafka与rocketMQ，最终选择了RocketMQ
为了性能上面的考虑，尽量使用异步编程，比如注册送优惠券，那么注册成功就可以给用户返回注册成功了，但是送优惠券可以是异步调用的，不阻塞注册的线程。
微服务框架下，日志不可能还分散在各个服务节点上，必须有统一的日志中心。ELK是一个实时日志分析平台，就是将各个服务的日志汇总于日志中心，然后可以按照系统、节点等进行搜索，除上述搜索条件外，我们还在各个微服务实现了按照业务id（一次请求生成一个业务id）与用户id搜索日志，方便跟踪与定位问题。
当然可能有更加轻量级与好用的disconf或spring cloud config，但是我们有php开发的应用，以上二者都不支持。如果全是JAVA应用，采用disconf还是非常不错的。
测试
每个程序员都有这样的经历，刚上线，客户又反馈了bug，原来是我们修改某个功能代码的时候，导致了其它功能的bug，每次上线心里都没底；这就体现了接口测试的必须性，尤其是每次版本升级的时候，都需要执行一遍，以防修改某个接口导致其它接口报错，比手动测试靠谱许多。
部署
docker已经家喻户晓了，这是继虚拟机以后，又一重大变革，将所有的单个微服务都放在docker中，这样你何时何地想部署，直接丢过去就OK了，快到爆。
用几句简单的命令就搞定了负载均衡，而且还可以平滑升级，版本升级的时候，大家就不用告诉客户：系统通知，某日某晚00:00-08:00我行处于系统升级维护中，大家不要去取钱哦，因为你可能取不出来，呵呵。
升级
我们采用工具flyway，可以对数据库脚本进行版本控制。
传统的版本升级，
1.开发推代码并同时记录自己提交了哪些文件；
2.项目经理根据svn审核文件，并打包成war包；
3.投到测试环境让测试公司测试；
4.中途修改了文件，可能需要重新打包；
….
我都写不下去了，项目经理像个超人似的。
现在用持续集成（CI）非常简单，我们用的工具是Jenkins，推完代码，点几下按钮就完成了上线，不管是测试环境，还是生产环境都非常简单，不然项目经理核对文件眼睛都绿了。
结尾
本文主要是介绍微服务开发上的选型，对于细则不做深究，大家感兴趣可以了解下各个组件。当然，我们的选型未免正确，不同场景应用可能完全不同，本文仅供参考。
SpringCloud Alibaba组件
一.组件组成
二. 各个组件的介绍
2.1. Gateway
GateWay是在spring生态系统上构建的API网关服务,它是基于springboot2,spring5,和project Reactor等技术
2.1.2 作用:
2.1.3优势
性能方面比zuul要好,因为gateway是基于webFlux框架实现(底层是Reactor模式的netty)
2.1.4 特点
2.1.5 为什么选择gateway?
3.三大核心概念
路由: 是构建网关的基本模块,他由id,目标url,一系列的断言和过滤器组成,如果断言为true则匹配该路由.
断言:
过滤: 过滤请求用的
4.工作流程
路由转发+ 过滤器链
二: config 分布式配置中心
1. 产生背景: 微服务项目中会根据业务来拆分成一个个子服务,而每个服务都会有自己的配置文件为了统一管理,所以configserver应运而生了.
2.概念:
springcloud config 为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为 各个不同的微服务 应用的所有环境提供一个 中心化的外部配置 .
3.作用:
1. 为了集中式和动态的管理配置信息
2.运行期间动态调整配置不在需要在每个服务器上部署的机器上编写配置文件,服务会向配置中心统一拉取配置信息
3.动态加载配置信息,服务不用重启就可以感知配置的变化并应用配置
4.把配置信息以rs风格接口的形式暴露(post或curl命令)
ps: 其实就相当于项目里的公共模块,一个意思
那我们如何使用它呢?
一. 首先config分为客户端和服务端.
二. 服务端其实就是我们常说的 分布式配置中心 ,它是一个独立的微服务应用, 可以用来连接配置服务器并为客户端提供获取配置信息,加密,解密信息等接口.
三. 而客户端是通过指定的配置中心来管理应用资源,这样有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理来访问配置内容.
四.分布式配置动态刷新问题
实现步骤:
1.pom里添加actuator监控
2.yml 暴露监控端点
3. 启动类上加 @RefreshScope
4.curl -X POST " "(每次修改后必须执行这个,否则客户端还是读取不到最新的配置信息)
五. 如果有多个客户端,难道每个微服务都要执行一次post命令?
可不可以只改一处,让其他的地方都生效
三. Bus 消息总线
1.概念
springcloud Bus 是用来将分布式系统的节点与轻量级消息系统链接起来的框架,它整合了java的时间处理机制和消息中间件的功能
五. Nacos
1. 概念
nacos是一个更易于构建云原生应用的动态服务发现, 配置管理和服务管理平台.
2. 各个配置中心对比
六 . Sentinel
1.概念
把流量作为切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性.
七. Seata
1. 概念
阿里巴巴开源产品,一个易于使用的高性能微服务分布式事务解决方案.
关于java统一配置中心和java配置中心都有哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。