Consul

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 在萌叔之前的文章里，我曾经提到过使用consul进行注册和发现的时候，consul agent默认情况下，只会转发watch请求，所以负载最终还是会施加在consul server上。 为了解决这个问题，有如下几种方案： 1.1 降低watch的频率 1.1.1 增加wait参数的值 1.1.2 打开consul agent的cache功能 不过使用consul agent的cache可能导致在一个很短的时间窗口数据不一致 1.1.3 在watch请求返回之后，增加sleep 同1.1.2 在很短的时间窗口，数据可能不一致 1.2 增强Consul Server的处理能力 官方推荐Consul Server硬件配置，可以达到816核，内存可以达到3264GB 1.3 增加Consul Server的数量 官方推荐的Consul Server的数量一般不超过5个。增加Consul Server的数量，确实可以提高整个集群的读请求的负载能力，但是由于Server数量增多，达成共识的速度可能会下降，也就是说，可能会影响写能力。 1.4 Enterprise feature: enhanced read scalability Read-heavy clusters (e.g. high RPC call rate, heavy DNS usage, etc.) will generally be bound by CPU and may take advantage of the read replicas Enterprise feature for improved scalability. This feature allows additional Consul servers to be introduced as non-voters. As a non-voter, the server will still participate in data replication, but it will not block the leader from committing log entries. Additional information can be found in the Server Performance section of the Consul product documentation. ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | 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": "dc1", "data_dir": "/data/consul", "disable_update_check": true, "server": true, "ui": true, "bind_addr": "192.168.100.3", "client_addr": "0.0.0.0", "node_name": "s1", "bootstrap_expect": 2, "retry_join": ["192.168.100.3", "192.168.100.4", "192.168.100.5"] } 5.2 client 模式 client上设置default token之后, 在client使用CLI或者执行API请求，都可以自动附加token ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | 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) 机房与机房之间 server节点之间有gossip(端口8302) 2.2 可能的瓶颈 2.2.1 client对server的RPC请求 client使用server的TCP/8300端口发起RPC请求, 管理service、kv都要通过这个端口，它们之间是长连接。 1个机房如果有3w+机器，则client和server至少要建立3w+长连接。 不过萌叔观察了一下，3w+长连接是相对均匀的分布在多个server上的，也就是说如果你有6台consul server, 那么每个server最多处理5k个长连接。还是可以接收的。 对于server的处理能力我简单压测了一下。大约是15k qps Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 4核CPU 8G内存 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | 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() } func tryLock(key string, sessionName string, wg *sync.WaitGroup) { defer wg.Done() // Get a new client config := &api.Config{ Address: "dev1:8500", Scheme: "http", } client, err := api.NewClient(config) if err != nil { panic(err) } opts := &api.LockOptions{ Key: key, SessionName: sessionName, } lock, err := client.LockOpts(opts) log.Println(sessionName, "try to get lock obj") for i := 0; i < 3; i++ { leaderCh, err := lock.Lock(nil) if err != nil { log.Println("err", err, sessionName) } if leaderCh == nil{ log.Println("err", err, sessionName) continue } log.Println(sessionName, "lock and sleep") time.Sleep(5 * time.Second) err = lock.Unlock() if err != nil { log.Fatal("err", err) } log.Println(sessionName, "unlock") time.Sleep(5 * time.Second) } } 3. 原理 consul中锁的主要是依赖KV Store和Session相关API ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | 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 很容易做到 3.2 服务发现 3.2.1 DNS方式 $ dig @127.0.0.1 -p 8600 web.service.consul ;; QUESTION SECTION: ;web.service.consul. IN A ;; ANSWER SECTION: web.service.consul. 0 IN A 127.0.0.1 我们可以通过cosul提供的DNS接口来获取当前的service “web” 对应的可用节点(详细用法见参考资料4) DNS方式要求使用方主动进行DNS解析，是主动请求的过程。它对线上服务节点的变化，反应是延迟的。 ...