一个分层架构设计的应用通常包含很多个逻辑层(Logical Layer)和物理层(Physical Tier)。分层架构这个名字里的层(Tier)，特指“物理层”(Tier)，每个物理层是由很多台机器构成，可以是部署在局域网下一个子网的虚拟机或裸金属机器。
分层是一种职责分离和依赖管理的方式：每层都有自己特定的职能；高层的服务可以调用低层的服务，但是反过来不行。
物理层运行在不同的机器上，一层可以直接调用另一层，或者通过消息队列进行通信。尽管每个逻辑层都可以被部署在独立的物理层，但不是必须的。为了节省资源，一个物理层可以部署多个逻辑层。通过物理层的隔离，架构的扩展性和容错性会更强，负面作用是会导致额外的网络通信延迟。
传统的三层应用（物理层）分别包含展示层、中间层、数据库层。中间层是可选的，较为复杂的应用通常会超过三层。上面的架构图中就包含了两个中间层，分别实现了不同的功能。
一个分层架构的应用，从逻辑层的视角来看，可以分为两类：
封闭架构严格限制了逻辑层之间的依赖关系，架构更为清晰。缺点是一些中间层只可能只对请求进行转发，导致不必要的网络交互。
应用场景
分层架构常见于IaaS系统，这类系统中每个物理层都运行在一组独立的物理机上。不过IaaS系统也不必采用纯粹的分层架构，毕竟架构中的某些部分使用现成的服务优势更大，比如缓存系统、消息队列和数据存储服务。
在以下场景中可以考虑分层架构：
- 简单的网络应用。
- 将本地部署的应用迁移上云。
- 本地部署应用与云服务应用混合开发的场景。
传统公司里本地部署（自家机房）的系统通常采用分层架构，各家云服务商也提供了裸金属服务器供传统企业上云。
架构优势
- 云服务和本地部署的可移植性高。
- 对于大多数开发者而言学习门槛低。
- 从传统架构模型演进过来的。
- 支持多种多样的部署环境，比如win/linux。
有哪些挑战
- 开发过程中，中间层很容易沦为对数据库的CRUD，只是增加了网络延迟。
- 按照单体架构的方式设计导致功能无法独立发布。
- 在IaaS管理整个系统比使用现成的服务维护成本高。
- 在大型系统中，网络安全会成为问题。
最佳实践
- 使用自动扩容功能，可以应对工作负载的变化。
- 使用消息队列把物理层进行解耦。
- 把半静态资源缓存起来。
- 数据库层配置成高可用模式。
- 在网络层(Web Tier)之前加一层防火墙(WAF)。
- 给每个物理层分配一个子网，不同子网之间只开放特定的ip port，以提高安全性。
- 限制数据层的访问，比如只允许中间层访问数据，不允许网络层(Web Tier)访问。
运行在虚拟机上的分层架构
这里我们给出一个在虚拟机上推荐的分层架构：
每个物理层均包含至少两台虚拟机，以避免单点故障；通过负载均衡，把请求分发到不同的虚拟机上；如果要支持横向扩容，我们可以在一个物理层配置更多虚拟机。
每个物理层都有自己的子网，所以这些虚拟机的内网IP在一个网段里。这样的优势是配置网络安全规则很方便，路由表也很容易配置。
网络层和业务逻辑层是无状态的。任何一个虚拟机都可以处理到达该层的请求。数据层是多备份的数据库系统。比如主从版本的MySQL、TiDB，或者云上Dynamodb等。
每个物理层都有自己的 inbound 和 outbound 网络安全规则，比如数据层可以设置只允许业务逻辑层的虚拟机IP进行访问；
补充说明
- 分层架构并不限定于3层，复杂的系统通常会有很多层；七层负载均衡或四层负载均衡都是很常见的选择。
- 层定义了扩展性、可靠性和安全性的边界；如果服务的SLA不一样，可以考虑放到不同的物理层。
- 架构中很多地方可以采用现成的服务，尤其是通用的缓存、消息队列、存储、数据库服务。
- 生产环境的虚拟机要禁止SSH或RDP直连；通常情况下，运维/开发人员可以登陆一个跳板机，跳板机可以直连生产环境虚拟机；对于跳板机，我们通常也会设置网络规则，比如只允许特定的公网IP通过SSH或RDP访问。
- 对于核心服务，多机房容灾也是要考虑的点。
