ключевых вывода
1. Микросервисы: Маленькие, автономные сервисы, работающие вместе
Микросервисы — это маленькие, автономные сервисы, работающие вместе.
Основы микросервисов. Архитектура микросервисов строится на принципе разработки программного обеспечения как набора маленьких, независимых сервисов. Каждый сервис сосредоточен на выполнении одной задачи, работает в своем собственном процессе и взаимодействует через легковесные механизмы, такие как HTTP/REST API. Этот подход обеспечивает большую гибкость, масштабируемость и поддерживаемость по сравнению с монолитными архитектурами.
Преимущества и вызовы. Ключевые преимущества микросервисов включают:
- Улучшенная модульность
- Легкость масштабирования отдельных компонентов
- Разнообразие технологий
- Повышенная изоляция отказов
- Быстрые циклы развертывания
Однако микросервисы также вносят вызовы, такие как:
- Увеличенная операционная сложность
- Проблемы распределенных систем (например, задержка сети, отказоустойчивость)
- Согласованность данных между сервисами
2. Эволюционная архитектура: Адаптация к изменяющимся требованиям
Роль архитектора — смотреть на общую картину и понимать этот баланс.
Принятие изменений. Эволюционная архитектура подчеркивает необходимость адаптации систем к изменяющимся требованиям со временем. Этот подход признает, что невозможно предсказать все будущие потребности, поэтому сосредотачивается на создании гибкой основы, которая может эволюционировать.
Ключевые принципы:
- Инкрементальные изменения: Делайте маленькие, частые обновления, а не большие, редкие
- Управляемые изменения: Используйте принципы и практики для руководства архитектурными решениями
- Множественные архитектуры: Признавайте, что разные части системы могут эволюционировать с разной скоростью
Архитекторы в этой модели действуют скорее как градостроители, устанавливая руководящие принципы и ограничения, а не диктуя каждую деталь. Это позволяет командам принимать локальные решения, обеспечивая при этом общую согласованность системы.
3. Моделирование сервисов: Определение границ и контекстов
Мы фокусируем границы наших сервисов на бизнес-границах, делая очевидным, где находится код для данной функциональности.
Проектирование, ориентированное на домен. Эффективное моделирование сервисов требует глубокого понимания бизнес-домена. Проектирование, ориентированное на домен (DDD), предоставляет ценные концепции для определения границ сервисов:
- Ограниченные контексты: Области домена с четкими границами
- Универсальный язык: Общий язык, разделяемый разработчиками и экспертами домена
- Агрегаты: Кластеры доменных объектов, рассматриваемые как единое целое
Определение границ сервисов:
- Соответствие бизнес-возможностям
- Инкапсуляция данных и поведения
- Минимизация зависимостей между сервисами
- Учет структуры команды и паттернов коммуникации
Хорошо определенные границы приводят к более сплоченным сервисам и более слабой связанности между ними, что облегчает независимую разработку и развертывание.
4. Стратегии интеграции: Выбор правильного подхода к коммуникации
Будьте консервативны в том, что вы делаете, и либеральны в том, что принимаете от других.
Важность интеграции. Эффективная интеграция имеет решающее значение для бесперебойной работы микросервисов. Выбор технологии интеграции значительно влияет на гибкость системы, производительность и поддерживаемость.
Ключевые паттерны интеграции:
- Синхронная коммуникация: REST, gRPC
- Асинхронная коммуникация: Очереди сообщений, потоковая передача событий
- API-шлюзы: Для маршрутизации и компоновки запросов
- Сервисная сетка: Для обработки коммуникации между сервисами
Лучшие практики:
- Используйте протоколы, не зависящие от технологии (например, HTTP)
- Реализуйте толерантных читателей для плавного управления изменениями
- Проектируйте с учетом отказов, используя прерыватели цепей и перегородки
- Рассматривайте архитектуры, основанные на событиях, для слабой связанности
Правильная стратегия интеграции зависит от вашего конкретного случая использования, требований к производительности и опыта команды.
5. Разделение монолита: Переход к микросервисам
Думайте о нашем монолите как о блоке мрамора. Мы могли бы взорвать его целиком, но это редко заканчивается хорошо. Гораздо разумнее постепенно откалывать от него куски.
Инкрементальный подход. Переход от монолитной архитектуры к микросервисам лучше всего осуществлять постепенно. Это позволяет командам учиться и адаптироваться, минимизируя риски.
Шаги для разделения монолита:
- Определите швы в существующем коде
- Извлеките ограниченные контексты в отдельные модули
- Рефакторинг общих структур данных и баз данных
- Создайте API для межмодульной коммуникации
- Извлеките модули в отдельные сервисы
- Реализуйте новые функции как микросервисы
Вызовы, которые нужно учитывать:
- Зависимости данных между сервисами
- Транзакционная целостность через границы сервисов
- Влияние сетевой коммуникации на производительность
- Операционная сложность управления множеством сервисов
Начните с самых простых и наименее рискованных извлечений, чтобы набраться уверенности и опыта, прежде чем приступать к более сложным частям системы.
6. Техники развертывания: Обеспечение надежности и масштабируемости
Если что-то делать правильно, но сложно, мы должны стремиться упростить это.
Автоматизированное развертывание. Надежное и масштабируемое развертывание критически важно для успеха микросервисов. Практики непрерывной интеграции и непрерывной доставки (CI/CD) необходимы для управления увеличенной сложностью развертывания.
Ключевые техники развертывания:
- Инфраструктура как код (IaC)
- Контейнеризация (например, Docker)
- Платформы оркестрации (например, Kubernetes)
- Развертывания синим-зеленым
- Канареечные релизы
Соображения при развертывании:
- Обнаружение сервисов и управление конфигурацией
- Мониторинг и логирование
- Безопасность и контроль доступа
- Миграции баз данных и согласованность данных
Инвестируйте в инструменты и автоматизацию, чтобы сделать развертывания проще, быстрее и надежнее. Это позволяет командам часто развертывать с уверенностью, реализуя все преимущества архитектуры микросервисов.
7. Тестирование микросервисов: Поддержание качества в распределенной системе
Чем больше движущихся частей, тем более хрупкими могут быть наши тесты и тем менее детерминированными они становятся.
Комплексная стратегия тестирования. Тестирование микросервисов требует многоуровневого подхода для обеспечения как качества отдельных сервисов, так и общего поведения системы.
Пирамида тестирования для микросервисов:
- Модульные тесты: Быстрые, сфокусированные тесты для отдельных компонентов
- Интеграционные тесты: Проверка взаимодействий между сервисами
- Контрактные тесты: Обеспечение соответствия сервисов согласованным интерфейсам
- Сквозные тесты: Проверка поведения всей системы
Вызовы тестирования:
- Увеличенная сложность из-за распределенной природы
- Управление тестовыми данными между сервисами
- Симуляция производственных сред
- Обработка асинхронных взаимодействий
Сосредоточьтесь на быстрых циклах обратной связи с помощью модульных и интеграционных тестов, используя меньшее количество тщательно выбранных сквозных тестов для проверки критических путей. Рассмотрите использование контрактов, управляемых потребителями, для эффективного управления зависимостями сервисов.
8. Мониторинг и безопасность: Поддержание здоровья и защиты микросервисов
Хорошее логирование, и особенно возможность агрегировать логи из нескольких систем, не предотвращает проблемы, но помогает в их обнаружении и восстановлении.
Целостный подход. Эффективный мониторинг и безопасность критически важны для поддержания здоровой экосистемы микросервисов. Эти аспекты становятся более сложными и важными в распределенных системах.
Лучшие практики мониторинга:
- Централизованное логирование и агрегация логов
- Распределенное трассирование (например, с использованием идентификаторов корреляции)
- Оповещения в реальном времени и панели мониторинга
- Мониторинг производительности приложений (APM)
- Синтетический мониторинг для критических путей
Соображения безопасности:
- Аутентификация и авторизация между сервисами
- API-шлюзы для безопасности на границе
- Управление секретами
- Сегментация сети
- Регулярные аудиты безопасности и тестирование на проникновение
Реализуйте стратегию глубокой защиты, обеспечивая безопасность как периметра, так и отдельных сервисов. Используйте автоматизацию для обеспечения последовательного применения политик безопасности ко всем сервисам.
9. Закон Конвея: Согласование организации и дизайна системы
Закон Конвея подчеркивает опасности попыток навязать дизайн системы, не соответствующий организации.
Влияние на организацию. Закон Конвея гласит, что дизайн системы отражает структуры коммуникации внутри организации. Этот принцип имеет значительные последствия для архитектуры микросервисов.
Согласование команд и сервисов:
- Организуйте команды вокруг бизнес-возможностей
- Дайте командам полную ответственность за сервисы
- Минимизируйте зависимости между командами
- Развивайте культуру сотрудничества и общей ответственности
Соображения:
- Размер и состав команды
- Паттерны и инструменты коммуникации
- Процессы принятия решений
- Развитие навыков и обмен знаниями
Признавайте, что организационная структура и архитектура системы взаимосвязаны. Развивайте их вместе, чтобы создать среду, способствующую успешной разработке и эксплуатации микросервисов.
10. Масштабирование микросервисов: Управление ростом и отказами
В масштабе, даже если вы купите лучшее оборудование, самое дорогое железо, вы не сможете избежать того, что вещи могут и будут выходить из строя.
Проектирование для масштабирования и устойчивости. Архитектуры микросервисов должны быть спроектированы так, чтобы справляться как с ростом спроса, так и с неизбежными отказами.
Стратегии масштабирования:
- Горизонтальное масштабирование (добавление большего количества экземпляров)
- Вертикальное масштабирование (увеличение ресурсов на экземпляр)
- Кэширование (в памяти, распределенное)
- Шардинг и репликация баз данных
- Асинхронная обработка и архитектуры, основанные на событиях
Паттерны устойчивости:
- Прерыватели цепей для предотвращения каскадных отказов
- Перегородки для изоляции отказов
- Тайм-ауты и повторные попытки с экспоненциальной задержкой
- Плавная деградация функциональности
Соображения теоремы CAP:
- Согласованность
- Доступность
- Устойчивость к разделению
Понимайте, что при масштабировании распределенных систем необходимы компромиссы. Приоритизируйте на основе ваших конкретных требований и ограничений. Реализуйте практики наблюдаемости и хаос-инжиниринга для постоянного улучшения устойчивости системы.
Последнее обновление:
FAQ
What's Building Microservices by Sam Newman about?
- Microservices Architecture: The book explores microservices, which are small, autonomous services that collaborate to form a system. It highlights how this architecture can enhance software delivery speed and flexibility.
- Business Domain Focus: Microservices are modeled around business domains, aligning software design with business needs and avoiding issues of monolithic architectures.
- Practical Guidance: Sam Newman provides real-world examples from companies like Netflix and Amazon, offering a comprehensive guide for adopting or understanding microservices.
Why should I read Building Microservices by Sam Newman?
- Comprehensive Resource: It covers design, development, deployment, testing, and maintenance of microservices, making it ideal for those transitioning from monolithic systems.
- Real-World Examples: The book includes insights from organizations that have successfully implemented microservices, providing practical perspectives and lessons learned.
- Continuous Learning: It encourages embracing continuous learning to keep up with the fast-evolving nature of microservices technology and practices.
What are the key takeaways of Building Microservices by Sam Newman?
- Microservices Benefits: The book outlines benefits like improved scalability, resilience, and quick adoption of new technologies due to service autonomy.
- Loose Coupling and High Cohesion: Emphasizes designing services to be loosely coupled and highly cohesive, facilitating easier maintenance and updates.
- Integration Strategies: Discusses synchronous and asynchronous communication strategies, crucial for maintaining service autonomy and effective collaboration.
What is the definition of microservices according to Building Microservices by Sam Newman?
- Small, Autonomous Services: Defined as "small, autonomous services that work together," highlighting their independence and functionality without reliance on others.
- Business Functionality Focus: Each microservice handles a specific business capability, aligning with organizational goals and prioritizing work effectively.
- Decoupled Communication: Services communicate through well-defined APIs, maintaining loose coupling and enabling independent development and deployment.
How does Building Microservices by Sam Newman suggest modeling services?
- Bounded Contexts: Introduces bounded contexts from Domain-Driven Design to define service boundaries, with each context representing a specific responsibility.
- Loose Coupling and High Cohesion: Stresses that related functionality should reside within the same service, while unrelated functionality should be separated.
- Iterative Approach: Recommends refining service boundaries over time to accommodate changes in business requirements and technology.
What are the integration strategies discussed in Building Microservices by Sam Newman?
- Synchronous vs. Asynchronous: Contrasts synchronous communication, where a service waits for a response, with asynchronous communication, where services operate independently.
- Event-Driven Architecture: Advocates for event-driven architectures, where services emit events to signal state changes, promoting loose coupling.
- REST and RPC: Discusses RESTful APIs and Remote Procedure Calls for service communication, emphasizing technology-agnostic APIs for flexibility.
What are the challenges of deploying microservices as outlined in Building Microservices by Sam Newman?
- Increased Complexity: Warns of the complexity due to interdependencies between services, which can lead to deployment challenges without proper management.
- Continuous Integration and Delivery: Emphasizes robust CI/CD practices to manage microservices effectively, ensuring quick and reliable deployments.
- Monitoring and Management: Suggests comprehensive monitoring solutions to track the health and performance of each service independently.
How does Building Microservices by Sam Newman address testing in microservices?
- Types of Tests: Categorizes tests into technology-facing and business-facing, including unit, integration, and end-to-end tests for service reliability.
- Consumer-Driven Contracts: Introduces consumer-driven contracts to validate service interactions, ensuring changes in one service don't break dependent services.
- Automated Testing: Advocates for automated testing to maintain quality and speed in deployment, allowing confident release of changes.
What is the significance of Conway’s Law in Building Microservices by Sam Newman?
- Organizational Structure and Architecture: Discusses Conway’s Law, which states that system designs reflect the communication structures of organizations.
- Team Autonomy: Emphasizes organizing microservices around autonomous teams that own specific services, fostering accountability and ownership.
- Impact on Design: Highlights the importance of aligning team structures with service boundaries for effective collaboration and faster feature delivery.
What are the best quotes from Building Microservices by Sam Newman and what do they mean?
- Freedom to React: "Microservices give us significantly more freedom to react and make different decisions," highlighting agility compared to monolithic architectures.
- Service Autonomy: "The golden rule: can you make a change to a service and deploy it by itself without changing anything else?" emphasizes designing independent services.
- Postel's Law: "Be conservative in what you do, be liberal in what you accept from others," underscores flexibility in service interactions while maintaining strict internal standards.
What are some architectural safety measures discussed in Building Microservices by Sam Newman?
- Circuit Breakers: Prevent cascading failures by stopping further calls to a failing service, allowing it to recover without being overwhelmed.
- Bulkheads: Isolate different parts of a system to prevent a failure in one area from affecting others, enhancing resilience and stability.
- Timeouts: Setting appropriate timeouts for service calls to avoid hanging requests, ensuring services can fail fast and recover effectively.
How does Building Microservices by Sam Newman suggest handling service discovery?
- Dynamic Service Registries: Discusses using tools like Consul and Eureka for managing service discovery, allowing easy registration and discovery of services.
- DNS as a Solution: Mentions DNS for service discovery, though it may not suit highly dynamic environments, suggesting load balancers to mitigate limitations.
- Human-Friendly Interfaces: Emphasizes creating user-friendly interfaces for service discovery, aiding developers in finding and understanding available services.
Отзывы
Создание микросервисов получает смешанные отзывы, многие хвалят его за всесторонний обзор концепций микросервисов и практические советы. Читатели ценят осторожный подход автора и примеры из реальной жизни. Критики отмечают недостаточную глубину книги по некоторым темам и её склонность переоценивать микросервисы. Многие считают её ценной для начинающих, но менее полезной для опытных архитекторов. Книга охватывает различные аспекты микросервисов, включая проектирование, развертывание, тестирование и масштабирование. Некоторые читатели хотели бы видеть больше конкретных деталей реализации, в то время как другие ценили её высокоуровневую перспективу на архитектуру программного обеспечения.
Similar Books
