Comments 3
Сравнение OSGi c Jigsaw сильно напоминает рекламныю брошуру OSGi (Netcracker). Я полагаю надо все таки быть честными, раз пишете техническую статью. Jgisaw это же только механизм в Java, на основе которого можно уже строить различные фреймворки по динамической загрузке (если я это правильно понимаю). А что OSGi с 2000 года существует и далеко не майнстрим- так это плата за сложность обращения с ним. Вот если бы вы написали про его будующее, про возможности интеграции с Jigsaw- было бы интересно…
Кейс, который вы пытаетесь обосновать, не выглядит убедительным. Изначально вы апеллируете к потребности в бесперебойной и непрерывной работе систем, критичных для бизнеса. Такая потребность существует и действительно решается путем кластеризации. Далее для подкрепления своей позиции вы неоднократно упираете на «избыточность» такого решения. Простите, но кластеризация используется далеко не только для того, чтобы обеспечивать прозрачное обновление программного кода. Если говорить о HA-кластерах, то они в первую очередь обеспечивают fail-over. Избыточность здесь несомненно присутствует (степень ее зависит от топологии кластера), но она совершенно оправдана и необходима. Конечно, есть традиционные аппаратные решения для высокой доступности без кластеризации, но это абсолютно нишевые продукты с огромной стоимостью владения.
Со всей очевидностью, «высоконагруженные системы, от адекватного функционирования которых зависит огромное число операций» должны иметь механизм для обеспечения fail-over. Этот механизм, который используется повсеместно и успешно — кластеризация. Поэтому никакой избыточности в плохом смысле здесь нет. Никто не городит кластер исключительно для горячего обновления компонентов. Кластер априори есть.
Я слабо понял, на какую нишу вы претендуете. Не в том смысле, что проповедуют ваши маркетекторы, а где ваше решение действительно оправдано. Если исходить из описания, что вы предоставили, возникают серьезные сомнения в масштабируемости предлагаемой архитектуры. Извиняюсь за банальность, но масштабируемость бывает вертикальной и горизонтальной. Поскольку кластеризацию вы активно отрицаете, правильно ли я понимаю, что предлагается масштабироваться вертикально? Собственно, упоминание такого преимущества как разогретый кэш предполагает два варианта: или кэш существует в рамках одного процесса (одной JVM), или он распределенный (data grid, например). Первый вариант масшабируется в крайне ограниченных пределах. О втором варианте нет ни слова.
Помимо этого, не могли бы вы прояснить следующие моменты:
Со всей очевидностью, «высоконагруженные системы, от адекватного функционирования которых зависит огромное число операций» должны иметь механизм для обеспечения fail-over. Этот механизм, который используется повсеместно и успешно — кластеризация. Поэтому никакой избыточности в плохом смысле здесь нет. Никто не городит кластер исключительно для горячего обновления компонентов. Кластер априори есть.
Я слабо понял, на какую нишу вы претендуете. Не в том смысле, что проповедуют ваши маркетекторы, а где ваше решение действительно оправдано. Если исходить из описания, что вы предоставили, возникают серьезные сомнения в масштабируемости предлагаемой архитектуры. Извиняюсь за банальность, но масштабируемость бывает вертикальной и горизонтальной. Поскольку кластеризацию вы активно отрицаете, правильно ли я понимаю, что предлагается масштабироваться вертикально? Собственно, упоминание такого преимущества как разогретый кэш предполагает два варианта: или кэш существует в рамках одного процесса (одной JVM), или он распределенный (data grid, например). Первый вариант масшабируется в крайне ограниченных пределах. О втором варианте нет ни слова.
Помимо этого, не могли бы вы прояснить следующие моменты:
- Что понимается под «поставить приложение на паузу»? О какой высокой доступности тогда идет речь?
- Насколько я понял, транспорт для отправки сообщений не использует персистентные очереди. Что произойдет в случает сбоя?
Параграф про облака описывает ровно первый вариант решения — избыточность и возможность обновлять отдельные экземпляры пока другие работают, но почему-то не проводит ни одной параллели с ним, а фактически противопоставляется. Почему так?
Sign up to leave a comment.
Обновление кода приложений на работающем сервере