Какой ужас. Практически все описанные преимущества на самом деле являются серьёзными недостатками. От чего бежали в JSP и прочих серверных реализациях клиента, сейчас преподносится, как благо.
Рендер на сервере на нагруженном сайте требует намного больше ресурсов.
Вместо передачи данных, передаётся вьюшка, что требует больше трафика.
Во многих случаях будет требоваться редеплой сервера.
Подпускать бэк разработчиков к фронту также плохая идея.
У меня есть опыт работы с приложением, написанным таким обобразомБаг на баге и каждый баг требует либо руками на сервере что-то править, либо полный редкплой, со всеми вытекающими...
Вполне возможно, хотя опять-же говорю только со своего опыта, поддержка монолитов намного проще для компаний с ограниченными ресурсами поддержки. Наша система обслуживает параллельно около 2х тысяч работников службы поддержки крупного оператора кабельного ТВ и, ежедневно опрашивает около 4 миллионов приставок на предмет диагностики. Всё бежит на двух физических серверах разбитых на 8 виртуалок. При апгрейде только один инстанс перегружается и система всегда доступна.
А если такая же ошибка в микросервисе, то они тоже будут падать и вся система перестанет нормально работать. У нас такая монолитно-кластерная архитектура работает уже лет десять и, в нескольких случаях, когда падала система, это были проблемы с сетесетевым оборудованием.
Можно построить кластерный монолит, где каждая нода имеет полную независимость и запросы распределяются через балансировщик нагрузки. Тогда нет необходимости иметь сложную микросервисную архитектуру. Сильно упрощает деплоймент и поддержку.
Спасибо, очень хорошая статья. Мы сами где-то год назад внедрили KeyCloak и находим все больше и больше плюсов используя этот продукт.
В наши приложения мы добавили авторегистрацию в кейклоке, чтобы новый клиент при деплое сам смогзарегистрироваться и залить все роли, которые он поддерживает.
Великолепная библиотека JPA Streamer - отправляет телеметрию в гугл
The only disadvantage I found is that it sends certain data back to Speedment’s servers for Google Analytics. If you wish to disable this feature, you need to contact their team. To be honest, I’m concerned a little.
Доброго времени суток. У нас есть мощный движок CMS, с гибким API. Было бы интересно пообщаться и посмотреть, как можно синтегрироваться. Инфу про наш продукт можно посмотреть на meld-ms.com
Мы настроили NFS на реплицируемых нодах VMWare. И, если одна нода упадёт, то сервис будет недоступен только на время, пока вторая нода не поднимется с тем же IP. А это пара секунд
Я настраивал Glusterfs для одного проекта, где сервера поочерёдно раз в 5 минут записывали на Glusterfs порядка 10к файлов (MRTG). И скорости сети и диска хватало с запасом, но Gluster периодически терял синхронизацию между нодами. Пришлось откатиться на NFS
ПРИМЕЧАНИЕ. Не все веб-серверы готовы к websocket-ам из коробки. Например, Rails v.5 пришлось перейти с WEBrick на Puma. При этом Puma не могла хранить больше 1024 соединений, что было исправлено в обновлении до четвертой версии только в 2019 гогоду.
Не могу себе представить сценарий, где в браузере нужно открывать сотни вебсокет соединений. Обычно открывается одно на вкладку. Может кто-то подскажет зачем?
Какой ужас. Практически все описанные преимущества на самом деле являются серьёзными недостатками. От чего бежали в JSP и прочих серверных реализациях клиента, сейчас преподносится, как благо.
Рендер на сервере на нагруженном сайте требует намного больше ресурсов.
Вместо передачи данных, передаётся вьюшка, что требует больше трафика.
Во многих случаях будет требоваться редеплой сервера.
Подпускать бэк разработчиков к фронту также плохая идея.
У меня есть опыт работы с приложением, написанным таким обобразомБаг на баге и каждый баг требует либо руками на сервере что-то править, либо полный редкплой, со всеми вытекающими...
А вот интересно, можно ли как-то трансформировать промпт Midjourney, с овсеми флагами и ключами, в аналогичный для Stable Diffusion?
А почему Keycloak не подошел?
Вполне возможно, хотя опять-же говорю только со своего опыта, поддержка монолитов намного проще для компаний с ограниченными ресурсами поддержки. Наша система обслуживает параллельно около 2х тысяч работников службы поддержки крупного оператора кабельного ТВ и, ежедневно опрашивает около 4 миллионов приставок на предмет диагностики. Всё бежит на двух физических серверах разбитых на 8 виртуалок. При апгрейде только один инстанс перегружается и система всегда доступна.
А если такая же ошибка в микросервисе, то они тоже будут падать и вся система перестанет нормально работать. У нас такая монолитно-кластерная архитектура работает уже лет десять и, в нескольких случаях, когда падала система, это были проблемы с сетесетевым оборудованием.
Так монолитов несколько. Один упал, остальные бегут.
Можно построить кластерный монолит, где каждая нода имеет полную независимость и запросы распределяются через балансировщик нагрузки. Тогда нет необходимости иметь сложную микросервисную архитектуру. Сильно упрощает деплоймент и поддержку.
Люди настолько против 2фа, что клиент не захотел этого делать. А фот SSO зашло с удовольствием
Спасибо, очень хорошая статья. Мы сами где-то год назад внедрили KeyCloak и находим все больше и больше плюсов используя этот продукт.
В наши приложения мы добавили авторегистрацию в кейклоке, чтобы новый клиент при деплое сам смогзарегистрироваться и залить все роли, которые он поддерживает.
Великолепная библиотека JPA Streamer - отправляет телеметрию в гугл
В Java17 нет различия между JDK и JRE. Конечно, можно было бы и скомпилировать граалем в нативное приложение, тогда джава вообще не нужна.
Доброго времени суток. У нас есть мощный движок CMS, с гибким API. Было бы интересно пообщаться и посмотреть, как можно синтегрироваться. Инфу про наш продукт можно посмотреть на meld-ms.com
Напишите в личку, если интересно.
Мы также рассматривали поставить rsync между двумя нодами NFS и подключаться к ним через HAProxy. Но не дошли руки
Мы настроили NFS на реплицируемых нодах VMWare. И, если одна нода упадёт, то сервис будет недоступен только на время, пока вторая нода не поднимется с тем же IP. А это пара секунд
glusterfs 7.9
2 пира симметрично реплицируемые по отдельному интефейсу
gluster peer status
Number of Peers: 1
Hostname: cfs2
Uuid: 0cf321d6-315b-416c-bdc4-7f9372aecdeb
State: Peer in Cluster (Connected)
Other names:
cfs2-back
Volume Name: mrtg
Type: Replicate
Volume ID: e5dff098-c7c6-4f33-baef-ad99f66150e4
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: cfs1:/home/mrtg
Brick2: cfs2:/home/mrtg
Options Reconfigured:
transport.address-family: inet
storage.fips-mode-rchecksum: on
nfs.disable: on
performance.client-io-threads: off
/etc/hosts
10.10.20.5 cfs1-back
10.10.20.6 cfs2-back
10.10.22.1 cfs1
10.10.22.2 cfs2
Я настраивал Glusterfs для одного проекта, где сервера поочерёдно раз в 5 минут записывали на Glusterfs порядка 10к файлов (MRTG). И скорости сети и диска хватало с запасом, но Gluster периодически терял синхронизацию между нодами. Пришлось откатиться на NFS
Интересно было бы понять, если можно что-то предложить, чего нет сейчас
А есть что-то для фигурного катания?
Chaperone от Pixel Nation тоже довольно гибкий инструмент
Это вроде про серверы
Не могу себе представить сценарий, где в браузере нужно открывать сотни вебсокет соединений. Обычно открывается одно на вкладку. Может кто-то подскажет зачем?