F
Пятничное чтиво
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
GitHub’s Journey from Monolith to Microservices
Гитхаб появился в 2008 как рельсовый монолит, а за последние 1.5 года компания увеличила штат инженеров в 2 раза. Ситуация стала отправной точкой, что бы компания начина миграцию на сервисы. В итоге ребята получили архитектуру с Twirp, кафкой (если правильно понял), отдельным authN/authZ сервисами и self-service runtime platform для деплоя.
К сожалению, статья поверхностная. Но, понравилось что инженеры решили начать миграцию не с выноса кода в отдельные модули, а с разделения данных на отдельные базы данных. Что позволило определять cross boundaries вызовы для последующего рефакторинга. Кажется, что это важнейшая идея из текста, о которой забывают в других компаниях.
Также, подтвердился личный опыт, что scientist помогает переключать трафик на новую часть кода с меньшей тревогой (если логика не меняется). И было бы интересно подробнее почитать больше о AuthN сервисе и почему монолит ходит в этот сервис через Twirp.
—————————————
Architecting Modern Decentralized Applications
Под dApp подразумевают приложения, работающие в децентрализованной системе (например поверх смарт контрактов). Кажется, что dApp подойдут в аукционах, идентификации пользователя, играх и около биржах. К сожалению, проектирование таких систем достаточно болезненно в виду того, что надо учитывать security, usability и decentralization со своими ограничениями и особенностями. А также думать о имутабельности данных.
В статье приводится пример реализации 5 видов децентрализованных систем с кратким описанием, плюсами и минусами. Полный список видов выглядит следующим образом:
- Fully Decentralized (The Pure Dapp)
- Semi Decentralized (The common Dapp)
- Semi Decentralized (The other common Dapp)
- Semi Decentralized (Backend + Wallet)
- Centralized (Backend + Centralized Wallet)
—————————————
Building an Idempotent Event Consumer with Quarkus and Kafka
Возникающий вопрос при проектировании асинхронных систем - как сделать идемпотентность для событий. Т.е. как сделать так, чтобы отправка одного события 2+ раза, каждый раз, приводила только к одному вызову консьюмера для события. Это необходимо, чтобы избежать проблемы дублирования данных, особенно когда дело касается денег.
Текст начинается с описания ситуаций, в которых может возникнуть такая проблема, а причин три: ошибка консьюмера, ошибка message broker и ошибка сети. Дальше автор объясняет зачем нужна идемпотентность в асинхронных коммуникациях. А в качестве решения проблемы предлагает использовать логику, поверх уникального message id, таблицы со всеми message id и логики, которая проверяет сообщения на уникальность. Для большей наглядности - приводится пример основанный на Quarkus, MySQL и Kafka.
Также, понравилось, что в конце найдете два альтернативных решения проблемы, описанных в другой статье.
Старые записи стримов можно найти на ютубе. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
GitHub’s Journey from Monolith to Microservices
Гитхаб появился в 2008 как рельсовый монолит, а за последние 1.5 года компания увеличила штат инженеров в 2 раза. Ситуация стала отправной точкой, что бы компания начина миграцию на сервисы. В итоге ребята получили архитектуру с Twirp, кафкой (если правильно понял), отдельным authN/authZ сервисами и self-service runtime platform для деплоя.
К сожалению, статья поверхностная. Но, понравилось что инженеры решили начать миграцию не с выноса кода в отдельные модули, а с разделения данных на отдельные базы данных. Что позволило определять cross boundaries вызовы для последующего рефакторинга. Кажется, что это важнейшая идея из текста, о которой забывают в других компаниях.
Также, подтвердился личный опыт, что scientist помогает переключать трафик на новую часть кода с меньшей тревогой (если логика не меняется). И было бы интересно подробнее почитать больше о AuthN сервисе и почему монолит ходит в этот сервис через Twirp.
—————————————
Architecting Modern Decentralized Applications
Под dApp подразумевают приложения, работающие в децентрализованной системе (например поверх смарт контрактов). Кажется, что dApp подойдут в аукционах, идентификации пользователя, играх и около биржах. К сожалению, проектирование таких систем достаточно болезненно в виду того, что надо учитывать security, usability и decentralization со своими ограничениями и особенностями. А также думать о имутабельности данных.
В статье приводится пример реализации 5 видов децентрализованных систем с кратким описанием, плюсами и минусами. Полный список видов выглядит следующим образом:
- Fully Decentralized (The Pure Dapp)
- Semi Decentralized (The common Dapp)
- Semi Decentralized (The other common Dapp)
- Semi Decentralized (Backend + Wallet)
- Centralized (Backend + Centralized Wallet)
—————————————
Building an Idempotent Event Consumer with Quarkus and Kafka
Возникающий вопрос при проектировании асинхронных систем - как сделать идемпотентность для событий. Т.е. как сделать так, чтобы отправка одного события 2+ раза, каждый раз, приводила только к одному вызову консьюмера для события. Это необходимо, чтобы избежать проблемы дублирования данных, особенно когда дело касается денег.
Текст начинается с описания ситуаций, в которых может возникнуть такая проблема, а причин три: ошибка консьюмера, ошибка message broker и ошибка сети. Дальше автор объясняет зачем нужна идемпотентность в асинхронных коммуникациях. А в качестве решения проблемы предлагает использовать логику, поверх уникального message id, таблицы со всеми message id и логики, которая проверяет сообщения на уникальность. Для большей наглядности - приводится пример основанный на Quarkus, MySQL и Kafka.
Также, понравилось, что в конце найдете два альтернативных решения проблемы, описанных в другой статье.
