Ядро платформы Маркбэйс — сервисы markbaseCORE

1) Краткое описание

markbaseCORE — выделенный контур операционных сервисов платформы: идентификация и сессии (UAM / Auth), защита периметра (Security), Billing и тарифные лимиты, Wallet (баланс), Registry (каталог модулей и маршрутизация), Scheduler (единые отложенные задачи), Monitoring, Captcha и связанные точки входа. Это не «ещё один модуль в монолите», а изолированные сервисы с собственными портами и контрактами, от которых зависят все бизнес-модули markbase.ru.

Боевой контур предполагает: единые правила company_id / мультитенантности, согласованные с публичной документацией ядра (CORESYSTEM), без обхода центральной аутентификации и без дублирования cron на стороне отдельных модулей.

2) Полный охват потребностей пользователя

Когда ядро закрывает задачу «на полную»

• Владелец бизнеса / директор видит предсказуемые расходы на платформу (Billing + Wallet), управляемые доступы (UAM), понятную карту подключённых сервисов (Registry) и отсутствие хаоса в фоновых задачах (Scheduler).
• ИБ и эксплуатация получают единый контур защиты периметра (Security), наблюдаемость (Monitoring), защиту от автоматизированного злоупотребления (Captcha) и опору для программ лояльности (Bonus) без точечных «костылей» в каждом модуле.
• Продукт и разработка опираются на стабильные контракты между сервисами: без этого любые бизнес-модули остаются хрупкими.

Помодульно (роль в экосистеме)

| Модуль | Порт (реестр) | Что закрывает для пользователя платформы целиком | |--------|----------------|---------------------------------------------------| | UAM | 8060 | Один вход, компании, сессии, при необходимости усиленная аутентификация — без второго «пользовательского сервера» у каждого модуля. | | Security | 8061 | Ограничение частоты запросов, политики IP, аудит — снижение риска компрометации API для всех клиентов Markbase. | | Monitoring | 8063 | Здоровье сервисов и метрики — основа для SLA и разборов «почему тормозит», не только для админов одного модуля. | | Registry | 8065 | Разрешение модулей и доменов — без этого мультисервисная архитектура превращается в ручное конфигурирование «кто куда ходит». | | Billing | 8069 | Тариф и лимиты как единый контур включения функций — связка с коммерческой моделью всей платформы. | | Wallet | 8070 | Движение денег по правилам экосистемы (детали — карточка «Единый кошелёк»). | | Scheduler | 8075 | Фоновые задачи без расползания cron по контейнерам — предсказуемость регламентов и биллинга. | | Captcha | 8079 | Защита форм и публичных точек входа от ботов — обязательный слой для массовых витрин. | | Bonus | 8100 | Бонусные программы и проверяемые вызовы (в т.ч. через Scheduler) — для удержания клиентов компании на платформе. |

Границы ответственности

Ядро не заменяет предметные модули (товары, заказы, производство): оно даёт идентичность, деньги по правилам платформы, каталог подключений и безопасный периметр. Бизнес-смысл всегда живёт в modouls/*.

Главные фишки

• UAM (Auth) — сессии, SSO по политике платформы, 2FA, регистрация, компании и контекст пользователя; единая точка для входа клиентских приложений и App кабинета.
• Security — rate limit, WAF-подходы, списки IP, аудит событий безопасности; снижение поверхности атаки для публичных API.
• Billing — тарифы, лимиты, подписки; целевой источник данных — выделенная БД биллинга; согласование с Wallet и модулями по событиям.
• Wallet — баланс, пополнения и списания (см. отдельную карточку «Единый кошелёк» в портфолио).
• Registry — каталог подключённых модулей, resolve/connect, привязка доменов; без Registry сложно масштабировать «плагинную» архитектуру.
• Scheduler — централизованные задания вместо разрозненных cron в каждом контейнере.
• Monitoring / Captcha / Bonus — наблюдаемость, защита форм, бонусные программы по канону ядра.

Технологический стек

• Сервисы: Node.js (типовой стек markbaseCORE), REST/внутренние контракты между модулями.
• Данные: PostgreSQL; разделение БД по доменам (auth, billing и т.д.) по мере эволюции платформы.
• Инфраструктура: Docker Compose на ядре, обратный прокси, TLS, изоляция портов (8060 UAM, 8061 Security, 8065 Registry, 8069 Billing, 8070 Wallet, 8075 Scheduler — по актуальному 00_POLNYJ_REESTR_MODULEJ).
• Интеграции: единые клиенты из modouls/_shared, без локальных копий критичных утилит.

Допущения и важные оговорки

• Домены и порты в документе — ориентир по реестру; при расхождении с деплоем истина в docker-compose и CORESYSTEM.
• Миграции биллинга на целевую схему могут поэтапно менять runtime; интерфейсы админки и модулей должны оставаться согласованными с контрактами API.
• Wallet и Billing тесно связаны, но разные ответственности: тариф/лимиты против движения денег на балансе.

Оценка стоимости

Поддержка и развитие контура ядра (несколько сервисов, HA, аудит, регресс интеграций) обычно сопоставимо с отдельной продуктовой линией.

Поддержка и эволюция ядра (год)

• Ориентир: 8–40 млн ₽/год в зависимости от SLA, числа интеграций и требований к безопасности/сертификации.

Новый изолированный сервис в контуре CORE (например, расширение Registry или Billing API)

• Ориентир: 2–12 млн ₽
• Сроки: 3–9 месяцев

Точные цифры — после фиксации объёма интеграций и политики отказоустойчивости.