在业务飞速发展当下，传统应对峰值手段显得老套。冗长链路、大量人工操作还有部门协作难题，促使企业寻找新对策，微博的 DCP 弹性伸缩方案就很值得研究。
传统手段困境
传统应对峰值的方式在当今业务场景下问题凸显。整个流程链路漫长，涉及众多环节。大部分操作靠人工完成，效率低且易出错。像客服业务高峰期人工处理大量咨询，错误率明显上升。而且不同部门协同困难，信息流通不畅导致时间和资源浪费，在电商大促期间供应链部门与销售部门协调难的情况很常见。
DCP 弹性伸缩方案架构
微博采用的 DCP 弹性伸缩方案架构独特。早期用物理机部署，之后化零为整建立冗余池，内部主要用私有云。2018 年就进行了架构调整来适应业务发展。建立统一设备资源管理池后，服务部署、资源调度成重点。微博把各业务冗余放共享池，业务有需求时从池里申请，提高资源利用率。
镜像分发与扩容策略
弹性伸缩多在公有云实现，阿里云上镜像请求大。微博在阿里云级联部署大量 Mirror 加快镜像分发速度。常规只需几台 Mirror，弹性扩缩容时将 Registry 横向扩容。业务扩容时按配比关系先扩 Registry 并预热镜像。做到分发速度千台规模分钟级，未来朝着 P2P 镜像拉取发展。
隔离设计挑战及应对
隔离设计涵盖平台层和部署/实例隔离。平台层隔离是一个集群对应一个部门，像微博平台、红包飞有各自大集群，内部业务再下级隔离。部署层隔离是同一业务在不同机房部署，如 Feed 业务在多个内部机房都有。底层单个节点用根容器存放业务通用部分，如系统资源监控。
管理员权限与角色
系统里管理员分超级、集群、服务池三种。超级管理员权限最大，负责整体架构和策略调整；集群管理员对特定集群进行管理；服务池管理员专注服务池相关操作。不同权限确保管理规范化、有序化。今年就明确了管理员操作规范和审核流程。
无人值守扩缩容实现
实现“无人值守”扩缩容，工具系统要自动化，各系统通过 API 打通实现联动。运维自动化监控业务和容量指标，数据给容量决策系统。“无人值守”核心是弹性伸缩、故障迁移和服务自动回收。平台提供原子型 API，业务方也能自定义。扩容时管理员向混合云平台请求，服务要外供还需接入统一负载均衡系统。
看完这篇文章，你觉得微博的 DCP 弹性伸缩方案能很好地应对流量峰值吗？不妨在评论区说说你的看法，别忘了点赞和分享本文！
