本案例是由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应用程序中进行相同的更改。

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

根据这一观察，我们的第一步是提取核心的关键业务功能到一个单独的服务中（这是本文的范围）。它是面向服务的架构模式。在整个系统范围内考虑“关注点分离”的原则。该服务是保持一种逻辑的，具体的更高级别的业务功能。给你一个真实的例子 - 服务可以是一个搜索引擎，销售系统等。

前端网站通过一个REST API来和服务进行通信。响应是基于JSON格式的。我们选择它的原因是简单性，相反SOAP始终对开发者来说比较困难（没有人喜欢分析XMLS...;-））

提取的服务并不处理如身份验证和会话管理之类的东西。这是必须的，这些事情是在一个更高的层次来处理的。前端网站负责这一点，因为只有他们才能确定他们的用户。这样，我们将服务更简化 - 在进一步扩展的问题和代码的东西上。没有什么不好的，因为它有不同的任务来处理。

优点:

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

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

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

缺点:

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

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

应用层

 

根据请求流，第一层是应用层，应用层里面包括HAProxy负载均衡器，Varnish和Symfony2 网络应用。来自前端网站的请求首先到达HAProxy，然后通过HAProxy分发到应用节点中。

应用节点配置

• Xeon E5-1620@3.60GHz, 64GB RAM, SATA

• Varnish

• Apache2

• PHP 5.4.X running as PHP-FPM, with APC bytecode cache

我们已经拥有三个这样的应用服务器。它是双活模式下的N+1模式 - ”备份“服务器主动处理请求。

保持Varnish在每个节点中的独立性使得快取命中率更低，但是这种方式下我们就不存在SPOF问题（一个节点失效，全部系统停止运转）。我们这样做的目的是考虑可用性高于性能（在我们的案例中性能不是问题）。

我们选择Apache2，它也被用在前端网站服务器中。避免混合进许多技术使得系统管理员的维护更加容易。


 

Symfony2 应用

应用本身是建立在Symfony2的顶层之上。它是一个完全PHP的栈框架，提供丰富的有用组件，这些组件能够加速开发的进程。将典型的REST服务建立在一个复杂的框架之上可能对某些人来说不可思议，让我对其中的原因进行说明：

• 易于PHP/Symfony开发者接受 - 客户的IT团队包括PHP开发者。引入新技术（比如Node.js）就意味着需要雇佣新的能够更好的维护系统的开发者。

• 清晰的项目结构 - Symfony2并没有利用非常复杂的项目结构，但它缺省的项目结构非常清晰。招聘新的开发者进入工程是非常简单的，因为Symfony2的代码对他们来讲非常熟悉。

• 现成的组件 - 遵循DRY理念... 没有人想去重新构造，所以我们也不想。我们广泛使用Symfony2的控制组件，该组件对于生成CLI命令、制作应用（调试工具栏）性能分析工具以及记录器等是一个非常棒的框架。

在使用之前，我们做了性能测试以确保其能够处理设定好的任务量。我们开发了概念验证模型并使用它运行JMeter。结果令人印象深刻-700req/s的响应时间最高50ms。这是我们确信，在我们的这个项目中可以使用这一复杂结构。

 

应用分析与监控

我们使用了Symfony2的工具来监控我们的应用。Symfony2有一个非常棒的性能分析组件，可以用来收集特定方法的执行时间，尤其是那些与第三方服务有关的方法。这样我们就可以找出潜在的弱点以及应用中最耗时的部分。

详细的日志是必须的。为此，我们使用PHP的Monolog库，它允许我们生成友好的、完全能够被开发者和系统管理者理解的格式化日志记录。必须时常谨记的是日志中要尽可能的增加细节，我们发现日志越详细越好。我们使用了不同的日志级别：

• 调试 - 一些将要产生的信息 - 比如在调用外部网络服务之前的请求信息；一些已经发生的信息-从API请求返回的响应；

• 错误 - 出现了错误但是请求流还没有停止（比如从第三方API返回的错误响应）；

• 危险 - 哎呦… 应用崩溃了。

在产品环境下，你能够看到Error级别日志，以及它下面的Critical级别日志。在开发/测试环境中，还有Debug日志可以看到。

我们将日志分成不同的文档（在Monolog库中他们被称为“通道”）。主日志文件用于存储所有应用范围的错误信息以及特定通道中的短日志信息。我们将来自不同通道中的详细日志信息保存在不同的文件中。

可扩展性

扩展平台上的应用层级并不是件难事。 HAProxy的性能并不会被常时间的消耗，我们只需要考虑避免单点故障(SPoF) 所需的冗余。

在此模式下只需要增加其他应用节点即可。

数据层

我们使用Redis和MySQL存储所有的数据。当Redis做为主数据存储时，MySQL则用于第三层的缓存存储。

Redis

当设计我们的系统时，我们需要考虑选择一个能够满足我们设定要求的数据库：

• 存储大量数据时（约2.5亿记录）不能降低性能

• 主要使用基于特定资源标识符的简单GETs（没有查找或复杂的SELECTs）

• 能够在单个请求中获取大量的资源以最小化延迟

经过一些调查，我们决定使用Redis。

• 我们进行的所有操作的复杂度为 O(1) 或 O(N)，N代表我们检索的主键数目。这意味着主键空间的大小不会影响到性能。

• 一次检索的主键数目大于100时我们大多使用MGET命令，与在一次回路中使用多个GETs相比，那样可以忽略网络延迟。

最近我们在主从复制模式下运行了两台Redis服务器。每个的配置为： Xeon E5-2650v2@2.60GHz, 128GB, SSD. 内存限制在100GB...内存经常被占满 :-)