适合于云端计划的应用架构

基于云的应用与运行在私有数据中心的应用之间最大的差别就是可扩展性。云提供了按需扩展的能力，能够根据负载的波动对应用进行扩展和收缩。但是传统应用要充分发挥云的优势，并不是简单地将应用部署到云上就万事大吉，而是需要根据云的特点围绕可扩展性重新进行架构设计，近日AppDynamics的开发布道者Dustin.Whittle撰文阐述了适合云端部署的应用架构，对我们传统应用往云端部署有很大的启发和借鉴意义。

 

应用的架构

 

Dustin.Whittle给出了云应用的示例架构，它具有高度的可扩展性，如下图所示：

 

 

 

适合于云端部署的应用架构

 

 

 

 

在这个图中，应用按照分层的理念进行了拆分，分别介绍如下：

 

客户端层：客户端层包含了针对目标平台的用户界面，可能会包括基于Web的、移动端的甚至是胖客户端的用户界面。一般来讲，这可能会是Web应用，包含诸如用户管理、会话管理、页面构建等功能，但是其他客户端所发起的交互都需要以RESTful服务的形式调用服务器。

 

服务：服务器包含了缓存服务以及聚合（aggregate）服务，其中缓存服务中持有记录系统（system of record）中最新的已知状态，而聚集服务会直接与记录系统交互，并且会执行一些破坏性的操作（会改变记录系统中的状态）。

 

记录系统：记录系统是领域特定的服务端，它会驱动业务功能，可能会包括客户管理系统、采购系统、预定系统等等，这些很可能是遗留系统，你的应用需要与其进行交互。聚集服务要负责将你的应用从这些特有的记录系统中抽象出来，并为你的应用提供一致的前端接口。

 

ESB：当记录系统发生数据变化的时候，它需要触发到指定主题（topic）的事件，这就是事件驱动架构（event-driven architecture，EDA）能够影响应用的地方了：当记录系统进行了一项其他系统可能感兴趣的变更时，它会触发一个事件，任何关注记录系统的其他系统会监听到这个事件，并作出对应的响应。这也是使用使用主题（topic）而不是队列（queue）的原因：队列支持点对点（point-to-point）的消息，而主题支持发布-订阅（publish-subscribe）的消息或事件。当与遗留系统进行集成时，我们很期望这些遗留的系统能够免遭负载的影响。因此，我们实现了一个缓存系统，这个缓存系统维持了记录系统中所有最新的已知状态。缓存系统会使用EDA的规则监听记录系统的变化，它会更新自己所保存数据的版本，从而保证与记录系统中的数据相匹配。这是一个很强大的策略，不过会将一致性模型变为最终一致性，也就是说如果你在社交媒体上发布一条状态的话，你的朋友可能在几秒钟甚至几分钟之后才能看到，数据最终是一致的，但有时你所看到的与你的朋友所看到的并不一致。如果能接受这种一致性的话，就能在很大程度上实现可扩展性的收益。

 

NoSQL：在数据存储方面，有很多的可选方案，但如果要存储大量数据的话，使用NoSQL存储能够更容易地扩展。有多种NoSQL存储可供选择，不过这要匹配所存储数据的特点，如MongoDB适合存储可搜索的数据，Neo4j适合存储高度互相关联的数据，而Cassandra适合存储键/值对，像Solr这样的搜索索引有利于加速对经常访问数据的查询。