➡️ Миграция в Cloud Native: пошаговая демонстрация от ByteByteGo

1️⃣ Application definition development
2️⃣ Orchestration and management
3️⃣ Runtime
4️⃣ Provisioning
5️⃣ Observability
6️⃣ Serverless

#проектирование_систем #инфографика

IBM MQ -> RabbitMQ -> Kafka -> Pulsar: как развиваются архитектуры инструментов управления очередями сообщений

🔹 IBM MQ — Message Oriented Middleware
🔹 RabbitMQ (Rabbit Technologies) — программный брокер сообщений на основе стандарта AMQP
🔹 Kafka (LinkedIn) — платформа потоковой передачи для создания конвейеров данных и приложений потоковой передачи в реальном времени
🔹 Pulsar (Yahoo) — распределенная платформа обмена сообщениями с гибкой моделью обмена и интуитивно понятным клиентским API

#проектирование_систем #инфографика

🎤 QCon SF 2023: как Netflix на самом деле использует Java, Пол Баккер

Пол Баккер, разработчик в команде Java-платформы Netflix и соавтор книги Java 9 Modularity, положил конец мифу о том, что «Netflix — это микросервисы RxJava, а всем заправляют Hystrix, Spring Cloud и Chaos Monkeys».

Баккер описал оригинальную архитектуру знакомого приложения Netflix для просмотра фильмов, доступ к которому осуществляется через ТВ и другие устройства, подключаемые к API-серверу с поддержкой Groovy с помощью REST и gRPC-подключений к различным сервисам.

Также Пол представил другие архитектурные модели и отметил, что Java был и остается в активной разработке в Netflix. Они поддерживают дистрибутив OpenJDK Azul Zulu 17 с активным тестированием на JDK 21, запуская ~2800 приложений, созданных с использованием ~1500 библиотек. Gradle вместе с Nebula, коллекцией плагинов Gradle, созданных Netflix, и IntelliJ IDEA являются их предпочтительными инструментами сборки.

👉 Подробнее

#проектирование_систем #java

Эволюция микросервисной архитектуры Airbnb за последние 15 лет: иллюстрация от ByteByteGo (Alex Xu) по мотивам этого выступления на конференции

⏱Микросервисная архитектура Airbnb прошла три основных этапа и продолжает развиваться:

1️⃣Монолит (2008 — 2017)
Сайт Airbnb начинался как простая торговая площадка для хозяев и гостей. Это был огромный монолит на Ruby on Rails.

📌В чем проблема?
— проблемы масштабирования;
— медленный деплой;
— снижение скорости разработки.

2️⃣Микросервисы (2017 — 2020)
Микросервис был призван решить эти проблемы. В микросервисной архитектуре было 4 ключевых сервиса, которые находились за API gateway:
— fetching сервис;
— сервис бизнес-логики;
— workflow сервис;
— UI aggregation сервис.

📌В чем проблема?
Разработчикам было трудно управлять сотнями сервисов и зависимостей.

3️⃣Микро+макросервисы (2020 — настоящее время)
Над этим сейчас работает Airbnb. Гибридная модель микро- и макросервисов фокусируется на унификации API.

#проектирование_систем

🤩 System Design 101: перевод на русский уже опубликованных на канале постов из рубрики #проектирование_систем и #инфографика от ByteByteGo (Alex Xu)

👉 Вас ждут следующие разделы:
☑️Протоколы
☑️CI/CD
☑️Архитектурные паттерны
☑️Базы данных
☑️Кэш
☑️Микросервисная архитектура
☑️Платежные системы
☑️DevOps
☑️Git
☑️Облачные сервисы
☑️Инструменты, повышающие продуктивность разработки
☑️Linux
☑️Безопасность
☑️Реальные системы

🎙️ArchDays — конференция по микросервисам и архитектуре IT-решений. Ниже — записи свежих и не только докладов с митапов, приуроченных к конференции.

📌 Выберите и смотрите ту тему, которая вам интересна:

📺 Сага — решение технической проблемы или доменный процесс / Михаил Натаров
📺 Об архитектуре системы моделирования на базе цифровых двойников производства / Илья Смирнов
📺 Многоликий DDD / Сергей Баранов
📺 Тернистый путь инструмента цифрового проектирования / Виктор Выскребенцев
📺 Проектирование БД: от NF к денормализации данных / Антон Цитульский
📺 Continuous deployment — следующая ступенька после Continuous delivery / Иван Волынкин
📺 Как автоматизация и AI позволяют сократить время устранения уязвимостей / Антон Башарин

#чтопроисходит #проектирование_систем

🛠 Как проектировать REST API: полезные советы для разработчика

1. Используйте существительные во множественном числе для обозначения коллекций.

# Хорошо
GET /products         
GET /products/{product_id} 

# Плохо
GET /product/{product_id}

2. Не добавляйте ненужные пути в структуру URL-адресов.

# Хорошо
GET /v3/application/listings/{listing_id}

# Плохо
PATCH /v3/application/shops/{shop_id}/listings/{listing_id}

3. Не добавляйте .json или другие расширения к URL-адресу.

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

