单体还是微服务：按组织与业务选择

架构选择为什么不能只看业务规模？

规模只是输入之一，更关键的是业务边界、团队协作、发布安排和运行能力。同样的业务量可能由一个团队维护，也可能有多个团队分别负责不同域；它们需要的独立部署与故障处理方式不同。不能用企业人数或订单数字划一条未经测量的万能分界线。

先描述当前问题：是否需要不同团队独立发布，是否某类负载需要单独处理，是否跨域调用和状态难以解释。若问题来源是权限缺失、查询低效或职责不清，拆服务未必直接解决。架构方案应说明具体问题与收益，不能只用技术名词构成采购理由。

模块化单体怎样组织业务？

模块化单体将业务职责划分在同一应用中，强调公开边界、调用方向和资料归属。它不等于把所有逻辑写在一个文件，也不意味着任何模块可以随意读取其他模块内部资料。清楚的用例与契约能够让团队分别维护职责，同时使用相对集中运行和发布方式。

BoolMall已有单体装配事实是：当前单体在 单体应用 中装配 UMS、PMS、OMS、CMS；四域保留各自迁移与公开类型，共享单体数据源和本地事务管理器。 选择时继续检查实际业务、团队与环境，参照架构文档核对当前源码边界。不能从“共享事务”推导所有跨业务动作已经符合客户新规则。

微服务增加哪些独立性和协作工作？

独立服务可以按边界管理运行与发布，但跨服务调用会带来契约、延迟、未知结果和状态一致性工作。业务动作不再仅依赖一个本地调用成功，可能需要查询、重试、补偿和对账。服务拆分后的团队必须能解释失败与恢复，否则技术上分开运行，业务上仍然难以维护。

数据归属和变更通知也要同步设计。不能让多个服务长期共同写一个数据库表来绕过边界，却宣称已经获得独立演进能力。公共类型、接口版本和运行资料由明确岗位维护；日志和业务编号需要让跨服务结果可查，不只是增加更多容器仪表盘。

两种方案怎样按相同条件比较？

判断维度	模块化单体需要核对	微服务需要核对
团队协作	域职责、代码边界与共同发布	服务归属、契约与独立发布责任
业务事务	本地事务范围与跨域规则	跨服务状态、未知结果与补救
运行资料	应用、数据库和关键依赖	服务发现、网络、观察与各服务状态
性能问题	混合负载和共同资源	可拆负载与剩余共享瓶颈
数据变更	域迁移与历史保全	各服务迁移及兼容协调
故障处理	进程与业务定位、恢复计划	依赖失败、降级与跨服务核对
定制升级	定制位置及全应用回归	服务版本与调用方兼容

比较表应填写真实证据和缺失材料，不能给某种架构预设满分。资源、人员、测试和维护工作都纳入沟通；即使计划未来拆分，也要说明当前方案如何保持清楚边界，以及什么业务变化会触发进一步演进。

有瓶颈时是否应该立即拆服务？

先定位瓶颈，可能是数据库查询、存储流量、外部渠道或后台作业与消费者争用资源。应用拆分不一定改变这些共同依赖，反而可能增加数据库连接和网络调用。测量当前版本、数据和混合负载，再比较优化、资源调整或独立处理某个工作负载的方案。

不要用单接口空数据测试证明整套架构能力，也不要把源码中的体验资源限制当成生产上限。更具体的测量方法见服务器容量推导。某个场景测试通过时说明条件与未覆盖范围，不将它扩大成所有业务规模都适用。

需要独立发布时应先准备什么？

确认业务边界和公开契约，列出依赖方与兼容规则。独立发布必须让旧调用方继续有可解释结果，或有明确的同步变更安排；不能每次都要求全部服务一起更新，却把它称作完全独立。测试覆盖字段、错误、权限及历史资料，发布记录绑定真实产物。

单体版仓库保留 OpenAPI 契约，管理端和 PC 端提供依据该契约生成接口类型的命令。 契约基础有助于管理接口变化，但自动生成类型并不解决全部行为兼容。还需要版本决定、变更通知和运行验证，确定哪种变化允许先发布、哪种必须共同安排。服务边界的收益取决于这类协作是否实际建立。

跨服务业务怎样避免状态难以解释？

为业务动作设计可追踪编号，区分接收、执行、查询和最终结果。超时意味着结果可能未知，不能直接重复写入；需要按照真实语义查证后恢复。补偿也不是撤销所有历史影响，支付、发货和外部记账各有自己的后续处理规则。

如果现有业务在单体里依赖一段本地事务，拆分时先说明它如何变化、失败后怎样处理以及如何核对差异。没有对应设计时保留原边界可能更稳妥。相关恢复和对账方法见集成专题，拆分协调平台基于源码定制（¥900 / 人天），需求确认后给固定总价。

怎样以逐步演进降低不确定性？

选择边界清楚、业务影响可控且确有独立运行收益的工作负载进行验证。先建立契约与资料归属，在隔离环境检查正常和失败场景，再安排运行观察。不要同时迁移全部业务域、接口和数据库，让问题发生时无法定位哪种变化造成影响。

每一步都保留继续与停止条件，核对消费者交易、后台操作和外部协作。原系统和新组件共同存在期间，写入权威与查询范围应明确。验证无法证明目标收益时回到方案比较，而不是因为已经引入新框架就继续扩大改造。

选型结论怎样兼顾二开与交接？

说明推荐方式、当前理由、前提、定制边界、运行责任和将来的复评条件。用商城选型对比表收集业务、团队和接口资料，结合架构体检服务核对现状；已确认底座说明见系统架构页。

回到二次开发专题记录定制、预算与升级影响。架构选择不是对企业能力的等级判断，两种方式都需要真实边界、数据责任和持续维护。

组织变化以后怎样重新沟通架构？

当团队责任、发布频率或外部系统发生变化，重新核对原选择前提。原来由一个团队维护的边界，可能需要新的契约与交接；也可能只是维护职责变动而无需拆分程序。保留原决定、变化事实和验证结果，以明确的问题推动调整，不因为技术名称流行就替换已稳定的运行方案。