мы держимся за эту память, тем выше шансы, что память будет содержать недостоверную информацию. Разумеется, если мы не станем запрашивать данные чаще, чем это требуется, наши системы станут гораздо эффективнее.
Иногда в памяти будут вполне приемлемые данные, но во всех остальных случаях нужно быть в курсе их изменений. Поэтому, решив обратиться к тому образу ресурса, который был в памяти, нужно также включить ссылку на исходный ресурс, позволяющую извлечь его новое состояние.
Рассмотрим пример обращения к сервису электронной почты на отправку сообщения о том, когда был выслан заказ. Теперь мы можем отправить запрос к сервису электронной почты с подробностями в виде электронного адреса клиента, его имени и заказа. Но если сервис электронной почты уже выстроил очередь из таких запросов или вынул их из очереди, то за время нахождения в ней могли произойти изменения. Может быть, рациональнее было бы просто отправить URI ресурсов Customer и Order и позволить серверу электронной почты просмотреть их, когда настанет срок отправки электронного сообщения.
Отличный контрапункт этому возникает при рассмотрении возможностей совместной работы на основе событий. Работая с событиями, мы говорим о факте случившегося, но нам нужно знать, что именно случилось. Например, если мы получаем обновления, связанные с ресурсом Customer, ценной для нас информацией будет то, на что стал похож Customer, когда событие произошло. Так как мы получили также ссылку на сам ресурс, можно посмотреть на его текущее состояние и взять из обоих миров то, что нам больше подходит.
Разумеется, при получении доступа по ссылке можно пойти и на другие компромиссы. Если при просмотре в ресурсе Customer информации о заданном клиенте мы всегда обращаемся к клиентскому сервису, нагрузка на этот сервис может быть весьма значительной. Если при извлечении ресурса предоставляется дополнительная информация, оповещающая о том, сколько времени ресурс провел в заданном состоянии и, возможно, как долго можно считать эту информацию свежей, то мы можем получить существенные выгоды от кэширования данных и снижения нагрузки на сервис. HTTP предоставляет нам для поддержки всего этого уже готовые решения с широким разнообразием средств управления кэш-памятью, часть из которых более подробно рассматриваются в главе 11.
Еще одна проблема связана с тем, что некоторым сервисам может быть и не нужна информация обо всем ресурсе Customer и, настаивая на том, чтобы они ее искали, мы потенциально усиливаем связанность. Например, может случиться так, что сервис электронной почты должен работать в более простом режиме и ему нужно отправить лишь электронный адрес и имя клиента. Вывести на этот счет какое-либо непреложное правило, конечно, нельзя, но при обходе в запросах тех данных, о степени свежести которых ничего не известно, нужно проявлять крайнюю осмотрительность.
Практически на каждой лекции о микросервисах мне задавали вопрос о том, как я справляюсь с управлением версиями. У людей возникало вполне законное беспокойство о том, что со временем в интерфейс сервиса придется вносить изменения, и они хотели понять, как это можно сделать. Разобьем эту проблему на части и посмотрим на те этапы, которые нужно будет пройти, чтобы с ней справиться.
Наилучшим способом уменьшить влияние внесения критических изменений в первую очередь является отказ от их внесения. Основным способом достижения этого может стать выбор правильной технологии интеграции, о чем и говорилось в данной главе. Интеграция путем использования базы данных является хорошим примером технологии, которая может существенно затруднить отказ от критических изменений. А вот REST помогает достичь желаемого результата, поскольку изменения, вносимые в тонкости внутренней реализации, скорее всего, не приведут к изменениям интерфейса сервиса.
Еще одним ключом к отсрочке внесения критических изменений является содействие правильному поведению ваших клиентов, в первую очередь удержание их от слишком жесткой привязки к вашим сервисам. Рассмотрим сервис электронной почты, чьей задачей является периодическая отправка электронных сообщений клиентам. Он получает задачу на отправку сообщения о высылке заказа клиенту с идентификатором ID 1234. Затем приступает к работе: извлекает данные о клиенте с указанным ID и получает в ответ что-либо подобное показанному в примере 4.3.
Пример 4.3. Пример ответа от клиентского сервиса
Теперь для отправки сообщения по электронной почте нужны только поля firstname, lastname и email. Нам не нужно знать содержимое поля telephoneNumber. Требуется просто извлечь те поля, которые нас интересуют, проигнорировав все остальные. Некоторые технологии связывания, в особенности те, которые используются строго типизированными языками, могут попытаться связать все поля независимо от того, нужны они потребителю или нет. Что произойдет, если мы поймем, что поле telephoneNumber никто не использует, и решим его удалить? Это может привести к совершенно ненужному нарушению режима работы потребителей.
А что, если нам придет в голову изменить структуру нашего объекта Customer так, чтобы она поддерживала более подробные данные, возможно, путем добавления некой дополнительной структуры, как в примере 4.4? А сервису электронной почты по-прежнему нужны все те же данные и под теми же именами, но, если в коде делаются абсолютно четкие предположения о том, где именно будут храниться данные полей firstname и lastname, то он опять может стать неработоспособным. В таком случае вместо этого для извлечения нужных нам полей можно воспользоваться XPath, что позволит безразлично относиться к тому, где именно находятся поля, поскольку мы все равно сможем их найти. Именно такая схема, предполагающая создание системы считывания данных, способной проигнорировать те изменения, которые нас не волнуют, получила от Мартина Фаулера название толерантного считывателя (Tolerant Reader).
Пример 4.4. Ресурс Customer с измененной структурой: данные никуда не делись, но сможет ли потребитель их найти?
Пример клиента, старающегося быть как можно гибче в использовании сервиса, демонстрирует закон Постела, известный также как принцип живучести (robustness principle), который гласит: «Будь требователен к тому, что отсылаешь, и либерален к тому, что принимаешь». Исходной средой для проявления этой мудрости служило взаимодействие сетевых устройств, при котором следует ожидать всевозможных странностей. В контексте же нашего взаимодействия в режиме «запрос — ответ» он может привести нас к стремлению сделать сервис приспособленным к изменениям и не требовать никаких изменений от нас.
Очень важно гарантировать выявление изменений, способных нарушить работу потребителей как можно раньше, потому что, даже выбрав наилучшую из возможных технологий, мы все равно не будем застрахованы от критических сбоев. Для содействия выявлению этих проблем на ранней стадии я настоятельно рекомендую воспользоваться контрактами, задаваемыми потребителями (consumer-driven contracts), которые рассматриваются в главе 7. Если вы поддерживаете сразу несколько различных клиентских библиотек, то еще одной вспомогательной технологией может стать выполнение тестов с использованием каждой поддерживаемой вами библиотеки в отношении самого последнего сервиса. Как только обнаружится состояние, близкое к нарушению режима работы потребителя, перед вами встает выбор либо попытаться вообще избежать этого нарушения, либо смириться с возникшим состоянием и приступить к переговорам с теми, кто сопровождает сервисы-потребители.
Разве плохо будет, если вы в качестве клиента получите возможность с одного взгляда на номер версии сервиса тут же понять, сможете ли вы интегрироваться с ним или нет? Семантическое управление версиями представляет собой спецификацию, позволяющую получить именно такую возможность. При семантическом управлении версиями у каждой версии есть номер, имеющий форму MAJOR.MINOR.PATCH (важный. второстепенный. исправление). Когда происходит увеличение MAJOR-части номера, это означает, что были внесены изменения, исключающие обратную совместимость. Когда увеличивается MINOR-часть номера, это означает, что была добавлена новая функциональная возможность, которая не должна нарушить обратную совместимость. И наконец, когда меняется PATCH-часть номера, это означает, что в существующие функциональные возможности были внесены исправления, устраняющие какие-либо недостатки.
Чтобы убедиться в пользе семантического управления версиями, рассмотрим простой практический пример. Приложение по поддержке клиентов было создано для работы с версией клиентского сервиса, имеющей номер 1.2.0. Если будет добавлено какое-либо новое свойство, которое станет причиной изменения номера версии сервиса на 1.3.0, приложение не заметит никаких изменений в поведении сервиса и от него не будет ожидаться внесения каких-либо изменений в работе. Но мы не можем гарантировать, что будем в состоянии работать с версией 1.1.0 клиентского сервиса, поскольку можем зависеть от наличия тех функциональных возможностей, которые были добавлены при выпуске версии 1.2.0. Мы также можем ожидать необходимости внесения изменений в приложение, если выйдет новый выпуск клиентского сервиса с номером версии 2.0.0.