过去一年中， Deliveroo 在商业和 IT 领域成长迅速，这导致它的大型单体应用面对不少的技术挑战。 Greg Beech 在近期的 QCon 伦敦大会演讲中指出，Deliveroo 对此问题的解决方案并非依靠微服务，而是向分布式转变。Beech 介绍了 Deliveroo 在从单体应用转变为分布式系统过程中的一些做法。
Deliveroo 公司创立于 2013 年，Beech 现任公司的首席工程师。公司起步于采用传统 Ruby on Rails 开发的单体应用，数据存储使用了 PostgreSQL 和 Redis ，通过不断增大数据库规模而处理日益增长的业务。一年前，他们需要运行大约 20 台 Heroku 托管服务器。当前运行的服务器规模达数百台，这已成为 Keroku 上部署的最大规模应用，峰值情况下需要使用 1800 个内核和 3TB 的内存。公司由 2015 年的 10 名工程师已成长为 2017 年的近 100 名工程师，主代码库中的有效代码行达到约 60 万行。
采用单体程序架构是一个经过深思熟虑的决策，他们因此可以快速添加适合市场需求的特性，但是现在这种架构需要面对一些问题。由于当前单体程序的规模增长得很大，Deliveroo 受困于性能下降和构建时间增加的问题，构建时间已经从两年前的 7 分钟左右增加到目前的两个小时左右，进而延缓了开发的速度。大型单体程序也会导致可靠性下降，因为出现一个问题就可能使得所有的服务宕机。
Deliveroo 的解决方案是转向分布式，实现中采用了一种将单体程序切分为三大类“十二要素”（Twelve-Factor）应用的方法。这三类应用分别是领域服务（Domain service）、外围服务（Edge service）和客户端应用（Client apps for the UI），事件总线为这些服务提供了支持。
领域服务是：
- 占有领域的重要部分。这些服务占有了领域的重要部分，这些部分只有紧密粘合在一起才具有作用。这就是 Beech 不喜欢称其为微服务的原因所在。
- 暴露内部真实的 REST API，包括超媒体。
- 从事件总线收发事件。
- 可以使用其它域服务的 API。
外围服务是：
- 不具有任何一部分领域。
- 向外部暴露聚合的 API。
- 从事件总线接收事件。
- 可以使用其它外围服务和领域服务的 API。
在这种分布式解决方案中，不存在共享的数据存储。每个应用都具有自身的数据存储，除非存在例外情况，否则每个应用的数据存储是不能被其它的应用访问的。此外，所有数据是作为 REST API 方式暴露的，Beech 指出这是真正包含超媒体的 REST。举个例子，API 返回的集合（Collection Resource）是一系列到实体的链接，而非内嵌的对象。他同时指出，RPC 是不允许使用的。
在创建、更新或删除实体后，领域服务会通过事件总线发送事件，他们将这种技术称为“呈现状态通知”（RSN，Representational State Notification）。事件中从不包含载体，只是链接到事件相关实体。这样做的部分原因是出于避免总线成为数据损失的一个关键源头。但是一些非关键的不可变值对象是可以在消息中发送的，这是一种例外情况。
Beech 指出虽然 Deliveroo 对于服务如何构建、如何分层及如何通信给出了相当强有力的指南，但依然可以从简单处着手，按自己需要去演化成一个更为复杂的架构。这样做的目的在于，允许团队就像具有自身问题切入点和目标的初创公司那样运行，按团队需求演化自身的架构，并在分布式架构经验有限的条件下取得成功。
查看英文原文： Moving Deliveroo from a Monolith to a Distributed System
感谢薛命灯对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论