Должны ли сервисы напрямую взаимодействовать друг с другом в микросервисной архитектуре?

У меня есть несколько веб-сервисов, которые формируют веб-приложение. Клиенты могут получить доступ к этим услугам через вызовы API REST.

Должны ли эти службы общаться напрямую друг с другом? Если это так, разве это не объединит их, что противоречит концепции микросервисов?

Должен ли клиент вызывать их напрямую один за другим, чтобы получить данные, необходимые для загрузки веб-страницы на клиенте?

Или у меня должен быть другой слой поверх моих служб, который обрабатывает запрос от клиента, выбирает данные для этого запроса и затем отправляет их обратно клиенту?

Если вы хотите, чтобы ваши услуги выглядели так, как на этой картинке, то да: это не так, как будто вы не можете этого сделать, но в большинстве случаев это будет иметь плохие последствия. Связь через REST не будет значительно отделять ваши услуги. При изменении какого-либо интерфейса службы все зависимые службы, скорее всего, должны быть изменены и повторно развернуты. Также при повторном развертывании службы вам придется отключить все зависимые службы, что не считается хорошим дизайном для стандартов высокой доступности.

В конце концов, у вас будет приложение для микросервисов, которое будет медленнее, чем альтернативное монолитное приложение, но с почти такими же проблемами!

Я должен не согласиться с @ Робертом Харви

На практике, однако, один или несколько ваших микросервисов (возможно, все они) будут общаться с некоторым центральным хранилищем данных, таким как база данных SQL.

Интеграция базы данных известного антипаттерна

Гораздо лучшим решением является использование шаблона публикации-подписки для того, чтобы сделать связь между вашими сервисами асинхронной:

Пожалуйста, взгляните на CQRS / ES способ реализации этого метода общения, Грег Янг и другие ребята предлагают множество хороших видео по этой теме. Просто Google для ключевого слова "CQRS / ES". При таком подходе каждый сервис становится издателем и подписчиком одновременно, что позволяет сервисам быть гораздо менее связанными.

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

Вы получите много очень хороших идей, прочитав, что Udi Dahan говорит о SOA .

Сервис - это технический орган для определенных бизнес-возможностей. Любая часть данных или правила должна принадлежать только одному сервису.

Это означает, что даже когда службы публикуют и подписываются на события друг друга, мы всегда знаем, что является авторитетным источником правды для каждого фрагмента данных и правила.

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

В частности, что касается композиции пользовательского интерфейса, статья Мауро Сервиенти о композиции пользовательского интерфейса является хорошей отправной точкой. Смотрите также видео Уди, доступное здесь .

Должны ли эти службы общаться напрямую друг с другом? Если это так, разве это не объединит их, что противоречит концепции микросервисов?

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

Помимо этого, такие методы, как обнаружение служб, могут ослабить зависимость от конкретного поставщика услуг, а брокеры сообщений могут отделить производителей и потребителей (им все еще нужно понимать сообщения друг друга и то, как взаимодействовать с API брокера сообщений - в этом нет никакой магии). ).

Это зависит от того, что вы подразумеваете под «напрямую».

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

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

Должны ли эти службы общаться напрямую друг с другом? Если это так, разве это не объединит их, что противоречит концепции микросервисов?

Сцепление - это не плохое слово. Каждое приложение уже имеет определенную степень связи; приложения, которые общаются с вашими микросервисами, уже связаны с микросервисами, иначе они не будут работать.

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

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

Кажется, что, говоря о SOA и архитектуре в целом, люди оказываются вовлеченными в семантику и жаргон. Что делает услугу «микро»? В конечном счете, это некоторый набор характеристик, которые в любой используемой вами «системе оценки» явно не делают сервис «немикро». Что сказал верховный суд о непристойности? «Я узнаю это, когда увижу».

Я уверен, что некоторые люди скажут, что это не ответ, но тогда они упускают суть. Микросервисные архитектуры призваны избежать нескольких проблем, среди которых проблема «тесной связи». Таким образом, если вы в конечном итоге создаете путаницу микро-сервисов, которые зависят от слишком большого количества мелких деталей друг о друге, вы создали тесную связь, которая - будь вы используете шину сообщений pub / sub или прямые вызовы - уничтожает ваша способность составлять новые решения из кусочков, перенастраивать отдельные куски без разрушения всей системы и т. д. и т. д.

Должен ли клиент вызывать их напрямую один за другим, чтобы получить данные, необходимые для загрузки веб-страницы на клиенте?

Это зависит; тем не менее, я бы предложил предоставить клиенту непосредственно используемые возможности и скрыть (инкапсулировать) детали того, как собираются результаты (например, с помощью нескольких микросервисов).

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

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

(Кроме того, поездки до клиента, вероятно, обходятся дороже, чем от ваших микросервисов друг к другу.)

Например, если вы посмотрите на направление, используемое GraphQL, то обнаружите, что клиенты выдают напрямую соответствующие запросы конечной точке, которая может быть или не быть реализована как набор микросервисов. Поскольку архитектура микросервисов скрыта за GraphQL, это упрощает ее реорганизацию и делает ее более удобной для клиента. См., Например, https://stackoverflow.com/a/38079681/471129 .

Основная цель микроуслуг - сделать ваше приложение слабо связанным. Поэтому службы не могут звонить друг другу. В противном случае он будет тесно связан. Но что мы будем делать, если у нас есть две службы, которые должны обмениваться данными? Ответ - Message Broker. Таким образом, служба, которая получает данные от клиента, может обмениваться данными с центральным брокером сообщений, а затем службы должны использовать эти данные, чтобы использовать их, преобразовывать и помещать в свое собственное хранилище данных. Я рекомендую Kafka, потому что вы можете объединять данные из разных тем на лету с Kafka Stream. PS. Лучше разделить ваши микро-услуги по функциям.