Бэкендошная
107 subscribers
2 photos
66 links
Канал о backend-разработке и backend-разработчиках: языки программирования, алгоритмы и структуры данных, методологии, околопрограммистские темы и никакого (ну почти) фронтенда
Download Telegram
Роняли прод?

Неверный вопрос, конечно же роняли. (киньте в меня камень первым если это не так)

И в случае, когда что-то пошло не так - очень важно уметь быстро откатываться до стабильного состояния.

Одна из техник, которая позволяет выполнять откат неудачных деплоев без плясок с шаманскими музыкальными инструментами - это Blue/Green.

Именно про нее и поговорим в сегодняшней статье.

https://readosapien.com/blue-green-deployment-zero-downtime-deployment/

#microservices #deploy #systemdesign
Обширная статья про некоторые неочевидные подводные камни Golang

Если вы уже знакомы с "50 Shades of Go" - это ее духовный наследник, который помимо всего приносит очень много новых ошибок новичка, на которые можно натолкнуться

https://rytisbiel.com/2021/03/06/darker-corners-of-go/

#golang
Привет!

Неделю назад я делился с вами методикой Blue/Green деплоя.

Сегодня же принес статью про еще один вариант безболезненных выкаток - это Канареечный релиз.

Метод канарейки можно применять не только для поэтапной раскатки, не ломая функционал для львиной доли пользователей, но также и для того чтобы, проверять гипотезы методом A/B. Раскатите новый функционал на 50% пользователей и следите за изменением метрик для обеих групп.

https://codefresh.io/learn/software-deployment/what-are-canary-deployments/

#microservices #deploy #systemdesign
Если ваше приложение на Golang активно использует память, то вам наверняка знакома проблема, связанная с частотой запуска GC, которая вызывает частые фризы из-за STW.

По умолчанию GC начинает работать при удвоении размера аллоцируемой памяти - это значит что при небольших значениях памяти и активном ее потреблении - GC будет запускаться чаще чем хочется и приложение будет чаще фризиться.

Несколько лет назад команда Twitch активно продвигала так называемый метод балласта - когда при старте приложения аллоцируется некий объем памяти, являющийся балластом и GC все-также срабатывает при удвоении памяти, но за счет балласта, старт его работы удается значительно отсрочить.

Но метод балласта не убережет вас от OOM так как рано или поздно - удвоение памяти приведет к попытке выхода за границы физической памяти.

Для того чтобы GC срабатывал не только при изменении потребления памяти, но при достижении определенных ее значений - в Go 1.19 был введен параметр GOMEMLIMIT который позволит сделать управление стартом GC более гибким и прозрачным.

Про опыт его использования и пойдет речь в сегодняшней статье

https://weaviate.io/blog/2022/08/GOMEMLIMIT-a-Game-Changer-for-High-Memory-Applications.html

#golang
👍1
Привет!

Сегодня хочу поделиться видео-рассуждением на тему, сможет ли Rust стать главным языком системного программирования на следующие 40 лет

https://www.youtube.com/watch?v=A3AdN7U24iU

#rust
💩1
Microservices. Microservices everywhere!

В последнее время микросервисы становятся чуть ли не must-have архитектурой для любой уважающей себя IT компании.

Но что, если микросервисы - это просто новый карго-культ и вам они не нужны?

Сегодня я принес вам статью, в которой автор описывает причины и приводит аргументы в пользу того, что на вашем проекте микросервисы могут скорее навредить, нежели принести ощутимую пользу при разработке и сопровождении.

https://itnext.io/you-dont-need-microservices-2ad8508b9e27

#microservices #systemdesign
Статья про то, как можно быстро, при помощи фреймворка go-zero, сделать ваши gRPC-хэндлеры переиспользуемыми для REST-протокола без необходимости дублирования кода, при помощи декларативного описания и кодогенерации.

