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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本文讲的是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 在寻找正确的焦点
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
4天前
|
消息中间件 Kubernetes Java
构建高性能微服务架构:从理论到实践
【2月更文挑战第24天】 在当今快速发展的数字化时代,微服务架构已成为软件开发领域的关键趋势。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、技术选型和性能优化策略。我们将通过实际案例分析,揭示微服务架构在提高可伸缩性、容错性和维护性方面的优势,并讨论在实施过程中可能遇到的挑战及其解决方案。
|
3天前
|
监控 持续交付 开发者
构建高效微服务架构:从理论到实践
【2月更文挑战第25天】本文旨在深入剖析微服务架构的核心概念、设计原则以及实践中的关键技术挑战。通过探讨微服务的独立性、分布式特性和弹性机制,文章为读者提供了一套系统化的方法论,以指导如何构建和维护一个高效、可扩展且容错性强的微服务系统。文中将结合案例分析,展示微服务架构在真实业务场景中的应用,并提供性能优化和故障恢复的策略建议。
54 3
|
4天前
|
消息中间件 前端开发 API
架构的未来:微前端与微服务的融合
架构的未来:微前端与微服务的融合
|
1天前
|
安全 数据管理 API
构建高效微服务架构:从理论到实践
【2月更文挑战第27天】 在数字化转型的浪潮中,微服务架构已成为企业追求敏捷、灵活与可扩展性的关键解决方案。本文将深入探讨微服务的设计原则、开发流程以及如何在实际项目中实现一个高性能的微服务系统。我们将通过分析微服务的核心优势,揭示其背后的技术挑战,并提供一系列切实可行的策略来优化微服务的性能和稳定性。文中不仅包含了丰富的理论依据,还结合了实际案例分析,为开发者和企业决策者提供了一套全面的微服务实施指南。
|
1天前
|
消息中间件 敏捷开发 运维
构建高性能微服务架构:策略与实践
【2月更文挑战第27天】 在当今快速迭代和持续部署的软件发展背景下,微服务架构因其灵活性、可扩展性和技术异构性的优势而成为众多企业的首选架构模式。然而,随之而来的复杂性管理和性能优化问题也不容忽视。本文深入探讨了构建高性能微服务架构的策略与实践,包括服务拆分原则、通信机制、数据一致性保障以及监控和故障处理等方面。通过分析具体案例和最佳实践,旨在为开发者提供一个清晰、高效的微服务性能优化路径。
|
2天前
|
监控 Kubernetes Docker
构建高效可扩展的微服务架构
本文将详细介绍如何构建高效可扩展的微服务架构,包括设计原则、技术选型和实施步骤。通过采用微服务架构,企业可以实现系统的解耦、灵活性和可伸缩性,提升开发效率和系统性能。
|
2天前
|
存储 Java 持续交付
构建高效微服务架构:从理论到实践
【2月更文挑战第26天】在现代软件开发的浪潮中,微服务架构已成为企业追求敏捷、可扩展和易于维护系统的重要解决方案。本文将深入探讨微服务的核心概念、设计原则以及如何在实际项目中实施微服务架构。我们将通过一个示例来揭示拆分传统单体应用的步骤,并讨论微服务架构在提高开发效率、支持快速迭代和优化资源使用方面的优势。同时,我们也将指出微服务实施过程中可能遇到的挑战,如服务发现、配置管理和分布式事务处理,并提出相应的解决策略。
|
2天前
|
监控 负载均衡 API
深入理解微服务架构下的API网关
【2月更文挑战第26天】在现代后端开发中,微服务架构已经成为一种主流的系统设计方式。本文将重点探讨微服务架构中的关键组件——API网关。我们将分析API网关的核心功能,包括请求路由、负载均衡、认证授权、监控和日志记录等。此外,文章还将讨论如何在实际项目中设计和实现一个高效、可扩展的API网关,以及它对微服务治理的重要性。通过本文,读者将获得对API网关在微服务架构中的重要作用和应用策略的深刻理解。
|
3天前
|
消息中间件 负载均衡 API
构建高效微服务架构:策略与实践
【2月更文挑战第25天】在数字化转型的浪潮中,微服务架构以其灵活性、可扩展性成为企业技术升级的关键选择。本文深入探讨了构建高效微服务架构的策略和实践方法,旨在为开发者提供一套系统的设计与实施指南。文中不仅阐述了微服务的核心概念和优势,还详细分析了在设计、部署和维护微服务过程中可能遇到的挑战及解决方案,同时结合案例分析,展示了如何在实际项目中落实这些策略。
|
4天前
|
运维 负载均衡 监控
探索微服务架构下的服务治理实践
【2月更文挑战第24天】 在当前软件开发领域,微服务架构已成为构建复杂系统的主流选择。它通过将大型单一应用程序分解为一组小的、松耦合的服务来提供灵活性和可维护性。然而,随之而来的是服务治理的挑战,包括服务发现、配置管理、负载均衡、熔断机制等。本文将深入探讨在微服务架构中实现有效服务治理的策略与技术实践,分享个人在这一过程中的感悟和经验教训。

相关产品

  • 微服务引擎
  • 服务网格