Вхід і реєстрація
Розробка · 13 грудня 2015, 10:48 1403
Vlad Mystetskyi, Lead full-stack web developer в Nielsen eXelate

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

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

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

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

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

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

Теми: архітектура, мікросервіси
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Владимир Чернышев Программист 15.12.2015 12:26

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

Відповісти
Підтримати
anonymous 15.12.2015 12:55

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

Відповісти
Підтримати
Владимир Чернышев
Владимир Чернышев Программист 15.12.2015 13:31

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

Відповісти
Підтримати
anonymous
anonymous 15.12.2015 13:42

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

Відповісти
Підтримати
Владимир Чернышев
Владимир Чернышев Программист 16.12.2015 05:46

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

Відповісти
Підтримати
anonymous
Никита Галкин Software Engineer, System Architect, Node.js Tech Speaker 13.12.2015 16:39

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

Відповісти
Підтримати
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 16:55

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

Відповісти
Підтримати
Никита Галкин
Никита Галкин Software Engineer, System Architect, Node.js Tech Speaker 13.12.2015 17:26

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

Відповісти
Підтримати
Vlad Mystetskyi
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 17:32

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

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

Відповісти
Підтримати
Никита Галкин
anonymous 13.12.2015 17:26
1) Вы уверены? Неужели это настолько малораспространенная проблема?
в основном апроачи, по типу которого я вам скинул — но который очень легко реализовать
Відповісти
Підтримати
Vlad Mystetskyi
Олексій Пєніє 13.12.2015 12:41

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

Відповісти
Підтримати
anonymous
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 13:39

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

Відповісти
Підтримати
anonymous
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 13:50

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

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

Відповісти
Підтримати
anonymous
anonymous 13.12.2015 13:54

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

Відповісти
Підтримати
Vlad Mystetskyi
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 13:58

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

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

Відповісти
Підтримати
anonymous
anonymous 13.12.2015 14:02

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

Відповісти
Підтримати
Vlad Mystetskyi
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 13:58

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

Відповісти
Підтримати
anonymous
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 14:07

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

Відповісти
Підтримати
anonymous
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 12:45

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 13.12.2015 12:26

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

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

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

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

Відповісти
Підтримати
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 12:38

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 13.12.2015 12:47

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

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

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

Відповісти
Підтримати
Vlad Mystetskyi
anonymous 13.12.2015 11:43

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

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

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

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

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

Відповісти
Підтримати
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 12:33

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

Відповісти
Підтримати
anonymous
anonymous 13.12.2015 12:51

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

Відповісти
Підтримати
Vlad Mystetskyi
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 13:40

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

Відповісти
Підтримати
anonymous
anonymous 13.12.2015 13:45

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

Відповісти
Підтримати
Vlad Mystetskyi
Vlad Mystetskyi Lead full-stack web developer в Nielsen eXelate 13.12.2015 13:51

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

Відповісти
Підтримати
anonymous

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.