https://dev.to/kevwan/5-minutes-to-add-restful-apis-for-your-grpc-services-2dnl

#golang
Обзорная статья про построение событийно-ориентированной архитектуры

Разбор компонентов, преимущества и недостатки, а также пошаговый разбор перехода от синхронного взаимодействия к асинхронному

https://engineering.hashnode.com/building-an-event-driven-architecture-at-hashnode

#systemdesign
Одна из основных проблем микросервисов - это проблема их коммуникации.

Если вы выберете неверную стратегию, то велика вероятность вместо микросервисной архитектуры получить распределнный монолит.

В сегодняшней статье приводятся основные виды коммуникации между микросервисами, их плюсы и минусы

https://skolaparthi.com/communication-between-microservices/

#microservices
Неделю назад я делился с вами статьей про реализацию событий-ориентированной архитектуры, а сегодня хочу поделиться статьей про пятерку подводных камней данного подхода и советы по их избеганию или решению

https://medium.com/wix-engineering/event-driven-architecture-5-pitfalls-to-avoid-b3ebf885bdb1

#systemdesign
Еще одна проблема в микросервисной архитектуре после перехода с монолита - это транзакции.

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

Для микросервисной архитектуры есть подход распределенных транзаций, но он не лишен изъянов

Сегодняшняя статья расскажет в том числе про такие изъяны, а также предложит новый вариант решения проблемы транзацикй в распределенной системе

https://krishnakrmahto.com/transactional-messaging-in-microservices

#microservices
Продолжаем тему решения различных проблем микросервисной архитектуры после перехода с монолита.

Сегодня речь пойдет про авторизацию и best practise по ее реализации в микросервисной архитектуре

https://www.osohq.com/post/microservices-authorization-patterns

#microservices
При разработке распределенного приложения, рано или поздно вы столкнетесь с проблемой, когда разным частям вашей системе потребуется согласованность данных друг с другом.

Но как быть, если у вас нет архитектуры распределенных транзакций?

Ответить на этот вопрос на примере одного из кейсов, где возникает подобная проблема, попробует автор видео

https://www.youtube.com/watch?v=Trl4--FO7Yo

#microservices
Статья Netflix про их собственную реализацию очередей с приоритетом, которая имеет высокую пропускную способность при минимальных задержках и покрывает все потребности их платформы.

Статья подробно рассказывает про ключевые концепции системы, охватывает историю её создания и развития, а также архитектуру на которой она построена

https://netflixtechblog.com/timestone-netflixs-high-throughput-low-latency-priority-queueing-system-with-built-in-support-1abf249ba95f

#highload
Один из самых частых этапов при подготовке к собеседованиям - это решение алгоритмических задач на Leetcode.

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

Сегодня я делюсь с вами интересным видео, в котором автор взял TOP-3 задачи, по которым меньше всего процент успешных решений и пытается их решить, плпутно делясь алгоритмами и подходами к решению

https://youtu.be/Ow1D5O05NfM

#leetcode
Привет!

Сегодня очень полезная информация для прохождения секции system design: пример пошагового проектирования системы на подобии Google Places - сервисов, которые основаны на поиске ближайших к вам мест по критериям - рестораны, гостиницы, заправки и т.д.

https://youtu.be/M4lR_Va97cQ

#systemdesign
Проблемы микросервисов

- сетевые издержки на коммуникацию между функциями
- сложности при отладке из-за распределенности системы
- усложнение архитектуры
- одинаковые функции в разных микросервисах

Про решение первых трех есть немало статей, в том числе и в этом канале они были - тут и тут

Сегодня я делюсь статьей с best practices решения проблем дублирования кода - вынесения его в библиотеки и переиспользование в нескольких независмых сервисах.

https://medium.com/duda/shared-libraries-design-and-best-practices-710774ae0bdc

#microservices
Статья про интересный подход к написанию чистого кода.

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

https://davidamos.dev/the-rule-of-six/

#cleancode