使用HAProxy、PHP、Redis和MySQL支撑10亿请求每周架构细节.docxVIP

HAProxy 、PHP 、Redis 和 MySQL在这篇文章中，我将展现一个特别简洁的架构，使用支撑每周 10 亿恳求；除此之外，我仍将展现项目将来的横向扩展途径及常见的模式，下面我 HAProxy 、PHP 、Redis 和 MySQL 在这篇文章中，我将展现一个特别简洁的架构，使用 支 撑每周 10 亿恳求；除此之外，我仍将展现项目将来的横向扩展途径及常见的模式，下面我 们一起看细节； 状态： . 服务器 1. 2. 3. 3 个应用程序节点 2 个 MySQL+1 个备份 2 个 Redis 应用程序 . 1. 2. 3. 4. 10 亿恳求 应用程序每周处理 峰值 700 Symfony2 实例（平均工作日约 550 恳求每秒） 恳求每秒的单 30 毫秒 平均响应时间 Varnish ，每秒恳求超过 数据储备 1.2 万次（压力测试过程中获得） . 1. 2. 平台： Redis 储存了 1.6 亿记录，数据体积大约 MySQL 储存了 3 亿记录，数据体积大约 100GB ，同时它是我们的主要数据储备 300GB ，通常情形下它作为三级缓存层 .监视：1.2.Icinga Collectd应用程序.1.2.3.HAProxy + Keepalived VarnishPHP （ PHP-FPM ） + Symfony2 Framework数据储备.1.2.MySQL （主从配置），使用HAProxy 做负载均衡Redis（主从配置） . 监视： 1. 2. Icinga Collectd 应用程序 . 1. 2. 3. HAProxy + Keepalived Varnish PHP （ PHP-FPM ） + Symfony2 Framework 数据储备 . 1. 2. MySQL （主从配置），使用 HAProxy 做负载均衡 Redis （主从配置） 背景 大约 1 年前， 一个伴侣找到我并提出了一个苛刻的要求： 它们是一个飞速进展的电子商务初 创公司， 而当时已经预备向国际进展； 介于那个时候他们仍旧是一个创业公司， 初始解决方 案必需符合所谓的成本效益， 因此也就无法在服务器上投入更多的资金； 遗留系统使用了标 准的 LAMP 堆栈，因此他们拥有一个强力的 PHP 开发团队；假如必需引入新技术的话，那 么这些技术必需足够简洁， 不会存在太多架构上的复杂性； 那么， 他们当下的技术团队就可 以对应用进行长期的保护； 为了满意他们扩展到下一个市场的需求，架构师必需 为了满意他们扩展到下一个市场的需求， 架构师必需使用可扩展理念进行设计； 第一， 我们 注视了他们的基础设施： PHP的 Web 应用程序；这个初创公司并共享了一些支撑业务规律的通老系统使用了单模块化设计思路，底层是一些基于有很多所谓的前端网站，它们大多都使用了独立的数据库，用代码；毫不客气的说，长期保护这种应用程序肯定 PHP 的 Web 应用程序；这个初创公司 并共享了一些支撑业务规律的通 老系统使用了单模块化设计思路，底层是一些基于 有很多所谓的前端网站， 它们大多都使用了独立的数据库， 用代码；毫不客气的说， 长期保护这种应用程序肯定是一个噩梦： 由于随着业务的进展，有 些代码必需被重写， 这样的话， 修改某个网站将不行防止导致业务规律上的不一样， 这样一 来，他们不得不在全部 Web 应用程序上做相同的修改； 通常情形下， 这该归结于项目治理问题， 治理员必需对横跨多个代码库的那些代码负责； 基 于这个观点， 整改第一步就是提取核心的业务关键功能， 并将之拆分为独立的服务 （这也是 “separation of 本文的一个重点部分），也就是所谓的面对服务架构，在整个系统内遵循 concern ”原就；每个服务只负责一个业务规律，同时也要明确更高等级的业务功能；举个形象的例子也就是，这个系统可能是个搜寻引擎、一个销售系统等；REST APIJSON 格式；为了简洁起见，我们没有前端网站通过与服务交互，响应就基于挑选 SOAP ，一个开发者比较无爱的协议，由于谁都不情愿解析一堆的XML ；提取一些不会常常处理的服务， concern ”原就；每个服务只负责一个业务规律，同时也要明确更高等级的业务功能；举个形 象的例子也就是，这个系统可能是个搜寻引擎、一个销售系统等； REST API JSON 格式；为了简洁起见，我们没有 前端网站通过 与服务交互，响应就基于 挑选 SOAP ，一个开发者比较无爱的协议，由于谁都不情愿解析一堆的 XML ； 提取一些不会常常处理的服务， 比如身份验证和会话治理； 这是特别必要的一个环节， 由于 它们的处理等级比较高； 前端网站负责这个部分， 只有它们可以识别用户； 这样一来我们可