版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 在萌叔的文章玩转consul(3)–大规模部署的性能开销定量分析 中,探讨了consul支持大规模集群可能出现性能瓶颈。引出可以通过拆分consul集群或者逻辑切分DC的方法,来降低consul的压力。本文将展开说明一下。 2. 解释 2.1 单个DC的情况 假设服务A依赖服务B(调用服务B), 服务A和服务B各有200个实例, 服务B注册到consul集群上, 服务A通过consul集群发现服务B。 如果服务B做滚动发布,考虑最坏的情况,每次发布一个实例, consul总共发出的通知数为 200 * 200 = 40,000 2.2 2个DC的情况 拆分成2个DC后,单个DC中,服务A和服务B各有100个实例,限制不允许跨DC调用。如果服务B做滚动发布,考虑最坏的情况,DC1和DC2同时发布,每次发布一个实例,consul总共发出的通知数为 100 * 100 + 100 * 100 = 20,000 3. 总结 当服务的规模很大时,即使拆分成2个DC,服务整体的高可用能力不会受到影响。对比2.1和2.2,consul集群的压力减少了一半。另外咱们之前提过,单个DC中consul集群(server)的规模不宜过大,否则会影响日志复制、还有选主的速度。拆分到2个DC后,原有的consul集群也被拆分成了2个集群,单个DC中consul集群的规模下降了,这样还给我们留出扩容的余地。 后记 2022年1月29日 用单元化的思想(见参考资料1、2)来解决注册中心压力大的问题与我文章中提到的,划分逻辑DC的思想不谋而合。 参考资料 1.单元化架构解决了什么问题 2.单元化介绍 请我喝瓶饮料

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 本文基于Consul v1.6.2 这篇文章并不是consul ACL的完全配置手册,感兴趣的读者请阅读参考资料1 2. Token存在的意义 Token其实用于权限控制中,表征使用者的身份 Consul的ACL中重要的3个实体 Token最终与一组Policy关联, 可以理解为RBAC(基于角色的访问控制)中的权限。 3. 能够细粒度控制的权限有哪些? 4. 如何使用Token 详见参考资料2 curl \ –header “X-Consul-Token: <consul token>” \ http://127.0.0.1:8500/v1/agent/members 其实也可以附加在Query中,但官方不推荐 5. 配置文件示例 5.1 server模式 { “acl”: { “enabled”: true, “default_policy”: “deny”, “enable_token_persistence”: true }, “datacenter”:… 继续阅读 玩转consul(4)-ACL机制要点

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 今天有朋友问萌叔,consul能否在大规模生产环境下进行应用。场景是总计大约10w+台机器,分为3 ~ 4个机房,单个机房最多3w万+机器。这个问题大的,可把萌叔吓了跳,部门里面consul集群的规模也就是1k+, 还分好几个机房。 不过他的问题确实也让我十分好奇,consul是否有能力支撑这么规模,我决定针对每个可能性能瓶颈进行定量分析 2. 分析 在进行分析前,我们来看看可能遇到瓶颈有哪些? 下图是consul在多DC情况下的体系架构图 2.1 明确一些概念 consul agent分2种模式server模式和client模式。在每个机房consul server(以下简称为server)会部署3 ~ 5台, 其余的consul节点都是consul client(以下简称为server)。 server的数量不宜过多,否则选主的速度会变慢 数据(包括kv数据,service信息,node信息)都是分机房存储的,由所在机房的server负责。如果需要请求其它机房的数据,则server会将请求转发到对应的机房。 比如dc1的某个应用app1想要获取dc2中key “hello”对应的值 过程如下 app1 –> client –> server(dc1) –> server(dc2) 如果读者仔细观察会发现,consul中,很多api都是可以加上dc参数的 consul kv get hello -datacenter dc2 每个dc的所有server构成一个raft集群,client不参与选主。注意上图的leader和follower标识。 单个机房内部consul节点之间有gossip(端口8301)… 继续阅读 玩转consul(3)–大规模部署的性能开销定量分析

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 分布式锁的场景,大家应该都有遇到过。比如对可靠性有较高要求的系统中,我们需要做主备切换。这时我们可以利用分布式锁,来做选主动作,抢到锁作为主,执行对应的任务,剩余的实例作为备份 redis和zookeeper都可以用来做分布式锁,典型的如redis,可以使用SETNX命令来实现分布式锁。本文将介绍基于consul的分布式锁实现 2. 例子 测试例子 test_lock.go package main import ( “github.com/hashicorp/consul/api” “log” “strconv” “sync” “time” ) func main() { wg := &sync.WaitGroup{} for i := 0; i < 3; i++ { wg.Add(1) go tryLock(“mylock”, “session”+strconv.Itoa(i), wg) } wg.Wait() }… 继续阅读 玩转CONSUL(2)–分布式锁

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 consul 经常被用于服务的注册和发现,本文将带你对watch做更深入的探究 2. consul对外暴露了4种通讯接口 2.1 RPC 主要用于内部通讯Gossip/日志分发/选主等 2.2 HTTP API 服务发现/健康检查/KV存储等几乎所有功能 默认端口为8500 2.3 Consul Commands (CLI) consul命令行工具可以与consul agent进行连接,提供一部分consul的功能。 实时上Consul CLI 默认就是调用的HTTP API来与consul集群进行通讯。 可以通过配置CONSUL_HTTP_ADDR 修改Consul CLI连接的目标地址 export CONSUL_HTTP_ADDR=http://127.0.0.1:8500 详见参考资料3 2.4 DNS 仅用于服务查询 3. 服务注册&发现 3.1 服务注册 服务注册可以通过 服务注册接口 /agent/service/register 很容易做到… 继续阅读 玩转consul(1)–watch机制探究