WeWin.RU

    • Зарегистрироваться
    • Войти
    • Поиск
    • Категории
    • Метки
    • Непрочитанные
    • Популярные
    • Пользователи
    • Группы

    Как продумать грамотную архитектуре

    Вопросы и инструкции
    2
    2
    238
    Загружаем больше сообщений
    • Сначала старые
    • Сначала новые
    • По количеству голосов
    Ответить
    • Ответить, создав новую тему
    Авторизуйтесь, чтобы ответить
    Эта тема была удалена. Только пользователи с правом управления темами могут её видеть.
    • Z
      zybik Уважаемый отредактировано

      В общем, коротко насколько можно суть "проекта":

      Сбор событий и коэффициентов с pinnacle(а именно с одного "вида/игры" в киберспорте). И дальнейшего отслеживания изменения коэффициентов для каждого матча с заданными интервалами(то есть наступило время проверки, скрапер идет собирает информацию) до выхода в лайв(после отслеживание не ведется). Матчей не так много, линии собираются тоже не все, только основные.

      Реализовано с асинхронным подходом, но есть нюанс, работа с postgresql без специальных драйверов, поддерживающих asyncio(Все методы в DatabaseOperations помечены как async, но внутри используют синхронные операции с БД?)

      Самый малый интервал проверки 1 минута. И то за 10 или 15 минут до матча.

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

      1. Стоит ли игра свеч, чтоб переписывать код под асинхронное взаимодействие с БД?
      2. Как повлияет на масштабируемость в будущем оставление в текущем виде?
        К примеру, я хочу прикрутить статистику, которую будет собирать отдельный ботик, а также добавить отслеживание коэффициентов с пары других контор, под каждую свой ботик. (Тут кстати тоже возникает интересный вопрос, как это все грамотно совместить)

      Хочется изначально все продумать наперед, выявить узкие места и потенциальные проблемы. Но опыта скажем так, его нет. Куда копать, на что обратить внимание?
      Одна аишка советует:

      Для добавления статистики и других букмекеров я бы предложил микросервисную архитектуру:
      
      Каждый бот - отдельный процесс
      Общая база данных
      Общий конфиг
      Возможно, очередь сообщений (RabbitMQ) для коммуникации
      

      Другая:

      Каждый бот собирает данные независимо и пишет их в БД (лучше через очередь, например, Redis, Kafka или даже простую таблицу в PostgreSQL).
      Главный процесс читает и агрегирует данные по запросу или с определённой периодичностью.
      Можно использовать отдельную таблицу для кэширования актуальных данных, чтобы не нагружать базу частыми запросами.
      Redis или PostgreSQL в качестве брокера сообщений будет нормальным решением.
      
      1 ответ Последний ответ Ответить Цитировать 0
      • kvakirsanov
        kvakirsanov отредактировано kvakirsanov

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

        Если говорить о сферической задаче получения данных от разных источников, и аналитике, то хорошо в этом работает микросервисная архитектура, общая шина обмена данных вроде ampq и pub/sub модель обмена данными.

        1 ответ Последний ответ Ответить Цитировать 1
        • 1 / 1
        • Первое сообщение
          Последнее сообщение