# Хорошо
GET /things returns:
{ "data": [{ ...thing1...}, { ...thing2...}] }

# Плохо
GET /things returns:
[{ ...thing1...}, { ...thing2...}]

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

# Хорошо
GET /things returns:
{
    "data": [
        { "id": "KEY3", "foo": "bat" }
    ]   
}

# Плохо
GET /things returns:
{
    "KEY3": { "id": "KEY3", "foo": "bat" }
}

6. Используйте строки для всех идентификаторов.

# Хорошо
{ "id": "123" }

# Плохо
{ "id": 123 }

7. Добавляйте префиксы к идентификаторам. Это улучшает читаемость API и помогает различать разные типы идентификаторов.

8. Не используйте 404 для обозначения "not found". Вместо этого рекомендуется использовать другие коды ошибок, чтобы точно указать на отсутствие ресурса.

9. Будьте последовательными. Несоответствие в схемах и структурах может вызвать путаницу и усложнить работу с API.

10. Используйте структурированный формат ошибок. Это облегчает отладку и обработку ошибок на разных уровнях системы.

11. Обеспечьте механизмы идемпотентности. Это важно для предотвращения дублирования операций в условиях нестабильной сети.

12. Используйте строки ISO8601 для временных меток. Строковое представление времени более читаемо и удобно для работы.

👉 Подробнее

#проектирование_систем

💡Развитие протоколов API в 2023 году: по мотивам статьи Alex Xu в блоге Postman

В PDF-файле — обзорная демонстрация, а в статье вас ждет подробный взгляд на шесть самых популярных протоколов API с акцентом на преимущества и проблемы каждого:

1️⃣ REST
2️⃣ Webhooks
3️⃣ GraphQL
4️⃣ SOAP
5️⃣ WebSocket
6️⃣ gRPC

💬 Какой используется в вашем проекте? Делитесь в комментариях мыслями по данной теме👇

#проектирование_систем

💡10 архитектурных стилей ПО и их паттерны: шпаргалка для разработчика

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

📌 Основные характеристики архитектурных стилей и примеры паттернов:

1️⃣ Многослойный: разделяет систему на слои с четко определенными ролями и зависимостями. Каждый слой выполняет определенную функцию.

📝 «N-уровневая архитектура», «Чистая архитектура».

2️⃣ Компонентно-ориентированный: фокусируется на разделении системы на отдельные, взаимозаменяемые компоненты, каждый из которых имеет четко определенный интерфейс.

📝 «Микроядро», «Плагин».

3️⃣ Сервисно-ориентированный: состоит из независимых сервисов, которые общаются друг с другом.

📝 SOA, Broker, «Микросервисы», FaaS.

4️⃣ Распределенная система: включает системы, распределенные по различным сетевым узлам для улучшения масштабируемости и надежности.

📝 Space-Based, «Одноранговая сеть».

5️⃣ Предметно-ориентированный: подход, сосредоточенный на моделировании домена и бизнес-логики, и акцентирующий внимание на сложных бизнес-правилах.

📝 Шестигранный паттерн, DDD.

6️⃣ Событийно-ориентированный: архитектура, основанная на обработке событий, где компоненты системы реагируют на события.

📝 CQRS, Pub-Sub.

7️⃣ Разделения ответственности: фокусируется на разделении системы на части, каждая из которых решает отдельную задачу.

📝 MVVP, MVP.

8️⃣ Интерпретатор: используется в кейсах, где требуется гибкость и возможность обработки разнообразных языковых структур.

📝 «Интерпретатор».

9️⃣ Конкурентность: ориентирован на разработку систем, которые одновременно выполняют несколько операций, улучшая производительность и отзывчивость.

📝 «Оркестрация», Choreography, Primary-Secondary, Pipeline.

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

📝 CQRS, Event Sourcing, Kappa, Lambda.

👉 Источник
👉 Читать на русском

#проектирование_систем

💬 Что такое микросервисная архитектура и как правильно ее реализовать с помощью Self-contained Systems?

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

В отличие от микросервисов, существует так называемый подход Self-contained Systems (SCS), который приоритезирует децентрализацию приложений на независимые системы, каждая из которых обладает своей доменной логикой, UI, хранилищем данных и сервисным API в случае необходимости. Обычно за них отвечает одна команда.

📌 Основные преимущества:

☑️ Автономность: каждая SCS работает независимо со своей базой данных, бизнес-логикой и UI
☑️ Ориентированность на домен: SCS структурированы вокруг конкретных бизнес-доменов
☑️ Децентрализованное управление данными: индивидуальные базы данных для каждой SCS обеспечивают консистентность данных в пределах своих границ, уменьшая зависимости между сервисами
☑️ Технологическое разнообразие: позволяет использовать различные технологические стеки в разных SCS, соответствующие конкретным потребностям каждого домена
☑️ Независимый деплой: каждую SCS можно деплоить, масштабировать и обновлять независимо, не влияя на другие системы

📌 Почему SCS можеть быть альтернативой микросервисам:

