Микросервисная архитектура достоинства и недостатки // Бесплатный урок OTUS

• Вебинар посвящен плюсам и минусам микросервисной архитектуры и ее сравнению с монолитами.  

• Спикер, Стас Учительников, рассказывает о своем опыте работы с микросервисами в компании Дом Клик.  

• Монолиты становятся сложными и тяжелыми для работы при достижении больших размеров.  

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

• Микросервис - это команда, которую можно накормить двумя пиццами, с одной предметной областью и одной функцией.  

• Микросервисная архитектура - это архитектура с множеством сервисов, выполняющих небольшие функции.  

• Переход от монолитов к микросервисам может быть сложным и требует декомпозиции приложения на сервисы.  

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

• Время доступа к вызовам функций и пересылка пакетов по сети сравниваются, чтобы показать масштаб катастрофы.  

• Доступность сервиса снижается из-за создания новых сервисов и связей между ними.  

• Доступность приложения становится хуже, так как доступность основного приложения и доступность оформления заказов снижается.  

• В микросервисах нужно обеспечивать отказа устойчивость, так как вероятность отказа возрастает.  

• В монолите отказоустойчивость не требуется, так как вероятность отказа минимальна.  

• Для обеспечения отказоустойчивости в микросервисах нужно проводить специальные упражнения и организовывать инфраструктуру.  

• Надежность и избыточность связаны, но избыточность не всегда является синонимом надежности.  

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

• Микросервисы требуют размещения на нескольких машинах, организации пайплайна и инфраструктуры.  

• Дебаг становится сложнее, так как нужно отслеживать логи нескольких сервисов и поднимать стенды для тестирования.  

• Разработка также усложняется, так как нужно учитывать возможные отказы и ненадежную сеть.  

• Используются различные инструменты и фреймворки, включая Kafka и gRPC.  

• Для взаимодействия между микросервисами часто используется событийная модель на Kafka.  

• Транзакционность может быть достигнута с помощью транзакционных баз данных или с использованием реактивного подхода.  

• Консистентность может быть достигнута с помощью различных инструментов, таких как Kafka и транзакции в базах данных.  

• В видео обсуждается, что в новой версии микросервисов вносятся только новые методы, а не все сразу.  

• Упоминается, что в документации написано, что микросервисы гарантируют очередность в очереди, но на самом деле это не так.  

• Микросервисы имеют плюсы, такие как возможность независимого развития и использования разных технологий, но также имеют минусы, такие как сложность внедрения и накладные расходы.  

• Микросервисы начинают себя хорошо показывать только при достаточно большом размере проекта.  

• Микросервисы не подходят для всех проектов, особенно для тех, где предметная область не ясна или сильно меняется.  

• Решение о внедрении микросервисов должно быть взвешенным и не является самоцелью.  

• В видео обсуждается, что микросервисы требуют автоматизации для решения проблем, связанных с откатом на предыдущую версию, изоляцией и утилизацией ресурсов.  

• Упоминается, что микросервисы появились в 2010-2015 годах, и с тех пор появилось много инструментов и технологий для их автоматизации.  

• Начинать с монолита, если предметная область хорошо формализована и понятен контекст.  

• Если команда умеет разрабатывать микросервисы и знает все паттерны, то начинать с них может быть более правильным решением.  

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

• Авторизация и взаимодействие между сервисами решаются на уровне инфраструктуры и сервис-мешей.  

• В видео обсуждаются основные паттерны микросервисной архитектуры, такие как токизация, сервис-дисквери, мониторинг, оркестрация и серверы.  

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

• Обсуждение паттернов, связанных с запуском процессов на одной машине с разным окружением, балансировкой сервисов, обнаружением сервисов и разграничением ресурсов.  

• Упоминаются инструменты, такие как Docker, Kubernetes и Service Mesh, которые помогают в решении этих задач.  

• Обсуждение паттернов, связанных с внешним доступом к микросервисам, аутентификацией и авторизацией клиентов, а также требованиями к прокси-серверам.  

• Упоминаются инструменты, такие как Ingress, Traefik и Ambassador, которые используются для решения этих задач.  

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

