Должны ли микросервисы общаться друг с другом?

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

Я считаю, что есть два варианта:

• Интегрируйте межсервисный механизм связи, который позволяет сервисам общаться напрямую. API-шлюз будет вызывать отдельную службу, которая затем вызывает другие службы для сбора данных, прежде чем возвращать консолидированный ответ на API-шлюз. Затем API возвращает ответ вызывающей стороне. (Это должны быть синхронные вызовы, когда вызову serviceB требуется ответ от serviceA. IE Seperate Person и Address Services.)
• Пусть API-шлюз вызывает каждую службу напрямую и объединяет данные в API, прежде чем вернуть ответ.

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

• Наличие API для выполнения нескольких вызовов нескольких служб увеличивает нагрузку на сервер API, особенно когда некоторые из этих вызовов блокируются.

• Этот метод будет означать, что API должен «знать» о том, что пытается сделать приложение (IE Logic должен быть запрограммирован в API для обработки вызова сервисов по очереди, а затем для консолидации данных), а не просто действовать как тупая «конечная точка» для микро-услуг.

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

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

Я хотел бы провести четкое различие между операциями изменения состояния и операциями чтения ( разделение запросов CQS ). Для операций по изменению состояния я бы использовал какую-то инфраструктуру обмена сообщениями и пошел бы на огонь и забыл Для запросов вы должны использовать синхронную передачу ответа на запрос и можете использовать http API или просто перейти непосредственно в свое хранилище данных.

Если вы используете обмен сообщениями, вы также можете посмотреть публикацию подписки на события между службами.

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

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

Надеюсь, это имеет смысл.

Это зависит от того, зачем вам нужны эти данные. Если это для пользовательского интерфейса, то это прекрасно. Более того, так и должно быть. У Криса Ричардсона есть хорошее объяснение этой концепции , а у Сэма Ньюмана есть отличная статья об очень похожей концепции, которая называется Backends for Frontends .

Но если вам нужна какая-то логика, есть вероятность, что границы вашего обслуживания неверны.

Здравый смысл подсказывает нам, что наши услуги должны обладать несколькими характеристиками . Они есть:

1. Низкая связь. Если вы вносите какие-либо изменения в службу A, вы не хотите, чтобы они влияли на службу B.
2. Высокая сплоченность Если вам нужно реализовать какую-то функцию, вы хотите, чтобы это затрагивало как можно меньшее количество служб.
3. Высокая автономия. Если какой-либо сервис отказывает, вы не хотите, чтобы вся система была недоступна.
4. Правильная зернистость. Вы не хотите, чтобы ваши сервисы были слишком болтливыми, поскольку ваша сеть более сложная вещь, чем вы думаете.
5. Сервисы должны общаться через события. Вы не хотите, чтобы ваши службы знали друг о друге, поскольку это снижает удобство обслуживания. Подумайте, что произойдет, если вам нужно добавить новый сервис.
6. Децентрализованные данные. Служба не должна делиться тем, как хранится информация. Как хороший объект, он демонстрирует поведение, а не данные.
7. Служба хореографии над оркестровкой.

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

1. Определите границы более высокого уровня. Мне нравится думать о них как о шагах, которые ваша организация должна пройти, чтобы достичь своей бизнес-цели, получить свою бизнес-ценность. Вы можете понять основные шаги, взглянув на цепочку добавленной стоимости Портера .
2. В рамках каждого сервиса, углубиться глубже. Идентифицируйте автономные единицы ребенка с их собственными обязанностями.
3. Следите за тем, как они общаются. Правильные службы общаются в основном через события. Подумайте о своей организационной структуре. Коммуникация внутри них довольно интенсивная, хотя обычно выявляется несколько внешних событий.

Пример применения такого подхода может быть какой - то интерес.

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

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

Чтобы развить вашу вторую заботу о том, чтобы API-шлюз был «умным», шаблон, который сейчас набирает силу с такими фреймворками, как Falcor и Relay / GraphQL, состоит в том, чтобы запросить больше спецификаций того, что делать, чтобы «Шлюз API» мог в целом выполнить эти спецификации, не зная, что GetTimelineвлечет за собой. Вместо этого он получит запрос типа «запросить эту пользовательскую информацию из пользовательского сервиса и получить эти сообщения из почтового сервиса» или что-то еще.

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

Вы можете объяснить больше о проблеме, которую пытаетесь решить? На простом английском?