编者按：小编也参加过不少技术大会，台下听到比较多的一种评论：“大师的分享很赞，不过我们这种体量的公司暂时还用不上……”，针对这种情况，小编挑选了一个发展十年的中型的电商网站 etsy，目前在 alexa 上排名 153，美国排名第 42，和国内很多电商公司流量相当。
etsy 的架构和很多成长型公司的架构非常相似，由于创始团队没有互联网开发经验，按照传统软件开发思维搭建的架构给后期扩展带来了沉重的负担；另外小编也了解到，大一点的互联网公司基本是按照职能进行分工的，RD，OP，DBA，QA 各司其职，这也是后文要谈的康威定律，也就是分工决定架构的思路的隐患。
原型：3 个工程师开发的系统
Etsy 的是手工品交易市场，网站从 2005 年 6 月开始做，由 3 人在一间公寓开发。这和很多初创型应用非常类似。
2007 年：中心化大型数据库的架构
技术栈：Ubuntu, PostgreSQL, lighttpd, PHP, Python
早期我们对互联网模式并不是特别熟悉，按照传统软件的思路，业务逻辑大多在 PostgreSQL 的存储过程中实现。前端交互使用 PHP 调用存储过程。使用大型中心化的数据库，按照业务功能分成不同的数据库。
当时的架构问题很多，可用性很差，需要定期维护窗口，意味着网站较长时间不可访问。上线部署往往会导致故障与中断。
2008 年：错误的架构决策：基于分工的架构选型
虽然过去了 2 年，依然是家创业公司，20 – 30 人。
康威定律：人力组织的架构往往决定了设计的层次。
康威定律描述了当时的现状，团队的结构：开发，DBA，运维。 开发写代码，DBA 写存储过程，运维部署代码。 团队之间由于分工形成了明显的隔阂。
为了解决架构的可扩展性问题，但也是由于受康威定律的思维局限，团队创建了一个名为 Sprouter 中间件层：存储过程路由器。这个成为后面架构沉重的包袱。
- Sprouter 是一个 Python 守护进程，处于 Web 服务器和数据库之间。前端给它传参，它调用存储过程并返回结果。从理论上讲它可以实现缓存和分片的逻辑，但这些功能当时都没有实现；
- 当时期望 Sprouter 比数据库更容易扩展，因为基于数据库存储过程的一个架构很难扩展；
- 但折衷的架构很难工作，Sprouter 在 2008 年秋天上线，但在 2009 年就被放弃，因为它几乎不能工作。
Sprouter 开发完成后依旧存在一大堆问题：
- 每次上线依赖 DBA 的工作，因为数据库所有的事情由 DBA 负责
- 上线发布更换乱，因为在 Sprouter 中，缓存了存储过程的标识符，如果进行了更新，标识符会失效。因此每次上线发布都成了一次灾难。
- 一些业务数据库仍然没有分片，这些数据库就成了系统的单点故障环节。
2008 年：Etsy 开发文化大转型
新来了 CTO（后来成为公司的 CEO） 带来了新的团队文化。
- 逐渐放弃 PostgreSQL 和存储过程；
- 使用标准 SQL 开发；
- 让开发人员接触生产环境；
- 放弃大版本大包发布的方法；
2009 年：转型中的架构：5 大改进
1. 引入 DevOps
- 打破开发和运维之间的隔阂，开发也是运维，运维也能承担开发工作；
- 打破团队隔阂：那就是信任、合作、透明以及共同承担责任；
- 我们是一条船上的人，只有互相帮助才能把东西做得更好。
2. 网站稳定性改进
- 增加及改善监控及图表。
- 授权开发人员可以访问及运行生产环境代码，以便他们能够帮助解决问题。 尽管不是所有的开发人员对生产设备开放 root 权限。
3. 实现一键式持续交付，没有独立的 QA
- 实现了持续交付。 任何工程师可以随时部署整个网站到生产环境，一键式部署，非常简单。
- 用 Chef 来做配置管理。
- 采用小迭代发布，放弃大包部署。上线如果出现问题，可以很快找出原因并立即修复。
- 上线的代码添加测试用例，以验证部署前的代码工作。
- 团队使用 IRC 随时交流。
- 没有独立的 QA 团队或流程，质量由开发负责。开发人员负责保证自己代码是稳定的，小迭代的开发模式让开发保证质量更为容易。
- 实现 A / B 测试方案，允许某个功能只开放给管理员或一定的比例用户，降低了开发人员上线风险。
- 每个开发人员都要求每年有一周来响应线上事务（on call），打破岗位之间隔阂。
4. 开发自己的 ORM，弃用 Sprouter
使用 ORM（对象关系映射）来代替 Sprouter。ORM 也是自己开发的。ORM 也实现一些缓存。前端 PHP 代码直接通过 ORM 来访问数据库。使用 ORM 将一些业务逻辑操作更多转移到前端代码，Web 服务器更容易扩展。
5. 数据库的分片扩展性改造：从 PostgreSQL 到 MySQL
由于公司新加入不少来自 Flickr 的工程师，所以逐渐引入来自 Flickr 的数据库分片方案 。
使用 MySQL 作为简单的数据存储服务器，这种架构已经在 Flickr 久经考验。数据库可以根据需要无限扩展。另外通过 MySQL 双主复制（master – master）来消除单点隐患。
2011 年春：Sprouter 下线
终于在 2011 年春天，Sprouter 从代码库中删除。
2011 年之后新的架构
- CentOS, MySQL, Apache, PHP.
- 逐步淘汰 PostreSQL。 迁移是通过一个个功能基础上的实现。
- 放弃 Python，使用 PHP 及 MySQL
2012 – 2016 年的 Etsy 架构
Etsy 一直以来都是一个看起来很有趣的平台，也有很多值得研究的地方，它从一个新型平台转型成一个稳定而值得认可的电子商务引擎。这种改变需要很多文化上的转变，但是其结果是引人注目的。
2012 年之后架构又发生了什么？他们还在创新吗？工程决策是如何决定的，而这又以怎样的方式影响了工程师文化？这一节我们要来问一问 Jon Cowie，他是 Etsy 的高级运维工程师，还是《定制 Chef》( Customizing Chef )一书的作者。
从 2012 年的升级之后就没有发生太大的改变。有些人可能会觉得无聊，但是这种情况却勾勒出了一个重要的概念，并且让我们获得了一些关于 Etsy 工程师文化的深入观察。我们在整篇文章中都会重新提到这种文化，但是接下来我们先说说他们的总体架构。
Etsy 的生产环境是采用物理机，但是开发时，他们采用虚拟化环境。这种方式让所有开发者拥有一台包含整个栈的微缩版本的虚拟机。真实的栈看起来仍然是这样：
- Linux
- Apache
- MySQL
- PHP
- Caching layers
- F5 负载均衡
他们有几个用于完成不同任务的不同高速缓存层。他们为了高速缓 存数据库对象，使用 memcached 的场景很多。
Etsy 有提供给第三方开发者的面向公众的 API，但是他们也有内部 API。他们有为这些 API 准备的缓存层，因为有些数据如果持续几个小时或几天都被人访问，就需要缓存。当然，缓存的图片和静态资产也很多。
这里的挑战在于缓存失效。一边要确保你没有把过期的脏数据提供给用户，一边却还要尽量利用缓存来减少你的数据库负载。同时还要通过把响应缓存到离终端用户足够近的地方，从而确保你对用户提供了足够快的响应。这是另一件 Etsy 团队深度关切的事，从他 们的工程博客 CodeasCraft.com 上的日常性能报告就能很明显地看出。
虽然整体架构变化不大，但是这并不意味着 Etsy 的工程师和运维 团队在这么长的时间内都坐在那里无所事事。没准有些人确实是这样，哈哈跑题了……
运维上的挑战是什么？他们是否仍然需要去灭火？
我们刚刚看到他们有多么信赖成熟和被验证过的技术，所以他们不需要花很多时间救火。新的问题通常都是通过引入新系统产生的。 我相信很多读者都有过这样的经历：你引入了一个论文中提到的新系统，这个系统会解决你的所有问题。除了它会对你现在环境中的其他组件产生一个复杂而且“不可能”的反应。所以你就必须弄明白原因是什么，以及解决问题的方法。
说实话，如果你身处这样的场景，那么这可能是一个千载难逢的机 会。这些让你抓耳挠腮的有趣挑战让你特别想把问题弄明白，然后才能去迎接下一次挑战。除非这个问题占据的时间太长，它就成了一个讨厌鬼。
为什么选型用 PHP？
另外一个很多公司都需要面对的挑战就是：想要雇佣伟大的牛人。 你在哪才能找到伟大的牛人？如果你正在使用最新最热的技术，可能你很难发现这些牛人，而且价格也会更加昂贵。如果你使用的技术十分成熟，比如 PHP，那么这件事就至少没有那么困难。当然仍然不简单，但是相对来说比寻找一个 Scala 方面的牛人要容易一些。
很多 PHP 工具都存在了十年之久，这门语言本身也是历史悠远。 很多最前沿的问题都已经被解决了。这就意味着难以解答的奇怪问题少之又少，而你又有更多的专家可以找。
这是否意味着他们从来没有对架构做过任何改变？
绝对不是。经过历史上的教训，目前对于架构选型及新技术使用有一个定义清晰的决策过程。
第一个就是“架构评审”，在这里支持者可以把支持材料和提议背后的理论说出来，然后团队就会想出一个他们认为可以适应 Etsy 现在环境的概念。
我们一起来看一下最近的一个例子。他们引入了 Kafka 来完成事件流操作。为此，团队想出了为什么要使用 Kafka 的用例，以及 Kafka 将如何解决 Etsy 上的真实问题。然后他们设立了一个架构评审，让高级工程师和所有相关方聚在一起讨论这个提议。
- 这是一种足够成熟而且被验证过的技术吗？
- 它会真正解决问题吗？它是解决问题的最佳方式吗？
- 这个组件和我们的组件在一起会有什么样的反应？
- 谁来支持这件事？
一旦这些问题得到了回答，那就可以进入架构实现阶段。
在上线之前，还需要经历另外一个被称为“上线操作评审”的流程，该流程会验证是否万事俱备。包括设立合适的监控和报警机制，以及为所有待命人员设定合适的规程等等。所有和这个实现相关的人员必须有 “做什么（What），何时做（When），如何做（How）”的计划。
另外一个重要的考虑就是“我们是否可以通过在已有的工具上进行改进来做这件事？”接下来我们将会详细地讲到这一点。
这类问题就是他们在实施一个技术提议前必须回答的问题。这种全面的分析可能需要时间，但是对于一个稳定的电子商务平台来说，正常可用时间就是黄金。
“我们非常看重我们网站的正常可用运行时间、可靠性、以及总体可操作性。”
定制化与开源
我们已经看到 Etsy 的文化是如何鼓励维持系统稳定性。但是我们没有讨论的这种文化是如何鼓励大家如何定制现有的工具。
正如刚刚看到，与其通过实施新的工具来解决问题，定制一个已经在使用的工具是更合理的做法。一个重要的例子就是定制 Chef。Jon Cowie 曾经参与了一些非常具有影响力的 Chef 定制，比如 Knife-spork。这个定制事实上来自 Etsy 团队试图解决的一个问题。当好几个开发者同时向同一个 Chef 服务器和仓库贡献变更之后，变更就被重写了。Jon 主导了这个工具的改进，他不仅帮助了开源社区，同时还解决了 Etsy 重要的限制性问题。
这也是激发 Jon 写作《定制 Chef》(Customizing Chef）一部分原因。他早就希望能完成这样一本书。
这也是 Chef 开源文化的一个好的例证。Jon 强调，Chef 的设计目的不是成为一个“一体适用”的解决方案。Chef 想要给人们提供一种能让自己解决自动化问题的工具。Chef 认为用户都是自己系统的专家，它无法告诉你该做什么，但是它给你提供工具，所以你可以自己做决定然后告诉它你想做什么。
当然，这不是说一切场合都追求定制，如果你定制了一段代码，你必须完全“拥有它”。一旦你决定开源这个工具，情况会变得更加复杂。事实上 Etsy 在决定开源工具之后马上就遇到了类似问题，他们要开源工具，开源之后往往工程师们会在本地使用一个版本，针对 Etsy 基础设施的需要编辑这个版本，然后永远都不再向主仓库回推，类似这样很多项目都不会再被更新。
一个内部项目如何判断是否适合开源？
他们是如何解决这个问题的？通过通过一个简单流程。如果一个人想要在 Etsy 开源一个项目，他需要回答几个关于这个项目的问题，包括明确该项目的维护方式。
流程帮助你确认哪些项目不会再被维护了，他们最终会仔细检查各种各样的项目，然后明确哪些项目不会再被更新了。这种做法让工程师们得以重组，并聚焦在他们真正在内部使用的工具上。
“我们设置这些流程的目的主要就是为了确保我们只开源我们自己在生产过程中活跃使用的技术。”
毕竟到了最后，如果没有人维护一个工具，这个工具对社区大概也起不到什么帮助。（小编：非常赞同，把公司已经不用的项目开源意义不大）
etsy 架构演进启示录
- 开放和信任比封闭和害怕要好得多。
- 如果你正在做的事情聪明的它可能是错的 。 如果你想扩展不采取未经检验的前端数据库的交互方式的机会。 Etsy的是一个电子商务网站，他们不发送火箭到月球。 他们在做什么不是超级争议，但它要么是并不常见。
- 每一个做出的架构决策，都将产生长久的深远的影响，即使在架构师离开公司之后的很长一段时间。
- 未来的路通常不是策划出来的，但是它会随着团队的文化逐渐成型。
通过 Etsy 团队重构及转型的观察，逐渐培养起敏捷、小团队、独立行动、松散的协作、目标驱动。中心化的文化让步于分布式的核心。
访谈内容作者：Christophe Limpalair
ScaleYourCode 主持人，ScaleYourCode 是一档致力于为专业开发者和公司传递专业知识的 Podcast 节目。本文根据其对 Jon Cowie 的采访改编，Jon Cowie 是 Etsy 的高级运维工程师。
本文访谈内容翻译李盼
原文出处——高可用架构「ArchNotes」微信公众号
本文链接：https://www.yunweipai.com/7501.html
网友评论comments