В слабо связанной архитектуре микросервисов, как вы отслеживаете свои зависимости?

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

Но одна из проблем, которые я предвижу в такой архитектуре, заключается в плохой видимости зависимостей приложения. Например, допустим, у меня есть приложение, которое ежедневно использует один набор вызовов REST. Это приложение также использует второй набор вызовов REST, но только раз в квартал. Если бы я просканировал журналы за последнюю неделю, я бы увидел все ежедневные дневники, но, скорее всего, не увидел бы ежеквартальных звонков. Когда приходит время для рефакторинга, ежеквартальные звонки подвергаются высокому риску прерывания.

Какие шаблоны или инструменты можно использовать для снижения этого риска и обеспечения большей наглядности в отношении слабозависимой архитектуры?

Какие шаблоны или инструменты могут быть использованы для снижения этого риска

Поддержание совместимости ваших API и возможностей вашего бизнеса.

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

Проверка здоровья.

Мой сервис является клиентом для ваших ежемесячных возможностей API. Но мой сервис является клиентом вашего API каждый раз, когда он работает. Таким образом, моя служба активируется каждые 10 минут или что-то еще, подключается к вашему ежемесячному API и запускает протокол, чтобы убедиться, что возможности, необходимые для моей службы, все еще доступны.

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

Есть как минимум два места, где вы можете найти зависимости:

• Конфигурация. Для доступа к внешним API-интерфейсам требуется знать кучу информации о каждом из этих API-интерфейсов. Идентификаторы доступа, секретные ключи, конечные точки. Все это не может быть в коде, так как такая информация будет меняться. Например, недавно я начал мигрировать все свои микросервисы в SSL. Это означает, что каждый сервис, который зависит от того, который переносится, должен быть перенастроен, чтобы указывать на https://версию вместо http://. Я рад, что конечные точки были в конфигурации, а не жестко закодированы.

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

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

Для этого и есть регрессионное тестирование.

Вы не можете просто посмотреть на код, изменить его и поверить себе, что ничего не сломано. Это не будет работать в архитектуре микросервисов. Это не будет работать и в монолитном приложении. Компилятор может отлавливать некоторые ошибки, которые вы будете вносить при изменении кода. В некоторых языках, таких как Haskell, компилятор может быть очень способным и отлавливать большинство ошибок; однако компиляторы для основных языков мало что сделают для вас. Если у вас нет тестов, вы облажались. Наличие микросервисов не имеет значения.

API-интерфейсы REST указываются слабо, поэтому в определенный момент может быть полезно перейти к gRPC, google protobufs или Thrift, чтобы определить интерфейс RPC, а затем обновить его.