企业级软件开发早已不是“能跑就行”的阶段。当系统需要支撑日均千万级请求、跨多个业务域协同、且必须满足等保与审计要求时，技术架构的选型直接决定了项目交付后的生命周期成本。万主信息科技（上海）有限公司在多年交付中形成了一套可复用的架构决策框架，以下从三个维度展开。

一、架构分层：把“变”与“不变”隔离开

我们通常将企业级系统划分为接入层、领域服务层、数据层与集成层。接入层负责协议适配与限流熔断，领域服务层按DDD边界拆分，数据层则根据读写比选择关系型或宽表方案。关键在于：领域服务层不应感知具体数据库类型，通过Repository模式保持可替换性。

• 接入层：Nginx + Spring Cloud Gateway，QPS压测基线不低于5万
• 服务层：Java 17 + Spring Boot 3，热部署与灰度发布能力必备
• 数据层：MySQL 8.0（强事务）+ ClickHouse（分析场景）

二、选型中的三个真实取舍

没有“最好”的技术，只有匹配业务节奏的决策。万主信息科技（上海）有限公司：软件开发，信息系统集成，企业数字化转型，技术咨询，互联网平台研发——这些服务背后，我们常遇到以下矛盾：

1. 自研网关 vs 云原生网关：若团队不足5人，直接用APISIX；若需深度定制鉴权逻辑，自研Kong插件更划算。
2. 单体 vs 微服务：日订单低于1万时，模块化单体（Modular Monolith）的运维成本比微服务低40%以上。
3. 消息队列：Kafka适合高吞吐日志，RocketMQ在事务消息上更成熟，RabbitMQ则胜在轻量。

三、一个制造企业的集成案例

某汽车零部件厂商需要将ERP、MES与自研质检系统打通。我们采用事件驱动架构，用Debezium捕获MySQL binlog，经Kafka Connect写入数据湖，再通过Flink做实时质量预警。上线后，质检异常响应时间从小时级降至12秒，同时满足了IATF 16949的追溯要求。

技术选型不是一次性的考试，而是持续的对齐过程。万主信息科技（上海）有限公司建议：每季度做一次架构决策记录（ADR）评审，把“为什么选A不选B”写清楚。这比任何架构图都更有长期价值。