• Упоминаются инструменты, такие как Prometheus, Grafana, Jaeger и другие, которые используются для сбора и визуализации данных.  

• Рекомендация книг по теме: "Обзор лабилити" от Elastic, "Обзор телеметрии" от Google, "Обзор девопс" от Google.  

• Обсуждение тестирования микросервисов, где интеграционные тесты могут быть сложными и болезненными.  

• Упоминается новый подход к тестированию - контрактное программирование, которое не относится к классическим тестам, но помогает проверить контракты между сервисами.  

• Примеры инструментов для контрактного программирования: пакт, постман, хром и селениум.  

• Проблема неправильной декомпозиции сервисов может привести к зависимым изменениям между сервисами и болезненным согласованием изменений.  

• Для декомпозиции сервисов рекомендуется использовать паттерн DDD и стратегический паттерн "ограниченный контекст".  

• Для анализа предметной области и выделения сущностей, характерных для DDD, используется практика шторминга.  

• Для декомпозиции сервисов также используется API-методология, где сначала придумываются сервисы и их зоны ответственности, а затем реализуется.  

• Для тестирования контрактов используется пакт.  

• Для распределения границ сервисов рекомендуется прочитать статью на английском языке "Service Sandbox" и книгу "Storming" (возможно, зарелизилась).  

• В микросервисной архитектуре данные могут дублироваться для обеспечения автономной работы нескольких сервисов.  

• Для обеспечения транзакционности используются паттерны, такие как жесткости и сага.  

• Для хранения данных используются базы данных, такие как Postgres, MySQL, и NoSQL.  

• В микросервисах рекомендуется хранить данные в одной базе данных на один сервис.  

• Для хранения потока событий используется паттерн секьюрес, который позволяет хранить текущее состояние или поток событий.  

• Для микросервисов характерно интенсивное использование синхронных протоколов взаимодействия, таких как Kafka и Thrift.  

• Взаимодействие между сервисами может быть вынесено на инфраструктурный уровень с использованием паттернов сервис мэш и микросервис чейсис.  

• Видео обсуждает сервис мээш, его назначение и использование.  

• Упоминается статья о сервисе мээш, которая считается одной из лучших для введения в тему.  

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

• Упоминается опыт использования рифта, который не подошел.  

• Упоминаются книги, которые считаются лучшими для изучения микросервисов, включая "Микросервисы: паттерны, принципы и практика" Криса Ричардсона, "Микросервисы: построение устойчивых систем" Сэма Ньюмана и "Воздушная архитектура" Милфорда.  

• Обсуждается выбор протокола для микросервисов, в зависимости от нагрузки и предметной области.  

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

• Упоминается книга "Клин архитектор" Боба Мартина, которая не посвящена микросервисам, а скорее сложной бизнес-логике.  

• Однако, концепции из этой книги могут быть полезны для микросервисов, но их нужно применять аккуратно.  

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

• Микросервисы могут потреблять до 4 ГБ оперативной памяти на запрос, что зависит от контекста и сложности проекта.  

• Сервер леса - это способ поставки кода в виде функций, который может быть полезен для простых функций, но требует дополнительных затрат на безопасность и производительность.  

• Для стартапов рекомендуется использовать облачные провайдеры, такие как Google Cloud, Amazon Web Services, Yandex Cloud и другие, для развертывания и настройки инфраструктуры.  

• Для игры с облачными провайдерами и тестирования под нагрузкой можно использовать мини-кубики, такие как Google Cloud, Kubernetes и другие.  

• Дом клике начал развиваться как небольшой стартап внутри Сбербанка, используя PHP и Java.  

• Перешли на Java, затем на Python и Kotlin, постепенно адаптируя инфраструктуру под новые языки.  

• Переехали на Kubernetes, используя опыт других компаний, таких как Губернетис и Шериф.  

• Используют Prometheus, Grafana, InfluxDB, ElasticSearch, Kafka, Elastik, и другие инструменты для мониторинга и управления.  

• Используют Postgres, MySQL, и другие базы данных для хранения данных.  

• Используют разные языки программирования, включая Java, Python, Kotlin, и Ruby.  

• Мобильная разработка на Swift и Kotlin.