Связь, высокая доступность и микросервисы

Question

Я понимаю, что микросервисы таковы, что вы можете "просто" раскрутить несколько экземпляров одного и того же сервиса, как требуется.

Мой вопрос: если у вас есть x экземпляров микросервиса,y серверы, как что-нибудь, вызывающее API на микросервисе, знает, где его найти?

Один из подходов, которые я видел, - это иметь какую-то службу обнаружения (фиксированный IP-адрес, который может направлять к экземпляру, например,балансировщик нагрузки);но, конечно, это просто отодвигает проблему обратно на уровень - службе обнаружения необходимо знать, где все находится / когда происходит сбой и т. д.?А как насчет высокой доступности для службы обнаружения (если у вас есть несколько таких случаев, вы снова не знаете, где что-то находится)

Другой подход может заключаться в использовании обмена сообщениями pub / sub, но сновавам все еще нужно знать, где находится администратор очередей (с высокой доступностью и т. д.);таким образом, у вас все еще есть та же самая проблема - и ответы на запросы более хитры с этим подходом.

Другая связанная проблема - если у вас есть микросервис, который извлекает данные из канала STOMP, как бы вы это сделали?HA?вы не можете просто иметь x экземпляров этой службы, или вы будете подписываться и читать данные x раз, что означает, что вы в конечном итоге дублируете данные, когда они передаются в последующие системы.Таким образом, вы хотели бы какой-то активный / пассивный подход к этому, верно?Что означает, что вам нужно что-то для управления этим аварийным переключением, которое снова дает единственную точку отказа?

Answer 1

У вас может быть реестр служб, в котором служба регистрируется при запуске. Реестр может прослушивать трансляции другими службами событий регистрации, поэтому местоположение реестра не нужно фиксировать где-либо в службе.

Все остальные Сервисы могут затем использовать этот реестр для поиска доступных экземпляров, запрашивая реестр. Реестр также может действовать как распознаватель DNS, поэтому ваши службы могут использовать DNS для разрешения других служб по имени, а также автоматически распределять нагрузку между несколькими хостами.

Другим способом может быть обратное реагирование, и служба, желающая связаться с другой службой, транслирует запросы, на которые другая служба отвечает необходимой информацией (что в основном и делает DNS).

Одним из доступных решений для этого является Консул Hashi Corp . Посмотрите на предоставляемые им функции, которые могут быть дополнительно полезны, например, healthchecks.

Answer 2

Я сделал следующее:

У меня есть каждая служба, генерирующая Оглавление при запуске, которая доступна как корневой ресурс (.../{service}/).В этом ToC все конечные точки как Map.

Ключ является (общеизвестным) EndpointId, значение всегда состоит из

• title
• href
• type (mediaType)

Итак, в основном обычная ссылка.

Магия лежит в href, где общедоступный хост (DNS) настраивается как переменная среды (например, Config Map).).Из-за использования DNS, LoadBalancing и т. Д. Вне конкуренции.Но вы могли бы использовать этот подход и для внутренних IP-адресов.

Это хорошая практика, упомянутая здесь .

API-интерфейс REST должен быть введен без каких-либо предварительных знаний.начальный URI (закладка) и набор стандартизированных типов мультимедиа, которые подходят для предполагаемой аудитории (т. е. ожидается, что будет понят любым клиентом, который может использовать API).С этого момента все переходы состояний приложения должны определяться выбором клиентом предоставленных сервером вариантов, которые присутствуют в полученных представлениях или подразумеваются манипуляциями пользователя с этими представлениями.Переходы могут быть определены (или ограничены) знаниями клиента о типах медиа и механизмах связи с ресурсами, которые могут быть улучшены на лету (например, код по запросу).[Ошибка здесь подразумевает, что внешняя информация является движущей силой взаимодействия, а не гипертекста.]

Таким образом, у каждой службы есть корневой ресурс, содержащий ссылки на все конечные точки (иногда шаблонные).

Тот же самый ToC используется повторно, публикуя его в теме Kafka, называемой «конечные точки», где key - это (хорошо известный) ServiceId («fooService» или «fooService: 1.2.3») и valueявляется его ToC.

Каждый сервис также имеет доступ для чтения к теме (GlobalKTable), поэтому, когда он хочет создать ссылку на FooService, он ищет свой ToC в GlobalKTable, ищет конечную точку своейИдентификатор заменяет шаблонные переменные действительными значениями и выполняется, он не меняет type, поскольку предполагается, что он правильный.

Крутая вещь здесь (из-за Kafkas GlobalKTable и QueryableKeyStores), чтокогда FooService изменяет свои конечные точки (только непрерывно), все другие службы автоматически создают новые ссылки.Изменение DNS или переименование сегментов пути будет просто работать.переименования параметров явно нет.