过去一年中，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