Слияние кода завершено, страница обновится автоматически
Только для учебных целей.
API-шлюз — это сервер, расположенный перед микросервисной архитектурой или распределенной системой, который используется для управления, мониторинга и защиты различных API-конечных точек в приложении. API-шлюз выступает в роли посредника между клиентами и backend-микросервисами, выполняя множество задач, включая маршрутизацию запросов, аутентификацию и авторизацию, преобразование запросов, балансировку нагрузки, кэширование, мониторинг и логирование.
Прикладные сценарии1. Маршрутизация и балансировка нагрузки: API-шлюз может маршрутизировать запросы на основе URL-адреса, пути или других идентификаторов к соответствующим backend-микросервисам. Он также может выполнять балансировку нагрузки, распределяя запросы по различным экземплярам сервисов, чтобы обеспечить эффективное использование ресурсов и высокую доступность. 2. Аутентификация и авторизация: API-шлюз может выполнять операции аутентификации и авторизации до того, как запросы достигнут backend-сервисов, чтобы убедиться, что только авторизованные пользователи могут получить доступ к определенным API. Это помогает защитить приложение от несанкционированного доступа. 3. Преобразование запросов: API-шлюз может выполнять преобразование запросов и ответов, преобразуя данные в различных форматах в формат, подходящий для клиентов, что снижает нагрузку на backend-микросервисы и улучшает клиентский опыт. 4. Кэширование: API-шлюз может реализовывать стратегии кэширования, кэшируя ответы на часто запрашиваемые запросы, что снижает нагрузку на backend-сервисы, повышает производительность и уменьшает время отклика. 5. Безопасность: API-шлюз может централизованно обрабатывать вопросы безопасности, такие как защита от атак DDoS, защита чувствительных данных и внедрение брандмауэров и списков разрешений/запретов.Мониторинг и анализ: API-шлюз может собирать и мониторить данные запросов и ответов, предоставляя подробную информацию о использовании API, производительности и ошибках. Это помогает выявлять узкие места, корректировать распределение ресурсов и выполнять диагностику. 7. Упрощение для клиентов: API-шлюз может абстрагировать сложность множества микросервисов для клиентов, упрощая процесс вызова и взаимодействия. 8. Управление версиями: API-шлюз может поддерживать управление версиями API, позволяя существовать различным версиям API одновременно и обеспечивая плавный переход. ### Регистрация и обнаружение сервисовРегистрация и обнаружение сервисов — это важный концепт в микросервисной архитектуре, используемый для управления и локализации различных экземпляров микросервисов в распределенной системе. Он решает проблему того, как микросервисы могут обнаруживать друг друга и устанавливать связь в динамической среде.
Недостатки
Модель Saga представляет собой дизайн-паттерн для обработки длинных транзакций (Long-Running Transactions) в распределённых системах. Длинные транзакции — это последовательность связанных операций, которые требуют выполнения на протяжении достаточно длительного времени, обычно включающая несколько шагов и может включать несколько сервисов или компонентов.
Модель Saga направлена на решение проблем распределённых транзакций, поскольку традиционные транзакции ACID часто сталкиваются с проблемами производительности и масштабируемости в распределённых системах. Модель Saga разбивает длинные транзакции на последовательность коротких транзакций, каждый из которых называется шагом (Step), и каждый шаг может быть выполнен в отдельной транзакции. Каждый шаг отвечает за выполнение части работы и фиксирует своё состояние выполнения.
Антипаттерн "Удавка" (Antipattern) — это термин из области программирования, который описывает общие, широко принятые, но доказавшие свою неэффективность практики в области дизайна, разработки или архитектуры программного обеспечения. Антипаттерн "Удавка" описывает методы, которые могут привести к усложнению системы, затруднению её поддержки и расширения.
Основные характеристики антипаттерна "Удавка" включают:1. Сначала кажется правильным: Антипаттерн "Удавка" обычно выглядит разумным и эффективным решением на начальной стадии, но с течением времени и ростом системы начинают проявляться проблемы. 2. Краткосрочная выгода: Антипаттерн "Удавка" может обеспечить некоторые краткосрочные преимущества, но в долгосрочной перспективе может привести к нестабильности, низкой эффективности или затруднению поддержки системы. 3. Нарушение лучших практик: Антипаттерн "Удавка" обычно нарушает лучшие практики программирования, такие как модульность, слабая связанность, принцип единой ответственности и другие. 4. Повторное появление: Антипаттерн "Удавка" может повторно появляться в различных проектах, что указывает на то, что это общее заблуждение или неправильное использование. Некоторые распространенные антипаттерны включают:- Магические числа: В коде жестко закодированы константы или числа, что затрудняет понимание и поддержку кода.
Паттерн Сайдкар является распространенным дизайном в микросервисной архитектуре, который помогает разделить бизнес-логику и общие функции, повышая поддерживаемость, масштабируемость и гибкость системы. Сайдкар-сервисы отделяют общие функции от основного приложения, обеспечивая поддержку последнего, при этом оставаясь независимыми.
Паттерн Сайдкар может применяться в различных сценариях, включая сборку логов, мониторинг, управление конфигурациями, аутентификацию и авторизацию. Он позволяет основному приложению сосредоточиться на своей основной бизнес-логике, передавая общие функции Сайдкар-сервисам.
Паттерн BFF (Backend for Frontend) представляет собой специализированный серверный слой, созданный для конкретного фронтенда. Паттерн BFF направлен на решение проблем несоответствия между требованиями и взаимодействием фронтенда и сервера в сложных фронтенд-приложениях.
В традиционной архитектуре с одним сервером фронтенд-приложение должно взаимодействовать с одним сервером, что может привести к следующим проблемам:1. Переизбыток и недостаток данных: Фронтенд может требовать больше или меньше данных, чем предоставляет сервер, что приводит к потере производительности и пропускной способности. 2. Частые изменения и поддержка: Фронтенд и сервер обычно имеют разные требования и циклы, что может привести к сложностям с согласованием и поддержкой. 3. Проблемы производительности: В условиях высокой конкуренции запросы фронтенда могут перегружать сервер, что снижает производительность системы.Паттерн BFF решает эти проблемы, создавая специализированный серверный слой для каждого фронтенд-приложения. Каждый фронтенд может иметь один или несколько BFF-серверов, которые отвечают за удовлетворение конкретных требований фронтенда, предоставляя точные данные и функции. Эти BFF-серверы могут объединять, агрегировать или преобразовывать данные из нескольких серверов, обеспечивая более эффективную и специализированную реакцию на запросы. Преимущества использования BFF-модели включают:
Преимущества использования BFF-модели включают:
Справочная документация Spring Boot
Многоокружная конфигурация.md## Описание модулей
tomato-platform
├── spring-boot-cli-demo -- на основе maven-archetype-plugin шаблона
├── tomato-bom -- управление версиями проекта POM
└── tomato-framework -- системные общие модули
├ ├── tomato-tracing-starter -- на основе Micrometer и Zipkin распределённый трейсинг
├ ├── tomato-cloud -- компоненты для cloud
├ ├── ├── tomato-cloud-alibaba-starter -- компоненты для Alibaba
├ ├── ├── tomato-cloud-feign-starter -- зависимости для Feign
├ ├── tomato-data -- зависимости для ORM
├ ├── ├── tomato-mybatis-starter -- на основе SqlProvider улучшенный MyBatis (упрощённый)
├ ├── ├── XXXXXX -- XXXXXX
├ ├── tomato-rabbitmq-starter -- конфигурация RabbitMQ, динамические очереди, динамические производители, динамические потребители
├ └── XXXXXX
├── tomato-gateway -- модуль шлюза
├ ├── tomato-gateway-core -- основные зависимости для шлюза
├ ├── tomato-gateway-web -- система шлюза [9999]
├── XXXXXX -- XXXXXX
└── tomato-example -- примеры кода
├ └── spring-boot-tracing -- пример на основе Micrometer и Zipkin распределённого трейсинга
├ └── spring-modulith -- пример модульного приложения на Spring Boot
└── tomato-module -- бизнес-модули
├ └── tomato-module-account -- сервис учётных записей [9080]
├ ├── tomato-module-monitor -- мониторинг сервиса на основе Spring Boot Admin [9994]
├ ├── tomato-module-notice -- система уведомлений [9996]
├ ├── tomato-module-pay -- сервис платежных каналов [9998]
├ ├── tomato-module-pay-monitor -- мониторинг платежных каналов [9997]
├ └── tomato-module-reconciliation -- центр сопоставления [9995]
├ └── tomato-module-sys -- система управления сайтом (RABC) [8001]
```## Вовлечённые роли
1. Агрегатор платежей (платёжная платформа)
2. Магазин (обычный магазин, магазин-посредник)
3. Пользователь (потребитель)
4. Финансовые: третьи платежные системы (WeChat, Alipay и т.д.); банки; UnionPay
## Финансовый поток
Агрегация платежей:
Платёжный процесс:
## Система сверки счетов (Центр сверки)
В банках или у третьих сторон по платежам, сверка счетов представляет собой процесс двусторонней проверки транзакций за определенный период времени. Обычно это происходит на следующий день, когда банк или компания по платежам обрабатывает транзакции предыдущего дня, формирует отчеты для скачивания платформой, и производит расчеты с мерчантами платформы.
На следующем уровне, в отрасли интернет-финансов или электронной коммерции, сверка счетов представляет собой процесс подтверждения правильности транзакций и средств за фиксированный период времени с поставщиками платежей (банками и третьими сторонами по платежам), гарантируя согласованность транзакций и средств между сторонами.
## Система счетов
Пополнение счета:
Задачи по расписанию:- [x] Расписание пополнения счета с асинхронной обработкой: AccountTradAsyncTimer
- [x] Расписание расчета счета: AccountSettleTimer
- [x] Расписание баланса вне периода риска: AccountOutReserveBalanceTimerОсновные операции со счетами:
- [ ] Создание счета
- [x] Базовое создание
- [ ] Изменение правила генерации номера счета accountNo
- [x] Закрытие счета
- [x] Заморозка счета для приема платежей
- [x] Заморозка счета для отправки платежей
- [x] Полная заморозка счета
- [x] Разморозка счета
Тарифы на счетах: суть в расширении функциональности системы платежей, например, расчеты не имеют комиссий, а комиссии за транзакции удерживаются в системе транзакций.
- [x] Инициализация тарифов
- [ ] Изменение тарифов
Операции с транзакциями счетов:
- [x] Транзакция
- [x] Вывод средств
- [ ] Возврат средств
- [ ] Расчет
- [ ] Корректировка счета
## Система уведомлений
Основная система приема платежей:
- [x] Синхронное прием платежей, основанное на RestTemplate, повторная попытка на основе MQ
- [x] Асинхронное прием платежей, основанное на WebClient, повторная попытка на основе локальной системы.
## Система платежей
## Система агентов
## Система перевода средств
## Система заказов
## Система каналов
## Система управления рисками
## Система мерчантов
## Система распродаж
## Система товаров
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )