dprdev блог: мысли о .net и архитектуре
195 subscribers
2 photos
6 links
Всякое об IT, технологиях, архитектуре, рабочих моментах и факапах

.net, c#, architecture, microservices, databases, devops, apache kafka и прочее зло в наличии
Download Telegram
Коротко о главном: максимально субъективный взгляд на IT, технологии и архитектуру

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

Welcome в dpr/dev space !

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


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

#orchestration
#distributed_transactions
#temporal
#security
#auth
#dotnet
#efcore
#db
#db_design
#dwh
#system_design
#api_design
#infrastructure
🌭2🎃2
Наблюдая извечные холивары о том, что такое МСА, когда нужно применять МСА, чем МСА лучше монолита, становится немного грустно: к сожалению, многие люди тотально не понимают двух вещей
1) довольно большое количество людей было введено в заблуждение относительно многих вещей, касающихся МСА
2) довольно немногие в действительности понимают, когда и зачем нужно декомпозировать монолит на разные деплоймент-юниты (сервисы. в привычной для всех терминологии)

Основные рабочие версии такие
- они нужны для больших рпс и лучшего скейлинга
- они нужны для роста ТТМ
- они нужны для повышения отказоустойчивости и надежности
- монолит превращается в комок грязи
- и тд, по порядку из книги ричардсона

Проблема этих утверждений в том, что они имеют место быть только при очень большом количестве «если», которые нужно каждый раз явно озвучивать.
Обычно этого не делают, что порождает многочасовые споры, а сами доводы переводит в разряд «набросов». Кто из нас не слышал фразы по типу «у меня такой же монолит и не болит (так же скейлится, более надежен и тд)

Глядя на все это, давно посещает мысль написать цикл статей на эту тему.
Возможно, начну со скейлинга (или очередного определения мса 🙈)
#temporal
#distributed_transactions
#orchestration

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

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

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

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

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

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

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

Temporal: Введение. Часть 1
👍2
dprdev блог: мысли о .net и архитектуре pinned «Коротко о главном: максимально субъективный взгляд на IT, технологии и архитектуру Тут могут быть - различные истории из рабочего опыта - интересные подходы и нюансы, которые могут мне повстречаться - описания жирных факапов прямо с прода Welcome в dpr/dev…»