本文讲的是Etsy 技术 VP 谈架构：微服务，单体应用和激光射钉枪？Etsy 在寻找正确的焦点， 【编者的话】 Etsy 是美国一个在线销售手工工艺品的网站，网站集聚了一大批极富影响力和号召力的手工艺术品设计师。在 Etsy，人们可以开店，销售自己的手工艺品，模式类似eBay和中国的淘宝。本文讨论了为什么关注点在“微服务“或“单体应用”的标签会干扰思考；Etsy 是如何演进它的技术架构以保证业务发展。

John Allspaw一直从事Web相关工作，曾经在Salon、Friendster和 Flickr任职。在最近的五年里，他在著名的电商网站Etsy工作，职位是运维和基础设施VP。在微服务理念盛行的今天，Etsy一直坚持使用单体应用架构（monolithic）。

Etsy 的架构随便你称呼，但它确实能行得通

SCALE（人名，记者）：我并不是非常了解Etsy的架构，但它也是我知道的为数不多的单体架构，可以这么说吧？

JOHN ALLSPAW：  呵呵，有意思。关于微服务和单体应用架构的定义其实并不清楚。我敢打赌你去找上几百个专家，然后去问他们某个架构图属于哪个结构，你一定会得到不同的答案。哈哈，在几周前的Velocity大会上，这个事已经得到验证。Etsy是单体架构还是SOA架构，或者是微服务架构，这决定于你问谁。说实话，我觉得这个问题的讨论对我来说真是个干扰。

你能细说下为什么这是个干扰吗？

有很多原因。第一，没必要把架构非要划分成两大阵营。我想做过可扩展性系统的人都应该知道，提架构是需要有上下文背景（context-specific）的。

例如，我一个好朋友正在构建一个电子交易系统。你可以想象设计电子交易系统的目标和限制条件，这是和Facebook不同的。Facebook可能又因限制条件和Amazon在架构上不同，Amazon甚至会和（同类的）Etsy不同。

如果你的关注焦点是『是微服务还是单体应用』，那就已经忽略了上下文背景，思考问题的方式也就错了。

“Etsy 跑着不同的语言程序，但就内部 API 和 WEB 应用来说，大部分是 PHP。这有很多很多好处”

我总是看到有人说“那么，我们从微服务架构看，这就是我们这么做的原因”。你会在看到它如何架构前绕很大一圈。你让他们用白板或者展示一个图--不是概念图，而是用例图，然后你回过头会说“这不是我想象中的微服务的样子”

你在架构上谈了多少？你真的修复你关于定义的误解了吗？我觉得这太抽象了。接近很容易，但不算具体规定。微服务的优劣，单体应用的优劣都是上下文特定的，所以我愿意跳过抽象，从具体问题分析。

听上去你更在意完成工作而不是它是如何完成的
我是说通常话题在于架构选型。依据组织机构的决策作为上下文去讨论会更好。通常人们会搬出 康威定律  去决定走向某方向而不是其他。这没问题，但中间有很多故事而不单单是康威那两个字儿。
一个有名的 PPT 关于 Etcy 的软件开发  

好吧，但为什么人们总说 Etsy 的架构 “哦，这是个单体应用架构。”并且不管如何，什么是 Etsy 业务正确的选型？

很多场合我们讨论的问题之一是，我们想要利用相对有限的常用工具的优势（去做架构）。例如，PHP是否是大部分 web 应用最合适的语言？几乎可以确定不是。能找出另外更优的语言吗？当然。

用最优解而不过度用同样的语言有细微的差别。Etsy 有其他语言应用，但内部 API 和 WEB 应用而言，大部分是 PHP。这有很多很多好处。

同样，用默认的存储 MySQL也有巨大好处。这是存储收藏或列表数据的合适的数据存储吗？这是存储商店统计最合适的数据存储吗？几乎可确定不是。但把数据存储在共享--我们叫它共享，同盟，分布式--数据存储有很多优势。

如果默认是 MySQL，我们可获得所有的好处。这意味着工程师可以穿梭不同团队，不需要重新学习一切。

