技术架构演进的三次飞跃：分布式、异地多活、统一资源调度（毕玄演讲整理）
此文是我在之前公司参与内部课程时做的笔记，讲师是毕玄老师。他结合自己亲历的经验，分享了技术架构在三个重要阶段的重大演进过程。我最近重新梳理了一下这些笔记，觉得其中的内容对当前的工作和技术实践仍有非常大的参考价值，因此整理成文，分享给大家。
一、第一次演进：从单体到分布式（2007-2009 年）
2007 年左右，业务快速增长，单体架构开始出现瓶颈，主要体现为：
- 用户快速增长带来的系统扩展压力；
- 业务复杂化带来的研发效能下降。
如何解决？毕玄分享的方案是拆分系统为分布式架构，将原本集中在一起的业务功能拆解成相对独立的领域服务，推动研发组织结构同步调整。这次拆分的关键是服务拆分粒度的控制，不能太细也不能太粗：
- 粗粒度拆分：按业务领域进行服务化，例如用户中心、交易中心独立出来。
- 为此也开发了大量的基础组件，比如：
- 同步交互的服务框架
- 异步交互的消息中间件
- 数据库分布式数据中间件
- 分布式缓存与文件系统
在此过程中，毕玄强调了一个特别重要的事情：分布式系统不是简单的拆分，而是需要扎实的基础设施与治理体系。
这个架构演进历时 3 年左右：
- 2007 年：「千岛湖项目」启动，拆出用户中心；
- 2008 年：「交易中心项目」上线，拆出交易模块；
- 2009 年：「五彩石项目」完成，融合淘宝和淘宝商城的技术架构。
演进成果：
- 实现了后续业务爆发式扩展，“加机器”就能解决绝大多数规模问题；
- 研发团队规模可以并行扩展至千人以上。
经验教训：
- 分布式架构必须重视基础设施建设（如 Tracing）；
- 服务拆分粒度、同步/异步交互比例如何确定非常主观，难度也很大，需要花多年填坑。
二、第二次演进：异地多活架构（2013 年后）
2013 年，单一机房模式遭遇性能瓶颈和灾备风险，「异地多活」方案提上日程。
所谓「异地多活」指的是：
业务同时部署在三个或以上、距离超过 1000 公里的机房，每个机房都承担业务流量，可随时灵活切换。
听起来简单，但最大的难题是跨机房的物理延时。特别是电商场景，交易、库存数据的强一致性要求，成为跨机房协作的巨大障碍。
解决这个难题的策略是：尽可能减少跨机房交互，具体做法是：
- 按用户维度进行流量与数据拆分（买家/卖家、商品维度）；
- 改动涉及全部基础组件和业务 API，以用户维度隔离读写数据；
- 必要时，牺牲少许可用性换取整体一致性。
异地多活的巨大工作量，换来了长期的成果：
- 提升了整体机房级的伸缩性；
- 提高了系统整体的高可用性；
- 为后续构建混合云与大促场景提供了技术底座；
- 加速了基础组件与架构迭代。
但毕玄也坦言，异地多活存在扩展性局限，未来还需持续迭代。
三、第三次演进：统一资源调度（2011 年起，大规模落地于 2016 年）
2011 年前后，毕玄团队敏锐发现服务器成本将成为未来制约公司发展的重大挑战，到 2015 年已经无法忽视，尤其大数据资源的成本暴增。
为此提出了统一资源调度方案：
第一阶段（2011-2015 年）：
- 受虚拟化内存超卖限制，团队自研容器化方案（T4），Docker 出现后，逐步融合。
第二阶段（2016 年后）：
借鉴 Google 的 Borg 系统（但相差 20%-30%），将大数据任务与在线业务合并调度到同一批机器，最大化利用在线业务的闲置资源。
推动机房选址，建设跨域大机房，解决跨域带宽问题；
通过计算存储分离，解决在线业务机器硬盘容量不足问题；
通过内核级 QoS 解决资源干扰。
这次架构调整极大降低了服务器成本：
- 每年节省服务器成本上亿级别；
- 推动了大机房建设、网络优化、计算存储分离与内核级 QoS 等基础技术发展。
同时毕玄也分享了宝贵经验：技术演进一定要对「天花板」有清晰的概念，尤其是向学术界与工业界的前沿探索。
我的收获与反思
毕玄分享的三次技术演进过程，不只是解决了业务上的难题，更重要的是建立了一个不断迭代和进化的架构思维：
- 从分布式拆分的基础设施与组织协调；
- 到异地多活带来的数据架构革新与高可用性；
- 再到统一资源调度带来的技术经济性和效率优化。
根据我的理解，Google 从最初设计服务器架构时，就已经采用了天然分布式和容灾的设计思想。
wechat
alipay