Zimin A.N.
7d2199a3f3
Phase 4 e2e suite (skipped в local mvn verify, гонится только на CI с testcontainers) поймал 3 issues. Все исправлены, e2e теперь 20/20 PASS локально (Postgres testcontainer): - AuthE2ETest 6/6 - AutoDeriveGeometryE2ETest 6/6 - BitemporalE2ETest 4/4 - OutboxKafkaE2ETest 1/1 - SmokeE2ETest 1/1 - WebhookE2ETest 2/2 Fix #1 — Liquibase XSD ordering (0016 changeset): - <comment> должен идти ПОСЛЕ <preConditions>. Liquibase XSD строгий: preConditions → comment → operations. - "Invalid content was found starting with element preConditions" на startup → ApplicationContext fail → весь webserver не поднимается. Fix #2 — JSONB ?-operator vs JDBC parameter substitution (0016): - Postgres JDBC PreparedStatement обрабатывает любой `?` как $N placeholder. SQL "prop.value ? 'x-references'" → "prop.value $1 'x-references'" → "syntax error at or near $1". Same для regex с $ anchor. - Replaced `?` operator на эквивалент `-> 'key' IS NOT NULL`, drop-or-replace regex anchors на `LIKE '%.%'` (split_part guards malformed values gracefully). - Comment в migration документирует ловушку для будущих changesets. Fix #3 — service size cap mismatch (LineageIndexService): - CascadeCloseService.evaluatePlan вызывает findRecordDependents с size=CASCADE_MAX_PER_REQUEST=500. Но findRecordDependents enforced size 1..200 → IllegalArgumentException → 400 на DELETE record path. - Bumped service cap до 500. Controller отдельно держит public cap=200 (UI не нуждается в больше). - Test updated: expects "size 1..500". Lessons learned: - Local pre-push discipline должна включать `mvn -P e2e` для миграций. Не запустил, потому что: e2e требует Docker, медленнее, не было в routine. Now corrected — будущие migration changes будут идти через e2e check. - Liquibase JDBC рабочий принцип: SQL прогоняется через PreparedStatement → любой `?` или `$N` ловится. Documenting в migration comment. Verify: - mvn -pl ordinis-app -am -P e2e test: BUILD SUCCESS, 20/20 PASS (28s). - mvn test: 106 unit tests + 20 e2e — все green.
Ordinis
MDM сервис для НСИ ЦУОД ОДХ (Оперативное и Долговременное Хранение). Часть линейки Terravault. Ордо/порядок (от лат. ordo) — упорядоченные классификаторы и справочные данные.
ЦУОД — anchor-клиент v1, второй клиент = свой config bundle, без code change.
Maven multimodule
ordinis/
├── ordinis-domain JPA entities, JSONB types, bitemporal model
├── ordinis-validation JSON Schema validator (networknt)
├── ordinis-events-api DTO для Kafka (semver shared module)
├── ordinis-outbox Outbox pattern + @Scheduled poller
├── ordinis-rest-api Admin write API (CRUD, bundle import)
├── ordinis-app Spring Boot main: writer side
├── ordinis-read-api Read service (PG replica + scope filtering)
├── ordinis-projection-writer Опц.: Kafka → Redis projection (feature-flagged)
├── ordinis-cuod-bundle ЦУОД config: JSON Schema, seed, Grafana dashboards
└── ordinis-migrations Liquibase changelogs → Helm pre-upgrade Job (1-shot)
Стек
- Java 21, Spring Boot 3.4
- PostgreSQL 18 + PostGIS 3.6 + btree_gist (EXCLUSION CONSTRAINT)
- Apache Kafka 4.2 (KRaft, SASL SCRAM-SHA-512)
- Hibernate Envers (tx-time) + valid_from/valid_to (effective-time) — bitemporal
- Liquibase
- Spring Cloud Config + Spring Cloud Vault (Kubernetes auth)
- Micrometer + Prometheus
- LogstashEncoder JSON stdout → Loki через Alloy
- OpenTelemetry → Tempo (OTLP gRPC)
Архитектурные принципы
- Generic dictionary engine + ЦУОД config bundle (Approach B). Engine не знает про "КА"/"наземные станции" — узнаёт через JSON Schema из bundle
- Bitemporal: Envers для tx-time + valid_from/valid_to для effective-time + EXCLUSION CONSTRAINT
- 3 scope-топика Kafka (
public/internal/restricted) — изоляция через ACL, не через filter в consumer - System boundary: 3 deployable делят БД (master+replica). Внешние consumers — только REST/Kafka, никогда прямо в БД
- Tiered performance: 1k RPS из коробки (PG replica + Caffeine). 10k+ RPS включается per-dictionary через Redis projection
- Audit log в БД (compliance), технические логи в Loki
Build
mvn clean install # все модули
mvn -pl ordinis-app -am package -DskipTests # только app + transitive
docker build -f ordinis-app/Dockerfile -t ordinis-app:0.1.0 .
docker build -f ordinis-migrations/Dockerfile -t ordinis-migrations:0.1.0 ordinis-migrations/
Связанные репо
- terravault/ordinis-infra — k8s манифесты, helm values
- terravault/ordinis-config — Spring Cloud Config (feature flags, business params)