如果你想把其他人开发的特性集成到你的工作，因为都是同样的编程模式，你可以检查和分析他人的代码。数据也大致存放在同个位置。

我想可以类比下 Google，用 BigTable 作为它的数据存储做同样的事情。我不认为你会说“我不相信 Google 是这么单体化”。

如果你合理考虑网站技术基础设施的演进，会有显而易见的事件在演进中发生。你会把关系数据库上的工作演进到分布式中

理解，而不是避免前沿
你提到了 MySQL。Facebook和其他公司以高扩展 MySQL出名，但 Etsy 并不是个小服务。随着公司发展扩展数据库层是否是个脏活？

可以从不同角度分析。如果你合理考虑网站技术基础设施的演进，会有显而易见的事件在演进中发生。你会把关系数据库上的工作演进到分布式中，或者不。从更高层次上公平地说，在跨 MySQL 服务器联合数据上，我们和 Facebook 做的事情一样。

这只和架构模式有关系。例如，不是把所有 Etsy 的数据放在一个数据库中，人们通常会这样 “好，现在取出我们的收藏，列表和用户资料。那么，我们会一个库放用户资料，一个库放收藏，一个库放列表。”

这种功能性的分库也有一个过期日期。然后你要立即改造，让我们可以跨海量机器存储 Etsy 的主要数据，然后我们可以在机器间达到负载均衡。

这些都不是 MySQL 特定的。当然会有一些技巧和窍门。你将要按你的期望去备份任务。你必须在应用程序中做额外的工作，比如找到存储特定数据的数据库服务器。

不过，这仍然真的只是一种架构模式。到达这一点，你就可以使用数据库作为一个合理的数据存储。这是你想要的：真正稳定，真正可靠。所有其他的杠杆，你也会添加在你的应用中。

这真的可以是其他数据库。MySQL 没有什么特别的。

“我们要为一个总是有东西出错的世界做规划。我们想做的是，当事情出错时，它们影响很小。”

你提到使用这套常用工具，可以处理各种各样的业务。但在 Etsy 有什么例子你可以称之为新的或尖端或下一代的技术？
我会更详细的描述它。我想说，我们希望有一个小数目的常用工具。…

如果我发现自己试着用锤子把螺丝钉拧下来，那么很可能是我该思考的时候，“好吧，这一努力是不值得的。我需要一把螺丝刀。”说到这，这也不意味着我有1000把锤子 -- 一个敲大理石，一个敲木材，一个敲石膏。

它不是像一个法令，“这些是被祝福的工具，所有其他的事情都是被禁止的。”

相反，我们所做的是过程方式，或在很大程度上，我们辨认偏离常态的用例。一位工程师说，“这个问题我不认为可以用 PHP ，MySQL 和 Linux 解决……或 Hadoop 或Lucene 或什么的。

“这是我的尝试。我尝试用那么东西，结果他们失败了，我不认为他们足够好。我不想用新技术，至少在没有好的理由前提下不用”

“所以，大家，我的工程伙伴，有没有有更好主意的？我想我了解了这个软件新模块。我想在我使用前，确定下大家都知道我们最终都会熟练使用它的”

我需要真的对解决难题有热情的工匠，给他们和这些说“我不在乎我在建造什么。我只需要使用激光射钉枪。”的候选人机会。

Redis - 这是数年前 - 是那些尝试之一。Elasticsearch一直是新尝试之一。共享的Solr是一个。我们大约有一半的搜索存储在Solr，一半是ElasticSearch。有一些不同的存储引擎，作为与 MySQL 的不同。

事情是，当你把新东西从架子上拿下来时，会有操作的开销。如果它出错了，你是唯一知道它是如何工作的人，那么它可能不是一个好的技术选择。如果你是为理想状况做打算，它可以是一个非常好的技术选择。我们不想为一个理想状况做计划。

我们要为一个总是有东西出错的世界做规划。我们想做的是，当事情出错时，它们影响很小，他们并不关键。它们出错，我们可以修复他们，我们可以自适应，有弹性。

