皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

从单体应用转为分布式系统:来自 Deliveroo 的实践

作者 Jan Stenberg ,译者 Rays

过去一年中,Deliveroo 在商业和 IT 领域成长迅速,这导致它的大型单体应用面对不少的技术挑战。Greg Beech 在近期的 QCon 伦敦大会 演讲中指出,Deliveroo 对此问题的解决方案并非依靠微服务,而是向分布式转变。Beech 介绍了 Deliveroo 在从单体应用转变为分布式系统过程中的一些做法。

Deliveroo 公司创立于 2013 年,Beech 现任公司的首席工程师。公司起步于采用传统 Ruby on Rails 开发的单体应用,数据存储使用了 PostgreSQLRedis,通过不断增大数据库规模而处理日益增长的业务。一年前,他们需要运行大约 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

转自 http://www.infoq.com/cn/news/2017/03/deliveroo-monolith-distributed

分享到:更多 ()