Создание микросервисов

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

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

В конечном счете этот подход является еще одной попыткой оптимизировать дефицит ресурсов, которые могут просто больше не вмещаться. Если вы примете решение в качестве модели развертывания разместить несколько сервисов на одном хосте, я бы настоятельно рекомендовал присмотреться к независимо развертываемым микросервисам как к артефактам. Применяя. NET-технологию, этого можно добиться с помощью использования таких средств, как Nancy, а в Java эта модель поддерживается на протяжении многих лет. Например, имеющий довольно почтенный возраст встроенный контейнер Jetty создается для весьма облегченного автономного HTTP-сервера, составляющего ядро стека Dropwizard. Известно, что в Google встроенные Jetty-контейнеры весьма успешно используются для непосредственного обслуживания статического контента и, следовательно, что все это может работать в широких масштабах.

Размещение по одному сервису на каждом хосте

При использовании модели размещения по одному сервису на каждом хосте (рис. 6.8) мы избавляемся от побочных эффектов, характерных для нескольких сервисов, размещаемых на одном хосте, существенно упрощая возможности контроля и внесения исправлений. Потенциально сокращается и количество критических точек сбоя. Выход из строя одного хоста повлияет только на один сервис, хотя это не всегда так, когда используется виртуализированная платформа. Более подробно создание разработок с прицелом на масштабирование и устойчивость к сбоям рассматривается в главе 11. Кроме того, упрощается масштабирование одного сервиса независимо от всех других, а сосредоточение внимания только на сервисе и требующем этого внимания хосте упрощают решение вопросов обеспечения безопасности.

Рис. 6.8. Размещение по одному сервису на каждом хосте

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

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

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

Платформа в качестве услуги