使用 HAProxy, PHP, Redis 和 MySQL 轻松构建每周上亿请求Web站点，超牛逼！

Posted 2021-05-01 OSC开源社区

本案例是由Antoni Orfin写的客座文章，他是Octivi的联合创始人和软件架构师。

在文章中，我将向您展示我们开发的基于HAProxy，php，Redis和mysql的非常简单的架构的方法，它可以无缝地处理约每周十亿次的请求。文章中还列举了进一步扩展它的可能途径，并指出了针对于该项目的不常见的模式。

数据：

• 服务器：

• 3x 应用节点

• 2x MySQL + 1x 用于备份

• 2x Redis

• 应用程序：

• 应用程序每周处理1,000,000,000请求

• 单一Symfony2实例达到700req/s(工作日平均550req/s)

• 平均响应时间 - 30 毫秒

• Varnish - 高于12,000 req/s (在压力测试中达到)

• 数据存储：

• Redis - 160,000,000记录， 100 GB 的数据 (我们主要的数据存储库！)，

• MySQL - 300,000,000记录 - 300 GB (第三层缓存)

平台：

• 监控：

• Icinga

• Collectd

• 应用程序：

• HAProxy with Keepalived

• Varnish

• PHP (PHP-FPM) with Symfony2 Framework

• 数据存储：

• MySQL (master-master) with HAProxy load balancing

• Redis (master-slave)

背景

差不多一年前，我们的朋友带着一个难以解决的问题来到我们的办公室。他们正在运行一个快速增长的电子商务新兴公司，当时他们希望将其扩展到国际水平。

因为他们仍然是一个新兴的公司，提出的解决方案必须是高性价比的，而不是在下一个服务器上将钱用完。遗留系统一直采用标准的LAMP架构搭建，他们 已经有一个强大的PHP开发团队。新技术的引进必须要精巧，不能是过于复杂的架构，并且能让他们现有工作人员进一步维护此平台。

系统体系结构必须被设计为可扩展的方式，来实现扩展到下一个市场的计划。所以我们只好来了，检查他们的基础设施...

以前的系统是以整体方式设计的。具体来说是一些独立的基于PHP的Web应用程序（在新兴公司有很多所谓的前端网站）。他们中的大多数都使用单一的数据库，他们共享一些常见的代码来处理业务逻辑。

进一步维护这样的应用可能是一个噩梦。由于部分代码已经被复制，更改一个网站，可能会导致业务逻辑的不一致 - 他们总是需要在所有的web应用程序中进行相同的更改。

此外，从项目管理的观点来看这也是一个问题 - 谁应该负责被分散在多个代码库的“那一部分”代码呢？

优点:

- 不同的子系统（服务）可以很容易被完全不同的开发团队开发。开发者之间可以互不干涉。

- 不用处理用户授权和访问问题，因此就不存在常见的等级问题了。

- 在一个地方维护业务逻辑-不同的前端网站之间不存在冗余的功能。

- 易于该服务被大众所接受。

缺点:

- 系统管理者的工作量更大- 因为服务是基于其自身的架构体系，所以系统管理员就需要对该架构增加关注。

- 保持向后兼容性-在一年的维护中，API 方法的改变多的会不计其数。 问题是这些改变千万不能破坏向后兼容性，不然每个前端网站的代码都需要修改，而且同时部署所有网站时会增加程序员工作...一年之后，所有的方法仍然能够与第一版的文档兼容。

更多内容请点击阅读原文。

-----------------------------------------------------------

更多内容请看点击阅读原文～

点击文章标题下的“开源中国”蓝字，或者在微信搜索“开源中国”即可订阅 开源中国 微信。

----------------------------—————————————————