Моя текущая компания разрабатывает единую платежную платформу.В связи с потребностями бизнеса компании ей необходим доступ к нескольким сторонним платежам.Чтобы более глубоко подумать о платежной платформе, я разберусь с ней.
шаблон компонента
Поскольку у компании есть бизнес во многих регионах, ей необходимо предоставить различные платежные каналы для развития бизнеса, поэтому разработанная платежная платформа должна иметь доступ к различным сторонним платежным каналам, таким как: оплата WeChat, Alipay оплата, оплата картой, быстрая оплата Все мы знаем, что у каждого стороннего платежа есть свой набор внешних API, а у официального есть набор SDK для реализации этих API, как нам организовать эти API?
Поскольку сторонние платежные каналы будут меняться по мере развития бизнеса, организация этих SDK должна гибко подключаться и отключаться, не затрагивая общую архитектуру платежной платформы.Здесь я использую идею компонентов для разделения API-интерфейс платежа в различные компоненты платежного компонента, компонент возврата, компонент заказа, компонент выставления счетов, компонент обработки исключений заказа и т. д., а затем, когда вводится сторонний платежный SDK, требуемый API может быть гибко добавлен в компонент. разработан следующим образом:
Унифицированный обратный вызов и асинхронная диспетчерская обработка
Соединение со сторонним платежом имеет особенность, то есть после успешной оплаты и возврата будет функция обратного вызова для оплаты и возврата.Цель: 1.Пусть торговая платформа сама проверит легитимность заказа, такого как предотвращение платежа, Если клиент злонамеренно подделал сумму и другие параметры, то после успешной оплаты заказ находится в состоянии оплаты и должен ждать стороннего обратного вызова.Если сумма платежа и сумма заказа после получения подтверждения обратного вызова мы можем изменить статус заказа на «Не удалось», чтобы предотвратить потерю средств. 2: Через обратный вызов мы можем обрабатывать бизнес-логику нашей собственной системы, распределение товаров и так далее. Идея обратного звонка нужна только для обеспечения окончательной непротиворечивости данных, поэтому нам не нужно проверять правильность параметров при инициации платежа, а только во время обратного звонка. Тогда как мы должны установить обратный вызов платежной платформы.
Поскольку платежной платформе необходим доступ к нескольким сторонним платежам, если каждый сторонний платеж устанавливает адрес обратного вызова в это время, будет несколько адресов обратного вызова.Поскольку API обратного вызова должен быть открыт для принятия стороннего обратного вызова, поэтому Будут проблемы с безопасностью.Мы должны настроить фильтрацию безопасности на внешнем уровне API, поэтому нам нужно единообразно вызывать API, единообразно выполнять проверку безопасности, а затем выполнять уровень распределения.
Используемый нами механизм распространения RabbitMq, здесь могут быть сомнения, если mq используется для обработки распределения, как результат проверки может быть возвращен третьей стороне в режиме реального времени? Вот некоторые мысли о обратных вызовах:
1.Система основана на микросервисной архитектуре Spring boot. Службы взаимодействуют через Http. Если Http используется для распространения, можно гарантировать возврат сообщения в режиме реального времени. Однако из-за нестабильной сети будут проблемы с запросом сбой или таймаут, а стабильность интерфейса нехорошая.гарантировать.2.Поскольку сторонний платеж получает ложный ответ, он снова инициирует запрос обратного вызова в следующий период времени. Цель этого состоит в том, чтобы обеспечить вероятность успешного обратного вызова. Для стороннего платежа это не проблема, но для продавцов Для платежной платформы это может быть довольно хитрый дизайн.Если подумать, предположим, что есть заказ, который злонамеренно подделал сумму во время оплаты, проверка обратного вызова не проходит, и стороннему лицу возвращается false платеж.В это время сторонний платеж будет отправляться снова и снова.Обратный вызов, независимо от того, сколько раз будет отправлен обратный вызов, проверка будет неудачной, что добавляет лишнее взаимодействие.Конечно, здесь также можно использовать идемпотентность. Ниже приведено описание сценария обратного вызова платежа WeChat:
Исходя из двух вышеперечисленных моментов, считаю ненужным возвращать false стороннему платежу.Для надежности системы я использую очередь сообщений для асинхронной рассылки.Платежная платформа сразу возвращает true после получения запроса обратного вызова. В это время у вас может возникнуть вопрос: если в это время проверка не пройдена, но в это время возвращается true, возникнут ли проблемы? Прежде всего, в случае сбоя проверки заказ должен находиться в состоянии сбоя оплаты.Целью возврата true в это время является сокращение ненужного удаленного взаимодействия со сторонним платежом.
Поскольку Mq сохраняет сообщения на диск, самым большим преимуществом очередей сообщений для распространения является просмотр сообщений в очередях сообщений для устранения неполадок, а очереди сообщений могут сократить трафик в часы пик.
Ниже представлена диаграмма архитектуры унифицированного обратного вызова и распределения:
Совокупный платеж
Платежная платформа агрегирует множество сторонних платежей, поэтому на уровне запроса необходимо проделать большую работу по адаптации, чтобы удовлетворить потребности различных платежей.Может быть, вы думаете, просто добавьте несколько строк if else непосредственно в адаптацию стороны, верно? , это не проблема сделать, и это также может удовлетворить потребности различных платежей, но если вы добавите сторонний платеж, вы можете добавить только несколько других условий к исходному методу, что вызовет запросите код уровня, чтобы продолжать развиваться вместе с бизнесом. Это изменение делает код крайне неэлегантным и неудобным в обслуживании. В настоящее время мы можем использовать режим стратегии, чтобы устранить эти коды if else. Когда мы добавляем сторонний платеж, мы нужно только создать новый класс стратегии следующим образом:
обработка запроса
Поскольку платежная платформа включает средства, различные запросы и возвраты платежей, а также ненормальные записи чрезвычайно важны для платежной платформы, поэтому нам необходимо записывать каждую запись платежного запроса для последующего устранения неполадок.
Исходя из этого, мы разрабатываем уровень обработчика, прежде чем начинать запрашивать сторонние платежи. Все запросы должны обрабатываться на уровне обработчика. Основные методы обработчика следующие:
public K handle(T t) {
K k;
try {
before(t);
k = execute(t);
after(k);
} catch (Exception e) {
exception(t, e);
}
return k;
}
protected abstract void before(T t);
protected abstract void after(K k);
protected abstract void exception(T t, Exception exception);
Уровень обработчика использует режим шаблона, который может не только записывать журнал, но и реализовывать различные методы обработки, такие как мониторинг запросов, отправка сообщений и т. д., что реализует высокую масштабируемость уровня обработчика.