在这篇文章中，我将展示一个非常简单的架构，使用 HAProxy、PHP、Redis 和 MySQL支撑每周 10 亿请求。除此之外，我还将展示项目未来的横向扩展途径及常见的模式，下面我们一起看细节。状态：服务器1. 3 个应用程序节点2. 2 个 MySQL+1 个备份3. 2 个 Redis应用程序1. 应用程序每周处理 10 亿请求2. 峰值 700 请求每秒的单 Symfony2 实例（平均工作日约 550 请求每秒）3. 平均响应时间 30 毫秒4. Varnish，每秒请求超过 1.2 万次（压力测试过程中获得）数据存储1. Redis 储存了 1.6 亿记录，数据体积大约 100GB，同时它是我们的主要数据存储2. MySQL 储存了 3 亿记录，数据体积大约 300GB，通常情况下它作为三级缓存层平台： 监视：1. Icinga2. Collectd应用程序1. HAProxy + Keepalived2. Varnish3. PHP（PHP-FPM）+ Symfony2 Framework数据存储1. MySQL（主从配置），使用 HAProxy 做负载均衡2. Redis （主从配置）背景大约 1 年前，一个朋友找到我并提出了一个苛刻的要求：它们是一个飞速进展的电子商务初创公司，而当时已经准备向国际进展。介于那个时候他们仍然是一个创业公司，初始解决方案必须符合所谓的成本效益，因此也就无法在服务器上投入更多的资金。遗留系统使用了标准的 LAMP 堆栈，因此他们拥有一个强力的 PHP 开发团队。假如必须引入新技术的话，那么这些技术必须足够简单，不会存在太多架构上的复杂性；那么，他们当下的技术团队就可以对应用进行长期的维护。为了满足他们扩展到下一个市场的需求，架构师必须使用可扩展理念进行设计。首先，我们审视了他们的基础设施： 老系统使用了单模块化设计思路，底层是一些基于 PHP 的 Web 应用程序。这个初创公司有许多所谓的前端网站，它们大多都使用了独立的数据库，并共享了一些支撑业务逻辑的通用代码。毫不客气的说，长期维护这种应用程序绝对是一个噩梦：因为随着业务的进展，有些代码必须被重写，这样的话，修改某个网站将不可避开导致业务逻辑上的不一致，这样一来，他们不得不在所有 Web 应用程序上做相同的修改。通常情况下，这该归结于项目管理问题，管理员必须对横跨多个代码库的那些代码负责。基于这个观点，整改第一步就是提取核心的业务关键功能，并将之拆分为独立的服务（这“也是本文的一个重点部分），也就是所谓的面对服务架构，在整个系统内遵循 separation of concern”原则。每...
