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

private String emailAddress;

private String age;

}

Что, если теперь выяснится, что, несмотря на выставление на всеобщее обозрение в наших объектах Customer поля возраста age, никто из потребителей им не пользуется? Мы решим, что поле нужно удалить. Но если серверная реализация удаляет поле age из своего определения данного типа, а мы не сделаем того же самого для всех потребителей, даже если они никогда не воспользуются этим полем, код, связанный с десериализацией объекта Customer на стороне потребителя, будет поврежден. Чтобы отменить это изменение, я буду вынужден одновременно развернуть как новый сервер, так и новых клиентов. В этом и состоит основная проблема с использованием любого RPC-механизма, продвигающего создание двоичной заглушки: вы не получаете возможности отдельных развертываний клиента и сервера. При использовании данной технологии в будущем вас ожидают такие вот одновременные выпуски с блокировкой всей работы.

Такая же проблема возникнет при желании реструктурировать объект Customer, даже если я не стану удалять какие-либо поля, например, если мне захочется для упрощения управления заключить firstName и surname в новый поименованный тип. Разумеется, я могу справиться с этим путем повсеместной передачи словарных типов в качестве параметров своего вызова, но тогда мне придется расстаться со многими преимуществами создания заглушек, поскольку мне все равно придется вручную искать соответствия и извлекать нужные поля.

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

Неужели RPC настолько страшен?

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

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

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

REST

Передача репрезентативного состояния (REpresentational State Transfer (REST)) представляет собой архитектурный стиль, инспирированный Всемирной сетью. У REST-стиля имеется множество принципов и ограничений, но мы собираемся сконцентрировать внимание на тех из них, которые действительно помогут нам при встрече с интеграционными трудностями в мире микросервисов и поиске стилей интерфейсов для наших сервисов, выступающих в качестве альтернативы RPC.

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

Существует множество различных стилей REST, но здесь они будут рассмотрены весьма поверхностно. Я настоятельно рекомендую вам ознакомиться с интернет-ресурсом Richardson Maturity Model, где сравниваются различные стили REST.