核心业务与非核心业务隔离需系统性规划稳定性、资源控制和故障影响范围，通过物理/逻辑分组部署、依赖收敛、资源流量分级及监控告警分级实现硬隔离与应急兜底。
核心业务与非核心业务隔离不是简单地把服务拆开部署，而是围绕稳定性、资源控制和故障影响范围做系统性规划。关键在于让核心链路“扛得住、不被拖累、出问题也不扩散”。
按业务域物理或逻辑分组部署
避免核心与非核心服务混跑在同一台机器、同一容器集群或同一K8s命名空间。实际做法包括：
- 核心交易、支付、用户登录等服务独占一组高可用虚拟机或Pod节点池，配置独立的CPU配额与内存Limit
- 非核心服务如日志上报、运营后台、数据导出、邮件推送等统一归入“辅助业务集群”，使用低优先级资源池
- 若用Kubernetes，通过NodeSelector + Taint/Tolerate+ResourceQuota三者组合实现硬隔离，而非仅靠命名空间软隔离
依赖关系强制收敛与反向约束
非核心服务可以调用核心服务，但核心服务不能反向依赖非核心服务。否则隔离就失效了。具体操作：
- 在API网关层配置黑白名单：禁止核心服务IP段访问非核心服务域名
- 服务注册中心（如Nacos、Consul）中，核心服务只订阅核心分组的服务列表；非核心服务可订阅全部，但需加熔断兜底
- 代码层面引入模块依赖检查工具（如ArchUnit），在CI阶段拦截核心模块对非核心SDK的直接引用
资源与流量分级管控
隔离不只是部署分开，更要让资源分配和流量调度体现业务优先级：
- 核心业务入口（如下单接口）设置独立限流阈值，且阈值高于整体系统水位线；非核心接口限流更激进，快速失败不排队
- 数据库读写分离时，“核心读”实例（查用户余额、订单状态）与“统计读”实例（查月活、留存率）完全独立，连连接池都分开配置
- 消息队列中，核心事件（如支付成功）走专用Topic+高优先级消费者组；非核心事件（如行为埋点）走另一套低SLA保障的通道
监控告警与故障响应分级
隔离效果最终要靠可观测性验证和应急机制兜底：
- 核心业务链路单独建Dashboard，指标维度包含P99延迟、错误率、下游超时占比；非核心业务只看成功率和吞吐量
- 告警策略分级：核心服务CPU > 70%持续2分钟即触发P0级电话告警；非核心服务同指标只发企业微信通知
- 预案中明确“非核心服务全挂”属于P2事件，允许人工延迟处理；而“核心服务任意节点不可用”必须15分钟内启动主备切换
