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　垂直应用架构方式

当然，垂直应用架构方式也存在一些弊端。系统管理员难以监控上下游应用的状态，例如，某些提供者已经失效了，而消费者只有在发起请求并捕捉到异常后，才能够判断出提供者的状态。此外，在高并发的场景下，如果系统没有设计熔断或流量管理机制，那么消费者将无法均匀地分发请求，只能使用轮询或者随机的负载均衡策略。

1.1.3　微服务与分布式架构

分布式系统最重要的特性之一就是解决服务与服务之间的通信问题。当单一服务被拆分后，各个服务之间的通信与交互复杂度增加。为使业务应用程序灵活地适应外界环境的变化，实现服务之间的松耦合，分布式架构设计的重点就转变为微服务设计。分布式架构将单一进程的应用做了拆分，形成独立对外提供服务的组件，每个组件通过网络协议对外提供服务。

在分布式架构下，服务之间的通信方式主要有3种。

第一种方式是通过Web服务基于简单对象访问协议（simple object access protocol，SOAP）实现，其本质是发送HTTP或HTTPS的扩展模块（extended module，XM）格式文本数据，缺点是通信协议比较“笨重”，难以管理。使用SOAP发送HTTP或HTTPS的可扩展标记语言（extensible markup language，XML）格式文本数据时，消费者与提供者是直连的，如果消费者类型和提供者类型比较多，那么管理起来就很棘手。例如，一个消费者要调用不同提供者的接口实现访问，假设该访问还有顺序要求，当其中一个提供者接口不可用时，将会造成本次访问失败。消费者需要对每个提供者实现容错机制和负载均衡。Web服务点对点直连架构方式如图1-5所示。

在图1-5中，所有服务都采用点对点直连的通信方式，拓扑图看起来像一个五角星的结构，消费者将直接向提供者发起请求。这里的通信协议不局限于SOAP、HTTP，报文格式也不局限于XML、JSON格式。在这种架构下，每个集群需要配置其他集群的实例地址信息。如果这些实例地址经常变动，那么管理起来将会非常麻烦。

图1-5　Web服务点对点直连架构方式

第二种方式是通过企业服务总线的方式完成服务之间的通信调用。但通常情况下，企业服务总线没有注册中心，因而很可能“牵一发而动全身”，服务变更进而影响到总线变更。企业服务总线架构方式如图1-6所示。

图1-6　企业服务总线架构方式

在图1-6中，服务与服务之间的请求是通过企业服务总线进行派发的，企业服务总线配置了每个集群的实例地址，当某一实例地址发生变动时，只需要在企业服务总线统一维护。企业服务总线扮演的角色是代理者，消费者的所有请求都通过企业服务总线进行代理，转发给提供者。由于通信过程中可能产生报文堆积，企业服务总线需要依赖消息队列机制保障即时通信能力。例如，在Apache Kafka分布式消息队列系统中，企业服务总线统一维护负载均衡策略，并监控每个实例的运行状态。

第三种方式是建立注册中心，服务之间的寻址由注册中心协同完成，服务之间使用轻量级的通信协议直接通信。消费者可以从注册中心订阅提供者的状态，及时获取变更通知。该通信方式也是本书重点介绍的对象。注册中心架构方式如图1-7所示。

在图1-7中，集群启动时，商品管理系统、客户管理系统和物流管理系统需要向注册中心注册自己的服务和角色。订单管理系统需要从注册中心获取对应服务实例信息，然后由订单管理系统直连提供者实例，发起请求并完成调用。注册中心还负责监控集群的运行状态，保存统一配置。因为订单管理系统直连提供者，所以实际上负载均衡策略需要订单管理系统自己实现。

图1-7　注册中心架构方式

纵观计算机服务扩容的发展历程，我们可以看出计算机服务扩容经历了从单一应用架构到集群架构，从集群架构到垂直应用架构，最后到微服务与分布式架构的发展过程。