所谓的应用后台就是指机房。机房架构是一个庞大的工程，你可能听说过很多大型互联网公司曾在各种技术峰会上介绍它们的“三地五中心”多机房，甚至是全球异地多活机房等，这些“高大上”的话题讨论的都是机房架构的内容。机房最简单的形式是单机房， 本章会用大量篇幅来讨论它。虽然拥有亿级用户的互联网应用的底层不大可能采用这种架构，但是它是我们了解机房架构的重要基础。首先，在建设多机房前，我们需要熟悉一个机房的“五脏六腑”，只有非常清楚地知道单机房架构的技术细节，才能轻车熟路地构建多机房架构；其次，各互联网公司的多机房架构体系并不是一步到位搭建的，而是随着用户的逐步扩张一步步演进而来的。让我们先抛开那些知名互联网公司今天的荣耀，回到它们过去艰难的岁月，一般而言，这些公司在创业起步阶段的特点如下。
- 用户量级相对较小。
- 研发工程师较少。
- 产品营收能力较差，现金储备紧张。
如果初创互联网公司选择直接构建多机房架构，则将是一件非常困难的事情。因为它要求公司：
- 已拥有海量用户，且难以接受机房级别的故障。海量用户意味着有海量数据、海量请求，单机房的资源已经无法满足业务需求，需要拓展到多机房；而且，如果发生了机房级别的不可用故障，则等于整个应用完全不可用，将会给公司造成难以承受的巨大损失。
- 研发工程师较多，且有多机房领域的架构师。多机房需要应对数据一致性、机房调度等复杂的技术问题，需要有大量专人投入建设。
- 现金流畅通。每个机房的选址、光缆铺设、电路铺设、设备采购、网络带宽、服务器维护，甚至防火、防水等都需要消耗大量的经济成本，这就不得不要求公司有一定的现金储备。
综上所述，从投入产出比的角度来说，初创互联网公司一般先使用单机房充当应用后台。典型的单机房架构如图1-1所示，其中包含各种重要角色。
假设这个单机房架构服务于某互联网社交应用Friendy，并为用户提供Web端和移动客户端两种使用途径，其中各角色的功能如下。
- DNS服务器负责将用户访问Friendy的域名映射为公网IP地址（或称为整个机房的入口IP地址），然后用户请求就可以通过IP协议进入机房了。
- LVS提供对外的公网IP地址作为机房的入口，同时作为四层负载均衡器将用户请求分发到Nginx集群。
- Nginx作为七层负载均衡器，根据HTTP(S)请求的协议头或URL路径规则将用户请求转发到对应的业务HTTP服务器。
- 业务服务层的HTTP服务真正处理用户请求，根据不同的HTTP URL向RPC服务发送业务逻辑处理请求。
- 业务服务层的RPC服务执行核心业务逻辑。如果业务逻辑涉及读/写数据，那么它会进一步访问数据层；如果业务逻辑涉及与其他RPC服务的交互，那么它也会调用其他RPC服务。
- 存储层是所有存储系统的集合，包括分布式缓存、关系型数据库、NoSQL数据库等。分布式缓存提供数据缓存，用于应对高并发的读请求访问；关系型数据库作为持久化存储保存用户数据（需要注意的是，若无特殊说明，本书后续章节提及的数据库均为关系型数据库），常见的关系型数据库包括MySQL、SQLite、SQL Server等；NoSQL数据库是一个大类，被应用于关系型数据库无法发挥作用的场景。
- 服务发现负责保存每个服务的动态访问地址列表，以便其他服务可以快速查找到某服务的访问地址。其功能与DNS相似。
- 消息中间件作为常用的研发中间件，用于请求异步执行、服务间解耦、请求削峰填谷。
在简单了解了单机房架构的组成角色之后，接下来将详细介绍各角色的相关技术与技术选型，以便读者对这些角色存在的意义能有更深刻的理解，甚至将来可以以架构师的身份主导一个互联网应用的机房建设工作。
