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

Примеры разбиения доменного слоя на независмые сервисы, отвязка их друг от друга, методы общения и антипаттерны

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

#microservices
На прошедшей конференции Open-Source Summit 2022 в секции ответов на вопросы Линус Торвальдс упомянул о возможности скорой интеграции в ядро Linux компонентов для разработки драйверов устройств на языке Rust.

Не исключается, что патчи с поддержкой Rust будут приняты в ближайшем окне приёма изменений, формирующем состав ядра 5.20, намеченного на конец сентября.

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

Подробнее про то, какие проблемы будет решать Rust в качестве языка разработки ядра самой популярной ОС для серверов во всем мире можно прочесть в статье

https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/

#rust
Если вы разрабатываете на Golang, то наверняка знаете о возможности вызова C-кода из программ на Golang через CGO

Но что если есть потребность в транспиляции C-кода в Golang для дальнейшего развития?

Для этого есть полноценная утилита - CCGO.

И основной вопрос, который возникает после подобной манипуляции - насколько полученный код на Golang будет сопоставим по скорости с CGO или даже с чистым C

Автор статьи провел эксперимент, в котором сравнил производительность кода на чистом C, CGO и результата от транспиляции через CCGO.

И его результаты могут вас удивить

https://blog.nobugware.com/post/2022/surprising-result-while-transpiling-go/

#golang #clang
Статья о системе статических проверок и методов на этапе компиляции в Rust, помогающих предотвратить баги, которые в других языках программирования возникают в рантайме.

Большинство из предотвращаемых багов связаны с памятью.

В статье показаны основные концепции Rust, которые позволяют не вдаваться в вопросы управления памятью, но при этом предотвращают неопределенное поведение еще на этапе компиляции.

https://polyfloyd.net/post/how-rust-helps-you-prevent-bugs/

#rust
Обширная статья Uber про выявленные шаблоны состояния гонки в микросервисах на Go

https://eng.uber.com/data-race-patterns-in-go/

#golang #microservices
Привет!

Совсем недавно я делился с вами новостью про возможность включения Rust в качестве языка разработки ядра Linux.

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

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

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

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

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

https://www.ribice.ba/golang-memory-savings/

#golang
Роняли прод?

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

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

Одна из техник, которая позволяет выполнять откат неудачных деплоев без плясок с шаманскими музыкальными инструментами - это 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