Будьте в курсе и будьте готовы к тому, что произойдет препятствие
Микросервисы - один из наиболее распространенных архитектурных шаблонов для создания масштабируемых распределенных приложений. Этот шаблон описывает доставку системы через небольшие, независимо выпускаемые службы. Сервис предоставляет функциональные возможности по сети (обычно через API).
Приведенный ниже тренд Google ясно показывает рост интереса к этой теме за последние 5-6 лет:
Я видел, как многие команды переходили на миграцию микросервисов, не понимая по-настоящему компромиссов.
В этой статье я расскажу о некоторых распространенных ошибках, о которых вам следует знать, прежде чем переходить к микросервисам.
Преимущества создания микросервисов
Многие из вас, вероятно, читали несколько статей, книг, рассказывающих о преимуществах микросервисов, и лично испытали многие из них. Вот краткое описание того, зачем создавать микросервисы:
- Микросервисы легко развернуть.
- Вы можете использовать наиболее подходящий стек технологий для каждой услуги. Это не заставляет вас придерживаться определенной технологии, даже если она вам не подходит.
- Несколько разработчиков / команд могут работать независимо, способствуя более быстрой параллельной разработке.
- Они способствуют слабой связи между службами, поскольку службы обычно взаимодействуют друг с другом по сети / HTTP.
А теперь давайте посмотрим на предполетный контрольный список перед посадкой на рейс микросервисов.
Неудачи неизбежны
Когда вы создаете систему, состоящую из микросервисов, имейте в виду, что сети будут медленными / неисправными. Различные службы могут быть включены / выключены в разное время. Следовательно, вам нужно создавать сервисы с учетом сбоев.
К счастью, существуют шаблоны, такие как автоматический выключатель, которые могут помочь преодолеть эти сбои и позволить системе работать в ухудшенном режиме.
Убедитесь, что вы знаете о библиотеках, которые могут помочь в решении таких проблем.
Примечание. В разделе "Ссылки" я оставил ссылку на статью, в которой подробно описывается схема автоматического выключателя и библиотеки для использования в этом сценарии.
Вам нужно больше, чем просто мониторинг
Как обсуждалось ранее, распределенные системы следует проектировать с учетом отказов. Работу с монолитом легче отлаживать и устранять неполадки, поскольку вы можете просматривать журналы практически на одной машине. В случае микросервисов это может быть не так.
Вам понадобится надежная система агрегирования журналов, которая может собирать журналы с разных машин и помещать их в единую систему. Прежде чем приступить к разработке микросервиса, убедитесь, что система настроена и работает.
Существует множество инструментов и платформ, которые предоставляют возможность агрегирования журналов, а именно. ElasticSearch-Logstash-Kibana (ELK), Splunk и др.
Когда разные модули взаимодействуют друг с другом при сбоях в монолитных приложениях, им просто нужно вызвать методы в одном экземпляре. В микросервисах эти вызовы происходят по сети. Отладка сбоев в этих сетевых вызовах очень болезненна, если у вас нет нужных инструментов. В наши дни люди предпочитают использовать технику под названием Распределенная трассировка для решения этих проблем.
В распределенной трассировке каждому внешнему запросу назначается уникальный идентификатор. Затем этот уникальный идентификатор передается каждой микрослужбе, участвующей в этом запросе. Этот уникальный идентификатор затем также используется во время регистрации. Он также фиксирует такую информацию, как время начала и время окончания, чтобы лучше понять диапазон запросов между различными микросервисами.
Существуют инструменты / платформы с открытым исходным кодом, такие как Jaeger, которые могут помочь решить эти проблемы. Убедитесь, что вы думали об использовании этих инструментов раньше.
Большинство облачных провайдеров поддерживают встроенные решения для мониторинга, такие как Google StackDriver, Azure Insights, AWS CloudWatch и т. Д.
Накладные расходы на операции
В мире микросервисов вам придется создавать, развертывать, запускать и отслеживать множество сервисов по сравнению с монолитными приложениями. Многим из этих сервисов потребуется аварийное переключение и отказоустойчивость, и, следовательно, потребуется развернуть несколько их экземпляров, добавить балансировщики нагрузки и очереди сообщений, и ваша экосистема начнет выглядеть огромной.
Чтобы развернуть эту огромную экосистему, вам потребуются надежные конвейеры развертывания и выпуска. Вам потребуются высококачественный мониторинг и инфраструктура, способные поддержать эту быструю разработку и развертывание.
Есть множество решений, которые помогут решить эти проблемы.
Такие платформы, как GitLab, Azure DevOps и GitHub, поддерживают необходимые конвейеры выпуска и сборки.
Ваша команда должна обладать значительными навыками DevSecOps, чтобы выпуск и развертывание были надежными, поэтому, пожалуйста, планируйте с умом.
Убедитесь, что вы подумали об этих инструментах / платформах, прежде чем погрузиться в микросервисы.
Опыт разработчиков
В наши дни большинство компаний пытаются измерить и улучшить опыт разработчиков в своих организациях. При наличии правильных инструментов высокая продуктивность разработчика может обеспечить быструю разработку.
Многие команды предпочитают использовать контейнеры для развертывания сервисов. Когда разработчику нужно опробовать эти вещи, ему, возможно, придется запустить несколько контейнеров на своей рабочей машине.
Следовательно, вам необходимо убедиться, что вы четко определили, как будут разрабатываться сервисы, как и где их следует тестировать и как запускать интеграционные тесты.
Вам нужно будет убедиться, что ваша команда хорошо оснащена этими инструментами и комфортно ими пользоваться.
Платформа оценки микросервисной архитектуры
Во время работы над этой статьей я наткнулся на очень классную платформу оценки, которая может помочь оценить вашу готовность. Этот инструмент задает вам вопросы о вашей нынешней зрелости по различным темам, например:
- Межсервисная связь
- Развертывание и надежность
- Наблюдаемость
- Внешняя конфигурация
- Инфра
- Документация
- И т.п.
Затем он показывает вам результаты. Я очень рекомендую вам попробовать это.
Заключение
Нет сомнений в том, что микросервисная архитектура - это благо в этом мире масштабов Интернета. У большинства препятствий есть правильные решения. Таким образом, прежде чем погрузиться в микросервисы, вы должны быть хорошо осведомлены и хорошо подготовлены!
использованная литература
- Шаблон автоматического выключателя - https://betterprogramming.pub/modern-day-architecture-design-patterns-for-software-professionals-9056ee1ed977#4c75
- ELK - https://www.elastic.co/log-monitoring
- Http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
- Https://martinfowler.com/bliki/MicroservicePrerequisites.html
