DeepSeek, генерируем саммари по любимой литературе
Просим ИИ сделать краткий пересказ по-русски английской книги Сэма Ньюмана про микросервисы.
Первое, что просит сделать обыватель джина, вызванного из лампы — решить самую насущную его, обывателя, проблему. В моем случае, задача по установке и настройке Postgresql на моем рабочем Mac-е не требовала отлагательств, и в качестве разминки новому ИИ было предложено сгенерировать инструкцию, чтобы мне не пришлось лазить по интернету в поисках этой инфы собственноручно. Ну а для чего еще по-вашему нужны помощники?..
После инструкции требовалось что-то еще. Нужно было нагрузить поганца как следует. Одна из моих проблем, которую ИИ смог бы немножко облегчить — тотальная нехватка времени, чтобы перечитать это все. Очень много литературы для ознакомления, отбора и въедливого изучения на двух языках. Причем в электронном виде объем литературы перевалил за все мыслимые границы. Нужно как-то отбирать лучшие и наиболее подходящие книги. Вот тут-то, казалось бы, у ИИ нет конкурентов. Не попробовать было бы глупо.
Для проверки анализа книжного текста была выбрана первая попавшаяся книга, Сэм Ньюман, "Building Microservices: Designing Fine-Grained Systems" на английском языке (вот, кстати, она на сайте издателя, а вот в переводе на русский в магазине).
Книга была загружена в чистый чат с DeepSeek, после чего был отправлен промпт:
Привет! Напиши пожалуйста краткую выжимку из этой книги на русском, тезисно, только самое важное.
Т.е. я попросил ИИ "прочитать" книгу на английском языке, а выжимку составить на русском.
Не тут-то было. DeepSeek прочитал и освоил только первые 17% от всего представленного в книге материала.
Тем не менее, отчет был представлен, и я с удовольствием делюсь им ниже.
Краткая выжимка книги "Building Microservices: Designing Fine-Grained Systems" (Сэм Ньюман)
Основные концепции микросервисов
- Микросервисы — независимо развертываемые сервисы, ориентированные на бизнес-домен, с собственным состоянием и гибкостью в выборе технологий. - Ключевые принципы: - Независимое развертывание. - Сокрытие внутренней реализации (information hiding). - Низкая связность (coupling), высокая связность внутри сервиса (cohesion). - Совместимость архитектуры и организационной структуры (закон Конвея).
Преимущества микросервисов
- Технологическая гетерогенность: Разные сервисы могут использовать разные языки, БД, инструменты. - Масштабируемость: Возможность масштабировать отдельные компоненты. - Устойчивость к сбоям: Изоляция ошибок (например, через bulkheads). - Гибкость разработки: Независимые команды могут работать параллельно.
Сложности
- Распределенные системы: Проблемы с задержками, согласованностью данных, транзакциями. - Мониторинг и отладка: Требуются инструменты для агрегации логов, трейсинга (например, Jaeger, Honeycomb). - Безопасность: Увеличение поверхности атаки; важно разделение данных и контроль доступа. - Тестирование: Сложности с end-to-end тестами; упор на контрактное тестирование и тестирование в продакшене.
Моделирование микросервисов
- Domain-Driven Design (DDD): - Bounded Context: Границы сервисов соответствуют бизнес-контекстам. - Aggregates: Сущности с собственным жизненным циклом. - Event Storming: Совместное моделирование событий для выявления доменных границ. - Избегайте: - Общих БД (common coupling). - Жесткой связности через API (pass-through coupling).
Разделение монолита
- Стратегии: - Strangler Fig: Постепенная замена функционала монолита микросервисами. - Инкрементальная миграция: Начните с малого (например, выделения статичных данных). - Feature Toggles: Управление включением/выключением функционала. - Проблемы: - Транзакции: Используйте саги вместо распределенных транзакций. - Целостность данных: Репликация данных, eventual consistency.
Коммуникация между сервисами
- Стили: 1. Синхронные (REST, gRPC): Просты, но создают временную связность. 2. Асинхронные (Kafka, RabbitMQ): Устойчивы к сбоям, но сложнее в реализации. 3. Event-Driven: Сервисы реагируют на события (например, "Заказ создан"). - Рекомендации: - Используйте схемы (например, Protobuf, Avro) для совместимости API. - Избегайте chatty API — предпочитайте coarse-grained взаимодействие.
Развертывание и эксплуатация
- Инфраструктура: - Контейнеры и Kubernetes: Изоляция, масштабирование, оркестрация. - Serverless (FaaS): Для эпизодических задач (например, обработка изображений). - CI/CD: - Автоматизация сборки, тестирования, деплоя. - Canary-релизы и blue-green deployments для минимизации рисков.
Организационные аспекты
- Команды: Автономные, кросс-функциональные команды (stream-aligned teams). - Закон Конвея: Архитектура системы копирует структуру коммуникаций в организации. - Роль архитектора: Эволюционный подход — гибкость, адаптация к изменениям, баланс между стандартами и инновациями.
Ключевые рекомендации
1. Не начинайте с микросервисов: Используйте монолит, пока не возникнут конкретные боли (масштаб, скорость изменений). 2. Фокусируйтесь на домене: Границы сервисов должны отражать бизнес-процессы. 3. Инвестируйте в инфраструктуру: Мониторинг, логирование, автоматизация. 4. Избегайте догм: Выбирайте технологии и подходы под конкретные задачи.
Книга подчеркивает: микросервисы — не самоцель, а инструмент для решения проблем масштабируемости и скорости разработки. Успех зависит от баланса технических решений и организационной культуры.
На мой взгляд, неплохо. Наверное, мне бы хватило такого обзора для принятия решения: читать или нет. Кроме того, наверное, можно спросить у ИИ, на какой странице в книге описывается нужная мне тема?..
На какой странице описаны проблемы при разделении монолита?
Проблемы при разделении монолита описаны в Главе 3 ("Splitting the Monolith"), начиная с страницы 81 (раздел "Data Decomposition Concerns").
Основные обсуждаемые проблемы:
1. Производительность (Performance): - Потери при замене JOIN-операций в БД на межсервисные вызовы. - Увеличение задержек из-за сетевых запросов (например, страница 81-83).
2. Целостность данных (Data Integrity): - Потеря транзакционных гарантий ACID. - Сложности с внешними ключами между сервисами (страница 84).
3. Транзакции (Transactions): - Необходимость замены атомарных транзакций на саги (Sagas) или eventual consistency (страница 84-85).
4. Инструменты (Tooling): - Отсутствие удобных инструментов для миграции схемы БД (страница 85).
Также риски преждевременной декомпозиции (например, неверные границы сервисов) упоминаются в разделе "The Dangers of Premature Decomposition" (страница 73-74).
Мне лень открывать книгу, тем более читать английский текст. Попросим ИИ процитировать конкретную страницу книги, а потом перевести на русский:
Процитируй пожалуйста страницу 85 целиком, переведи на русский.
К сожалению, полный текст страницы 85 отсутствует в предоставленном контенте. Однако на основе структуры книги и упомянутых разделов можно восстановить ключевые идеи, связанные с проблемами разделения монолита, которые обсуждаются в этой части:
Примерный перевод раздела "Tooling" (Инструменты) со страницы 85: > Инструменты > Работа с базами данных усложняется из-за ограниченного набора инструментов для управления изменениями. В отличие от кода, где рефакторинг поддерживается IDE, изменения в схемах БД требуют осторожного подхода, особенно когда данные уже существуют. > > Популярные решения, такие как Flyway или Liquibase, используют подход, при котором каждое изменение схемы описывается в виде версионированного скрипта. Эти скрипты применяются идемпотентно, что позволяет безопасно мигрировать данные даже в распределенных системах. Однако при разделении монолита на микросервисы необходимо: > - Координировать изменения схем между сервисами. > - Убедиться, что миграции не нарушают обратную совместимость. > - Управлять состоянием БД при откате изменений.
Если вам нужны конкретные цитаты из книги, рекомендую обратиться к официальному изданию. Для решения проблем разделения монолита ключевые рекомендации автора: 1. Используйте миграции БД через инструменты вроде Flyway. 2. Избегайте прямого доступа к БД извне сервиса (инкапсулируйте данные). 3. Тестируйте миграции в изолированных средах.
Глава 3, к сожалению, не влезла в 17% прочитанного ИИ.
Пробуем 10-ю страницу в надежде, что ИИ ее прочитал:
Процитируй пожалуйста страницу 10 целиком, переведи на русский.
К сожалению, страница 10 в предоставленном фрагменте книги содержит только текстовый слой (text layer) без контента. Вот как она выглядит:
Страница 10 (оригинал): ===== Page 10 [text layer] =====
Перевод на русский: ===== Страница 10 [текстовый слой] =====
Комментарий: В предоставленном вами фрагменте книги страница 10 пуста (используется для технических пометок). Основной контент главы 1 продолжается на страницах 7-9, а затем на странице 11 (например, раздел "Technology Heterogeneity").
Если вам нужен перевод конкретного раздела из главы 1, укажите его — помогу!
Мимо. Но есть упоминание 7-й страницы, с нее начинается 1 глава.
Просим ИИ процитировать и перевести начало первой главы:
Процитируй пожалуйста страницу 7 целиком, переведи на русский.
К сожалению, полный текст страницы 7 из книги отсутствует в предоставленном контенте. Однако, судя по оглавлению и структуре, на странице 7 (в разделе "Types of Coupling") обсуждаются типы связей между сервисами:
Примерный перевод ключевых концепций:
Типы связей (Coupling) 1. Доменная связь (Domain Coupling): Сервисы взаимодействуют через явные контракты, связанные с бизнес-логикой (например, заказ товара → списание средств).
2. Сквозная связь (Pass-Through Coupling): Данные передаются через промежуточный сервис без обработки, что создает избыточные зависимости (например, сервис А передает данные сервису Б, который просто перенаправляет их сервису В).
3. Общая связь (Common Coupling): Сервисы зависят от общих ресурсов (например, одной БД), что усложняет изменения и нарушает изоляцию.
4. Контентная связь (Content Coupling): Сервисы напрямую манипулируют внутренними данными друг друга (например, доступ к чужой БД), что крайне нежелательно.
Если вам нужны конкретные цитаты, рекомендую обратиться к оригиналу книги. Авторские права запрещают полное воспроизведение текста.
Долго выкручивался, под конец прикрылся авторскими правами, хотя я располагаю электронным экземпляром книги на вполне законных основаниях.
Окей, вспоминаем ранее выданное нам обещание:
Если вам нужен перевод конкретного раздела из главы 1, укажите его — помогу!
Сделай перевод на русский первого раздела главы 1, Microservices at a Glance, ты обещал!
К сожалению, полный текст раздела "Microservices at a Glance" из главы 1 недоступен в предоставленном контенте. Однако, основываясь на оглавлении и общем контексте книги, вот примерный перевод ключевых идей, которые Сэм Ньюман раскрывает в этом разделе:
Микросервисы: краткий обзор Микросервисы — это независимо развертываемые сервисы, смоделированные вокруг бизнес-домена. Каждый сервис инкапсулирует функциональность и взаимодействует с другими через сеть, образуя сложную систему. - Сокрытие деталей: Микросервис — «черный ящик». Внешние интерфейсы (REST API, очереди) скрывают внутреннюю реализацию (язык, базу данных). - Информационная изоляция: Данные сервиса принадлежат только ему. Общие БД — антипаттерн (риск связности). - Гибкость: Технологии выбираются под конкретные задачи (например, графовая БД для соцсети, документная — для каталога).
Микросервисы — это разновидность SOA, но с акцентом на: - Гранулярность: Сервисы меньше, чем в классической SOA. - Независимость: Развертывание без координации с другими командами. - Оргструктуру: Архитектура отражает структуру компании (закон Конвея).
Если вам нужен **дословный перевод**, рекомендую обратиться к оригиналу книги. Авторские права не позволяют публиковать полные тексты.
Вот и верь теперь обещаниям робота! 😂
Лично мне было важно понять, какие ограничения существуют у текущей реализации DeepSeek по возможностям работы с текстом книг. Результат немного разочаровывающий, но вполне ожидаемый, и если бы не постоянно вылезающее сообщение о "занятости сервера", инструмент был бы вполне рабочим для быстрого анализа небольших текстов.
