Size: a a a

Scala User Group

2020 September 11

S

Simon in Scala User Group
Ностальгия... апп сервер, 400 потоков в константном тредпуле обработки http для приложения. Красота!
источник

𝛈µ

𝛈 µ in Scala User Group
Python
Вопрос к 7mind про distage. Вот есть такая проблема, к примеру. В одной большой фирме, не буду говорить какой, напонаписали дофигища микросервисов, поэтому чтобы их всех на локальной машине запустить, требуется много гибабайт оперативной памяти.

В итоге усложнаяется разработка на локальных компьютерах. Можно память тупо купить или вынести часть этих микросервисов на сервера.

Но есть ещё одна идея. Все эти микросервисы написаны на милой Скале и работают на JVM. Поэтому, возможно, можно их всех запускать без докеров в одной JVM, возможно, даже убрав уровень коммуникации (HTTP сервер и всё такое).

Можно вполне придумать как это всё сделать самим. Но вот я как-то давно копался в distage и там были всякие интересные штуки типа ролей и лаунчеров по ролям. Это по теме? Стоит там ещё покопаться. Что-то сходу в документации не нашёл. Может статья какая-нибудь в интернете есть?
Эту проблему хорошо решает дистейдж, если нет конвергенции версий
источник

𝛈µ

𝛈 µ in Scala User Group
Если есть конвергенция версий - настало время прикрутить к дистейджу механизм изолированных класслоадеров
источник

𝛈µ

𝛈 µ in Scala User Group
Python
Вопрос к 7mind про distage. Вот есть такая проблема, к примеру. В одной большой фирме, не буду говорить какой, напонаписали дофигища микросервисов, поэтому чтобы их всех на локальной машине запустить, требуется много гибабайт оперативной памяти.

В итоге усложнаяется разработка на локальных компьютерах. Можно память тупо купить или вынести часть этих микросервисов на сервера.

Но есть ещё одна идея. Все эти микросервисы написаны на милой Скале и работают на JVM. Поэтому, возможно, можно их всех запускать без докеров в одной JVM, возможно, даже убрав уровень коммуникации (HTTP сервер и всё такое).

Можно вполне придумать как это всё сделать самим. Но вот я как-то давно копался в distage и там были всякие интересные штуки типа ролей и лаунчеров по ролям. Это по теме? Стоит там ещё покопаться. Что-то сходу в документации не нашёл. Может статья какая-нибудь в интернете есть?
Есть наша презентация на fscala 2019
источник

𝛈µ

𝛈 µ in Scala User Group
Проблему увеличения денсити мы там упоминаем. Собственно, увеличение денсити - это одна из проблем, адресуемых дистейджем
источник

𝛈µ

𝛈 µ in Scala User Group
А вообще в вопросах про дистагу лучше кого-то из нас тегать
источник

𝛈µ

𝛈 µ in Scala User Group
Я абсолютно случайно этот вопрос увидел
источник

𝛈µ

𝛈 µ in Scala User Group
Sergey Alaev
В Finagle есть другое решение этой проблемы - вместе с любым запросом к микросервису можно послать пакет метаданных, который оверрайдит service discovery для всех участвующих микросервисов.

Т.е. отлаживаемый микросервис запускаешь локально, а запрос отправляешь на тестовую среду. И один из микросервисов отткуда сделает запрос на твою машину.
Прекрасное решение, особенно когда твоя локальная машина стоит за натом, а твоё тестовое окружение вообще от мира отключено
источник

𝛈µ

𝛈 µ in Scala User Group
Simon
Знаю проект, где куча сервисов на одной jvm независимо работали и отдельно обновлялись - все это через OSGi. Взаимодействие через опубликованные в OSGi сервисыв.
Забавная штука была - мне нравилось с ней работать. Проблем особых не было.
У озги три проблемы:
1) В него сложно войти. Нужно учить очень много ритуалов
2) В нем очень много древностей и легаси
3) Он заставляет писать мутабельный код, любая внешняя зависимость каждого компонента в любой момент времени может стать null и к этому надо быть готовым
источник

𝛈µ

𝛈 µ in Scala User Group
Но да, конечно, одна из мотиваций делать дистейдж - неудовлетворённость озги
источник

S

Simon in Scala User Group
𝛈 µ
У озги три проблемы:
1) В него сложно войти. Нужно учить очень много ритуалов
2) В нем очень много древностей и легаси
3) Он заставляет писать мутабельный код, любая внешняя зависимость каждого компонента в любой момент времени может стать null и к этому надо быть готовым
1. 1 раз провести - потом все ок.
2. Возможно, но работает
3. Мы слушали события и убивали все, что зависело от отваливающегося сервиса. И запускали то, что зависело от поднявшегося.
источник

SA

Sergey Alaev in Scala User Group
𝛈 µ
Прекрасное решение, особенно когда твоя локальная машина стоит за натом, а твоё тестовое окружение вообще от мира отключено
Люди вообще делятся на две категории - которые используют vpn и которые страдают. Но личное дело каждого, да.
источник

𝛈µ

𝛈 µ in Scala User Group
Simon
1. 1 раз провести - потом все ок.
2. Возможно, но работает
3. Мы слушали события и убивали все, что зависело от отваливающегося сервиса. И запускали то, что зависело от поднявшегося.
1/2 - мне как-то оказалось слишком тошно. Особенно с учётом того, что вокруг слишком много библиотек с рантаймовой кодогенерацией и синглтонами, которые препятствуют выгрузке/замене версий
источник

𝛈µ

𝛈 µ in Scala User Group
(3) - одно событие убийства триггерило новые?
источник

S

Simon in Scala User Group
Если падает корень дерева, то все дерево должно упасть
источник

S

Simon in Scala User Group
Главное циклы не создавать - но они и подняться не смогут
источник

𝛈µ

𝛈 µ in Scala User Group
Simon
Если падает корень дерева, то все дерево должно упасть
Мм, я вот не помню, как оно там работало
источник

𝛈µ

𝛈 µ in Scala User Group
Возможно
источник

𝛈µ

𝛈 µ in Scala User Group
Simon
Главное циклы не создавать - но они и подняться не смогут
Почему не смогут? Смутируется поле и будет тебе цикл. Опять же емнип
источник

S

Simon in Scala User Group
Вручную.
3 приложения: A, B, C
Каждое публикует сервисы, соответственно A1, B1, C1
Зависимости: B1 от A1, С1 от B1.
Поднимаем приложения B и C - они ничего не публикуют, слушают появление своих зависимостей
Поднимаем A, публикуется A1, B ловит событие и публикует B1, C ловит событие и публикует C1.
Опускаем A - опускается A1 => опускается B1 => опускается C1
источник