一套完整的云应用、服务架构通常可以分为5层。

·负载均衡层（Load Balancing）

·应用服务层（Application Server）

·缓存服务层（Caching Server）

·数据库服务层（Database Server）

·云存储层（Cloud Storage）

图：云应用的五层架构

（1）负载均衡

负载均衡层（Load-Balancing Layer，LB Layer）的实现是5层架构中最早面对用户的，也是相对最容易实现的。通常为了避免SPOF，至少设置两台LB服务器（通常在两台物理主机之上，以避免单机硬件故障导致SPOF）。整个扩展设置过程通常可以完全自动化，例如通过DNS API来配置新增或删除LB节点。最常见的LB解决方案有HAProxy或Nginx，它们通常可以支持跨云平台的负载均衡（即服务器及其他层跨云，当然这种架构的设计与实现复杂度会急剧增高。前面我们提到过的Cloud Bursting就是典型的跨云基础架构模式）。智能的LB层实现能做到根据应用服务器层的健康状态、负载状态来动态引流，以确保系统真正实现均衡的负载。

云服务提供商通常会提供现成的LB服务，例如AWS的ELB（Elastic Load-Balancer）、RackSpace的CLB（Cloud Load-Balancer），还有VMware vCloud Air Gateway Services都提供强大的LB服务。

（2）应用服务

负载均衡层之下就是应用服务器层，它负责处理LB转发的用户请求并返回相应的数据集。通常数据集分为静态数据与动态数据。前者大抵可以在缓存层保留以降低应用服务器及数据库服务器的负载（见上图）并加速客户端获得返回数据，后者通常需要底层的数据库层配合来动态生成所需数据集。本层的扩展实现通常通过对现有服务器的负载进行监控（主要是CPU，其次为内存、网络、存储空间），并根据需要进行横向或纵向扩展。横向扩展（Scale-out）通常是上线同构的服务器（物理机或虚拟机），以降低现有服务器或服务器集群负载；纵向扩展（Scale-up）则是对CPU、内存、网络、存储空间进行升级。横向扩展通常不需要系统下线，但是纵向扩展则要求被升级的主机（可能是虚拟机或容器）重启。

应用服务层因为涉及应用服务逻辑，当多台服务器协同工作时，还需要确保它们之上运行的服务的一致性。这个DevOps问题通常是作为PaaS层一部分任务或是数据中心中的M&O组件来实现一致化的应用升级、部署等。

（3）缓存

缓存层既可能存在于应用服务器层与数据库服务器层之间，也可能在应用服务器层之上。前者可以被用来降低数据库服务器的重复计算与网络负载。后者则被用来降低应用服务器负载与网络带宽消耗。缓存技术应用的范围极广，从Web服务器、中间件、数据库都大量使用缓存以降低不必要的重复计算，进而提高系统综合性能。

缓存层的扩展性实现在避免出现SPOF基础之上（单个节点的缓存服务器或与应用服务器共享节点的方式在生产环境中都是不可取的），主要是如何实现多缓存节点间的负载均衡。最常见的分布式简单缓存实现是memcached（全球最繁忙的20个网站中，有18个使用了memcached3），在多台memcached服务器间形成了一张哈希表，当有新的缓存节点加入或老的节点被删除（或下线）时，现有节点并不需要全大规模改动来生成新的哈希表（这一算法也称作Consistent Hashing Algorithm，一致性哈希算法）。对于哈希表中数据的替换与更新，Memcached采用的是TTL（Time-To-Live）与LRU（Least-Recently-Used）模式。对于更复杂的高扩展性缓存系统设计，属于NoSQL类的CouchBase数据库提供了更为健全的企业级缓存功能实现，例如Data Persistence（数据常存）、Auto-Reblanacing（自动负载均衡）、多租户支持等。

后面的两层架构我们将单辟文章来向诸位单独解读。