Создание микросервисов — Книга посвящена программированию микросервисов — небольших автономных компонентов, позволяющих добиться модульности и отказоустойчивости любой программы. Теория микросервисов тесно связана с философией Unix, способствует улучшению архитектуры любых приложений, дает возможность избегать громоздкого и запутанного кода. Эта книга поможет читателю заново взглянуть на многие, казалось бы, трудноразрешимые проблемы, масштабировать любые проекты, ювелирно разрабатывать даже самые сложные системы.
Название: Создание микросервисов Автор: Сэм Ньюмен Издательство: Питер Год: 2016 Страниц: 300 Формат: PDF, EPUB Размер: 10,8 Мб ISBN: 978-5-496-02011-4 Качество: Отличное Серия: Бестселлеры O’Reilly Язык: Русский
Содержание:
Предисловие Для кого написана эта книга Зачем я написал эту книгу Мир микросервисов сегодня Структура книги Соглашения, принятые в этой книге Благодарности Об авторе От издательства Глава 1. Микросервисы Что же такое микросервисы Небольшие и нацеленные на то чтобы хорошо справляться только с одной работой Автономные Основные преимущества Технологическая разнородность Устойчивость Масштабирование Простота развертывания Решение организационных вопросов Компонуемость Оптимизация с целью последующей замены А как насчет сервис-ориентированной архитектуры? Другие технологии декомпозиции Совместно используемые библиотеки Модули Никаких универсальных решений Резюме Глава 2. Архитектор развития Неверные сравнения Эволюционное видение для архитектора Зонирование Принципиальный подход Стратегические цели Принципы Инструкции Объединение принципов и инструкций Практический пример Необходимый стандарт Мониторинг Интерфейсы Архитектурная безопасность Управление посредством кода Экземпляры Подгоняемый шаблон сервиса Технические обязательства Работа с исключениями Руководство и ведущая роль центра Формирование команды Резюме Глава 3. Как моделировать сервисы Представление MusicCorp Как создать хороший сервис Слабая связанность Сильное зацепление Ограниченный контекст Общие и скрытые модели Модули и сервисы Преждевременная декомпозиция Бизнес-возможности Внизу сплошные черепахи Обмен данными с точки зрения бизнес-концепций Техническая граница Резюме Глава 4. Интеграция Поиск идеальной интеграционной технологии Уклонение от разрушающих изменений Сохранение технологической независимости применяемых API Сохранение простоты использования сервиса потребителями Скрытие внутренних деталей реализации Взаимодействие с потребителями Совместно используемая база данных Сравнение синхронного и асинхронного стилей Сравнение оркестрового и хореографического принципов Удаленные вызовы процедуры Технологическая связанность Локальные вызовы не похожи на удаленные Хрупкость Неужели RPC настолько страшен? REST REST и HTTP Гиперсреда как механизм определения состояния приложения JSON, XML или что-то другое? Опасайтесь слишком больших удобств Недостатки REST с использованием HTTP Реализация асинхронной совместной работы на основе событий Выбор технологии Сложности асинхронных архитектур Сервисы как машины состояний Реактивные расширения DRY и риски повторного использования кода в мире микросервисов Доступ по ссылке Управление версиями Откладывание изменений на максимально возможный срок Выявление критических изменений на самой ранней стадии Использование семантического управления версиями Сосуществование различных конечных точек Использование нескольких параллельных версий сервиса Пользовательские интерфейсы Движение в направлении к единым цифровым устройствам Ограничения API-композиция Составление фрагментов пользовательского интерфейса Внутренние интерфейсы, предназначенные для внешних интерфейсов Гибридный подход Интеграция с программами сторонних разработчиков Отсутствие должного контроля Адаптация Тонкости интеграции На наших собственных условиях Шаблон Strangler (Дроссель) Резюме Глава 5. Разбиение монолита на части Все дело в стыках Разбиение MusicCorp на части Мотивы для разбиения монолита на части Темпы изменений Структура команды Безопасность Технология Запутанные зависимости База данных Решение проблем Пример 1: разрыв взаимоотношений, использующих внешние ключи Пример 2: совместно используемые статичные данные Пример 3: совместное использование данных Пример 4: совместно используемые таблицы Перестройка баз данных Транзакционные границы Повторная попытка Отмена всей операции Распределенные транзакции Так что же делать? Создание отчетов База данных для создания отчетов Извлечение данных посредством служебных вызовов Программы перекачки данных Альтернативные направления Перекачка данных на основе событий Перекачка данных на основе систем резервного копирования Переход к реальности Цена внесения изменений Умение разбираться в основных причинах Резюме Глава 6. Развертывание Краткое введение в непрерывную интеграцию Отображение непрерывной интеграции на микросервисы Сборочные конвейеры и непрерывная доставка Артефакты для конкретных платформ Артефакты операционных систем Настраиваемые образы Образы как артефакты Неизменяемые серверы Среды Конфигурация сервиса Отображение сервиса на хост Несколько сервисов на каждый хост Приложения-контейнеры Размещение по одному сервису на каждом хосте Платформа в качестве услуги Автоматизация От физического к виртуальному Традиционная виртуализация Vagrant Контейнеры Linux Docker Интерфейс развертывания Резюме Глава 7. Тестирование Разновидности тестов Области применения тестов Блочные тесты Тесты сервиса Сквозные тесты Компромиссы Что и в каком объеме проводить Реализация тестов сервисов Использование имитации или применение заглушки Более интеллектуальный сервис-заглушка Сложности, связанные со сквозными тестами Недостатки сквозного тестирования Тесты со странностями, не дающие четкого представления об источнике сбоя Кто создает все эти тесты Насколько продолжительными бывают тесты Сплошное нагромождение Метаверсия Тестируйте маршруты, а не истории Тесты на основе запросов потребителей, спасающие ситуацию Pact О переговорах А нужно ли вообще пользоваться сквозными тестами? Тестирование после перевода в производственный режим работы Отделение развертывания от выпуска Канареечный выпуск Что важнее: среднее время восстановления работоспособности или среднее время безотказной работы? Межфункциональное тестирование Резюме Глава 8. Мониторинг Один сервис на одном сервере Один сервис на нескольких серверах Несколько сервисов на нескольких серверах Журналы, журналы и еще журналы Отслеживание показателей сразу нескольких сервисов Рабочие показатели сервисов Искусственный мониторинг Реализация семантического мониторинга Идентификаторы взаимосвязанности Каскадные сбои Стандартизация Расчет на аудиторию Перспективы Резюме Глава 9. Безопасность Аутентификация и авторизация Общепринятые реализации технологии единого входа Шлюз технологии единого входа Авторизация с высокой степенью детализации Взаимная аутентификация и авторизация сервисов Разрешение всего в пределах периметра Стандарт HTTP (S) Basic Authentication Использование SAML или OpenID Connect Клиентские сертификаты HMAC через HTTP API-ключи Проблема помощника Безопасность данных, находящихся в покое Пользуйтесь хорошо известными средствами Все зависит от ключей Выберите защищаемые объекты Расшифровка по требованию Шифровка резервных копий Глубоко эшелонированная оборона Брандмауэры Регистрация Система обнаружения (и предотвращения) вторжений Обособление сетей Операционная система Рабочий пример Проявляйте сдержанность Человеческий фактор Золотое правило Создание системы безопасности Внешняя проверка Резюме Глава 10. Закон Конвея и проектирование систем Доказательства Организации со слабыми и сильными связями Windows Vista Netflix и Amazon Так что же со всем этим делать? Адаптация к направлениям обмена данными Владение сервисом Побудительные мотивы для создания общих сервисов Слишком большие трудности разбиения на части Команды разработки функций Узкие места, касающиеся вопросов поставки Семейственный открытый код Роль кураторов Зрелость Инструментарий Ограниченные контексты и структуры команд Осиротевшая служба? Конкретный пример: RealEstate.com.au Закон Конвея наоборот Люди Резюме Глава 11. Масштабирование микросервисов Сбои могут происходить везде Слишком много - это сколько? Снижение уровня функциональных возможностей Архитектурные меры безопасности Антихрупкая организация Настройки времени ожидания Предохранители Переборки Изолированность Идемпотентность Масштабирование Наращивание мощностей Разделение рабочих нагрузок Распределение риска Балансировка нагрузки Системы на основе исполнителей Начинаем все заново Масштабирование баз данных Доступность сервиса против долговечности данных Масштабирование для считываний Масштабирование для производства записей Совместно используемые инфраструктуры баз данных CQRS Кэширование данных Кэширование на стороне клиента, прокси-сервере и стороне сервера Кэширование при использовании технологии HTTP Кэширование, проводимое для операций записи Кэширование в целях повышения отказоустойчивости Скрытие источника Не нужно ничего усложнять Отравление кэша: предостережение Автоматическое масштабирование Теорема CAP Принесение в жертву согласованности Принесение в жертву доступности А как насчет принесения в жертву терпимости к разделению? AP или CP? Это не все или ничего И реальный мир Обнаружение сервисов DNS Динамическая регистрация сервисов Zookeeper Consul Eureka Прокатка собственной системы Не забывайте про людей! Документирующие сервисы Swagger HAL и HAL-браузер Самостоятельно описываемая система Резюме Глава 12. Коротко обо всем Принципы микросервисов Модель, построенная вокруг бизнес-концепций Внедрение культуры автоматизации Скрытие подробности внутренней реализации Всесторонняя децентрализация Независимое развертывание Изолирование сбоев Всестороннее наблюдение А когда не следует применять микросервисы? Напутствие