Коротко о главном: максимально субъективный взгляд на IT, технологии и архитектуру

Тут могут быть
- различные истории из рабочего опыта
- интересные подходы и нюансы, которые могут мне повстречаться
- описания жирных факапов прямо с прода

Welcome в dpr/dev space !

PS: (токсичным) Желающим похоливарить про кафку тут всегда рады.


Полезные теги для поиска

#orchestration
#distributed_transactions
#temporal
#security
#auth
#dotnet
#efcore
#db
#db_design
#dwh
#system_design
#api_design
#infrastructure

#temporal
#distributed_transactions
#orchestration

Temporal: Введение. Часть 1

В сегодняшнем посте речь пойдет о Temporal и о том, как мы его используем. Для тех, кто не в курсе, Temporal — движок оркестрации процессов, который устанавливается как отдельный инфраструктурный компонент в кластер и может выступать в качестве платформы для реализации длительных процессов.

Естественно, такие преимущества, как персистентность шагов, восстановление после сбоев (DR), высокая скорость исполнения и прочее — все это присутствует. Почитать можно здесь.

Сам Temporal состоит из нескольких ключевых компонентов:

- Кластер — платформа, которая умеет планировать задачи, выполнять их, регистрировать воркеры и т.д.
- Воркеры — отдельные приложения, которые хостят и запускают реализованные инженерами процессы (в дальнейшем — воркфлоу).

Каждый воркер может содержать несколько воркфлоу. Их можно запускать в разных очередях задач и неймспейсах. Подробнее с этими концепциями можно ознакомиться в документации.

Важно понимать следующее: все шаги Temporal персистит в базе данных, и когда он восстанавливает воркфлоу, он заново проходит по всем шагам от начала и до конца (до места последней остановки или ожидания следующего шага).

Temporal: Введение. Часть 1

#temporal
#distributed_transactions
#orchestration

Ухххх. Мне самому не верится, но я-таки нашел пару свободных часов и дописал то, что обещал дописать несколько месяцев назад :)


Temporal: Intro. Часть 2: workflow versioning

В этой статье мы продолжим говорить о Temporal, а именно о том, какие подходы существуют для версионирования temporal workflow.

Погнали:

Temporal: Intro. Часть 2: workflow versioning

#temporal
#system_design
#requirements

Так-с, ну вот ещё одна :)

Несмотря на то, что в заголовке фигурирует Temporal, это не совсем статья про Temporal. Это материал про проектирование систем. Про то, как превратить неструктурированные хотелки в формальные требования, не потерять здравый смысл по пути, заложить архитектурный фундамент и не пожалеть об этом через месяц. Ну и спроектировать workflow на Temporal, конечно же :)

В этой части я попробовал описать анализ требований в новом формате — с живыми диалогами, структурированными каталогами и архитектурными выводами прямо на ходу.

Интересно будет узнать в комментариях, насколько такой стиль заходит. Особенно от тех, кто осилит статью до конца (а статья получилась довольно большой, пришлось даже ужимать - надеюсь, что не в ущерб качеству) :)

—

📖 Часть 1 — «Анализ требований» — уже доступна:
Temporal: Deep Dive. От требований до workflow: проектируем биллинг с оркестрацией.

В этой статье мы отойдём от абстрактной теории и наконец-то займемся чем-то интересным. Вместо обсуждения надуманных примеров, мы возьмём вполне реалистичную задачу для огромного количества (не финтех) компаний — обработку платёжных транзакций. Вместе мы попробуем пройти весь путь: от первых продуктовых обсуждений до готовой системы, часть которой реализована с помощью Temporal Workflow.

Мы начнём с того, что трансформируем неструктурированные хотелки в формализованные требования: функциональные, нефункциональные и бизнес-правила. Затем мы разберёмся с особенностями интеграции с платёжным шлюзом и ограничениями, которые она накладывает.

После этого — обсудим архитектурные решения, объясним, почему для оркестрации мы выбрали именно Temporal, и, наконец, покажем, как перейти от идей и диаграмм к коду — включая тестирование, наблюдаемость и поддержку изменений.

Готовы? Поехали!