企业服务，是时候告别微服务默认选项了

一套工单系统，几百个人使用，却要启动十几个服务，配齐服务发现、配置管理和调用链监控。客户还没开始处理工单，运维已经先忙起来了。

私有化交付尤其容易暴露这个问题：用户规模缩小了，服务拓扑留了下来。业务负载不高，架构的固定开销却降不下来。

对于业务关联紧密、团队规模适中、需要兼顾 SaaS 与私有化交付的企业软件，模块化单体应当成为优先选项。 独立服务带来的扩容、发布或隔离收益，应当足以覆盖它的长期成本。

过去十几年，微服务有它成立的条件：互联网业务增长，需要多台服务器分担负载；研发团队扩大，需要独立发布；模块负载悬殊，需要分别扩容。

服务拆分随后进入企业软件的选型清单。账户、客户、权限、工单、流程，每个业务名词都容易变成一个独立进程。

但模块需要清晰的接口，独立部署需要额外的理由。这是两笔账。

今天，这笔账的基础条件已经变了。

单机能够提供的并行计算资源大幅增加。AMD EPYC 9965 提供 192 个物理核心，2026 年公布的 EPYC 9006 系列进一步给出了单路最高 256 核、512 线程的规格。原本分散在多台低配服务器上的计算负载，有了集中承载的空间。

应用通过多线程、多进程利用多核，实际吞吐仍受内存带宽、数据库、存储 I/O 和锁竞争约束。选型之前，应先测清单机容量与真实瓶颈。

数据库与存储也提供了成熟的复制、备份和故障切换能力。例如 Aurora 的存储层通过跨三个可用区的六份副本提供容错支持。应用通过数据库接口使用这些能力，内部仍可保持紧凑的模块结构。事务、租户隔离与业务正确性，则由应用团队负责。

硬件扩大了单机容量，基础设施承接了通用能力，应用层应该重新审视每一次拆分的必要性。

先看资源成本。

假设一个系统有 12 个服务，每个服务的运行时与基础内存占用按 512 MiB 估算，仅这些进程就需要约 6 GiB 内存。全部部署双副本，这部分就是约 12 GiB。这里还没有计算数据库、缓存、业务数据和其他配套组件。

实际占用随语言和实现而异，但独立进程都有运行成本。即使服务共用主机，进程、连接池和版本依赖仍然存在。

SaaS 可以通过大量租户分摊这些开销。私有化客户可能只有几十名操作人员，却仍然需要完整功能和整套依赖。

还有人的成本：安装要处理启动顺序，升级要确认版本兼容，故障要沿调用链排查。服务越多，运维越依赖自动化与团队经验，都需要持续投入。

私有化交付应该关注一个具体指标：完整业务功能的最低运行成本。 配置应贴近实际负载，尽量压低架构本身的固定开销。

再看一次操作的响应成本。

提交一张工单，通常需要校验权限、读取客户信息、检查字段、保存记录、触发流程。如果这些能力分别处于独立服务，一次操作就可能变成多次远程调用。序列化、网络传输、服务端排队和反序列化，都会进入响应时间。

串行请求耗时 ≈ 业务计算 + 数据访问 + 各次远程调用的通信与排队开销

远程调用还要处理部分失败：请求执行成功，响应却没有送达，重试就可能造成重复操作；跨服务更新执行到一半失败，又需要补偿和恢复。这些都会增加工程成本。

模块化单体让相关模块通过进程内接口协作。同一数据库事务能够覆盖的更新可以原子提交，外部通知和耗时任务按需异步执行，排障也更容易集中到查询、计算与事务等待上。

减少内部调用链上的等待，是提升响应体验的一条直接路径。 索引缺失、权限查询低效、重复取数等问题仍需逐项优化。

企业软件口中的“几万用户”，又意味着多大负载？

两万账号可能只有两千人同时操作，操作之间还有阅读和输入时间。容量规划要把人数换算成请求，再分析计算和数据访问成本。

以轻交互工单应用为例，假设每位活跃用户平均每 10 秒产生一次业务 API 请求：

2,000 人活跃在线 × 0.1 请求/秒 = 200 RPS
20,000 人活跃在线 × 0.1 请求/秒 = 2,000 RPS

页面中的多个 API、轮询与后台同步都要计入。若人均频率提高到每 2 秒一次，流量就是五倍。

按上述负载模型估算，以工单列表、详情、创建、回复和状态更新为主，读写比例设为 80:20，可以建立以下容量预算。前提是多核利用、索引与分页合理；附件、批量导入、复杂报表和 AI 推理另计资源。

表中 vCPU 使用云实例规格口径，与物理核心的对应关系取决于实例架构；Redis 数值表示内存规格。SSD 存储、文件容量、后台计算和高可用备用资源需要另行计入完整配置。

若同时活跃比例为 10%，常规私有化一档对应约 2,000～5,000 个账号，高配 SaaS 一档对应约 5 万～20 万个账号。专职坐席的在线比例与操作频率更高，应按实际工作节奏计算。

数据库还要单独算账：2,000 RPS，每次请求平均执行 5 条 SQL，就是每秒约 10,000 次 SQL 执行。主键查询与大表聚合的成本相差很大。增加应用服务器，可能只是让更多请求等待数据库。

压测应使用目标规模的数据、真实权限和工作流，覆盖完整读写路径。普通接口可先以 P95 延迟不超过 300 毫秒、错误率低于 0.1% 为目标，持续加压并观察锁等待、连接池和任务积压，再从稳定负载反推可承载人数。

当这些账算清楚，企业应用的基础结构可以非常朴素：

用户
  ↓
访问入口 / 负载均衡
  ↓
模块化业务应用（一个或多个副本）
  ├─ 关系数据库
  ├─ Redis（按需使用）
  └─ 文件存储 / 后台任务 / 专用计算（按需接入）

对于需要缓存和共享状态的常规业务，可以用“应用服务器 + 云数据库 + 云 Redis”概括核心组合。私有化环境使用对应的本地或私有云组件。需要高可用，就配置应用副本、数据库故障切换与备份恢复，并验证故障后的剩余容量。

同一个单体应用可以运行多个副本，通过负载均衡扩展应用层，前提是做好共享状态、任务协调和幂等处理。SaaS 与私有化可复用核心代码和模块边界，按负载调整配置、实例数量与租户管理方式。

统一部署要求内部结构清楚：模块有明确职责和公开接口，跨模块依赖可检查，数据修改遵守所属模块的业务规则。边界必须落实到代码中。

深流的 OpenDesk 是一个落地案例：以单体多模块组织在线会话、客户资料与工单，围绕会话转工单设计完整路径，通过字段、布局和工作流配置承接客户差异。业务能力持续扩展，交付结构仍可保持紧凑。

GPU 推理的专用资源、实时语音的延迟要求、批量分析的任务隔离，以及大型团队的独立发布，都是值得设置独立运行边界的具体理由。

架构演进应先设计好数据模型和模块接口，优化查询与事务；测出容量边界，再决定提升配置、增加副本或拆分能力。

复杂架构需要拿出可衡量的收益。 每个新增服务都应解决一个已经识别的问题。企业软件的技术进步，最终要体现为更高的资源效率、更稳定的交付，以及更少的操作等待。