Микросервисы: как интегрировать пользовательский интерфейс?

Сегодня я начал читать о архитектуре Microservice - и это кажется очень интересным! Но у меня есть одно сомнение в том, что мне нужно какое-то выражение: Предположим, что я хочу создать блог и построил бы 4 микросервиса для этого: Служба пользователя/входа в систему, Служба статей, Служба комментариев и Служба отчетов/аналитики (не реалистичный пример, я знаю...). Служба Reporting/Analytics является исключительно бэкэнд - здесь нет проблем для моего понимания. Но три других связаны с частью UI, и, насколько я понимаю, эта часть пользовательского интерфейса также должна быть частью самого микросервиса, верно? Как интеграция пользовательского интерфейса будет работать? Будет ли у меня 5-я служба "входных дверей", которая собирает запросы пользователя, пересылает их другим службам, которые затем отвечают с помощью HTML/CSS, а служба входных дверей будет составлять отдельные ответы на то, что возвращается пользователю?

В любом случае у вас есть пример/прецедент для такого сценария?

Спасибо и приветствую!

Ответ 1

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

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

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

Другое, что я хотел бы отметить, это то, что архитектура микросервисов замечательна только тогда, когда приложение становится слишком большим и сложным. Архитектура микросервисов требует больше ресурсов, так как у нее есть дополнительные накладные расходы. Начните сначала с монолитного:).

Ответ 2

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

С другой стороны, каждый микросервис может предоставлять набор фрагментов HTML. Затем вам нужен внешний интерфейс для создания страниц и навигации. Все фрагменты должны использовать один и тот же словарь для CSS или любых других средств, которые вы используете для определения внешнего вида. Такой подход может привести к появлению нечетных страниц, когда фрагменты HTML составляются без одного или нескольких сервисов, которые могут быть включены.

Наконец, поверх микросервисов может быть построен полный пользовательский интерфейс приложения. Это может привести к "более тесному" интерфейсу с лучшим потоком. Как правило, это займет больше времени и будет сложнее изменить при добавлении новых услуг.

Что лучше? Как и в большинстве случаев в разработке программного обеспечения, это зависит от того, что вы строите. В случае приложения "Блог" вы описали, что я подозреваю, что у каждого сервиса может быть свой полный пользовательский интерфейс на одну страницу. Чаще всего с полным пользовательским интерфейсом я видел подход. Подход HTML-фрагмента более универсален, но изначально требует больше времени для разработки. Однако после его создания у вас будет больше гибкости в развертывании приложения. Это может быть реальным преимуществом для компании, занимающейся программными продуктами.

Надеюсь, это поможет.