32、微服务的适用场景与决策之道

微服务的适用场景与决策之道

1. 何时不应使用微服务

在技术选型的过程中，微服务并非适用于所有场景。以下几种情况，需要谨慎考虑是否采用微服务架构。

1.1 对领域理解不足

如果对业务领域的理解不够深入，那么很难为服务找到合适的边界上下文。服务边界划分错误可能会导致服务间协作时需要进行大量更改，这是一项成本高昂的操作。因此，当面对一个不熟悉业务领域的单体系统时，建议先花时间了解系统的功能，再确定清晰的模块边界，之后再进行服务拆分。具体步骤如下：
1. 学习系统功能：了解系统的整体业务流程和各个模块的功能。
2. 确定模块边界：根据对系统的理解，找出各个模块之间的边界。
3. 拆分服务：在确定模块边界后，逐步将系统拆分为多个微服务。

1.2 绿地开发项目

绿地开发项目通常意味着要面对全新的业务领域，而且相比于对已有系统进行拆分，从头开始构建微服务架构更为困难。因此，建议先采用单体架构进行开发，待系统稳定后再进行拆分。具体步骤如下：
1. 采用单体架构开发：快速搭建系统原型，验证业务需求。
2. 系统稳定后评估：在系统稳定运行一段时间后，评估是否需要将其拆分为微服务。
3. 逐步拆分服务：根据评估结果，逐步将单体系统拆分为多个微服务。

1.3 大规模场景下的挑战

随着服务数量的增加，微服务面临的挑战也会加剧。手动操作在服务数量较少时可能可行，但当服务数量增加到 5 个或 10 个时，就会变得困难。传统的监控方式，如仅关注 CPU 和内存统计信息，在服务数量较少时可能有效，但随着服务间协作的增多，这种方式会变得越来越痛苦。因此，在采用微服