我们做法之一就是批判性地看一下我们的选择。我们不需要出于很好含义和意图的选择，但需要非常热情的工程师，他不认为一切都行得通。没有一个工程师会想到所有的意外事件。这就是为什么我们需要多种看法。

然后，当我们说：“好吧，就是它。Redis -- 我们要去使用它。我们要在这里用它。用在这里比较好，” 然后我们会更熟练使用它，这意味着我们收获了更多的信心。

另一个 Etsy 用到的新工具是 HipHop 虚拟机，Facebook 创造的提高 PHP 性能的工具。来源： Code as Craft

我一直听到的一件事是，当谈到雇用，人们喜欢知道他们将开始用新技术工作。Esty 确实是这样雇用员工的，如果前景不需要考虑，“是的，我会在在未来三个月用 Golang 做开发！“

某种程度上我是这样想的：如果我雇用木匠盖房子，将用传统方式。我想让木匠因为房子的设计和挑战而高兴。我们必须在悬崖边上建造这座博物馆。

我需要真的对解决难题有热情的工匠，给他们和这些候选人机会。他们会说“我不在乎我在建造什么。我只需要使用激光射钉枪。我不在乎它是厕所。我不在乎这是不是一个谷仓。”

这些工程师将有更多的认知空间。他们也会在解决问题上有更多的关注，而不是限定在一份特定保险。歌比吉他更重要。

但这并没有说，你不能用能很合适解决特定问题的工具。事实上，我们写了很多自己的工具，因为我们无法找到真正适合我们用例的工具。

事实上，真正的难题在这里 —- 难以置信的工程问题，实际上跟任何工具无关。他们只是难题。

我们最近一直在谈论的一个最出名的事情就是推荐系统。我们不是常规的电子商务网站。我们有数以百万计的独特的东西，而不是一个非常小的确定门类。

这就像一个长长的尾巴。

这基本上都是长尾。我们可以说。我们的数据科学和工程团队……他们不想花更多的时间在他们的工具上，因为他们想解决问题。当世界上只有一个东西时，你建议一个人买什么东西？就是这回事。

“像很多公司一样决定使用裸机，我们只是把这个变得有效率。我们只是榨干裸机的性能”

速度重要，所以硬件重要

在 Etsy ，核心基础设施是怎样的，网站是建立在什么形式上？我最近读到是你大部分跑在自己的硬件上

在一个高层面上，在服务器容量前提下，我们主要是这样，但不是全部。我们仍然使用托管设施之类的东西。不得不说的是，为了简易存储长尾图像库，我们成为亚马逊的S3的重度用户。我们要使用各种技巧隔绝亚马逊或S3的可能出的问题。
大体上，我们自己运维服务器。我们有一个很小但很有效的数据中心团队。我们尽可能在所有安全的方式做到确保部署和配置的自动化。

我们在硬件选择上写了很多博客文章。我们也总结了很多我们的大数据技术栈的博客文章。

这是值得一提的一件事。很多人 -- 包括我们 -- 当在需要的时候是用 AWS 的弹性 MapReduce 来做大量的分析工作。但是随着时间的推移，我们业务有效地增长。我们将通过在一个新的集群上进行更高效的工作。这种模式已经固化了几年了。我们很满意这点。它行得通，它相当不错。

像很多公司一样决定使用裸机，我们只是把这个变得有效率。我们只是榨干裸机的性能。我们很好地确保工作负载是适当的。

请记住，我们不是新闻网站。实例的加速和减速对我们来说影响不大。我们可以从裸机中获得更多的好处，而不是将我们的基础设施移到云端。

当你谈论效率，是指成本控制，性能还是控制方面？
很大程度上是关于速度更快。我们可以获利更多。它有助于 PHP 开发者在公司的工作，我来给你个例子。我们可以在单一节点的基础上做开发，而不是与通用平台即服务供应商打交道。
我们会定期做这道数学，试着从财务角度看，是否使用云计算会更有效。再以次，我想是因为我们的任务负载是合理的，我们只是做了一些简单的老式容量规划，这样仍然可行。

