营销模块更新快、账务模块更新慢，服务化拆分应先看什么？

正确答案 B

题干给出的痛点是迭代节奏不同却被捆绑，且已确认职责能够分离。按业务边界与生命周期拆分，才有机会让快变模块不再被慢变模块拖住，选B。代码量相同或服务数增加，都不能直接解决这一问题。

一次促销规则调整，不应无理由地迫使稳定账务模块也重新交付。但“拆开部署”仍需配合清晰的接口约定和兼容性检查，否则两边一改接口就必须同时上线，捆绑关系只是换了个位置。教材强调服务内部高内聚、面向接口编程，目的不是把代码切得越碎越好。真实项目还需衡量调用、测试和运维成本；本题用“经评估职责可分离”限定了前提，并非推荐每个小应用都微服务化。

选项分析

A

行数能衡量代码规模，却不能代表业务职责或发布节奏，平均切分可能把一项完整业务拆散。

B

直接针对生命周期差异解除不必要的发布绑定，同时通过业务边界和接口维持职责清晰。

C

函数粒度未必对应独立业务能力，大量细碎服务可能增加协调成本，服务数量不能代替边界质量。

D

页面数量不是充分的服务边界依据，仍强制同步修改发布，也没有解除题干中的迭代牵制。

再巩固一步

• 服务化题不只数服务，要问：为什么拆、边界是否清楚、能否按各自节奏迭代、代价是否可接受。