InfoQ 播客：Randy Shoup 谈 Stitch Fix 的技术栈，数据科学和微服务架构

在本周的 InfoQ 播客中， QCon 主席 Wesley Reisz 与 Randy Shoup 进行了对话。Shoup 是 Stitch Fix 的工程副总裁。在来到 Stitch Fix 之前，他曾在谷歌担任工程和云计算主管一职，同时他曾经也是 Shopilly 的首席技术官和联合创始人，并且还担任过 Ebay 的首席工程师。

关键要点

• Stitch Fix 的业务充满艺术与科学相互结合的过程。人类在机器的协助下可以获得更高的工作效率，机器在人类的操纵下可以更完美的完成工作。
• Stitch Fix 有 60 个工程师，80 个数据科学家和算法开发人员。这种数据科学家与工程师的比例在业内是独一无二的。
• 由于使用了基于 Postgres 数据库的 Ruby-on-Rails 框架，Stitch Fix 在同一个技术栈上维护着 30 个不同的应用。
• 通过实践测试驱动开发使持续交付成为可能，构建代码的人同时还要负责代码的运维。这样一来，我们可以同时将这两件事做得更好。
• 速度（velocity）是微服务的三个特性之一，它指的是一种能力，而这种能力可以使各个团队快速的推进自己的业务，同时彼此之间保持独立，各自进行独立的部署。
• 微服务解决了系统伸缩性的问题。它解决了组织扩展问题和技术扩展问题。不过，在创业初期，我们并不会遇到这些问题。
• 在一个单片架构的业务体系中，如果你不能持续的从垂直方向扩展你的应用、数据库或该业务的任何其他部分。那么为了保证业务的可伸缩性，你可能需要考虑把该业务分解成独立的子服务，也就是所谓的微服务。

点击播客链接收听

摘要

数据科学和 Stitch Fix

• 1 分 57 秒：Stitch Fix 重塑了零售业，尤其是服装行业。当你在 Stitch Fix 的网站上进行注册时，我们首先会要求你填写一个调查问卷。这个问卷主要是用来调查你感兴趣的和不感兴趣的商品的。在这之后，我们会基于已经拥有的数百万客户的选择，来为你挑选在我们看来你会喜欢的商品。在这个挑选的过程中，我们使用了大量的数据科学技术与方法。
• 3 分 00 秒：我们设计了专门的算法用于这个挑选过程，这个算法会基于所有我们已知的其他用户的信息，来为你挑选出我们推荐的个性化的产品。我们同样也有人工筛选的过程：在整个美国有 3200 位设计师，他们会为你挑选出他们所推荐的 5 件（服装）商品，并将这些商品放到你的购物车中。
• 3 分 29 秒：我们很喜欢的地方是，这整个推荐的过程是一个艺术与科学相互结合的过程。现代公司会使用机器进行数据分析，机器所擅长分析的地方，比如对数百万的用户进行 60 到 70 个问题的问卷调查，然后再结合设计师给出的建议，最后我们可以清楚哪些事物是可以搭配在一起的，哪些事物是潮流的趋势，哪些事物是比较适合现在进行售卖等等。人类在机器的协助下可以获得更高的工作效率，机器在人类的操纵下可以更完美的完成工作。

关于 Stitch Fix 团队

• 4 分 38 秒：我们对商业数据科学和算法方面的业务进行了大量投资，而这方面的证据就是我们的人力资源配置。在工程方面，我们有大约 60 名工程师，有 80 名数据科学家和算法开发人员。这种数据科学家与工程师的比例在业内是独一无二的。
• 5 分 45 秒：我们的工程组有 60 人。公司的总部设在旧金山，但我们的大多数工程师都是远程办公，可以说他们分布在全国各地。
• 6 分 00 秒：我们有直接与业务部门协作的团队。我们有一个团队会专门为购买衣服的人们制作软件，这些购买衣服的人们也被称为经销商。有一个团队会专门为我们制作仓库和库存管理软件。同时也有一个团队会专门为 3200 名设计师制作一个软件用来为客户选择个性化的商品。还有团队负责制作客户支持相关的软件。同时也有团队，负责构建我们的网站和移动应用程序。我们的技术团队模式是拥有很多小规模的全栈开发的团队，每个团队直接负责相应的业务功能需求。

Stitch Fix 的技术架构

