Python-сообщество

FishHook

Вы серьезно? Вот это вот основной критерий выбора инструмента? “Давайте будем современными”!

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

не поинтересовались наличием кадров на рынке труда

Всем привет!
Не люблю когда мои посты остаются без хотябы частичного ответа, поэтому, стремлюсь подводить их итог сам. Ответов 1-в-1 к вопросам из первого поста не будет, но надеюсь, что хоть кому-то будет полезно.

Чтобы мой пост не выглядел как просто список библиотек, мне придется немного описать компоненты системы. В данный момент, на dev-машине, проект представляет из себя несколько (не знаю как их обобщенно назвать) модулей/процессов/хостов?:

* Хост c postgres'ом 12-й версии;
* Хост с redis;
* Хост с rabbitMQ;
* Хост с Sentry;
* Хост с экземпляром CRM-системы ЗАКАЗЧИКА написанной на python-3.4. Это готовый софт заказчика с которым нужна интеграция;
* Хост со стабом прикидывающимся карточным проессингом и реализующим его API. Написан на ruby-2.1. Это готовый софт, который я взял с прошлого места работы;
* Хост со стабом прикидывающимся API QIWI. Написан на python-3.8 (Flask) разработан моей текущй командой;
* gw_proccessing - гейтвеей к API-карточного процессинга написанный на ruby-2.1. Это готовый софт, который я взял с прошлого места работы;
* gw_qiwi - гейтвеей к API аггрегатора услуг QIWI, написанный на python-3.4. Это готовый софт заказчика;
* mod_crm - модуль, который просто реализует обертку вокруг CRM'ки заказчика;
* mod_deals - модуль гарантирующий совершение сделки и отмену сделки между пользователем (mod_crm), карточным процессингом (mod_cards) и поставщиком услуги (mod_services).
* mod_cards - модуль интегрированный с процессингом (в будущем с несколькмим процессингами), оебспечивает AML-провекри при совершении пользователем оплаты картой, дает возможность привязать карту на постоянной основе к аккаунту (в mod_crm) клиента для проведения быстрых платежей.
* mod_services - осуществляет прием платежей за услуги поставщика с последуюшим начислением средств на счета поставщика. В данный момент речь идет только о бронировании/продажах билетов для мероприятий. В будущем будет реализована оплата прочих услуг, таких как: оплата за мобильную связь, оплата штрафов, комуналка. По-сути продажа чего угодно с обертками в других мобильных прложениях.
* mod_tickets - Модуль предоставляющий билеты на мероприятие, при этом он может является как владельцем билетов, если событие происходит на объектах заказчика, так и являтся шлюзом к внешней системе, если событие происходит у партнера.
* mod_events - Реестр мероприятий.
* mod_passport - управляет сессиями и выдачей прав посредством JWT. Он регулирует как уровень досутпа пользователя-человека к сервисам системы описанным в mod_api, так и регулирует уровень доступа модулей друг к другу;
* mod_api - Это единственный из mod_*, который доступен из интернета, он, как видно из названия, предоставляет API для взаимодействия с внешними системами.
* tickets_api - Это внешний модуль смотрящий только в mod_api и предоставляющий публичное API для мобилок iOS/ANdroid (Мобильное приложение пронирования билетов). Его задача предоставить только те сервисы, которые необходимы для совершения сделок по билетам;
* services_api - Это второй внешний модуль смотрящий только в mod_api и предоставляющий публичное API для мобилок iOS/Aтdroid (Мобильное приложение оплаты услуг). Его задача предоставить только те сервисы, которые необходимы для совершения сделок по услугам. Работы некоторое время велись, но этот проект, пока что, заморожен по моей просьбе. Мне удалось убедить заказчика не пытаться сделать все и сразу;

Итого: 19 компонентов, т.е. 19 докер-контейнеров. В данный момент готовы прототипы ВСЕХ компонентов.

Окружение разработчика по моему замыслу управляется посредством:
* docker/docker-compose - runtime-среда идеальная для каждого из компонентов;
* pyenv - для управления версиями python;
* poetry - для управления пакетами и их зависимостями.

При наличии docker'а Pyenv нужен просто для корректной работы poetry, а сам poetry нужен ТОЛЬКО для разрешения зависимостей. Правда в команде есть пара разрабов, которые не стали заниматься докеризацией, им для работы требуются и другие варианты использования Pyenv и poetry.

