我正处于一个中等规模的应用程序的规划阶段——经过一些讨论和会议，我和我的同事达成了一个结论，我们将在这个应用程序中使用SOA。以下是简要计划…
四层架构…
|-------- database (NoSQL + SQL polyglot store) --------|
|-------- python for all the heavy business logic --------|
|-------- php would talk to python using SOA and render HTML --------|
|-------- front-end (html+css+js) --------|
- 我们将有两个python实例(2台机器)，一个将作为龙卷风服务器用于实时协作，另一个将服务于非实时业务逻辑。
- PHP将通过定义良好的RESTful接口与非实时机器通信。
- 实时协作机将直接与浏览器中的JS客户端对话
我的问题是……
- 你看到设计中有什么直接的缺陷吗?
- 您推荐的RESTful通信的最佳传输介质是XML、JSON还是protobuf (protobuf被google使用) 你认为在Python和PHP层之间缓存是一个好主意吗?PHP不会做任何直接的数据库通信——只通过Python。
- 还有什么需要指出的吗?
—UPDATE—
虽然我不允许透露应用程序的细节，但我想说的是，该应用程序是一个高度本质上是协作的，在浏览器中处理大量的文本编辑。有点像谷歌文档——但不完全是。
PHP层之所以重要是因为…
我们需要保持Python层完全独立于HTML模板。这一层不应该甚至不知道我们在做一个网络应用。这样做的原因是我们有多个模板。高级浏览器的html相当复杂有很多控件，鼠标手势事件和ajax。旧版本浏览器的模板(IE-6、7、FF-2、3等)简单且"只读"——没有ajax交互。
还有第三组模板，我们需要用于应用程序的Adobe AIR组件。该公司还计划发布移动&桌面版本的应用程序，如果它变成成功。
由于这个原因，我们不能在python层引入HTML。我们能做的是用另一个python层替换PHP层(用django之类的)来处理模板。但我们认为在PHP中可以更好地处理模板因为它非常适合模板化。我们不打算添加任何复杂的逻辑——只是展示机制
关于您的想法的一些想法:正如Mikko的评论所提到的，PHP层似乎是多余的。目前还不清楚它实际将实现什么功能，特别是就它在服务层之上提供的抽象而言。现代应用程序设计趋向于用javascript+html实现UI。由于您已经承诺通过http公开业务逻辑，因此它还必须完成所有输入验证和认证/认证，因此php中间件不会有太多工作要做。
一个真正的RESTful服务不会规定它支持的输出，相反，它会尽最大努力满足请求的Accept-Content-Type。至少在Python中，支持json通常是最简单的。Protobuf还很年轻，所以除非你真的需要它提供的严格类型，否则我不会使用它。但是，从自描述的角度来看，XML是有用的，如果前端和后端是独立开发的，那么XML可能是首选。