configServer

Spring Cloud 配置变化监听

微笑、不失礼 提交于 2020-08-05 01:09:40
Spring Cloud 配置变化监听 背景 开发中遇到个需求,期望可以在配置变更的时候,监听配置的变化,做一些逻辑处理,原生ApplicationEvent已经有发出对应的配置更新事件,但是包含的是所有的变更,开发人员一般只关心自己需要的配置变更 原生事件发出EnvironmentChangeEvent(如spring cloud config)或RefreshEvent(nacos 最终也会发EnvironmentChangeEvent事件) 对此我们可以基于EnvironmentChangeEvent,最一层包装,封装我们自己需要的事件 使用 先看下效果,直接基于EventListener捕获ConfigRefreshEvent,condition使用el表达式配置需要监听的key,针对集合或map 可以使用正则匹配 @EventListener(condition = "#event.key eq 'sys.loglevel.root'") void handleConditionalListener(ConfigRefreshEvent event) { // 业务逻辑 balabala System.out.println("handleConditionalListener event key :" + event.getKey() + ", before :" +

SpringCloud之Config

▼魔方 西西 提交于 2020-07-27 13:02:22
配置中心,也就是SpringCloud中的Config组件,主要应用在哪些方面? 配置文件方便维护 配置文件内容安全和权限 更新项目配置不需要重启 本文主要围绕两个方面,一个是Config Server,另一个是Config Client。还是以我个人博客系统其中的一个模块为例。 一、搭建Config Server 1.Maven依赖 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> </dependencies> 2.添加主类 package

MongoDB的集群模式--Sharding(分片)

大兔子大兔子 提交于 2020-05-02 11:10:12
分片是数据跨多台机器存储,MongoDB使用分片来支持具有非常大的数据集和高吞吐量操作的部署。 具有大型数据集或高吞吐量应用程序的数据库系统可能会挑战单个服务器的容量。 例如,高查询率会耗尽服务器的CPU容量。 工作集大小大于系统的RAM会强调磁盘驱动器的I / O容量。 有两种解决系统增长的方法:垂直和水平缩放。 垂直扩展 涉及增加单个服务器的容量,例如使用更强大的CPU,添加更多RAM或增加存储空间量。 可用技术的局限性可能会限制单个机器对于给定工作负载而言足够强大。 此外,基于云的提供商基于可用的硬件配置具有硬性上限。 结果,垂直缩放有实际的最大值。 水平扩展 涉及划分系统数据集并加载多个服务器,添加其他服务器以根据需要增加容量。 虽然单个机器的总体速度或容量可能不高,但每台机器处理整个工作负载的子集,可能提供比单个高速大容量服务器更高的效率。 扩展部署容量只需要根据需要添加额外的服务器,这可能比单个机器的高端硬件的总体成本更低。 权衡是基础架构和部署维护的复杂性增加。 MongoDB支持 通过 分片进行 水平扩展 。 一、组件 shard :每个分片包含分片数据的子集。每个分片都可以部署为 副本集(replica set )。可以分片,不分片的数据存于主分片服务器上。 部署为3成员副本集 mongos :mongos充当查询路由器,提供客户端应用程序和分片集群之间的接口

mongodb副本集加分片集群安全认证使用账号密码登录

寵の児 提交于 2020-05-02 07:23:12
mongodb副本集加分片集群安全认证使用账号密码登录 2017年12月05日 20:48:59 大伟爱自由 阅读数 8298更多 分类专栏: mongoDB 版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 本文链接: https://blog.csdn.net/uncle_david/article/details/78713551 mongodb副本集加分片集群搭建网上资料有很多。粘贴一个写的比较好的。 副本集加分片搭建 对于搭建好的mongodb副本集加分片集群,为了安全,启动安全认证,使用账号密码登录。 默认的mongodb是不设置认证的。只要ip和端口正确就能连接,这样是不安全的。mongodb官网上也说,为了能保障mongodb的安全可以做以下几个步骤: 1、使用新的端口,默认的27017端口如果一旦知道了ip就能连接上,不太安全 2、设置mongodb的网络环境,最好将mongodb部署到公司服务器内网,这样外网是访问不到的。公司内部访问使用vpn等 3、开启安全认证。认证要同时设置服务器之间的内部认证方式,同时要设置客户端连接到集群的账号密码认证方式 环境准备 最简单的集群是3*3,即三个分片和三个副本集,可以保证高可用,即使一台机器全宕机了,服务仍然能够正常访问。 mongodb版本:mongodb

springcloud 入门 8 (config配置中心)

假装没事ソ 提交于 2020-05-01 07:25:58
Spring Cloud Config:   配置中心为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件,它就是Spring Cloud Config.   在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring cloud config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。在spring cloud config 组件中,分两个角色,一是config server,二是config client。  服务端搭建:   第一步:创建一个springcloud的项目,重新开发,和前面几章创建的项目没有关系了。后期会整合起来的。pom如下:        第二步:启动类配置: @EnableConfigServer        第三步:修改配置文件:application.yml             第四步:启动服务端进行测试:     github上的配置文件目录如下:              启动项目后,访问zuul-dev的配置文件,有两类访问方式:        第一种,rest访问:                  第二种:直接对应文件名称访问           

009.MongoDB分片群集部署

独自空忆成欢 提交于 2020-05-01 02:42:02
一 前期准备 1.1 组件说明 MongoDB分片群集包含以下组件: shard:每个分片是分片数据的子集。从MongoDB 3.6开始,必须将分片部署为副本集。 mongos:mongos充当查询路由器,提供客户端应用程序和分片集群之间的接口。 config servers:配置服务器存储群集的元数据和配置设置。从MongoDB 3.4开始,必须将配置服务器部署为副本集(CSRS)。 注意:mongos不需创建复制集,config不需指定主副节点及仲裁节点,但是要创建复制集。 1.2 组件规划 本实验基于生产环境考虑,组件规划如下: 将Config Server部署为3成员副本集; 将每个Shard部署为3成员副本集,总共部署三个shard; 部署两个mongos路由器。 提示:部署多个mongos路由器支持高可用性和可伸缩性。常见的模式是mongos在每个应用程序服务器上放置一个,可以减少应用程序和路由器之间的网络延迟。 也可以将mongos路由器放在专用主机上,通过用于大型规模部署。因为它将客户端应用程序服务器的数量与mongos实例数量分离。这样可以更好地控制mongod实例所服务的连接数。 注意:mongos路由器部署的数量没有限制。但是,由于mongos路由器经常与Config Server通信,因此在增加路由器数量时会密切监视配置服务器性能。如果发现性能下降

mongodb单机和分布式安装部署过程

ぐ巨炮叔叔 提交于 2020-05-01 02:41:40
mongodb 1.部署 a. 单机部署 1.配置MongoDB的yum源 创建yum源文件: vim /etc/yum.repos.d/mongodb-org-3.4.repo 添加以下内容: [mongodb-org-3.4] name=MongoDB Repository baseurl= https://repo.mongodb.org/yum/redhat/ $releasever/mongodb-org/3.4/x86_64/ gpgcheck=1 enabled=1 gpgkey= https://www.mongodb.org/static/pgp/server-3.4.asc 这里可以修改 gpgcheck=0, 省去gpg验证 安装之前先更新所有包 :yum update (可选操作) 2.安装MongoDB 安装命令: yum -y install mongodb-org 安装完成后 查看mongo安装位置 whereis mongod 查看修改配置文件 : vim /etc/mongod.conf 3.启动MongoDB 启动mongodb :systemctl start mongod.service 停止mongodb :systemctl stop mongod.service 查到mongodb的状态:systemctl status mongod

MongoDB高可用集群搭建(主从、分片、路由、安全验证)

怎甘沉沦 提交于 2020-05-01 02:14:12
目录 一、环境准备 1、部署图 2、模块介绍 3、服务器准备 二、环境变量 1、准备三台集群 2、安装解压 3、配置环境变量 三、集群搭建 1、新建配置目录 2、修改配置文件 3、分发其他节点 4、批量启动 5、创建配置服务器副本集 四、集群测试 1、启动路由服务器客户端 2、插入数据 3、验证主从 5、web控制台(浏览器访问) 1、登陆路由服务器 2、串联路由和分片副本集 3、查看分片服务器的配置 4、数据库的分片设置 5、验证分片 七、高可用验证 1、测试集群的高可用性 2、查看sharding status 3、查看数据库配置信息 八、集群安全验证 1、Key生成 2、配置文件修改 3、增加权限实例 4、针对于数据库 siger建用户 九、安全管理 1、查询数据库所有用户 2、查询数据库角色 3、修改权限 MongoDB高可用集群搭建(主从、分片、路由、安全验证) 一、环境准备 1、部署图 集群部署图1 集群部署图2 图片来源于网络 2、模块介绍 Shard服务器:使用Replica Sets确保每个数据节点都具有备份、自动容错转移、自动恢复的能力。 配置服务器:使用使用3个配置服务器确保元数据完整性。 路由进程:使用3个路由进程实现平衡,提高客户端接入性能 3 个分片进程:Shard11,Shard12,Shard13 组成一个副本集,提供Sharding 中

MongoDB Sharding分片配置

谁都会走 提交于 2020-05-01 00:05:52
Ps:mongod是mongodb实例,mongos被默认为为mongodb sharding的路由实例。 本文使用的mongodb版本为3.2.9,因此参考网址为: https://docs.mongodb.com/v3.2/sharding/ 此外最后几个部分还引用了 https://yq.aliyun.com/articles/60096 中的一些问题描述及解决方案。 一、Sharding集群简介 1.数据分片(Shards) 用来保存数据,保证数据的高可用性和一致性。可以是一个单独的mongod实例,也可以是一个副本集。在生产环境下Shard一般是一个Replica Set,以防止该数据片的单点故障。可以将所有shard的副本集放在一个服务器多个mongodb实例中。 sharding的每个node的database中的集合可以是分片也可以不分片,每个db都有一个primary shard,未分片的集合就是存在其各自的primary shard中的。 2.查询路由(Query Routers) 路由就是mongos的实例,客户端直接连接mongos,由mongos把读写请求路由到指定的Shard上去。 一个Sharding集群,可以有一个mongos,也可以如上图所示为每个App Server配置一个mongos以减轻路由压力。 注意这里的mongos并不要配置为rs

快速掌握mongoDB(六)——读写分离的副本集实现和Sharing介绍

隐身守侯 提交于 2020-04-28 12:57:44
1 mongoDB副本集 1 副本集简介   前边我们介绍都是单机MongoDB的使用,在实际开发中很少会用单机MongoDB,因为使用单机会有数据丢失的风险,同时单台服务器无法做到高可用性(即当服务器宕机时,没有替代的服务器顶上来,我们的业务也就挂了),MongoDB中的副本集可以完美地解决上边的两个问题。   MongoDB的副本集本质上就是一组mongod进程。复制集的成员有:     1.Primary:主节点,负责所有的写操作;     2.Secondaries:从节点,同步主节点的数据,保存数据副本;     3.Arbiter:仲裁节点,不保存数据,只有一个投票的作用;   副本集运行过程:主节点是集群中唯一一个负责写操作的节点,主节点的写操作都会记录在其操作日志(oplog,是一个 capped collection )中,从节点复制主节点的oplog日志并执行日志中的命令,以此保持数据和主节点一致。副本集的所有节点都可以进行读操作,但是应用程序默认从主节点读取数据。当主节点一段时间(当前默认为10s)不和从节点通信,集群就会开始投票选取新的主节点。下图来自官网,描述了一个一主两从的副本集的结构,应用程序的读写操作默认都是通过主节点进行的。 2 副本集搭建   MongoDB的副本集搭建并不复杂,这里简单演示一下搭建过程。搭建mongoDB副本集时