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

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

Обмен данными с точки зрения бизнес-концепций

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

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

Техническая граница

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

Команда и система разрослись. Изначально в представлении отдельно взятого человека система вбирала в себя все больше и больше функций и у нее становилось все больше и больше пользователей. В конце концов организация решила увеличить штат команды — создать новую группу разработчиков, находящуюся в Бразилии, и переложить на нее часть работы. Система подверглась разбиению, причем одна половина приложения, по существу, утратила конкретное «гражданство» и стала представлять собой общедоступный сайт (рис. 3.4). Другая половина системы стала простым интерфейсом удаленного вызова процедуры (Remote Procedure Call (RPC)) в отношении хранилища данных. Представьте, что вы, по сути, берете в своем исходном коде уровень хранилища данных и превращаете его в отдельный сервис.

Рис. 3.4. Граница сервиса, проложенная по техническому стыку

В оба сервиса пришлось часто вносить изменения. И оба сервиса рассматривались в понятиях низкоуровневого вызова методов в RPC-стиле, которые обладали излишней хрупкостью (этот вопрос будет рассматриваться в главе 4). Сервисный интерфейс был также слишком многословен, что влекло за собой проблемы с производительностью. Все это вылилось в необходимость усовершенствования механизмов RPC-пакетирования. Я назвал это луковой архитектурой, поскольку в ней имелось множество уровней и она заставляла меня плакать, когда ее приходилось разрезать.

На первый взгляд идея разбиения ранее монолитной системы по географическим или организационным линиям была вполне осмысленной, и ее развернутое представление будет рассмотрено в главе 10. Но в данном случае вместо того, чтобы разрезать стек по вертикали на бизнес-ориентированные куски, команда сделала выбор в пользу того, что ранее было API внутри процесса, и произвела горизонтальный разрез.

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

Резюме