服务端性能季度统计－来源： Code as Craft

为什么业务问题会支配技术选型

比较 Etsy 和其他一些你工作过的地方。举例来说，我已经注意到一个常规基础点，Etsy 会每年更新其统计数据，讨论它的运行时长，页面加载速度和其他指标。这是否与 Etsy 用户的期望有关？

我想说，答案是它有与用户期望激动人心的不同点。

拿 Flickr 来说，有许多不同点会改变网站用户的期望。在 Flickr ，你有内容生产者 -- 拍照的人。然后是浏览照片的人。而这两部分用户的交集在 Etsy 是接近1：1的，如果你从买方和卖方的角度去看。

如果你是一个卖家在 Etsy，上传照片和罗列商品是非常长的活动，需要明确的流程和正常运行。至于容错性而言，最好是秘密性故障，而不是公开性故障。

我什么意思？如果我列出销售表，有一大堆内容：我会给出描述，标题，材料，我要告诉你我在哪儿发货，我要告诉你我商店的政策，诸如此类的事情。

这与“我要上传照片。”完全不同。上传要么成功要么失败。当您上传在Flickr上的照片，你不必检查。你上传就上传了。它不会变化。没有人会买它并下架它。

为了确保有一个可以接受的体验，尤其是在降级时，你要采取不同的方法优雅降级。在Flickr，如果程序出故障 - 比方说收藏出故障 - 我们会关掉收藏保住网站其他功能。你只是无法用收藏功能。我们做了很多工作。由于消费者和生产者都是平均的，在很大程度上，我们在故障上也会均衡处理。

在 Etsy ，我们必须要考虑的事情有点不同。如果商品列表出错，买东西和搜索可能完全正常，因为我们做了特别的解耦处理。也许出问题时卖家无法上传新的列表或更新列表，但除了卖家，没人知道。

我想，你问题的答案是，在 Etsy 的情况下和你在 Flickr 下的，甚至可能是其他公司的架构 for failure 是不同的。过于简单化地说，是因为涉及金钱，但肯定金钱是主要原因。

“我们希望基础设施和代码自适应。不是能人工智能方式的自适应，而是有可塑性。我们就可以很容易随意改动“

如果你要停止当前，去下一份工作，从明天从头构建技术基础设施，你会怎么做？

我的答案是有至少两种方法。第一个可能不是非常令人满意：这取决于，我要到什么地方去。如果我在一个交易平台工作，我可能会采用一个非常，非常不同的方法。

如果我是在不同的电子商务公司工作，这我无法想象，但我会再次使简单复用以前的架构模式，因为它们是经过实战检验的，它们是老路子。从一种显著不同的架构模式重新构建不太可行，这更可能是因为我们的批判性思维方式而不是给定技术。

有一件事，在 Etsy的五年多，我还高兴地看到，我们采取的软件开发 -- 为运营和安全和所有其他 - 是真正的以人为本。这就是说，我们不只是解决难题，我们不相信有什么神奇的算法。

算法之类的机器学习和深度学习，这些都是非常重要的，但他们只是盒子里的工具。我在任何公司都会做的事情是写软件给人们思考。

我来说一个残酷的场景：给定一段代码，绝对是最佳的 -- 它，但除了作者没人知道它现在是如何运行的 -- 与一段某人写的可扩充，可修改，灵活的和其他类似特性的代码相比，我会采取后者。

我们希望基础设施和代码自适应。不是能人工智能方式的自适应，而是有可塑性。我们就可以很容易随意改动。

这是我所学到的东西。我会带身上（经常回顾）。对不起，这可能很含糊，但我认为这是非常重要的。

原文链接：Microservices, monoliths and laser nail guns: Etsy tech boss on finding the right focus（翻译：沈冠璞）

原文发布时间为：2015-09-06

本文作者：沈冠璞 

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：Etsy 技术 VP 谈架构：微服务，单体应用和激光射钉枪？Etsy 在寻找正确的焦点