Multi-service deployment

xly is not a single Spring Boot WAR — it's a small constellation of independently runnable services that share a database, share the metadata layer, and communicate through JMS.

The runnable services

Service	Module	Role	Default port (dev profile)
xlyEntry	xlyEntry/	Main back-end runtime + the framework's own admin (BACK). Hosts BusinessBaseController and the /business/* API.	8080 (dev), 8597 (deployed dev)
xlyApi	xlyApi/	Web-facing UI WAR — static assets + Thymeleaf templates + browser-facing endpoints. Different context-path.	8080 with context /xlyApi (dev)
xlyInterface	xlyInterface/	External-integration service — third-party APIs, webhooks, file imports.	configured per environment
xlyPlc	xlyPlc/	Shop-floor PLC bridge (Slice 6).	one per press-model deployment
xlyFace	xlyFace/	Face-recognition (ArcSoft SDK). Niche; commented-out for many deployments.	configured per environment

Each has its own application.yml + several application-<profile>.yml files. The active profile is selected at startup via -Dspring.profiles.active=….

Disabled in settings.gradle

//include 'xlyErpTask'
//include 'xlyRxtx'
//include 'xlyFile'

Three modules are present on disk but excluded from the active build:

• xlyErpTask — long-running background tasks. Disabled likely because the same scheduling now runs inside xlyEntry / xlyFlow via Quartz.
• xlyRxtx — native serial-port library. Disabled when xlyPlc doesn't need direct serial access (some press models use TCP/Ethernet instead).
• xlyFile — older file-management module, superseded by Aliyun OSS integration in xlyPlatFileUpload.

A maintainer cleaning up the codebase should consider whether to delete these or keep them as historical reference. They take up disk space but do not affect the build.

Plat* family

The xlyPlat* modules (xlyPlatMerchantController, xlyPlatUserService, xlyPlatPayService, xlyPlatMarketingService, xlyPlatCainiaoWaybillSevice, xlyPlatSmsService, xlyPlatReportForm, xlyPlatFileUpload, xlyPlatJmsConsumer/Productor, xlyPlatTask, xlyPlatWebsocket, xlyPlatConstant) are the B2B printing-platform layer — out-of-scope for this wiki. The plat_* tables those modules write to are empty in this dev DB; see the recon report's §5.

How services find each other

Three communication channels:

1. Shared database — every service reads/writes the same MySQL schema. Most cross-service "communication" is implicit through shared tables.
2. JMS (ActiveMQ + RocketMQ) — fanout for events that affect multiple services. Cache invalidation (cache invalidation on metadata change) uses this channel.
3. HTTP REST — for synchronous calls (e.g., xlyApi calling xlyEntry's /business/* endpoints).

There is no service registry / discovery mechanism beyond the application-<profile>.yml files, which hardcode peer URLs per environment.

URL routing in deployed environments

The dev URLs http://118.178.19.35:8597 (BACK) and http://118.178.19.35:8598 (FROUNT) suggest:

• 8597 is xlyEntry with context /xlyEntry/ (confirmed observed from network traces in Slice 1).
• 8598 is likely xlyApi or another front-of-house service.

Both are likely behind an nginx / reverse proxy in production, with URL paths cross-routed based on path or hostname. The exact routing config lives in the deployment environment, not the codebase.

Profile permutations

application-saas.yml, application-linux.yml, application-win.yml, application-15S.yml, application-S10.yml, application-pro.yml, application-T0.yml, application-T1.yml, … cover combinations of:

• Operating system (linux / win)
• Customer category (saas, 15S, S10, …)
• Environment (dev, pro)
• Press-model (for xlyPlc)

A given deployment selects exactly one profile per service. The mapping from "this customer" → "these profiles" lives in deployment ops documentation, not the codebase.

Open: production URL routing

The exact nginx / reverse-proxy config that maps 8597 / 8598 to context-paths and back-ends would be useful here. It's not in the codebase repo — it lives with the deployment scripts. A maintainer chapter to add when those scripts are available.