9 лучших практик разработки микросервисов: наглядная иллюстрация от Alex Xu

1⃣Use separate data storage for each microservice
2⃣Keep code at a similar level of maturity
3⃣Separate build for each microservice
4⃣Assign each microservice with a single responsibility
5⃣Deploy into containers
6⃣Design stateless services
7⃣Adopt domain-driven design
8⃣Design micro frontend
9⃣Orchestrating microservices

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

Сессии, токены, JWT, SSO и OAuth: наглядная иллюстрация от Alex Xu.

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

➡️ Миграция в 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 для временных меток. Строковое представление времени более читаемо и удобно для работы.

👉 Подробнее

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