MQ, должно быть, использовался более или менее всеми.Общая архитектура после доступа к MQ выглядит следующим образом:

Можно видеть, что после использования MQ восходящая и нисходящая связь становятся такими, как на диаграмме.

У нас также есть общее решение для этого метода взаимодействия между процессами, использующее службы RPC, такие как Dubbo.

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

Тогда почему бы не использовать RPC или MQ для решения этой проблемы??

На самом деле это все определяется бизнес-сценарием, говорить про архитектуру в отрыве от бизнес-сценария - это хулиганство! Не существует единой архитектуры, подходящей для всех, есть только правильная.

Давайте посмотрим, какие сценарии подходят для RPC, а какие — для MQ.

Сценарии RPC

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

В качестве примера возьмем сервис входа в систему.Схема архитектуры выглядит следующим образом:

Запрос на вход, инициированный пользователем, сначала принимается внешней веб-службой, а затем служба веб-службы вызывает службу пользователя для запроса информации о пользователе, а затем сравнивает пароль пользователя.

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

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

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

• Восходящий поток не может напрямую получать результаты нисходящего потока
• Добавление компонента MQ делает систему более сложной.

Сценарий MQ

Сценарии, в которых восходящий поток не заботится о результатах нижестоящего

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

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

Вы можете представить, что пользователь действительно получил дебетовое SMS с банковской карты, но платежная система дает сбой из-за сбоя биллинговой системы, и в результате нет возможности вернуться во внешний мир. Это неприемлемо для пользователей. Я заплатил все деньги, но вы сказали мне, что платеж был ненормальным.

Итак, для этого сценария прямого использования вызовов RPC недостаточно по следующим причинам:

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

Это должно быть решено с помощью MQ?

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

В конце концов, добавление MQ сделает систему более сложной, и нам придется отдельно эксплуатировать и поддерживать MQ, что по-прежнему является большой работой для небольшой команды.

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

Добавить развязку MQ

В этом сценарии используется развязка MQ, что дает несколько преимуществ:

• Задача 1: сократить время выполнения вышестоящей системы
• Задача 2: восходящая и нисходящая логическая развязка, физическая развязка
• Задача 3: Самый важный момент — добавить нижестоящий сервис, на который нужно только подписаться, а вышестоящему сервису не нужно менять код

Сценарии запланированных задач на основе данных

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

• Файл согласования каналов для загрузки задач по времени, метод загрузки может быть загрузкой через интерфейс Http или загрузкой через SFTP.
• Запланированная задача анализирует файл сверки, а затем сохраняет данные сверки в базе данных.
• Запланированная задача сверяет свои собственные локальные платежные данные с данными сверки.

Вышеупомянутые задачи по времени планируются с использованием Spring-Schedule, при условии, что время загрузки каждой задачи по времени следующее:

На приведенном выше рисунке есть три задачи, вторая задача должна быть завершена первой задачей, а третья задача должна быть завершена второй задачей.

Мы использовали этот шаблон раньше и обычно сталкивались с несколькими проблемами:

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

Развязка с MQ

Схема архитектуры после использования развязки MQ выглядит следующим образом:

Таким образом, пока запланированная задача задачи 1 запускается вовремя, сообщение MQ отправляется после завершения задачи 1, задача запускается после ее получения задачей 2, а сообщение отправляется в MQ после завершения. Процесс выполнения третьей задачи такой же, как и второй.

Преимущества использования этого метода:

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

Суммировать

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

Сценарии, подходящие для использования MQ:

• Сценарии, в которых восходящий поток не заботится о результатах нижестоящего
• Зависимости задачи синхронизации на основе данных

Прочитав три вещи ❤️

Если вы считаете, что этот контент очень полезен для вас, я хотел бы пригласить вас сделать мне три небольших одолжения:

1. Лайки, репосты и ваши "лайки и комментарии" - движущая сила моего творчества.

2. Обратите внимание на общедоступный номер 『яванская гнилая свиная кожа’, время от времени делясь оригинальными знаниями.

3. В то же время вы можете рассчитывать на последующие статьи🚀

4. , Подпишитесь и ответьте на [666] Отсканируйте код, чтобы получить обучающий пакет