我们正在开发一款产品，该产品将作为一组部署在本地的服务（例如在办公室、工厂等的本地网络中）。由于每个客户可能有很多部署目标，并且我们希望通过尽可能自动化来最大限度地减少配置工作量，因此我们正在考虑使用领事作为服务发现和配置服务器的解决方案。它满足我们的要求，并且提供服务之间的相互 TLS 认证，使得整个设置更加安全。
我们有两个基本要求：
- 这部署目标将非常多样化：一些客户会将软件部署在其员工的工作站中（因此这些工作站可以在一天结束时关闭），其他一些客户会有专用的服务器，大多数客户会同时采用两种情况（一台或两台专用服务器和几个工作站）。
- 每个客户至少会有一台机器要么永远不会关闭，要么将在其他所有机器（这是理所当然的，因为这种工作方式在我们提供给客户的手册中）。我们称这种机器为掌握。
但是，在互联网上进行研究并大量使用 Consul 之后，我们仍然对此存在一些疑问。特别是，我们需要有关 Consul 文档中要求的建议，即您的集群中至少需要 3 个实例。它是否适合我们的用例，即它将安装在我们客户员工的工作站中，可以随时关闭（即使有一个实例（我们称之为 master）始终可用）？
答案1
Consul 不适合你的用例，因为它需要有一定数量的节点可用于达成共识。与所有分布式共识系统一样，它也是一个挑剔的、不稳定的软件，它会导致比它能避免的更多的停机时间，直到你花费很多时间会解决它的所有缺点。
我曾经接到过一位前雇主的电话，乞讨我去修复他们被搞垮的 Consul 集群，因为它已经把一切都搞垮了，而且那里没有人知道如何甜言蜜语地让它恢复生机。
不要试图对服务发现进行花哨的操作；由于您有一台始终可用的机器，只需在那里粘贴某种数据库并尽情发挥即可。