Должны ли / могут ли коммунальные микросервисы объединяться со всеми иждивенцами, если они не могут функционировать без микросервисов коммунальных служб?

Question

TL; DR: Если вы анализируете какую-либо конкретную архитектуру микросервисов и объединяете сервисы A и B вместе, чтобы избежать A не работает, потому что B сломался (потому что он сильно зависит от B , и согласно спецификации проекта A не может выполнить запрос, если B неисправен), учитывая достаточное количество итераций, разве вы не собираетесь в итоге получить монолитную архитектуру?

---

Этот вопрос был недавно задан в нашей компании, и я боюсь, что онпринятие близорукого решения.

Краткое описание архитектуры:
- это наша первая система, использующая микросервисную архитектуру
- у нас есть N количество микросервисов (в частности, каждый микросервис представляет собой JARработает в модуле kubernetes в кластере)
- Каждый JAR предоставляет один сервис (например, auth, users, images ...) через HTTP API
- 99% наших сервисов требуютавторизация пользователя, но без аутентификации (это делаетсяНа другом уровне наш сервис предполагает, что если запрос достиг его, заголовок запроса содержит действительный пользовательский токен
- чтобы перевести пользовательский токен в нечто материальное (например, информацию о пользователе)), мы делаем запрос к службе users
- В настоящее время каждая служба делает это, чтобы проверить, соответствует ли пользователь некоторым критериям, относящимся к услуге.

Теперь на совещании несколько старших разработчиков выразили обеспокоенность тем, что если users по какой-то причине не удастся (не обязательно что-то связанное с программным обеспечением, давайте просто предположим, что машины, выделенные для этих служб, неисправны), всеперестанет работать, делая это (по их мнению) квазимонолитной архитектурой с дополнительными шагами.Чтобы избежать этого, они предлагают преобразовать службу users в статическую библиотеку и добавить в качестве зависимости все службы, которым она требуется, чтобы каждая служба содержала эту функцию сама по себе, а не в зависимости от удаленного API.

Но разве это не проблема спецификации , а не проблема архитектуры?Это не то, что images API (технически говоря) не может функционировать без users, просто в текущей спецификации проекта не определено, что он должен делать в этом случае, поэтому он простопроисходит сбой, как будто сама служба неисправна .

Причина, по которой я лично считаю, что это недальновидное решение, заключается в том, что можно утверждать, что любой вид связи между микросервисами можно считать таковымриск.Этот случай - просто очень очевидная потенциальная точка отказа и первая итерация анализа «что может сломать».С достаточным вниманием к нему любая конечная точка, используемая многими службами, может обрабатываться одинаково, если не указан «план B» (например, если изображение не может быть получено из службы image, используйте предопределенное изображение заполнителя)

Answer 1

У меня 2 комментария к вашей теме:

• Re: спецификация. Вы определяете «альтернативное» поведение для ситуации, когда конкретная вещь терпит неудачу.

  Пример : сервис изображений запрашивает информацию об авторе у сервиса пользователей для отображения информации о том, кто загрузил изображение.

  Насколько я понимаю, вы решили отклонить запрос изображений, если сервис изображений не может получить информацию об авторе. Вы могли бы выбрать отображение имени автора как «N / A» или просто не отображать какую-либо информацию пользователя вместе с изображением, если служба пользователя недоступна.

  Вы определяете альтернативный путь. Теперь, конечно, есть плюсы и минусы для каждого пути и действительно зависит от сценария.

• Re: архитектура.

  ИМХО, я думаю, одним из преимуществ архитектуры микросервисов является изоляция отдельных сервисов. Я не знаю вашу текущую архитектуру, но в традиционных микросервисах я бы ожидал, что пользовательский сервис будет иметь изолированное хранилище и предоставит интерфейс HTTP (или RPC и т. Д.) Для других сервисов, чтобы получить эту информацию.

  Если вы начнете использовать ее в качестве библиотеки, вы попадете по пути, по которому, как только вы измените свою библиотеку «пользовательского сервиса», вам придется обновить ее во всех сервисах, в противном случае различия в схеме или бизнес-логике будет разыгрываться со временем. В худшем случае создание последовательной зависимости для обновления ...

  Я думаю, вы просто должны принять, что ваш пользовательский сервис является критически важной частью вашей архитектуры, и действительно приложить усилия для того, чтобы сделать его высокодоступным, т. Е. Обеспечить его развертывание хотя бы на нескольких разных хостах (или даже в регионах, если вы поддержите это)

