Get best of the week

食品基础设施：我们如何支持Tanuki



用一个著名的历史人物来解释，对我们来说最重要的服务就是送货。在目前的情况下，如果家里没有面包或比萨饼，我们该怎么办？我不想想象。碰巧的是，两年前，我们得到了最大的网络之一-Tanuki的支持。该网站每月的访问量约为一百万。现在是2020年。 Tanuki在2018年开始与我们合作时，规模缩小了2倍。我们确保毫不费力地迁移到新的数据中心，并完全重整了基础架构-实际上，由于该基础架构，站点和应用程序能够承受增加的负载而不会出现问题。

有时，我们非常遗憾地认为我们离最近的Tanuki餐厅很远；否则，我们的所有成功（和很少的不幸）都会被美味的面包卷所卡住。

总的来说，今天我们想告诉您有关国内“酒店业”最大的网络项目之一的支持故事。

我们于2018年3月底见面。

国际妇女节已经​​过去了很长时间，但是你们刚刚应付了它的后果。一切都很平淡：3月8日前夕，访问量急剧增加，而且该网站长期无法使用。真的很长，没有几个小时。因为流量不仅通过主站点，而且还来自应用程序（适用于Android和iOS）以及聚集器（Yandex。Food，Delivery Club，Zaka-Zaka）。

我们所看到的


从技术上讲，该项目非常复杂：

  • 该站点是具有SSR（服务器端渲染）的React应用程序。
  • 移动应用程序-适用于iOS / Android。
  • API-所有应用程序都可以使用它。
  • 外部系统，包括订单处理。


该系统是反向代理服务器：它们的流量经过DDoS攻击的保护系统，并已从那里分发到后端服务器。在接受时，有一个旧站点和一个用于移动版本的API，因此开始了新站点的开发。新API的开发是在单独的服务器上进行的。

数据库集群由两台具有主/主复制的服务器组成，由于浮动IP，在发生故障的情况下在网络级别进行切换。所有写入应用程序都使用此IP，而每个后端服务器上都有用于读取的MySQL从站-因此，该应用程序与localhost一起工作。

在接待处，我们看到了以下问题：

  • 数据库配置中的平衡机制可靠性不足。母版复制母版导致频繁失败。
  • 每个后端上的从站-需要大量磁盘空间。而且任何操纵或添加新的后端服务器都是昂贵的。
  • 没有适用于应用程序的通用部署系统-通过网络存在一个独立的部署系统。
  • 没有用于收集日志的系统-因此，在使用订单系统时首先很难调查事件，因为无法确定如何接收特定订单。
  • 没有监视业务指标-无法及时记录订单减少或完全没有订单。

在对接受监视的服务器进行初步审核之后，我们从形成操作路线图开始。最初，确定了两个主要工作领域：
  1. 稳定应用程序。
  2. 为新的API和网站组织一个舒适的开发环境。

第一个方向的决定主要与MySQL集群的稳定性有关。我不想拒绝主复制主服务器，但是无法继续使用浮动IP。定期观察到网络连接中断，这导致群集运行中断。

首先，我们决定放弃浮动IP，转而使用代理服务器，因为我们使用nginx作为MySQL的代理，因此将在主服务器之间控制上游。第二步是为从服务器分配两个单独的服务器。还通过代理服务器组织了与他们的合作。而且自重组以来，我们忘记了与使用数据库相关的问题。

接下来，我们在数据库中的查询级别监视订单。任何与规范的偏离（或多或少）都会立即引起调查。然后，在日志级别，我们形成了用于监视外部交互（特别是与订单管理系统）的度量。

根据同事的要求，我们与同事一起对所有系统进行了额外的调整，以实现稳定和快速的运行。它既在调整MySQL，又在更新PHP版本。另外，同事们介绍了基于Redis的缓存系统，这也有助于减少数据库的负载。

所有这些都很重要...但是，该业务的主要目的是增加销售额。在这种情况下，公司经理对新站点寄予厚望。对于开发人员来说，有必要获得一个稳定，便捷的系统来进行部署和应用程序控制。

