阿里云是国内规模最大的云计算服务商之一，底层架构已经演进了十多年。它最早是为阿里巴巴电商业务自用的，后来才对外提供几百款云产品。想弄清阿里云的架构，光记住几个组件名字不够，还要知道每一步为什么这样做。
从飞天到云原生，路线是怎么走过来的
早期的底座叫飞天（Apsara）。它由分布式操作系统、分布式文件系统盘古（Pangu）和分布式计算框架MaxCompute等部分组成，思路很直接：把大批廉价服务器当成一台可以统一调度的超级计算机来用。
后来容器和微服务普及，阿里云的重心转向云原生。变化主要落在三件事上：计算资源从虚拟机往容器迁，单体服务拆成微服务，运维从人工操作转向自动调度。资源利用率和迭代速度因此都有明显提升。
分层之后，职责边界清楚了
从硬件往上，整体大致分为五层：
- 基础设施层：自研服务器、数据中心、液冷，以及网络设备和光纤链路。
- 资源调度层：以飞天为核心，统一分配计算、存储和网络资源。
- 平台服务层：数据库（如PolarDB）、消息队列、缓存、大数据计算等通用能力。
- 应用开发层：容器服务、函数计算、微服务框架，帮开发者更快把应用搭起来。
- 行业解决方案层：面向金融、政务、制造等行业，提供已经过验证的组合方案。
分层的好处很实际。底层换了东西，上层应用不会直接跟着动；上层产品也能各自迭代，不必每次都去改底座。
计算与存储分开放
传统数据库通常把计算和存储绑在同一台机器上。扩容时要整体迁移数据，代价不小。PolarDB采用存储与计算分离的设计：底层是共享的分布式存储，上层计算节点按需增减，只读副本的同步延迟也能压在较低水平。
以双十一为例，大促时流量可能在短时间内涨好几倍。计算节点可以弹性扩容，存储层不用迁移数据，资源调整能在较短时间内完成，不必提前几周做容量规划。这是分离架构最直接的好处。
高并发下，一致性怎么保
交易场景里，数据一致性往往是最难处理的部分。阿里云的思路是在数据库层实现分布式事务能力，再开放给上层业务使用。开源项目Seata也源于阿里巴巴内部的分布式事务实践，提供AT、TCC、SAGA等模式，业务方可以按自身特点选择。
拿电商下单来说，订单、库存、支付三个服务要保持数据一致。传统两阶段提交的性能损耗较大。换成Seata的AT模式，很多场景下不用大改业务代码就能完成补偿，一致性和吞吐量都能兼顾。选型前，最好先梳理清楚业务里哪些环节需要人工补偿，哪些可以自动回滚。
容器调度与混部
容器服务ACK基于Kubernetes构建，调度层做了不少优化。比如混部：同一批服务器上同时跑在线业务和离线计算。在线业务多集中在白天高峰，离线任务常在夜间执行，两者错峰用资源，整体利用率因此提上来了。
混部难的地方在隔离。在线业务的响应延迟不能被离线任务拖慢，所以CPU、内存、网络都要做精细的资源隔离和优先级控制。利用率提高是好事，但前提是在线服务先稳住。
安全和稳定性是云厂商的基本功
作为云服务商，架构里的安全部分不能省。网络层靠专有网络VPC实现租户之间的逻辑隔离；数据层提供加密存储和访问审计；应用层有Web应用防火墙WAF和DDoS高防服务。
稳定性上，阿里云强调多可用区部署和容灾演练。单个机房出问题时，业务可以切换到同城或异地的其他可用区，这背后依赖的正是前面提到的存储计算分离和自动化调度。
对普通团队有什么参考
阿里云的做法对小团队也有借鉴意义，可以落到三个动作上：
- 把状态和计算拆开，服务尽量无状态化，扩缩容时才不用搬数据。
- 一致性方案做成可选项，同一个系统里，强一致的环节和最终一致的环节分开选。
- 把资源利用率纳入架构指标，而不只看功能能不能跑。
不过大部分团队用不到阿里云那种规模。中小型项目先用好托管数据库、容器服务和消息队列，通常已经够用。架构复杂度要跟业务规模匹配，照着大厂架构堆组件，往往是给自己添麻烦。
回头看，阿里云的路线更像是从自用一路走到对外通用。它先把底层资源抽象清楚，再用分层和模块化的方式交给不同规模的客户。
