3个版本

使用旧的Rust 2015

0.0.3 2015年7月27日
0.0.2 2015年7月27日
0.0.1 2015年7月27日

#9#meet

Apache-2.0

10KB
171

Discotech 🌐

连接特殊服务的完美场所。

美式酸黄瓜

当使用分布式系统的工程师看到现有的开源服务发现和负载均衡机制时,他们会对这些机制感到些许不适,于是产生了Discotech。

  • DNS A记录适用于高效地将名称分发到尊重TTL或短生命周期的客户端。大多数开源基础设施忽略了DNS TTL。工程师知道如何编写指数退避,但很少在后端不可用时重新解析。如果在故障期间重新解析,但后端只部分不可用,你的基础设施中的配置可能会出现分裂,直到重新配置的部分不可用服务完全禁用。A记录不包含端口信息,因此后端的所有实例都使用相同的端口是常见的,这给操作和利用率带来了额外的约束。
  • 在需要集中本地服务发现和负载均衡逻辑的情况下,使用本地代理/使节是很不错的。通常,本地代理会在端口上监听,以便本地客户端连接并发送请求,然后将其转发到选定的下游。在某些情况下,本地客户端将尝试连接到 "some-service.some-cluster.some-dc.some-domain.some-tld",DNS系统将返回一个特定的魔法IP地址,该地址触发一个转发规则(可能使用iptables/nftables/ipfw/pf等...)转发到local-host:service-specific-port,其中本地代理正在监听。一些代理使用类似于splice(2)的零拷贝机制来避免由于复制请求而产生的性能损耗。仍然有一些额外的开销,因为客户端每次向套接字写入时都需要等待代理通知新数据,然后调用splice。代理无法智能地设置SPLICE_F_MORE,因为它不知道客户端何时完成发送,这导致一些优化技术变得不可能。另一个问题是,你仍然需要一个外部机制来将所需的服务映射到本地代理端口。
  • 当只有单个后端且不需要负载均衡逻辑时,使用转发逻辑如iptables是可以的。否则,你将需要依赖外部机制。

Discotech是一种有用的恶意软件 - 钩子getaddrinfo和connect。这允许各种高性能和灵活的模式

  • 服务发现
  • 负载均衡
  • 连接预取
  • 通过在getaddrinfo钩子中将一些SRV地址映射到魔法IP,并在connect钩子中交换魔法IP和任意端口到所选后端进行SRV-over-A。

配置

  • 努力避免由于相邻层的问题而导致的不可用性放大
  • 从可配置的来源接收更新:ZK、DNS SRV、平面文件等...
  • 忽略急剧下降(假解配置)
  • 缓存最后已知的好结果

依赖项

~4.5MB
~88K SLoC