Идея микросервисной архитектуры в том, чтобы эти сервисы самостоятельно не разрабатывать, а разрабатывать с сообществом этого сервиса: раньше известны баги, апдейты, но отсюда ограничение кастомизации, лишние свистелки-перделки от сообщества.
короче накатил путинки, развернул коробочек, настроил между них мосты интегрировал в общую верстку по аналогии с xgm.guru/shoutbox и радуешься, как Кет. Плюс коробочек, что у них могут быть свои мобильные приложения, но вон джаспер это и минусом считает, потому что люди вообще перестанут на сайт заходить.
Даже в такой помойке как код в8, это делается достаточно просто. Не сам фикс, а нахождение бага. Баг локализовать просто, сложно пофиксить в некоторых случаях из-за отвратной не структурированной архитектуры.
Все сложно поддерживать если нету четкой и структурированной архитектуры. Можно заделать кучу микросервисов, но толку, если они будут не правильно структурированы. Проблема в текущем решении ХГМ - это использование его как песочницы. Потому что большинство фич которые прикручивались - это лишь способ попробовать что-то новое из технологий или в программировании. Отсюда и появляется функционал которым пользуется 1 или 2 пользователя, который ничего не дает, в нем куча багов, структура кривая и непонятное, потому что автор просто хотел поиграться с новой технологией.
поддерживать, по сути, с какой-то стороны проще, на самом то деле
не совсем, надо локализовать сперва в каком это сервисе, из-за какого API затем это вылазит, потом пофиксить тот API или его расширить из-за не хватки данных, потом его выкатить, потом пофиксть обработку этого API и потом обновить этот сервис.
когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть
Даже в такой помойке как код в8, это делается достаточно просто. Не сам фикс, а нахождение бага. Баг локализовать просто, сложно пофиксить в некоторых случаях из-за отвратной не структурированной архитектуры.
Все сложно поддерживать если нету четкой и структурированной архитектуры. Можно заделать кучу микросервисов, но толку, если они будут не правильно структурированы. Проблема в текущем решении ХГМ - это использование его как песочницы. Потому что большинство фич которые прикручивались - это лишь способ попробовать что-то новое из технологий или в программировании. Отсюда и появляется функционал которым пользуется 1 или 2 пользователя, который ничего не дает, в нем куча багов, структура кривая и непонятное, потому что автор просто хотел поиграться с новой технологией.
По личному опыту поддержки и разрботки высоконагруженных распределенных систем, развивать микросервисную архитектуру, а тем более отлаживать в случае заковыристых багов очень сложно. Вот у нас тут есть пайплайн из уже почти 10 разных микросервисов и иногда понять в какой момент отвалились данные, весьма сложно. А потом еще и исправить это, особенно если фикс приходится на несколько сервисов, достаточно проблемно.
В этом есть несомненнно плюсы, но не при разработке портала как например хгм, оно того не стоит. Потому что все это сольется опять же в ту же кашу. Смотрите пункт про песочницу
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
Что в данном контексте подразумевается под "чувствует"?)
Натягиваешь везде один схожий дизайн, делаешь поддомены forum.xgm.guru, vodka.xgm.guru итд на каждый сервис с единой сессией и авторизацией да и все.
Реализация не сложная, хоть и трудоёмкая, поддерживать, по сути, с какой-то стороны проще, на самом то деле, чем когда все слито в кучу и ты не понимаешь, где именно баг, в чем проблема и куда лезть, чтобы добавить новую кнопочку или плагин.
Там все слито в одну экосистему.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
Господи, какое же неудобное говно.
Может с мобилки оно еще ок, даже лень смотреть, но с бука выглядит как лютый высер. ZlaYa1000:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Нормальная тема. Главное, чтобы сервисы по-максимуму соблюдали "Принцип единственной ответственности".
Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
Пишется отдельный сервис-роутер, основная цель существования которого - быть связующим звеном между другими сервисами. На нём делается нужное количество end-point"ов, на которые обращается, форум/баг трекер/сайт/по хрен что, отдавая или запрашивая нужные данные, а данный сервис знает, что со всем этим делать.
Нормальная система же, много кто так делает.
BLOG-TYSCHP…
Комментарии проекта Он вам не клоун!
По технической реализации xgm
Ред. alexprey
Ред. KotoBog
С ними удобнее, поэтому и написал, но это моё имхо.
Ред. KotoBog
Натягиваешь везде один схожий дизайн, делаешь поддомены forum.xgm.guru, vodka.xgm.guru итд на каждый сервис с единой сессией и авторизацией да и все.
Пользователь не чувствует, что переходит в другой сервис.
Если Тыща это имел ввиду в своем предложении, то ок. Но все еще остается проблема поддержки и развития большого количества сервисов.
Может с мобилки оно еще ок, даже лень смотреть, но с бука выглядит как лютый высер.
ZlaYa1000:
Нормальная система же, много кто так делает.