или авторизуйтесь, если у вас он уже есть
Кажется, что задачи масштабирования в микросервисной архитектуре решаются просто: поднимаем нужное количество сервисов, и оно работает, что тут проектировать. Однако, есть много подводных камней, связанных с возможными блокировками, сбалансированностью нагрузки между разными сервисами для быстрой обработки сообщений, устойчивостью работы при падении экземпляров сервисов. А еще надо обеспечить приемлемую скорость ответа для пользователя, который, быть может, именно сейчас с нетерпением ждет, когда, наконец, можно будет оплатить заказ и думает, не пойти ли ему за заказом на соседний сайт, раз уж тут так все медленно.
Заложенные в архитектуру решения проявляются при работе пользователей, который получает непредвиденные ошибки и неустойчивую работу системы, поэтому их необходимо представлять не только разработчикам, но и аналитикам, тестировщикам и бизнесу. Для этого хорошо иметь наглядное визуальное представление. Классические диаграммы (UML, ER-диаграммы и другие, придуманные в эпоху монолитов) не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием, и диаграммы C4-model тоже не отражает работу в динамике.
Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах, и проиллюстрирую ее использование конкретными примерами. Такая визуализация сильно помогает в проектировании и в объяснении работы приложения. Выступление будет развитием серию моих докладов по акторной модели, начатую осенью 2020 года на AnalystDays.