前端网站通过一个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日志可以看到。