Мы разрабатываем продукт, который будет работать как набор сервисов, развернутых локально (например, в локальной сети офиса, завода и т. Д.). Поскольку для каждого клиента может быть множество целей развертывания, и мы хотим свести к минимуму усилия по настройке за счет максимальной автоматизации, мы думаем об использовании консул как решение для сервера обнаружения и настройки сервисов. Это отвечает нашим требованиям, а также обеспечивает взаимную аутентификацию TLS между сервисами, делая всю настройку более безопасной.
У нас есть два основных требования:
Однако, проведя исследования в Интернете и много поиграв с Consul, мы все еще сомневаемся в этом. В частности, нам понадобится совет по требованию от Consul docs, что вам необходимо как минимум 3 экземпляра в вашем кластере. Подходит ли он к нашему сценарию использования, в котором он будет установлен на рабочих станциях сотрудников наших клиентов, которые могут быть отключены в любое время (даже при условии, что один экземпляр, который мы называем мастером, всегда будет доступен)?
Consul не подходит для вашего варианта использования, поскольку предполагает наличие кворума узлов, доступных для консенсуса. Кроме того, как и все системы распределенного консенсуса, это привередливое ухищрение, которое вызывает больше простоев, чем предотвращает, пока вы не потратите много времени проработка всех его слабостей.
Однажды мне позвонил бывший работодатель, попрошайничество мне починить их обтянутый шлангом кластер Consul, потому что он все снес, и никто из оставшихся там не знал, как вернуть его к жизни.
Не пытайтесь фантазировать с обнаружением сервисов; поскольку у вас есть одна машина, которая всегда будет доступна, просто вставьте на нее какую-нибудь базу данных и начните с ума.