Визуальное проектирование масштабируемых приложений (Стачка-2026) — различия между версиями
м |
м |
||
| (не показана одна промежуточная версия этого же участника) | |||
| Строка 2: | Строка 2: | ||
10-11.04.2026 Ульяновск [https://ul.nastachku.ru/ '''Стачка'''] | 10-11.04.2026 Ульяновск [https://ul.nastachku.ru/ '''Стачка'''] | ||
[https://ul.nastachku.ru/lp/ul26/speeches/vizualnoe-proektirovanie-masshtabiruemykh-prilozhenii Выступление на сайте конференции] | [https://ul.nastachku.ru/lp/ul26/speeches/vizualnoe-proektirovanie-masshtabiruemykh-prilozhenii Выступление на сайте конференции] | ||
| + | Видео ожидается | ||
Кажется, что задачи масштабирования в микросервисной архитектуре решаются просто: поднимаем нужное количество сервисов, и оно работает, что тут проектировать. Однако, есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. А еще надо обеспечить приемлемую скорость ответа для пользователя, который, быть может, именно сейчас с нетерпением ждет, когда, наконец, можно будет оплатить заказ и думает, не пойти ли ему за заказом на соседний сайт, раз уж тут так все медленно. | Кажется, что задачи масштабирования в микросервисной архитектуре решаются просто: поднимаем нужное количество сервисов, и оно работает, что тут проектировать. Однако, есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. А еще надо обеспечить приемлемую скорость ответа для пользователя, который, быть может, именно сейчас с нетерпением ждет, когда, наконец, можно будет оплатить заказ и думает, не пойти ли ему за заказом на соседний сайт, раз уж тут так все медленно. | ||
| Строка 7: | Строка 8: | ||
Заложенные в архитектуру решения проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, поэтому их необходимо представлять не только разработчикам, но и аналитикам, тестировщикам и бизнесу. Для этого хорошо иметь наглядное визуальное представление. Классические диаграммы (UML, ER-диаграммы и другие, придуманные в эпоху монолитов) не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием, и диаграммы C4-model тоже не отражает работу в динамике. | Заложенные в архитектуру решения проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, поэтому их необходимо представлять не только разработчикам, но и аналитикам, тестировщикам и бизнесу. Для этого хорошо иметь наглядное визуальное представление. Классические диаграммы (UML, ER-диаграммы и другие, придуманные в эпоху монолитов) не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием, и диаграммы C4-model тоже не отражает работу в динамике. | ||
| − | Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах, и проиллюстрирую ее использование конкретными примерами. Такая визуализация сильно помогает в проектировании и в объяснении работы приложения. Выступление будет развитием серию моих докладов по акторной модели, начатую осенью 2020 года на AnalystDays. Предыдущие выступления — [[:Категория:Акторная модель|'''Акторная модель''']] | + | Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах, и проиллюстрирую ее использование конкретными примерами. Такая визуализация сильно помогает в проектировании и в объяснении работы приложения. Выступление будет развитием серию моих докладов по акторной модели, начатую осенью 2020 года на AnalystDays. Предыдущие выступления — [[:Категория:Акторная модель|'''Акторная модель''']], последнее '''[[Визуальное проектирование масштабируемых приложений (Highload-2022)]]'''. |
= Презентация = | = Презентация = | ||
Текущая версия на 18:02, 12 апреля 2026
10-11.04.2026 Ульяновск Стачка Выступление на сайте конференции Видео ожидается
Кажется, что задачи масштабирования в микросервисной архитектуре решаются просто: поднимаем нужное количество сервисов, и оно работает, что тут проектировать. Однако, есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. А еще надо обеспечить приемлемую скорость ответа для пользователя, который, быть может, именно сейчас с нетерпением ждет, когда, наконец, можно будет оплатить заказ и думает, не пойти ли ему за заказом на соседний сайт, раз уж тут так все медленно.
Заложенные в архитектуру решения проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, поэтому их необходимо представлять не только разработчикам, но и аналитикам, тестировщикам и бизнесу. Для этого хорошо иметь наглядное визуальное представление. Классические диаграммы (UML, ER-диаграммы и другие, придуманные в эпоху монолитов) не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием, и диаграммы C4-model тоже не отражает работу в динамике.
Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах, и проиллюстрирую ее использование конкретными примерами. Такая визуализация сильно помогает в проектировании и в объяснении работы приложения. Выступление будет развитием серию моих докладов по акторной модели, начатую осенью 2020 года на AnalystDays. Предыдущие выступления — Акторная модель, последнее Визуальное проектирование масштабируемых приложений (Highload-2022).