• 6 分 54 秒：我们主要的技术栈是基于 Postgres 数据库的 Ruby on Rails 框架。同时，我们也正准备在 Go 中开发更多的后端服务。我们在大致相同的同一个技术栈上维护着大约 30 个不同的应用程序，这些应用程序分别对应着特定的业务功能。
• 7 分 25 秒：我们没有构建一个基于单片架构的应用程序，而是在基于微服务的架构上构建了一系列单独的微服务应用程序，但这些微服务应用并不是那么纯粹的微服务应用。它们分别负责各自特定的业务领域。
• 7 分 50 秒：我们最大的应用程序是我们设计师所使用的应用，这个应用会帮助设计师提供个性化的建议，同时帮助他们为特定的用户挑选个性化的商品。在我们的仓库中，有一个专门用来负责退货的应用程序；这背后所遵循的原则就是，保证每一个应用程序只负责一个特定的功能，并且该功能需要完全满足你的使用场景，而不是做一个功能“大而全”的应用。

微服务和进程

• 13 分 11 秒：我们进行了大量的测试驱动开发，并且不断的实践可持续交付，同时我们也在实践 Devops 方法：我们的整个项目便是以这样的不断 实践作为开始的。没有说法认为如果你在项目开始前进行这些训练，后期的项目架构会变得简单。这里的所有员工在之前的工作中，都经历过不采用这些实践的场景，所以他们知道这意味着什么。
• 13 分 55 秒：这些实践彼此协同工作，互相依存。通过实践测试驱动开发使持续交付成为可能，构建代码的人同时还要负责代码的运维。这样一来，我们可以同时将这两件事做得更好。
• 15 分 56 秒：能够快速提供所需资源，并且能够同时快速地进行应用程序部署，这些能力是在微服务架构中取得成功的绝对先决条件。你必须能够进行快速的推进并快速部署，这样才能体会到微服务架构带来的好处。
• 16 分 39 秒：使用微服务架构你能获得怎样的好处？使用微服务架构可以使各个团队快速的推进自己的业务，同时彼此之间保持独立，各自进行独立的部署。同时具备自由扩展基础设施容量的能力，并且各个应用程序和服务彼此保持独立。

改变你的组织架构

• 17 分 23 秒：康威定律表明，业务系统的架构直接反映了你团队的组织结构，特别是组织中的沟通路径将直接反映在你的系统架构中。
• 18 分 59 秒：如果你是一个中级架构师，那么你有两件事可以去做。第一件事是，你不要天真的认为你的项目领导会了解关于架构的所有概念。
• 19 分 29 秒：另一件事是，你可以在你领导的团队内对团队负责的服务或应用程序服务进行具体的划分。例如，如果你的团队有 8 个人或 10 个人，相较于整个团队都做同一件事，细分这些团队，使他们分别工作在相应的服务或应用程序服务上会更好。即使你不能控制整个团队的工作方式，你也可以按照这些思路来组织你所领导队员的工作方式。
• 20 分 35 秒：Stitch Fix 没有基于单片架构的应用程序，但我们有一个基于单片架构的数据库系统。我们在 Stitch Fix 内对所有数据库实体操作都在一个共享数据库中进行。但现在我们正在把这些不同业务的数据库分离出来，并基于这些分离出来的数据库创建微服务。我们应该在一开始就使用微服务架构吗？并不是这样。
• 22 分 03 秒：微服务解决了系统伸缩性的问题。它解决了组织扩展问题和技术扩展问题。但这些都不是你在早期创业中会遇到的问题。

这些迹象表明你需要使用微服务来保证业务的可伸缩性

• 23 分 27 秒：如果你认为雇用新的工程师，使他们快速熟悉业务、并具备生产力是一件很痛苦的事情，或者说如果你很难提高现有团队的生产力，因为团队中每个人的业务都相互依赖彼此，那么这些迹象都表明你需要考虑使用微服务将你的业务分解成不同的部分，并且对这些部分进行单独的处理。
• 23 分 41 秒：在一个单片架构的业务体系中，如果你不能持续的从垂直方向扩展你的应用、数据库或该业务的任何其他部分。那么为了保证业务的可伸缩性，你可能需要考虑把该业务分解成独立的子服务，也就是所谓的微服务。
• 24 分 03 秒：另一个也很常见的问题就是所谓的部署独立性，部署独立性意为一个完整系统的不同部分有着不同的生命周期。如果你的系统符合部署独立性的特征，即一个完整系统的不同部分有着不同的生命周期，那么这同样表明你可能需要考虑将这个系统分解成更小的部分，也就是微服务。

文中提及的人物

• Martin Fowler
• Melvin Conway
• Stefan Krawczyk

文中提及的公司

• Google
• Ebay
• Shopilly
• Stitch Fix

文中提及的编程语言

• Go
• HTTP
• JSON
• Ruby on Rails

文中提及的产品

• Postgres

文中提及的管理流程

• Continuous Development
• Devops
• TDD

更多关于播客的信息

最新播客可通过我们的 RSS feed 更新，也可通过 SoundCloud 和 iTunes 收听。本页所列出的播客摘要内容均附有可点击链接（英文原文），点击后可直接切换到音频的相关部分。

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。