User
Привет! Меня зовут Саша Сусиков. Я проверяю клавиатуры на прочность около 10 лет из них последние 2 года с помощью Go. Сейчас я участвую в разработке платформы СберМаркета, где создаю инструменты, которые упрощают жизнь разработчикам. Эта статья для тех, кому предстоит настроить процесс взаимодействия сервисов в компании и вы ищете, как не наломать дров.
В эпоху докризисной жизни, мне, как инженеру ориентировавшемуся на европейский и американский рынок, приходилось часто бывать на различных собеседованиях. Этот длиннотекст - краткое обобщение опыта общения с различными зарубежными компаниями в период 2021-2023 года в основном по профилю Software Engineer c редким вкраплением DevOps/SRE.
Мы уже рассказывали, почему первая версия архитектуры игры не была идеальной. Pixel Gun 3D изначально был прототипом в новом для команды жанре PvP-шутер. Хотели протестировать идею, чтобы собрать фидбек от игроков, но популярность игры начала расти достаточно быстро — писать ее заново было уже поздно. Сейчас подход к разработке новых проектов у нас сильно изменился, но зато тогда, без опыта, мы не потратили уйму времени на создание прототипа, который мог оказаться неинтересным для игроков.
С ростом функционала приходилось «на лету» менять архитектуру, делать ее масштабируемой, а также реализовать нашу идею — сделать шутер без даунтаймов даже во время технических работ или форс-мажора.
Далее сравним серверную архитектуру проекта несколько лет назад и сейчас, а также расскажу, как мы добивались дополнительной стабильности с помощью аварийных режимов с рубильниками для серверов.
Однажды в своем PvP-шутере мы за один день потеряли 30% от 60 тысяч одновременного онлайна. Это был 2018-й, в тот день на iOS вышел Fortnite. И хотя хайп был уже около года, а PUBG регулярно бил рекорды, без королевской битвы нам жилось вполне спокойно. Но тут стало очевидно, что батлрояль нельзя игнорировать, игрокам он нравится и нужно разрабатывать свой.
За два месяца мы проделали много интересной и сложной работы. Например, сделали свой редактор террейна, чтобы отрисовывать ландшафт не в 500 тысяч треугольников, как это делал Unity Terrain, а всего в 30 тысяч. Или написали мешбейкер, сократив количество запросов на отрисовку с 800 до 100, а освещение научились запекать за 5 минут вместо 30 часов.
И это не говоря уже об огромном количестве разных оптимизаций ассетов, подгрузки объектов и так далее. Обо всем этом и многом другом подробно расскажу под катом.
Yelp — это крупнейшее в США приложение для заказа еды и услуг. Оно установлено более чем на 30 млн. уникальных устройств, в нём зарегистрировано более 5 млн. компаний. Для хранения и доступа к данным в Yelp используют Cassandra. Как и для каких задач применяется эта база данных, на конференции Cassandra Day Russia 2021 рассказал Александр Широков, Database Reliability Engineer в Yelp.
Слышали про такой инструмент, как Airtable, но не знали, с чего начать? Тогда приглашаем в мир визуального программирования построения БД!
Этим постом мы начинаем цикл обучающих статей, в которых будем давать практические примеры работы с нашим инструментом Quarkly. В этом уроке мы сделаем простое веб-приложение, которое будет показывать сотрудников компании. При создании приложения ни один сотрудник РЖД не пострадал.
Фронт будем делать при помощи Quarkly, а данные подтягивать из базы в Airtable. На выходе получим react-приложение, синхронизированное с базой данных.
Данная статья рассчитана на новичков. Если вы опытный ниндзя, просто вспомните о том, как когда-то подобная информация могла быть полезной и для вас.
Kubernetes был создан Google на основе собственного опыта работы с контейнерами в производственной среде, и своим успехом он во многом обязан именно Google.
Так что же такое Kubernetes и для чего мы в принципе хотим использовать именно его, а не обычные контейнеры, например Docker.
Имеем: проект web API на .net core с исходниками в GitHub.
Хотим: авторазвертывание на виртуалке AWS EC2 после завершения работы с кодом (для примера push в develop ветку).
Инструментарий: GitHub Actions, AWS CodeDeploy, S3, EC2.
Ниже flow процесса, который будем реализовывать, погнали.
fn main() {
println!("Hello, Rust!");
println!("... Goodbye!");
}Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом на Rust. И сложно найти что-то другое, что вызывало бы больше негодования у новичков, и при этом такое, к чему совершенно спокойно относятся уже "понюхавшие пороха" Rust-программисты. Посмотрите, например, сколько эмоций вызывает синтаксис Rust у комментаторов одной из типичных новостей про Rust на OpenNET:
Настроить хранение данных приложений, запущенных в кластере Kubernetes, можно несколькими способами. Одни из них уже устарели, другие появились совсем недавно. В этой статье рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний — подключение через Container Storage Interface.
Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).
Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.
Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.
Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).
22 сентября мы провели Backend United #2: Фарш — встречу, посвященную тестированию бэкенда. Говорили о приемах тестирования бэкенда, его отличиях в разных языках. Обсуждали CDC-подход к тестированию микросервисов — почему в Авито используют нативные тесты, написанные на языках сервисов-потребителей. Рассказали о механике и сложностях внедрения Pact — наборе библиотек, которые реализуют Consumer-Driven Contract подход в тестировании API. И узнали, как в микросервисной архитектуре создать честные и эффективные изоляционные тесты.
Под катом делимся впечатлениями, фото, видео, презентациями со встречи и отзывами слушателей.
Привет! Меня зовут Константин Евтеев, я работаю в Авито руководителем юнита DBA. Наша команда развивает системы хранения данных Авито, помогает в выборе или выдаче баз данных и сопутствующей инфраструктуры, поддерживает Service Level Objective для серверов баз данных, а еще мы отвечаем за эффективность использования ресурсов и мониторинг, консультируем по проектированию, а возможно и разрабатываем микросервисы, сильно завязанные на системы хранения, или сервисы для развития платформы в контексте хранилищ.
Я хочу рассказать, как мы решили один из вызовов микросервисной архитектуры — проведение бизнес-транзакций в инфраструктуре сервисов, построенных с помощью паттерна Database per service. С докладом на эту тему я выступал на конференции Highload++ Siberia 2018.
