Визуальное проектирование масштабируемых приложений (Highload-2022) — различия между версиями
(Новая страница: « 13-14.05.2022 [https://highload.ru/foundation/2022 Highload-2022] [https://www.highload.ru/moscow/2021/abstracts/7943 Доклад на сайте конфер…») |
м |
||
Строка 1: | Строка 1: | ||
13-14.05.2022 [https://highload.ru/foundation/2022 Highload-2022] | 13-14.05.2022 [https://highload.ru/foundation/2022 Highload-2022] | ||
[https://www.highload.ru/moscow/2021/abstracts/7943 Доклад на сайте конференции] | [https://www.highload.ru/moscow/2021/abstracts/7943 Доклад на сайте конференции] | ||
+ | Видео ожидается, пока смотрите [[Визуальное проектирование масштабируемых приложений (TechLead-2021)|предыдущий доклад]] из серии [[:Категория:Акторная модель|Акторная модель]] | ||
Современная архитектура обычно предполагает поднимать для масштабирования много экземпляров одного сервиса с асинхронным взаимодействием через сообщения. При этом есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. Многие из этих аспектов проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, влияют на стоимость инфраструктуры и работу службы поддержки. Поэтому возможные решения надо обсуждать не только между разработчиками, а со всеми участниками проекта, включая бизнес. | Современная архитектура обычно предполагает поднимать для масштабирования много экземпляров одного сервиса с асинхронным взаимодействием через сообщения. При этом есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. Многие из этих аспектов проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, влияют на стоимость инфраструктуры и работу службы поддержки. Поэтому возможные решения надо обсуждать не только между разработчиками, а со всеми участниками проекта, включая бизнес. |
Версия 09:53, 12 мая 2022
13-14.05.2022 Highload-2022 Доклад на сайте конференции Видео ожидается, пока смотрите предыдущий доклад из серии Акторная модель
Современная архитектура обычно предполагает поднимать для масштабирования много экземпляров одного сервиса с асинхронным взаимодействием через сообщения. При этом есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. Многие из этих аспектов проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, влияют на стоимость инфраструктуры и работу службы поддержки. Поэтому возможные решения надо обсуждать не только между разработчиками, а со всеми участниками проекта, включая бизнес. Для этого хорошо иметь наглядное визуальное представление, которое послужит основой для обсуждения. Классические подходы и диаграммы проектирования - ER-диаграммы, UML, и другие были придуманы в эпоху монолитов, не слишком хорошо позволяют обсуждать такую архитектуру.
Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах. И проиллюстрирую ее использование конкретными примерами. Доклад продолжает серию моих докладов и мастер-классов по акторной модели, начатую осенью 2020 года на AnalystDays.
Презентация
Скачать весь pdf