第1章

分布式架构与中台架构简介

在过去的几十年里，互联网改变了我们的生活方式。通过互联网提供的服务通常是由复杂的软件系统提供支持的，这些软件系统跨越大量服务器并且通常在地理位置上相距很远。这种系统在计算机科学术语中被称为分布式系统。为了正确、高效地运行大型系统，系统内的进程应能够以容错方式正确实现任务调度，进程间遵守的协议被称为分布式协议。为了更好地理解分布式系统中进程协作的原理，我们先来介绍计算机服务扩容的发展历程。

1.1

计算机服务扩容的发展历程

早期的互联网信息系统通常为单节点架构，随着用户数量的增多，系统逐渐发展为分布式架构。

1.1.1　从单一应用架构到集群架构

早期的互联网信息系统业务相对简单，应用访问量较少，软件服务提供商通常将所有功能都部署在单一服务中，以减少部署节点的成本。在这个阶段，数据库性能优化是系统优化的关键。这种单一服务部署的模式被称为单一应用架构方式，如图1-1所示。

图1-1 单一应用架构方式

采用单一应用架构方式时，用户请求直接发送到单一服务，然后由单一服务处理请求并对数据库进行操作。这里的数据库也可以部署在独立服务器上面。

当信息系统业务成熟、应用访问量增多时，在单一应用架构方式下服务器很快会遇到性能瓶颈。这个时候，增加服务器是解决问题最高效的方式之一。例如，可以将应用和数据库分别部署在专用服务器上，该方式不仅能提高单机负载，也能增加系统的稳健性，减少系统宕机风险。

当应用访问量继续增加时，可以通过再次增加应用服务器的方式，将应用分别部署在不同的服务器上，从而提升前端应用的访问效率。在这个阶段，各个应用服务器相互隔离，依赖唯一的数据库统一提供服务，如图1-2所示。

图1-2　集群架构方式

采用集群架构方式时，用户请求经过统一路由器后，按照负载均衡策略，被分发给集群中相对空闲的服务实例进行处理。这些集群中的服务实例负责处理请求，但仍将访问同一个数据库。

应用被集群化管理后，数据库的短板逐渐显现，单节点部署的数据库无法完全承担集群化应用的数据处理请求。为了优化单节点数据库负载，系统引入数据库缓存机制，把常用数据提前加载到内存当中；引入读写分离机制来缓解数据库的压力，把查询操作放到一个数据库实例上进行，把新增、删除和修改（简称增删改）操作放到另一个数据库实例上进行，并在两个数据库之间建立同步机制。所以，当单节点数据库不能解决性能问题时，多实例部署数据库逐渐成为趋势。多实例部署数据库的架构如图1-3所示。

图1-3　多实例部署数据库的架构

在图1-3中，用户请求经过统一路由器后，按照负载均衡策略，被分发给集群中相对空闲的服务实例进行处理。这些集群中的服务实例会进一步细分业务逻辑，增删改操作会直接请求数据库主库，纯粹的查询操作会直接请求数据库备库。主库将依据同步策略将变化的数据同步给备库。

1.1.2　从集群架构到垂直应用架构

随着企业互联网业务应用的不断发展延伸，企业建立业务生态圈后，业务应用数据量不断增加和规模不断扩大。此时，可以分别将应用、数据库拆分成几个互相独立的应用和数据库，部署在不同的服务器节点上，从而提升系统性能和吞吐量，这种模式通常被称为垂直应用架构方式。

例如，电商系统在垂直应用架构方式下，根据业务的类型大体上可以分为4个集群，即客户管理系统集群、商品管理系统集群、订单管理系统集群和物流管理系统集群，每个集群都拥有自己的数据库集群，如图1-4所示。从运维层面来说，应用与数据库彼此相对独立，不管是业务实例集群还是数据库集群，通常都部署在独立服务器上面。例如，订单管理系统需要访问其他3个系统时，可通过点对点直接建立连接，实现数据互通。

图1-4　垂直应用架构方式