Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Архитектура микросервисов в браузере

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

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

Пока я вижу это так — должен быть некий core, который обязательно поддерживает AMD (догружать код и ассеты микроаппов надо на лету, потому что разные пользователи могут иметь разные права на разные микроаппы), предоставляющий сервисные функции: работа с сервером, общий стейт, раутинг и т.д.
Видели ли вы подобные плюс-минус готовые решения, что бы не изобретать велосипед? Или хотя бы подборку наиболее подходящих компонент для подобной задачи.

Возможно, кто-то имеет опыт разработки такой архитектуры?

Интересны любые мнения. Спасибо.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

WebWorkers являются полным аналогом микросервисов на бэкенде.

вы бы хоть в теме разобрались сперва.
как, многопоточность в JS может быть полным аналогом микросервисов?

Обеспечивает изоляцию. Суть микросервисов — изоляция.

изоляцию можно обеспечить и при помощи
(function () {} ())

И как вы обеспечите, чтобы функция не замыкала на себя ничего из контекста, чтобы не использовала глобальный объект?

1) Вам придется изобретать свой велосипед, так как ни одно готовое решение на 100% не покроет ваши проблемы.
2) Ключевое проблемой является не GIT или разделение на команды, а процесс разработки.
3) Ведите хорошо документацию, спецификаци.
4) Используйте UML или что-то близкое для визуализации.
5) CI!

1) Вы уверены? Неужели это настолько малораспространенная проблема?
2) Процесс разработки включает в себя разделение на команды, GIT, CI/CD и прочие вещи. Это комплекс решений
3) Код должен быть самодокументируемым! В целом понятно, но удаленная команда должна начать разрабатывать свой модуль без необходимости читать 20 страниц документации
4) Не понятно для чего
5) Одна из частей процесса разработки. Каждая команда должна иметь возможность автономно и самостоятельно обновить их часть приложения, при этом это минимальным образом должно повлиять на приложение в целом.

1) Проблема распространная. Для ее решения есть паттерны, но не silver bullet.
2) Я акцентирую ваше внимание на процессе, а не на инструментах. Важно одинаковое понимание процесса у каждой из команд. Свои внутренние процессы команда может инкапсулировать, но очень важно понимать весь процесс в целом. Понимать, что команда может делать по своему, а что является стандартом на уровне компании.
3) Еще один адепт самодокументированого кода. Я правильно вас понимаю, вы мне предлагаете лезть в код чужого приложения, чтобы разобраться как оно работает?
4) Чтобы у всех команд было одинаковое представление, как работает система. Дебаггинг в микросервисах еще-то удовольствие. Короче см. п.2
5) Мне кажется вы не понимаете какие проблемы решает CI, а какие разделение на микросервисы и команды. В итоге смешение мух и котлет.

2) Это понятно
3) Это была шутка, если что. Понятно, что каждый микроапп должен быть хорошо документирован на всех уровнях. Но, ИМХО, это должно делаться автоматически и в одном стиле (JSDocs, JDocs и т.д.)
4) Ок
5) Проблемы решают разные, но имеют достаточно четкую взаимосвязь. Когда у нас одно монолитное приложение и над ним работают 5 разных команд и каждая при вливании своего кода должна мерджиться с кодом других команд и не имеют возможности задеплоить изменение в своем функционале без полного передеплоя — это проблема.
Потому я и рассматриваю это как комплекс, а не как «отдельные части».

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

1) Вы уверены? Неужели это настолько малораспространенная проблема?
в основном апроачи, по типу которого я вам скинул — но который очень легко реализовать

Розподілу по ролях — от чого тут нема. Тобто, кожен клієнт має отримувати свій набір мікросервісів, це має сервер вирішувати. Інакше не варто і розпилювати на частини, краще взагалі прибрати перевірку залежностей — це значно спростить деплой та відкат.

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

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

При таких условиях — работать над одним проектом (физически одним репозитарием в гите) становится практически нереально.
Не говоря про проведение рефакторинга и код ревью.
Основная идея микроаппов:
— они должны быть маленькими. настолько маленькими, что бы переписывание его с нуля было подъемной задачей и его код не обрастал миллионом заплаток и хаков
— каждый микроапп должен быть в ответственности одной определенной команды
— каждый микроапп может быть написан на любом стеке технологий (с некоторыми ограничениями, конечно)

Так может вам сделать обыкновенные сандбоксы с шиной ивентов?

Примерно так и собираемся сделать, только шина ивентов еще должна решать задачу авторизации, обработки ошибок и т.д.

С сервером все более ли менее понятно. Изначальный вопрос топика — как правильно поддержать эту архитектуру на стороне клиента

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

О, спасибо, сейчас глянем-сс

В первую очередь основная проблема — каждый микроапп это набор из UI и бекенда. Причем как бекенд может быть написан на любой технологии, так и UI (кто-то на джеквери, кто-то на реакте, а кто-то на англуляре). И это всё должно жить в одном приложении.

Ну так почему нету? Клиент и получает пермишены на каждый апп и каждый скрин внутри аппа

Баланьнейшие плагины и виджеты. К примеру, так пашут все приложения соц.сетей — есть API, берёшь и пользуешь.

Основная задача архитектора — определить точки разреза. Потому как любое разделение — это настройка взаимодействия, которую надо держать в голове, а не в компьютере. Потому разрез должен идти в тех местах, где взаимодействие минимально.

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

Вообще сама идея микросервисов — достаточно слабая. Реальные разделения делаются весьма серьёзными кусками. Пазл не должен состоять из тысяч деталей, иначе его очень сложно будет собрать. Особенно если собирать не тебе.

Ну не совсем так. В данном случае микроапп не только ui, это комплект из ui+api, причём обе части могут взаимодействовать с другими микроаппами или использовать общие части (как раз таки плагины и виджеты)

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

Если считаешь иначе — скажу где грабли: сотни и сотни разных имён, которые нужно будет выучивать дабы ими пользоватся. И каждая собака по-своему одно и то же проименует, свои способы вызова присобачит, и поддерживать всё это затрахаешься искать разработчиков.

Проблема стара как сам корпоративный софт. И каждый раз причина смерти № 0 — это разрез в неправильном месте, неподъёмное API, взаимодействие через задницу.

у нас на проекте есть что-то похожее.

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

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

используем реквайр джс для этого дела. в целом оно работает.

а если не секрет, то зачем вам?

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

Require плюс небольшой велосипед по обслуживанию этого дела.
Есть большой минус — лоадинг тайм. Грузит джс порядка минуты.

Не совсем понял. RequireJS это же имплементация AMD? То есть сначала он загружает только базовые классы, а потом асинхронно подгружает необходимые модули для каждого куска приложения.
Какой джс он грузит порядка минуты?

Имеется ввиду стандартная конфигурация всего приложения. Иными словами это время загрузки для самого частовстречаемого набора сервисов. Вызванно изза хттп оверхеда

Не пробовали собирать базовую конфигурацию (частовстречаемы набор сервисов) в одну js-ку?

Подписаться на комментарии