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

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

Модули

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

В качестве одной из технологий подхода к модульной декомпозиции стоит упомянуть спецификацию динамической плагинной (модульной) шины для создания Java-приложений — Open Source Gateway Initiative (OSGI). В самом языке Java понятие «модули» отсутствует, и чтобы увидеть его добавленным к языку, придется, видимо, ждать выхода Java 9. Спецификация OSGI, появившаяся в качестве среды, позволяющей устанавливать дополнительные модули (плагины) в Eclipse Java IDE, используется в данное время в качестве способа подгонки модульной концепции в Java посредством библиотеки.

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

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

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

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

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

Никаких универсальных решений

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