淘宝网2009年的痛

上一章提到，淘宝在08年，淘宝网的用户量已经到达8000多万（根据今天查阅的资源，需要更正一下，是9800万注册用户）。



有这么一句话，幸福和痛苦是对双胞胎，痛苦往往是伴随幸福并存。

在业务高速发展的时候，2009年的淘宝，也是有很多痛苦的地方的，甚至称得上是杯具。



在09年的时候，减去正常维护时段（发版本、提前发公告），因为以下各种问题而导致了核心业务功能不可用的总计时长是43.8小时，可以理解为亚洲最大的购物商城，因为各种问题，全年关门不营业将近2天，但水电费，员工的工资都要照付。

（1）程序bug 占比56%

  (2)   操作不当 占比15

（3）外部故障 占比14%

   剩余的是一些外部攻击、硬件故障、配置错误。

五大难题

当时候，认为遇到的难题主要有五大类：

 （1） 监测报警难：2009年的时候，APM这个领域刚起步，淘宝网那时候大规模在用zabbix，今天加这个告警，明天加那个告警，但告警误报的情况太多了。每个月发告警短信的量都很大，但大家都不怎么看，甚至屏蔽掉，到最后还专门做了告警短信成本核算统计。

（2）资源公用，互相抢夺：当时候业务发展太快，一些非核心应用本来流量不大，就和核心应用部署在同一台机器上（物理宿主机、虚拟机），结果突然非核心应用的流量突增，和核心应用抢夺资源，影响了核心应用的正常运行。

（3）流量不受控： 一开始涉及服务调用框架的时候，没考虑到太多流量控制的事情，在真的流量突增的时候，没有很优雅的方式去限流。 同时也没去真正的评估，一个业务系统上了生产后，到底能扛住多大的流量，只是说有个预估值，心里没底就多扩一些机器上去。

（4）外部环境：外部这块，主要是网络和硬件的常见问题，但由于机器实在太多了，过万台（见下图），可能是千分之一概率发生的问题，在淘宝网体量如此大的情况下，就会是常见的问题。  曾经有一年采购了一些新的硬件，因为是新产品，也没抗过淘宝网那么大的压力场景，偶发性的出现IO抖动，如果访问量少，应该根本看不出来，但采购了几百个这样的硬件，天天出问题。



（5）调用关系复杂：08-09年开始做服务化后，拆分了很多中心，各个中心直接的依赖关系，极度复杂（见下图）。这样的调用关系，已经很难靠人脑梳理出来了。很多时候刚梳理出来，过一天发个新版本的代码上去，刚梳理出来的链路图已经是过时了。



两大矛盾点

上面讲了这么多难题，也不是不想去解决。

人们常说，理想很丰满，但现实很骨感。

大概的意思是，目标和现实之间，隔着千山万水，要一步步的才能走过去。



稳定性和效率的矛盾：

（1）当运维团队想要求稳定的时候，业务团队不会给那么的时间让你去搞好各种各样的基础设施。往往是业务需求倒逼着开发团队做更多的业务逻辑，系统就越复杂。

（2）需求变多，逻辑变得复杂，改个代码胆战心惊，一上线就出问题，不上线也不行。



人才的矛盾：

（1）各个团队都是很缺人，但09年的淘宝网，薪酬体系还是比不上百度、腾讯、网易等当红炸子鸡，找不到太多好的人

（2）在稳定性这块，没有统一的平台和组织，大家都是摸着石头过河。

（3）人数跟不上，就导致代码质量差，经常出问题。



关于下一篇内容的说明

今天是挑战28天更新计划的第三天。没想到这一页PPT也写了这么多内容，也重新参阅了不少资料。

明天更新的内容，主要是围绕09年的痛，当时候淘宝网的工程师们做出的改变和努力，有技术上的，也有组织流程上的。



公开材料参考：

华黎：淘宝网架构变迁和挑战 https://www.oracle.com/technetwork/cn/community/developer-day/3-taobao-structure-457247-zhs.pdf

蒋江伟：淘宝前台系统优化实践“吞吐量优化”  https://m.open-open.com/pdf/6ca8c9e83a5d40fc97343915c6b6452e.html