Docker-compose из коробки реализует все основные команды по запуску о остановке как всей системы, так и конкретного модуля в частности. Также для некоторых специфичных операций, таких как: заполнение БД seed-данными, либо снятие какого-то специфичного состояния БД (если вдруг надо переключиться в другую ветку для багфиксов, а затем обратно) пишутся bash-скрипты (пока что нет ни одного длинее 40-ка строк), асортимент которых растет.

Самое большое недовольство, которое я получил от команды, от такого подхода связано с неудобством дебага. Одного Sentry не достаточно, всегда есть необходимость поставить точку останова и разобраться с проблемой по факту, в месте ее возникновения. Но и тут мне удалось решить эту проблему для себя - многое от IDEшки зависит. Тем, кто использует Pycharm, я помог настроить IDE на использоание интерпритатора внутри docker-контейнеров. Теперь и я, и они дебажим просто из Pycharm, расставляя точки останова прям в IDE. Противники Pycharm создали свой альтернативный механизм запуска системы не использующий докеризацию, но вижу, что вторым шагом у них стал поиск аналогичного решения для их IDE'шек. Проблема дебага постепенно исходит на нет .

Теперь о самом стеке. Он не большой, но нарядный
* Все компоненты с префиксом mod_*, а также tickets_api и services_api реализованы на python 3.8;
* Все компоненты с префиксом mod_* реализованы с использованием событийно-ориентированного фреймворка Nameko. Этот фреймворк реализует rpc-вызовы через RabbitMQ, а также grpc-вызовы. На данный момент примерно 8 из 10 внутрисистемных вызовов являются grpc-вызовами, а 2 - rpc. Прекрасный дизайн Nameko позволяет разработчику программировать микросервисы так словно он находится в монолите, т.е. границы чувствуются минимально - очень крутой опыт для меня.
* tickets_api и services_api реализованы на Pyramid.
* mod_api также сделан на Pyramid, но также является и Nameko-based системой. Т.е. внешний мир вызвает сервисы по пирамидовскому роутингу, внутри же, в контроллерах, происходят rpc-вызовы внутренних Nameko-компонентов.
* Для работы с СУБД используется SQLAlchemy, но не ORM. От ORM отказался в пользу реализации Repository.

Спасибо за внимание.

Отредактировано ksimmi (Янв. 20, 2020 13:13:00)

> я помог настроить IDE на использоание интерпритатора внутри docker-контейнеров

А какой профит от Docker-а на машине разработчика?

Rodegast
А какой профит от Docker-а на машине разработчика?

> Поднять локально какой-нибудь сервис

Запустить к примеру PostgreSQL в Dockere-е вполне модно, но они там держат код который тестируют. Не понимаю на хрена так делать…

В моем прошлом проекте к моменту (проекту было 9 месяцев), когда я присоеденился к той команде было 7 разных способов запустить систему, в т.ч. и на Docker, но без docker-compose, и еще через 4 месяца остался только 1 и это был вариант БЕЗ контейнеризации.

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

Rodegast
> Поднять локально какой-нибудь сервисЗапустить к примеру PostgreSQL в Dockere-е вполне модно, но они там держат код который тестируют. Не понимаю на хрена так делать…

Rodegast
> Поднять локально какой-нибудь сервисЗапустить к примеру PostgreSQL в Dockere-е вполне модно, но они там держат код который тестируют. Не понимаю на хрена так делать…

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

А в чём проблема их запустить локально?

> Почему тестируемый код плохо поднимать в контейнере? Чем это хуже чем обычный запуск того же на локалхосте?

Как минимум проблемой с отладкой, с чем собственно ты и столкнулся.

ИХМО Docker это система контейнерной виртуализации, а не “запускалка сервисов”. Если нуден гибкий запуск/управление сервисами, то лучше сделать bash скрипт который будет запускать/останавливать всё что нужно.

Rodegast

Rodegast
> …Как минимум проблемой с отладкой, с чем собственно ты и столкнулся…

Rodegast
>… ИХМО Docker это система контейнерной виртуализации, а не “запускалка сервисов”. Если нуден гибкий запуск/управление сервисами, то лучше сделать bash скрипт который будет запускать/останавливать всё что нужно.

 ./debug_module.sh mod_crm

Rodegast
А в чём проблема их запустить локально?