一提到阿里云，很多人先想到的是双11那几个小时的流量高峰，或者杭州的城市大脑。可如果把时间拨回2009年，阿里云成立时更像是一次没有太多现成答案的技术押注。这篇文章从成立背景讲起，看看早期做了哪些关键决定，以及它怎样从集团内部的基础设施，慢慢变成对外提供服务的云平台。
如果你只是想查阿里云哪一年成立，答案是2009年。不过在这个年份之前，阿里巴巴的电商业务已经大到必须换一种方式搭建系统。
成立背景：电商规模倒逼技术转型
2009年前后，阿里巴巴集团的业务增长很快，淘宝和天猫的访问量、交易量都在往上走。按照传统做法，每个业务系统各自采购服务器和存储。问题在于，流量高峰来的时候才临时加机器，平时大部分设备又闲着。钱花了不少，扩容还慢，遇到突发流量仍然吃紧。
在这种压力下，阿里巴巴决定把计算能力抽象成可以统一调度的资源池。同年，阿里云计算有限公司正式成立，由王坚担任负责人，主攻自研的分布式计算体系。思路其实很朴素：给每个业务单独搭一套系统，成本和速度都跟不上，所以先建一个通用底层平台，业务需要什么就取什么。
早期的关键决定：自研飞天系统
阿里云成立初期最重要的动作，是启动“飞天”分布式操作系统的研发。当时业界主流方案大多依赖国外开源或商业软件，阿里团队选择从底层重新设计，涵盖分布式文件系统、资源调度和计算框架等核心部分。
这个选择风险不小。自研要投入大量工程师，验证周期也长，中间很难看到明显成果。但好处同样明显：系统从一开始就按大规模、高并发的场景设计，而不是在已有架构上一点点打补丁。对后来的公共云业务来说，这种对底层的掌控力很关键，出了问题能自己定位，改起来也不用等别人的版本发布。
从内部基础设施到对外服务
阿里云并没有一开始就把所有能力开放出去。早期的主要任务是支撑集团内部的电商业务。经过几年的打磨，平台在大促场景中的稳定性逐步得到验证，对外提供服务这件事才有了底气。
对外服务时，阿里云先从中小企业和开发者入手，推出云服务器、对象存储、数据库等基础产品。比起为大型企业做定制项目，这类标准化产品更容易复制到更多客户身上。更值得一提的是，很多开发者第一次接触到“按量付费、随用随取”的使用方式，这种体验本身就在改变他们搭建系统的习惯。
两个常被提到的案例
说明阿里云的能力边界时，常会提到两个例子。
第一个是双11大促。促销开始的那一刻，交易请求会在极短时间内集中涌入。依托弹性调度，系统可以在高峰前快速扩容，结束后再释放资源。既要保证交易稳定，又不能让大量机器白白空转，这件事本身就是对云计算核心价值的一次实际检验。
第二个是杭州城市大脑。2016年前后，阿里云与杭州市政府合作，尝试利用云计算和数据分析优化城市交通信号配置。系统汇总路口的车流数据做实时调度，在部分路段有效减少了通行等待时间。它说明云计算的用处不限于企业IT，也能延伸到城市治理这类公共场景。
如果你在评估云服务，可以参考这几点
读阿里云的成立历程，对正在选云的团队也有一些实际参考。
- 别只看价格，也要问底层。确认厂商的资源调度和扩容能力是否经过高并发业务检验，并且弄清你的业务峰值通常出现在什么时候。
- 留意产品的标准化程度。标准化的云服务器、对象存储、数据库通常更容易迁移和监控，定制程度越高，后续切换的成本往往越大。
- 提前算清闲置成本。弹性计费能省钱，前提是负载有明显的波峰波谷。如果业务长期稳定运行，最好和包年包月方案对比一下再决定。
阿里云从电商集团的内部需求，走到对外提供公共云服务，这条路并不短。成立年份是2009年，但理解它，还是要看那几年围绕自研系统和内部验证做出的取舍。
