最近在读Martin Folwer的企业应用架构。这是一本2004年的书，现在看来很多观点都已经成为流行的框架了。虽然我并没有在开发企业级应用，但还是被这本书深深吸引。在讨论分布式对象的时候，Martin表示并不看好分布式对象，因为在大多数情况下，分布式部署对象的效率，总是比在单个节点部署所有对象然后配合集群的情况要差。这让我重新考虑了目前正在进行的前端应用和后台服务分开部署的尝试。

在传统Java的Web应用中，前端页面和后台逻辑被统一包装在一个WAR形式的压缩包中，然后通过应用服务器统一部署。从应用性能的角度考虑，也可以采用动静分离，也就是把相应前端HTML页面、JS脚本和CSS样式文件单独部署在CDN或者支持高速读取的HTTP服务器上，然后单独部署后台服务，配合缓存服务器进行截获式、或者嵌入式缓存支持，以提高性能。

比如说我就很喜欢ElasticSearch的监测模块，设计的很好，可以通过各种外部扩展来图形化ES集群的运行状态，如ElasticHQ就只是由HTML、JS和CSS组成的前端页面，然后通过访问后端监测服务来读取数据。这种noBackend风格的设计正是我追求的一个目标，通过分离Web应用和后台服务，提高系统的扩展性。但实际上存在两个困难：一是服务器端必须实现CORS跨域资源共享协议，二是可用于扩展的Web应用必须足够简单。在实际的项目中，第二个困难很难克服，因为页面需要注入URL和参数，而且本身还使用了HTML模板，无法通过JS完成所有的工作。一种方案是在HTTP服务器中安装脚本模块，通过脚本实现简单的HTML模板，比如说安装了Lua模块的Nginx。

把HTTP前端应用和后台服务分离本身是符合分层架构的要求的，但是如果前端植入了脚本，是否属于Martin所描述的分布式对象的范畴呢？前提是植入的脚本不能涉及后台服务，那么所有的服务还是统一由客户端运行的前端页面发出，那么至少在后端并不存在分布式对象的情况。但如果植入的脚本依赖后台的某个服务，那么单次页面调用势必造成两次远程调用，倒不如还是在后端来实现脚本需要的功能会比较好。

因为我需要的只是一个HTML模板和少量的配置读取，使用Lua脚本应该绰绰有余了。