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

Является ли микросервис самодостаточным?

Под автономным я подразумеваю, что он должен быть максимально независимым от любых других сервисов. Это означает, что у него должна быть выделенная база данных, ответственная команда и конвейер ci / cd. Давайте рассмотрим каждый из этих пунктов.

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

Если микросервисы совместно используют базу данных, это означает, что изменения могут повлиять на другие службы. А для любых изменений вам необходимо знать, какие службы используют базу данных, общаться с ответственными командами и разработать план развертывания всех изменений в производственной среде. Так что я думаю, что это слишком много работы. И поэтому микросервисы должны взаимодействовать через API, очереди или потоки. У вас должны быть только выделенные модели, которые являются общими, и за то, как данные сохраняются в микросервисах, должен отвечать микросервис.

  • Почему за микросервис должна отвечать одна специальная команда?

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

  • Почему не следует забывать о конвейере CI / CD?

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

Обеспечивается ли наблюдаемость?

Наблюдаемость основана на трех принципах: метрики, ведение журнала и распределенная трассировка. Эти вещи очень важны для проверки работоспособности службы и выявления потенциальных проблем. Давайте подробнее расскажем о каждом из них.

Вы должны указать показатели для всех вызовов API, всех последующих вызовов и важных внутренних процессов. Убедитесь, что у метрик есть все подходящие типы: датчики, счетчики и таймеры. И не забудьте добавить агрегированную информацию, например теги, например ответ на основе кода или различных типов запросов. Из них вы можете создавать информационные панели, где вы можете видеть состояние системы в одном месте.

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

Ведение журнала должно помочь вам найти информацию обо всех процессах в системе в одном месте, особенно ELK - очень популярный способ сделать это. Кроме того, рекомендуется использовать один конкретный идентификатор во всей системе.

Трассировка помогает найти маршрут запроса во всей системе: сколько времени требуется для конкретной службы и какие методы вызываются.

Было ли это охвачено исчерпывающей документацией?

Хорошая документация поможет вам избежать недопонимания между командами относительно способа использования реализованного API. Если нет четкого объяснения, что другие команды должны тратить драгоценное время на понимание того, как работает API. И даже внутри команды может быть проблемой найти ответ, если вы должны проверить код или спросить товарищей по команде, как он работает.

Должен быть задокументирован не только API, но и все внутренние процессы и внешняя связь. И все изменения в сервисах должны быть задокументированы [как минимум!] В изменениях релиза. Каждое изменение должно иметь причины и ссылки на систему отслеживания ошибок, где предоставляется дополнительная информация.

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

Подведем итог в один контрольный список:

  • Не делитесь базой данных
  • Выделенная команда
  • CI / CD настроен
  • Наблюдаемость
  • Полная документация

В заключение, я надеюсь, что эти вещи были очень полезны. Не забудьте составить контрольный список для всех микросервисов и проверять один за другим, не упустили ли вы ничего из виду. Пусть ваши услуги будут независимыми, наблюдаемыми и хорошо задокументированными.