Answer 2

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

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

2. Везде, где это целесообразно, исследовать возможность введения материализованных представлений в отдельной базе данных услуг с материализованным представлением и источником событий и сбором данных об изменениях (предпочтительно на основе журнала)

3. Изучите возможность использования аварийного отклика с автоматическим выключателем. Обратите внимание, что если бесплатный пользователь хочет смотреть видео премиум-класса, когда пользовательский сервис не работает, Business может захотеть позволить бесплатному пользователю просматривать видео, а не ограничивать премиум-пользователя.

Answer 3

Это довольно типично для архитектурного решения, когда есть некоторый компромисс, который потенциально может улучшить некоторые атрибуты качества за счет затрат на другие атрибуты качества.В вашем случае решение преобразовать службу пользователей в библиотеку повысит надежность, но вопрос в том, на какие атрибуты качества это может повлиять.Существует не так много информации об этом сервисе, но давайте рассуждать.Одним из хороших свойств стиля микро-сервисов является способность поддерживать жизненный цикл изолированной разработки сервисов.То есть микросервис, пользовательский компонент может быть доставлен независимо от других компонентов, если в публичных контрактах не произойдет каких-либо серьезных изменений.Например, внутренние исправления или улучшения могут быть предоставлены с новой версией службы и должны стать доступными для других служб, не затрагивая жизненный цикл выпуска других служб.С библиотекой ситуация становится немного другой - чтобы выпустить какое-то критическое (или некритическое исправление в библиотеке), вам придется обновить все компоненты, зависящие от этой библиотеки.Даже если учесть, что этот процесс автоматизирован, он может наложить некоторые дополнительные операционные проблемы, связанные с вопросами, как часто это может происходить, если этот процесс гарантирует нулевое время простоя, как обрабатывать сценарии сбоя, когда происходит сбой обновления некоторых служб, когда некоторые службы уже обновлены.Другим аспектом является масштабируемость - будучи услугой, пользовательский компонент может масштабироваться независимо от типичной нагрузки, создаваемой всеми его потребителями.С библиотекой предполагается, что она должна делить ресурсы с другими компонентами, и, что еще хуже, она должна быть в состоянии справиться с нагрузкой, равной нагрузке компонента, которым используется библиотека, без возможности самостоятельно настраивать потребление ресурсов.Безопасность также может быть аспектом, который требует дополнительного внимания, предполагая, что пользовательский сервис должен использовать некоторый источник данных, который может хранить конфиденциальную информацию с библиотекой, и всем другим сервисам должен быть разрешен доступ к этому источнику данных, потенциально угрожающему безопасности данных.С другой стороны, надежность может быть достигнута за счет избыточности пользовательских компонентов службы, например, с помощью нескольких экземпляров службы и ее источника данных.

Возвращаясь к первоначальному утверждению, у вас есть своего рода компромисс и решениезависит от того, какие качественные атрибуты более критичны для всей системы.Если сложно добиться высокой доступности услуг пользователей из-за некоторых ограничений или высоких затрат на этот процесс, и это относительно редкий сценарий, когда эту функцию можно обновлять независимо, стоит рассмотреть возможность перехода в библиотеку или если на нее влияют атрибуты качества процесса, имеющие решающее значение длясистемная архитектура, это может указывать на то, что стоит уделять больше внимания тактике повышения доступности обслуживания пользователей вместо того, чтобы ставить под угрозу качественные атрибуты, достигаемые стилем микросервисов.

В качестве дополнительного замечания о спецификации по сравнению с вопросом архитектуры.Полагаю, под спецификацией вы подразумевали требования.Архитектура всегда определяется требованиями, и они относятся к архитектуре, поэтому в любом случае это архитектурная проблема.