首先，我们考虑了CI / CD应用程序的组装和交付管道，以及用于收集和处理日志的系统。

所有客户端存储库都托管在自托管的Bitbucket解决方案上。为了组织管道，选择了詹金斯。

首先，习惯在开发环境上实现管道-这使我们能够显着提高开发速度。然后将其引入生产电路，在此自动部署使我们避免了通常由人为因素引起的频繁错误。

实施后，CI / CD开始组织日志的收集并与之合作。选择ELK堆栈作为主要堆栈，这使客户可以在发生事件时更快，更好地进行调查。结果，应用程序开发变得更快。

“比两次大火还可怕……”


在完成了非常复杂但仍然是标准的任务之后，Tanuki告诉了我们很久以来他们想说的话：“走吧！”

DC的变化是由经济因素引起的。此外，客户还通过新DC中已有的其他服务扩展了其基础架构-这也影响了迁移的决定。

任何系统的迁移，更不用说复杂的迁移，都是一个需要大量计划和大量资源的过程。

此举是反复进行的：在第一阶段，在新的DC中创建了反向代理服务器。而且由于只有他们拥有公共ip，所以它们还充当管理员的系统访问点。

然后，我们启动了所有基础架构服务-日志记录和CI / CD。一个领事允许组织方便，可管理且相当可靠的客户端应用程序之间交互的服务。

迁移了以下数据库，Redis和队列代理-RabbitMQ。重要的是组织所有内容，以便它们在服务发现协议中正确注册，从而控制DNS的运行。请注意，应用程序不是直接与数据库一起使用，而是通过Haproxy直接使用，这使您可以方便地在数据库之间进行平衡并在发生故障时进行切换。

在准备阶段，数据中心之间的数据库复制没有增加。我只需要传输备份。接下来，我们开始直接配置应用程序，这是通过内部DNS进行的所有交互的组织-应用程序与数据库/ Redis / RabbitMQ /外部服务（例如，订购服务）之间的交互。自然，在同一阶段，所有CI / CD机制都立即连接在一起-然后在体系结构上进行了第二次更改。以前，无法通过界面更改应用程序设置-只能通过直接在控制台中编辑文件。随即，我们推出了一种解决方案，可让您通过Web界面方便地管理设置。它基于Hashicorp保管库（Consul充当其后端），这使我们能够建立方便的机制来管理环境变量。

下一步是将服务切换到新的DC。由于所有系统的工作都是使用http协议组织的，并且所有域都经过了针对DDoS攻击的保护系统，因此切换直接在该系统的界面中进行了上游操作。

以前，从旧的DC到新的DC都组织了必要的副本。然后切换到商定的工作窗口。

现在什么样的基础架构





  • 所有流量都流向平衡器。到该API的流量不是直接从Tanuki应用程序（在Android / iOS上）而是通过Qrator进行的。
  • tanuki.ru项目的主站点位于静态服务器上，tanuki.ru项目是具有登录页面的服务器。
  • 后端集群现在由服务器组成：前端服务器，静态服务器，应用程序服务器。

订单传递方案
接收到的订单通过Qrator（我们立即过滤掉攻击）并到达API。然后他去Raiden交付订单，去Redis并去Nginx，然后离开数据库。

对客户有什么改变


  • 系统的可靠性：在2019年7月发现问题-在一小时内未下达订单。但是那是在全球行动之前。随后未发现重大事件。
  • 开发人员的生活：他们拥有便捷的CI / CD开发环境。
  • 容错能力：基础架构现在可以承受大量流量。例如，在假期期间，RPS达到550个峰值。

下一步是什么


在现代情况下，在线销售脱颖而出。该项目应为服务客户提供可靠性和可访问性。但是开发也是一个非常重要的组成部分：产品发布应尽可能快且对最终用户不可见。

另一个重要问题是资源的利用和减少系统维护成本。

所有这些导致需要对系统进行整体审查。第一步是组织应用程序容器化。然后计划组织一个Kubernetes集群。但是我们将在下一篇文章中讨论。在此期间-好的胃口:-)

More articles:


All Articles