ых местах, а кроме того, нужно будет еще и развертывать такие изменения. И тут уже придется распрощаться с зацеплением.
Помните, что говорилось об основных принципах, закладываемых в качественные микросервисы? Сильное зацепление и слабая связанность. А с интеграцией при помощи базы данных мы теряем и то и другое. База данных упрощает для сервисов совместное использование данных, но ничего не может поделать с общим поведением. Внутреннее представление по сети выставляется напоказ другим потребителям, и избежать разрушительных изменений становится очень трудно, что неминуемо приводит к возникновению страха перед внесением любых изменений. А этого нужно избегать практически любой ценой.
Далее в главе будут рассмотрены разные стили интеграции, связывающие совместно работающие сервисы, которые сами скрывают собственное внутреннее представление.
Перед тем как углубиться в особенности технологического выбора, нужно рассмотреть одно из наиболее важных принимаемых решений в понятиях способов совместной работы сервисов. Каким должен быть обмен данными, синхронным или асинхронным? Этот основополагающий выбор неминуемо приводит нас к конкретным деталям реализации.
При синхронном обмене данными делается вызов на удаленный сервер, блокирующий всю работу вплоть до завершения операции. При асинхронном обмене данными вызывающая сторона перед тем, как вернуть управление, не будет дожидаться завершения операции и даже может не беспокоиться о ее завершении.
Проще рассуждать о синхронном обмене данными. Мы знаем, когда все завершается удачно, а когда — нет. Асинхронный обмен данными может оказаться весьма полезным для продолжительных заданий, где долговременное удержание открытым подключения между клиентом и сервером непрактично. Оно также хорошо себя проявляет, когда не нужны большие задержки, при которых вызов блокирует работу в ожидании результата, что может замедлить весь процесс. Вследствие особенностей, присущих мобильным сетям и устройствам, выдача запросов при условии, что все продолжает работать (если не указано обратное), может гарантировать сохранение отзывчивости пользовательского интерфейса, даже если сеть будет сильно тормозить. В то же время, как мы вскоре узнаем, технология управления асинхронным обменом данными может быть несколько сложнее.
Эти два разных режима обмена данными могут допускать два различных идиоматических стиля совместной работы: «запрос — ответ» или «опора на события». При применении стиля «запрос — ответ» клиент инициирует запрос и ждет получения ответа. Эта модель полностью вписывается в синхронный обмен данными, но может работать и при асинхронном обмене. Можно начать операцию и зарегистрировать обратный вызов, обращаясь к серверу с просьбой дать знать о том, когда операция будет завершена.
При совместной работе, основанной на применении событий, все наоборот. Вместо того чтобы клиент инициировал запросы на выполняемые действия, он говорит о том, что случилось нечто конкретное, и ожидает того, что другие стороны знают, что им следует делать. О том, что нужно делать, никому другому никогда не говорится. По своей природе системы, основанные на использовании событий, относятся к асинхронным. Интеллектуальные решения распределяются более равномерно, то есть бизнес-логика не централизована в основных интеллектуальных ядрах, а вытеснена в различные совместно работающие сервисы. Кроме того, совместная работа на основе событий обладает высокой степенью разобщенности. Клиент, выдающий событие, не имеет возможности узнать, кто или как на него среагирует, что также означает: вы можете добавить новых подписчиков на эти события без необходимости уведомлять об этом клиента.
Итак, есть ли какие-нибудь другие побудительные причины, которые могли бы подтолкнуть нас к выбору того или иного стиля? Заслуживает рассмотрения то, насколько хорошо эти стили подходят для решения самых сложных задач: как мы справляемся с процессами, выходящими за границы сервисов и выполняемыми достаточно долго?
Приступая к моделированию все более сложной логики, нам приходится справляться с проблемами управления бизнес-процессами, выходящими за границы отдельных сервисов. А при работе с микросервисами с этим ограничением приходится сталкиваться еще чаще. Возьмем пример из MusicCorp и посмотрим, что происходит при создании клиента.
1. В банке очков лояльности по отношению к клиенту создается новая запись.
2. Наша почтовая система отправляет набор приветственных сообщений.
3. Клиенту отправляется приветственное сообщение по электронной почте.
Концептуально это легко поддается моделированию в виде блок-схемы, что, собственно, и сделано на рис. 4.2.
Рис. 4.2. Процессы, предназначенные для создания нового клиента
Когда наступает черед фактической реализации того, что изображено на блок-схеме, можно придерживаться двух стилей архитектуры. При использовании оркестрового принципа за основу берется центральный интеллект, направляющий процессы и управляющий ими, во многом напоминающий своими действиями дирижера оркестра. При использовании хореографического принципа каждую часть системы информируют о поставленной перед ней задаче, а детали разрешается прорабатывать самостоятельно, они подобны танцорам, находящим собственный путь и реагирующим на всех окружающих их артистов балета.
Подумаем, какой вид согласно этой блок-схеме приобретет решение по использованию оркестрового принципа. Здесь, наверное, проще всего было бы заставить наш сервис работать в качестве центрального интеллекта. Как показано на рис. 4.3, при создании через серию вызовов «запрос — ответ» происходит общение с банком очков лояльности по отношению к клиенту, сервисом электронной почты и сервисом обычной почты. В дальнейшем сервис клиентов самостоятельно может отслеживать положение клиента в этом процессе. Он может проверить установку учетной записи клиента, или отправку электронной почты, или доставку почтового сообщения. Мы можем взять блок-схему, показанную на рис. 4.2, и смоделировать ее непосредственно в коде. И даже можем воспользоваться инструментарием, который сделает это за нас, возможно, с применением соответствующего обработчика правил. Для этой цели существуют коммерческие инструменты в виде программ моделирования бизнес-процессов. Предположив, что используется синхронный стиль вида «запрос — ответ», мы даже можем узнать, пройден ли тот или иной этап.
Рис. 4.3. Подход к созданию клиента с помощью оркестрового принципа
Недостаток подхода с использованием оркестрового принципа заключается в том, что сервис клиентов может получить излишне централизованные руководящие полномочия. Он может стать узлом в середине сети и центральной точкой, из которой исходит логика. Я видел, как такой подход приводит к возникновению небольшого количества «божественных» сервисов, предписывающих вялым сервисам на CRUD-основе, что им надлежит делать.
При подходе с использованием хореографического принципа вместо этого можно обязать сервис клиентов выдавать в асинхронной манере события, которые бы оповещали о создании клиента. Затем, как показано на рис. 4.4, сервис электронной почты, сервис обычной почты и банк очков лояльности просто подписались бы на подобные события и реагировали на них соответствующим образом. Этот подход имеет намного более разобщенный характер. Если какому-либо другому сервису потребуется добраться до создания клиента, ему просто нужно будет подписаться на события и выполнять по мере необходимости возложенную на него задачу. Недостатком является то, что явное представление бизнес-процесса, которое показано на рис. 4.2, теперь отражается в нашей системе лишь в неявном виде.
Рис. 4.4. Подход к созданию клиента с использованием хореографического принципа
Это означает необходимость выполнения дополнительной работы, дающей возможность наблюдать и отслеживать надлежащее развитие событий. Например, узнаете ли вы о том, что банк очков лояльности имеет некий изъян и по какой-то причине не завел нужную учетную запись? Одним из предпочитаемых мной подходов является построение системы наблюдения, которая в точности соответствует представлению бизнес-процессов, показанному на рис. 4.2, с последующим отслеживанием того, что делает каждый сервис в качестве независимой единицы. Это позволит замечать случайные исключения, отображаемые на более явное течение процесса. Рассмотренная ранее блок-схема является не побудительной причиной, а всего лишь одной из линз, через которую можно увидеть характер поведения системы.
Вообще-то я понял, что системы, больше тяготеющие к подходу с использованием хореографического принципа, обладают намного более слабой связанностью и большей гибкостью и податливостью к изменениям. Но при этом приходится выполнять дополнительную работу для наблюдения и отслеживания процессов, проходящих через системные границы. Я понял, что системы, обладающие самой сильной приверженностью к использованию оркестрового принципа, получаются слишком хрупкими и требующими более высоких затрат на внесение изменений. Помня об этом, я являюсь стойким приверженцем нацеливания на реализацию системы с использованием хореографического принципа, где каждый сервис обладает достаточным интеллектом для понимания своей роли во всем танце.
Мы можем рассмотреть довольно много факторов. Синхронные вызовы проще, и мы будем осведомлены о том, что все идет намеченным курсом. Если нам нравится семантика «запрос — ответ», но мы имеем дело с долговременными процессами, можем просто инициировать асинхронные запросы и ждать обратных вызовов. В то же время совместная работа с использованием асинхронных событий помогает ввести подход, использующий хореографический принцип, который может привести к созданию намного более разобщенных сервисов, к чему, собственно, мы и стремимся, чтобы обеспечить для своих сервисов независимую разъемность.