Какую архитектуру проекта выбрать?

Question

[Lasha]

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

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

1. api.example.ru - API для терминалов и других систем оплат, где будет проверяться пользователь и пополняться баланс (jwt)
2. app.example.ru - API для приложения пользователей с веб для iframe (jwt)
3. web.example.ru - лендинг для пользователей с личным кабинетом
4. biz.example.ru - простой лендинг с подпиской почты
5. partner.example.ru - API для партнёрского приложения (думаю будет написано на Vue Native) (jwt)
6. console.example.ru - админская часть откуда должно всё управляться админами и операторами

Было несколько идей:
1. Линковать папки с общей логикой в проекты, но это как то не то
2. Сделать один монолитное приложенные где сервисы будут распределяться по доменам в роутах
3. Сделать один Middleware Server где будут подключаться все вышесказанные странички

Просто у меня нету опыта в больших проектах, буду рад любым советам.

Answer 1

[Macbet]

сделайте набор микросервисов и посадите их за проксик ( nginx / traefik ) для удобства можно все упаковать в докер и будет легкая доставка и легкое обновление :)

Comments

[Lasha]

это интересно, там не так много общей логики наберётся где то 10-15 классов, можно сделать один сервис только с общей логикой

но есть один нюанс вместе с данными в сервис придётся передавать IP и User-Agent пользователя чтобы знать откуда кто что

[Macbet]

cardinaltm, у nginx'а (например) есть

proxy_set_header X-Real-IP $remote_addr;

а user-agent и так будет пробрасываться

Answer 2

[Philipp]

Для всех пользователей - лендинг на www.example.com.
Все API www.example.com/api/version/whatever

Все скрывать за реверсивным прокси!

А теперь почему следует делать именно так.
Домен следует вешать на www по простой причине - субдомены кэшируются на более короткое время, а следовательно переезд будет менее болезненный.
Лендинги и дребедень делать удобнее всего внутри каталогов. Например, у вас есть ссылка www.example.com/megapartner она может быть расшарена в соц.сетях, на форумах и т.д. Это все увеличивает вес вашего домена для поисковых систем. Если вы будете использовать субдомены, то этот вес будет размываться, т.к. поисковики будут все считать разными сайтами.
Авторизация и управление пользователями должны быть унифицированы. Не стоит делать 20 разных мест, для которых надо авторизовываться по 100 раз. Для этого давно были придуманы роли. Я рекомендую сразу реализовывать вход через тот же Facebook/Google/OK/VK и т.д.
Общая авторизация дает громадное количество преимуществ, например облегчает поддержку в разы, позволяет знать контекст выполнения действий.
Один домен облегчает взаимодействие с пользователем, т.к. ему не нужно запоминать десяток разных страниц.
Ну и дополнительные плюшки реверсивного прокси заключаются в том, что всегда можно настроить редирект, что-то закэшировать, показать правильную станичку, если какой-то из сервисов отвалился.
Позади прокси следует все делить по назначению, держать каждый проект в разных репозитариях и т.д. Это может существенно упростить разработку, например можно отдать какой-то лендинг в переработку просто дав доступ к репозитарию.

Если очень хочется упороться и поиграть в девопса, разбейте на 100500 микросервисов, засуньте все внутрь кубернетиса с каким-нибудь истио. Будет красивая архитектура с контейнерами и плюшками.
Когда наиграитесь, возьмете обычный nginx, напишете конфигурацию простого реверса и он будет работать годами как часы.