核心业务与非核心业务隔离需系统性规划稳定性、资源控制和故障影响范围，通过物理/逻辑分组部署、依赖收敛、资源流量分级及监控告警分级实现硬隔离与应急兜底。

核心业务与非核心业务隔离不是简单地把服务拆开部署，而是围绕稳定性、资源控制和故障影响范围做系统性规划。关键在于让核心链路“扛得住、不被拖累、出问题也不扩散”。

按业务域物理或逻辑分组部署

避免核心与非核心服务混跑在同一台机器、同一容器集群或同一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分钟内启动主备切换