☑️ Более широкий охват
☑️ Уменьшенная операционная сложность
☑️ Консистентность данных
☑️ Уменьшенное межсервисное взаимодействие

Такие системы хорошо сочетаются с DDD. Первый шаг в создании таких систем — анализ домена, который может быть проведен путем выявления ограниченных контекстов, соответствующих конкретным бизнес-доменам. Каждый ограниченный контекст затем инкапсулируется в SCS, который включает в себя управление данными, бизнес-логику и UI, обеспечивая автономность каждой системы, но при этом способность взаимодействовать с другими через четко определенные API при необходимости.

👉 Источник

#проектирование_систем

Доставка кода в продакшен: типичный workflow от ByteByteGo (Alex Xu)

#проектирование_систем

👨‍🎓Направления проектирования систем: шпаргалка для подготовки к собесу от ByteByteGo

☑️ Балансировка нагрузки
☑️ API Gateway
☑️ Протоколы связи
☑️ CDN
☑️ База данных
☑️ Кэш
☑️ Очередь сообщений
☑️ Генерация уникальных идентификаторов
☑️ Масштабируемость
☑️ Доступность
☑️ Производительность
☑️ Устойчивость к сбоям и восстановление
☑️ Безопасность и многое другое

#проектирование_систем

🤯 Архитектурное собеседование — одно из самых сложных как для кандидата, так и для интервьюера. Подготовиться к нему можно многими способами, один из таких — это мок-собесы👇

🔹 Интервью по System Design. Александр Поломодов
🔹 Владимир Иванов, Антон Сорокин: публичное собеседование по System Design
🔹 Павел Филонов, Александр Гранин: техническое интервью, архитектурная секция
🔹 Владимир Иванов, Александр Поломодов: техническое интервью, архитектурная секция

#проектирование_систем

👀 Свежий взгляд на методологию The Twelve-Factor App для разработки SaaS-приложений

Методология предоставляет набор лучших практик для разработки современных веб-приложений на любой платформе. Практики описывают приложения, которые готовы:

✔️ к горизонтальному масштабированию;
✔️ к непрерывному развертыванию;
✔️ к современным облачным хостингам.

👉 Читать

#проектирование_систем #инфографика

🧰 Краткий обзор архитектуры Reddit, основанный на исследованиях из инженерных блогов

🔹 CDN
🔹 Фронтенд: jQuery —> Typescript —> Node.js
🔹 Балансировка нагрузки
🔹 Микросервисы: монолит на Python —> микросервисы на Go
🔹 API: GraphQL —> GraphQL Federation —> несколько новых Go subgraphs для разделения монолита GraphQL
🔹 Хранение данных: memcached + Postgres + Cassandra
🔹 Репликация данных: Debezium
🔹 Асинхронная обработка: RabbitMQ + Kafka
🔹 Хостинг: AWS и Kubernetes
🔹 Деплой и инфраструктура: Spinnaker, Drone CI и Terraform

👉 Источник

#инфографика #проектирование_систем

🔁 Обработка ретраев на практике

В распределенных системах и сетевых приложениях стратегии ретраев имеют решающее значение для эффективной обработки временных ошибок и нестабильности сети. На диаграмме показаны 4 распространенные стратегии:

🔹 Linear Backoff
🔹 Linear Jitter Backoff
🔹 Exponential Backoff
🔹 Exponential Jitter Backoff

👉 Источник

#проектирование_систем #инфографика

📑 Пагинация страниц при проектировании API: основные методы

🔹 На основе смещения:
GET /orders?offset=0&limit=3

🔹 На основе курсора:
GET /orders?cursor=xxx

🔹 На основе страницы:
GET /items?page=2&size=3

🔹 На основе ключа:
GET /items?after_id=102&limit=3

🔹 На основе времени:
GET /items?start_time=xxx&end_time=yyy

🔹 Гибридная пагинация:
GET /items?cursor=abc&start_time=xxx&end_time=yyy

👉 Читать подробнее о достоинствах и недостатках

#проектирование_систем #инфографика

🚀 История девятимесячного пути к горизонтальному шардированию стека Postgres Figma и ключ к открытию (почти) бесконечной масштабируемости: по мотивам статьи из блога Figma

Стек базы данных Postgres, с ростом пользовательской базы на 200% с 2018 года до 3 миллионов пользователей в месяц, вырос почти в 100 раз.

📌 Как команде это удалось?

🔷 Вертикальное масштабирование и репликация: они обновили базу до крупнейшего инстанса Amazon RDS и создали несколько реплик для масштабирования чтения, используя PgBouncer для управления соединениями.
🔷 Вертикальное разделение: перенесли высоконагруженные таблицы в отдельные базы данных, управляемые несколькими PgBouncer.
🔷 Горизонтальное шардирование: для больших таблиц внедрили горизонтальное шардирование, создавая новый сервис DBProxy для маршрутизации и выполнения запросов.

👉 Подробнее
👉 Источник

#проектирование_систем #инфографика

👨‍💻 Шпаргалка по проектированию реляционных баз данных

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

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

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

👉 Источник

#инфографика #проектирование_систем