开发者社区> 轩墨> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

Etsy 技术 VP 谈架构:微服务,单体应用和激光射钉枪?Etsy 在寻找正确的焦点

简介: 本文讲的是Etsy 技术 VP 谈架构:微服务,单体应用和激光射钉枪?Etsy 在寻找正确的焦点,【编者的话】 Etsy 是美国一个在线销售手工工艺品的网站,网站集聚了一大批极富影响力和号召力的手工艺术品设计师。
+关注继续查看
本文讲的是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 -- 我们要去使用它。我们要在这里用它。用在这里比较好,” 然后我们会更熟练使用它,这意味着我们收获了更多的信心。
1-iYnP3qyskKoj4aeMTX-dsQ.png

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

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

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

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

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

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

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

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

这就像一个长长的尾巴。

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

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

速度重要,所以硬件重要

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

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

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

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

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

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

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

服务端性能季度统计-来源: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 在寻找正确的焦点

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
开源 | 蚂蚁金服分布式中间件开源第二弹:丰富微服务架构体系
小蚂蚁说: 数据、消息、微服务是蚂蚁金服自主研发的金融级分布式中间件 SOFA (Scalable Open Financial Architecture)的三大方向。 一个多月前,蚂蚁金服开源了 SOFABoot 和 SOFARPC 两个组件,受到了社区的热烈欢迎(点击文章阅读《开源|蚂蚁金服启动分布式中间件开源计划,用于快速构建金融级云原生架构》,了解更多),也收到了很多大家的反馈,其中大家对开源更多组件的呼声很大哦~! 今天我们就给大家介绍下本次 SOFA 中间件开源的几个微服务体系组件。
9222 0
微服务架构中基于DNS的服务发现
当前,微服务架构已经成为企业尤其是互联网企业技术选型的一个重要参考。微服务架构中涉及到很多模块,本文将重点介绍微服务架构的服务注册与发现以及如何基于DNS做服务发现。最后,简单介绍下阿里巴巴内部是如何基于DNS做服务发现的。
8084 0
大规模微服务架构下的 Service Mesh 探索之路
今天给大家带来的分享:Service Mesh 探索之路,但是在前面加了一个定语:大规模微服务架构下。之所以加上这个词,是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的,蚂蚁金服的体量大家可以想象,所以这个探索会带有一个非常隆重的色彩:对性能/规模/高可用等方面的思考。
2968 0
微服务架构风格
特点 通过将一个应用程序设计构建为一组松散耦合的协作服务。每个服务都实现了一部分的相关功能。对应于Scale Cube(参考分布式系统三维可缩放模型)的Y轴。 服务使用HTTP / REST等同步协议或AMQP等异步协议进行通信。
925 0
《微服务架构实战-基于Dubbo和Spring Cloud》值得期待的新书
image.png 首先我要感谢我的写作团队和编辑牺牲大量的业余时间来共同完成本书,本书将于10月左右正式上市,期待大家多多关注。 书中的内容既包括大量非常有新意的微服务理论知识,也包括大量工作中实践的案例,多种案例可以直接上手借鉴使用。
1332 0
Scala微服务架构 三
四 Controller层 之前我们已经把基层架构搭建好了,那么要如何使用呢? 首先看看我的Controller层代码 @Singleton class BMAuthController @Inject()(implicit cc: ControllerComponents, actorSystem...
1012 0
Scala微服务架构 二
三. Scala的Macro(宏) Scala Macros对scala函数库编程人员来说是一项不可或缺的编程工具,可以通过它来解决一些用普通编程或者类层次编程(type level programming)都无法解决的问题,这是因为Scala Macros可以直接对程序进行修改。
1216 0
Scala微服务架构 一
因为公司的一个项目需求变动会非常频繁,同时改动在可控范围内,加上产品同学喜欢一些超前思维,我们的CTO决定提前开启八门,使用微服务架构。 划重点 微服务架构主要特点: ==独立组件(自主开发升级)== ==开运一体(谁开发谁运维)== ==去中心化(语言,系统,数据,统统可以分开不一样)== 一. 那么什么是微服务架构呢? 引自 https://www.ibm.com/developerworks/community/blogs/ “微服务”架构是近期软件应用领域非常热门的概念。
2012 0
分布式、微服务架构Spring Boot入门及实例介绍
spring boot入门 -- 介绍和第一个例子 “越来越多的企业选择使用spring boot 开发系统,spring boot牛在什么地方?难不难学?心动不如行动,让我们一起开始学习吧!” 使用Spring boot ,可以轻松的创建独立运行的程序,非常容易构建独立的服务组件,是实现分布式架构、微服务架构利器。
1485 0
微服务架构十条最佳实践
确保你在分布式系统中,努力实现这些微服务的最佳实践,例如监控和REST成熟度。 使用微服务架构可以解决所有的软件架构的问题,对吗?当然,这是不对的。
789 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
御膳房架构演进
立即下载
见微知著,APM在tutorabc的应用
立即下载
亿级视频广告事件预测系统构建之道
立即下载