# Etsy Saga：从筒仓到开心到一个月的浏览量达到数十亿 > 原文： [http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html)  我们很少听到有关流行网站在其形成时期所获得的颠簸和擦伤的故事。 [Etsy 的高级软件工程师 Ross Snyder](http://ross-snyder.com/) 通过在 [Surge 2011](http://omniti.com/surge/) ：[扩展 Etsy：什么地方出错了，什么地方正确了](http://www.youtube.com/watch?v=eenrfm50mXw)。 罗斯详细而诚实地描述了 Etsy 从 2005 年的原始创业公司到 2007 年为成功而苦苦挣扎的创业公司，再到 2011 年成为普通的手工，超级缩放，ops 驱动的机器。 从这个富有启发性的变革故事中可以学到很多东西： ## 起源故事 * [Etsy](http://www.etsy.com/) 是手工制品的市场。 他们与买卖双方建立联系，类似于 eBay，他们不处理商品。 * 开始时间：2005 年 6 月， [3 个人住在一个​​公寓里](http://www.seomoz.org/web2.0/interview/etsy/2006)。 * 如今：250 名员工，每月浏览量达数十亿。 总共 6 年。 ## 2007 年–当时的架构 * Ubuntu，PostgreSQL，lighttpd，PHP，Python * PostgreSQL 存储过程中全部包含业务逻辑。 一次非常常见的体系结构。 * 前端使用包装在 PHP 中的存储过程调用与数据库进行了交互。 * 大型中央数据库，具有按功能进行分区。 分区给他们买了一些时间。 * 网站正常运行时间不是很好，这需要为电子商务网站付费。 * 定期维护窗口意味着该站点将定期关闭。 * 大爆炸软件部署通常会导致中断。 ## 2008-失败的 Sprouter 实验 * 现阶段仍是一家初创企业，最高人数为 20-30 人。 * 康威定律：当团队生产产品时，产品最终类似于生产产品的团队。 * 团队看起来像：开发人员，DBA，运营人员。 开发人员编写代码，DBA 编写存储的 proc，Ops 部署的代码。 一个筒仓组织，团队之间有很多墙。 * 为了解决其可伸缩性问题，他们创建了中间件层，称为 Sprouter-存储过程路由器。 * Sprouter 是位于 Web 服务器和数据库之间的 Python 守护程序。 给它一些参数，它调用存储过程，并返回结果。 从理论上讲，它可以进行一些缓存和分片，但是这些功能并未实现。 * 希望 Sprouter 比数据库更容易扩展，因为围绕存储过程构建的体系结构几乎是不可能的。 * 已于 08 年秋季准备就绪。自 09 年起弃用，此方法无效。 * Sprouter 仍然是一个筒仓架构，类似于他们拥有的团队。 * 由于 DBA 忙于所有数据库工作，这给开发人员带来了很多麻烦，这与时间表的依赖关系很大。 请记住，只有 DBA 才能进行数据库工作。 * 已弃用 Ops 仍必须处理依赖项。 事实证明，Sprouter 依赖于 Python 的早期版本，这意味着他们无法升级 Python。 因此，有很多运营开销。 * 由于 Sprouter 缓存了存储过程标识符（在升级期间无效），因此 Made 的部署情况更糟。 部署几乎每次都中断。 * 没有分片，数据库仍然是单点故障。 ## 2008 年-大文化转变 * [Chad Dickerson](http://blog.chaddickerson.com/) 被聘为首席技术官，后来成为首席执行官。 他带来了新的文化，以前的文化不再存在于 Etsy。 * 删除旧文化也被删除： * 致力于 PostgreSQL 和存储过程。 * 担心开发人员使用 SQL 编码。 * 通常，开发人员都不会接触该产品。 * 不频繁和大型部署是将代码移入生产环境的想法。 * 美国国立卫生研究院的一般态度。 ## 2009 年春季-前进的方式：第 1 部分 * DevOps 救援 * DevOps 是同时也是工程师和 Ops 的 Ops 人员。 * 筒仓变坏了。 * 信任，合作，透明和共同承担责任变得良好。 * 我们在一起。 让我们互相帮助，共同完成任务。 * 稳定网站： * **安装/改进指标并监视**。 * 尽可能垂直升级数据库。 还是不够，但是买了一些呼吸的空间。 * 使开发人员生产**访问正在运行的代码**，以便他们可以帮助解决问题。 开发了一个名为 [StatsD](https://github.com/etsy/statsd) 的工具。 虽然并非所有开发人员都扎根于生产机器。 ## 持续部署-前进的方向：第 2 部分 * 添加了**连续部署**。 Etsy 中的任何工程师都可以随时将整个站点部署到生产中。 每天发生 25 次，因为它很容易。 这是**一键部署**。 * 开发了一个名为 [Deployinator](https://github.com/etsy/deployinator) 的工具。 **Chef** 用于配置管理。 * 最大的收获是，**小更改集**一直在淘汰，而不是大规模部署。 如果出现问题，他们可以迅速找出问题所在并加以解决。 * 添加了对代码运行的测试，以在部署之前验证代码是否正常运行。 * 小组**始终在 **IRC** 上与彼此**进行交谈。 * **质量检查由开发人员**执行。 在此过程中，没有单独的质量检查小组或阶段。 开发人员负责确保代码可靠。 较小的变更集使此操作变得容易。 * 在持续不断的部署过程中，数据库架构更改是异常的。 他们每周有一天，即**模式更改日**。 功能标志用于打开和关闭功能，因此它们可以翻转标志，并且架构在适当的位置可以打开标志。 * A / B 测试方案允许仅为管理员打开功能或将其发布给一定比例的用户。 他们创建一个**功能标记**，提交一堆代码，然后打开该标记，以便只有开发人员才能看到它。 * 每年的一周内，每个开发人员都在寻求**支持。 他们将在假期前后加倍。 Ops 有自己的轮换方式，因此开发人员和 Ops 总是随时待命。** ## 2009 年春季-Sprouter 之死-前进的方向：第 3 部分 * 使用**对象关系映射器**绕过 Sprouter。 他们写了自己的。 * 现在（再次），前端 PHP 代码通过 ORM 直接与数据库对话。 * 使用 ORM 将一些工作转移到了易于扩展的 Web 服务器上。 * ORM 进行一些前端缓存。 * ORM 是一个臭名昭著的瓶颈，但还没有解决这个问题，但他们意识到了这一潜力。 ## 分片的到来-前进的方向：第 4 部分 * 在 Sprouter 被中和后，数据库仍然是单点故障。 * 由于 **Flickr** 的很多人都去了 Etsy，因此他们采用了 Flickr 的[分片方案。](http://highscalability.com/flickr-architecture) * 基于 **MySQL** 作为简单的数据存储。 **经过 Flickr 的战斗测试**。 * 将数据库**沿水平方向**缩放到无穷远甚至更大。 * **主-主**复制用于删除 SPOF。 ## 2011 年春季-关闭 Sprouter * Sprouter 使用停止所有策略释放。 当人们在基础架构上工作时，功能开发几乎停止了，大型部署在您的面前爆炸了。 * 为了证明文化是如何发生变化的，有几个人在一边进行 Sprouter 的替换，然后他们**逐渐逐步使用**。 即使他们愿意，他们也不能只专注于 Sprouter。 * 终于在 2011 年春季，从代码库中删除了 Sprouter。 ## 2011-现在的 Etsy 体系结构 * CentOS，MySQL，Apache，PHP。 * **逐步淘汰 PostreSQL** 。 仍然没有完成。 迁移基于每个功能。 * **Python 不见了**。 他们需要让人们参与进来，以便在 PHP 和 MySQL 上实现标准化。 ## 获得的经验教训 * **开放和信任**比封闭和恐惧好得多。 * 如果您聪明地执行**，则可能是错误的**。 如果您打算扩展规模，请不要冒险使用未经测试的前端到数据库交互方法。 Etsy 是一个电子商务网站，他们没有向月球发射火箭。 他们在做什么并没有那么大的争议，但这也不是那么普遍。 * 在您离开后很长时间，今天做出的架构决策将产生重大影响。 * 没有漏洞那么深，以至于可靠的缩放策略无法将您排除在外。 * 没有前进的道路。 没有计划。 在文化转变开始后的几年中，这种情况逐渐发生。 尽管 Etsy 并未完全履行其 NIH 承诺，但由于他们自己构建了大多数内容，因此有关团队结构如何决定软件结构的文化/团队观察是一个深刻的问题。 [如上，](http://en.wikipedia.org/wiki/Hermeticism)以下，古人举行了会议。 在实践中如此清晰地看到它是很了不起的。 有趣的是，我们在网络开发团队中看到的全面变革-敏捷，叛乱，小组，独立行动，松散协调，目标驱动-与[第四代战争](http://en.wikipedia.org/wiki/Fourth_generation_warfare)的战斗策略和战术平行 。 我们看到集中化让位于分布式核心。 似乎复杂的不断变化的景观触发了并行的演变。 ## 相关文章 * [Etsy 博客](http://codeascraft.etsy.com/) * [Flickr 架构](http://highscalability.com/flickr-architecture) * [优化开发人员的幸福感](http://codeascraft.etsy.com/2011/06/06/optimizing-for-developer-happiness/) * [推送：Facebook，Flickr，Etsy](http://codeascraft.etsy.com/2011/06/01/pushing-facebook-flickr-etsy/) * [不断变化的战争面孔：进入第四代](http://globalguerrillas.typepad.com/lind/the-changing-face-of-war-into-the-fourth-generation.html) 我很好奇要了解有关为什么分片 PostgreSQL 在 2011 年不如分片 MySQL 来证明引入第二个数据库系统的理由的更多详细信息吗？ 我不知道 PostgreSQL 是否有问题，因为 Flickr 系统是建立在 MySQL 之上的，因此这显然是实现其方案的选择。 Etsy 工程团队还有一个博客，标题为“ Code as Craft”。 = > http://codeascraft.etsy.com 你好 我想知道 postgres 是否不适用于可扩展性高的网站。 谢谢 tan 有趣的是有人从 python 转向 php。