在完成核心逻辑/非核心逻辑拆分 ( 分级 ) 后，在技术评审、代码管理、容量评估、日常巡检& 监控告警、故障演练 & 应急处理，都更聚焦：
-
技术评审方面：对方案上涉及核心服务的需求，可以驱动有意识地思考核心链路是否合理；在方案审核上也终于不用担心管理端各种批处理长请求 ( 产生的大资源抢占和长垃圾回收 ) 影响到用户端稳定性，尽管由于主库仍然是共享，在更新上还是有会存在相互阻塞，但已经极大地缩小范围。
-
代码管理方面：终于从繁重的 Code Review 安排出来，每次迭代大几千行 Code Review 量，合计下来没有两三天的很难搞定，而且也只能做到蜻蜓点水看个大概！而现在能更聚焦，优先关注核心服务，根据以往几次的 CR 来看，核心服务的改动量大多是百行以内，再 MR 完之后，可以对核心服务做一次全量 Code Review，有条不紊地处理历史遗留问题、处理代码坏味道、处理潜在问题 ( 非核心接口的强依赖 )，少即是稳。同时，核心服务也可以成 ( 作 ) 为一个很好编码规范示例。
-
容量评估方面：移除大量无关代码 ( 非核心代码 ) 之后，由于代码量少、逻辑简洁清晰，无论是在评估 RT 和 QPS，还是设置线程池线程数量，基本上都能人肉估算。
-
日常巡检 & 监控告警方面：相比之前的一刀切，现在能更好的分层级关注，根据不同的优先级轻缓急地处理，更聚焦更有章法。
-
故障演练 & 应急处理方面：故障演练作为用来保证隔离效果的兜底，而一旦发现资源紧张的时候，可直接关闭非核心服务来应援核心服务。
Above all，从关注的服务数粒度来看，从原来关注 7 个 变成现在核心 3 个，效率提升约 2.3 倍左右，进一步从代码行数粒度来看，保守估计核心服务只有原服务 1/10 之一的代码，因此效率就进一步提升 10 倍。在存储资源流量上，核心流量相对非核心流量更小且更稳 ( 在存储资源的隔离，除了 DB 本身支持的 Replicate，DTS 在实现数据隔离确实很香 )。
核心服务/非核心服务划分粒度较粗，可以进一步区分 P0、P1、P2 ······，针对核心和非核心，每次迭代发布例行故障演练确保核心服务的稳定 ( P0 服务和其他服务 )，而至于 P0、P1、P2······ 递增降级的演练，由于过程更多，则可以放长演练周期。
PS：并不意味着非核心服务/低权重服务不重要，而是有不同侧重点，例如核心服务因为数量可控。很容易追求极致性能、优雅和稳定性；而对于非核心服务则主要是整体的风格和可降级。
