下载掌阅APP，畅读海量书库
立即打开
当前，网络负载均衡层已足够成熟，能够基于协议头标识、加权计算和限流设置对请求进行分发和处理。然而，在数据库行业中，依然没有适用于SQL的负载均衡层，不能对SQL进行解析，这意味着无法满足数据库系统对请求分发粒度的要求。为弥补数据库行业负载均衡层存在的缺陷，解决之道是开发出能够理解SQL的智能SQL负载均衡器。
除了常见的负载均衡器功能（如高性能、流量治理、服务发现和高可用性），智能SQL负载均衡器还具有分析SQL和计算查询开销的功能。
在清楚SQL的特征和查询到开销后，智能SQL负载均衡器接下来采取的措施是给计算节点乃至存储节点指定标签。当然，可使用自定义标签，如SELECT && $cost<3、UPDATE && $transaction=true && $cost<10和(SELECT && GROUP) || $cost>300。
智能SQL负载均衡器可将要执行的SQL同预定义的标签相关联，进而将请求分发给正确的计算节点或存储节点。图2.2展示了智能SQL负载均衡器的部署架构。
图2.2 智能SQL负载均衡器的部署架构
在图2.2中，中间部分是使用智能SQL负载均衡器的分布式数据库集群架构，其中复杂的负载均衡层确保高可用性，这是通过存活（keepalived）消息和虚拟互联网协议（virtual internet protocol，VIP）等组织和管理方法实现的。
右侧部分是智能SQL负载均衡器的内核设计。通过模拟目标数据库协议，智能SQL负载均衡器实现了负载均衡层代理，使得访问智能SQL负载均衡器的方式与直接访问目标数据库（MySQL、PostgreSQL等）的方式是一致的。除了上述理解SQL的功能，节点管理部分还包含其他基本功能，如动态配置、心跳监视器、数据库发现和负载均衡器。
左侧部分是一个标签配置示例，包含计算节点和存储节点的用户定义标签。标签存储在智能SQL负载均衡器的注册中心中，因此计算层和存储层只需负责处理请求。另外，这两层无须为负载均衡功能费心，因此预期的SQL请求返回时间相当接近将请求发送给相应计算节点或存储节点所需的时间。这种改进解决了大规模数据库集群中存在的痛点，具体作用如下：
● 极大地改善了系统的QoS，让整个集群能够更平稳地运行，并最大程度地降低了出现单节点性能消耗器的可能性；
● 以更细致的方式有效地隔离了事务计算、分析计算和其他操作，从而让集群资源分配更为合理，用户可方便地根据标签描述定制节点的硬件资源。
接下来将介绍如何使用边车模式来集成负载均衡器，以改善性能和可用性。
众所周知，对系统来说，关键是性能和可用性，而非或花里胡哨的额外功能。然而，添加负载均衡层后，网络跳数可能增加，性能和可用性都可能受到影响。另外，系统还需要添加一个虚拟互联网协议或负载均衡器，以解决负载均衡层本身存在的高可用性问题，这将导致系统更加复杂。对于新增负载均衡层带来的问题，边车模式是解决它们的“银弹”。
边车模式指的是在每个应用服务器上都添加一个负载均衡器，该负载均衡器的生命周期与应用本身相同：应用启动时，其负载均衡器启动；应用被销毁时，其负载均衡器消失。每个应用都有自己的负载均衡器，这确保了负载均衡器的高可用性。这种方法也最大程度地减少了性能耗损，因为负载均衡器和应用部署在同一个物理容器中，这意味着远程过程调用（remote procedure call，RPC）变成了进程间通信（interprocess communication，IPC）。
除了改善性能和高可用性，边车模式还将应用与数据库SDK解耦，这让运维团队能够随时升级边车和数据库，因为这种设计使得升级不会影响业务应用。由于边车是独立于应用的，因此只要边车采用的是金丝雀发布（canary release），它对应用开发人员来说就是完全透明的。不同于被连接到应用中的类库，使用边车可更有效地统一在线应用版本。
实际上，流行的服务网格概念就将边车作为数据平面，以处理系统中的东西流量和南北流量，它还使用控制平面来向数据平面发送指令，以控制流量或完成透明的升级。
边车模式存在的最大问题是其高昂的部署和管理开销，因为需要为每个应用都部署边车。由于需要部署大量的边车，因此必须测量其资源占有量和体量，这至关重要。
提示 良好的边车应用必须是极度轻量级的。
为降低边车的部署和管理开销，一种不错的方式是使用Kubernetes。Kubernetes可将负载均衡器和应用镜像放在Pod中或使用DaemonSet，以简化部署过程。Pod开始运行后，可将边车视为操作系统不可分割的部分，而应用将通过本地主机（localhost）来访问数据库。
对应用来说，总是有一个容量有限但永远不会崩溃的数据库。Kubernetes早已成为云原生操作系统的事实标准，因此在云领域，使用Kubernetes在云端部署边车是绝对可以接受的。而面向服务的云原生可编程流量与服务网格一起，彻底改变了服务云市场。
当前，云原生数据库的重心依然是云原生数据存储，它没有像服务网格这样让人能够通过网络平稳地交付适配器。基于边车模式的数据库网格由Kubernetes和智能SQL负载均衡器组成，它无疑将给云原生数据库带来巨大的影响，同时能够更好地分析SQL。
数据库网格的3个核心组件是负载均衡层、可编程流量和云原生。图2.3展示了数据库网格的架构。
图2.3 数据库网格的架构
可以看到，控制平面管理着负载均衡层、计算层和存储层，它还可能管理着所有的数据库流量。控制平面包含注册中心和管理控制台。注册中心用于服务发现的分布式协调、存储元数据（例如标签定义以及计算节点和存储节点的映射信息）以及存储集群中各个组件的操作状态。在管理控制台中，节点管理和可观察性是云原生分布式数据库的关键功能，它们通过云管理和遥测（telemetry）技术管理整个集群的资源。除资源控制外，管理控制台还让SQL命令能够操作集群配置。用于控制分布式集群的SQL不同于用于操作数据库的SQL，因此我们定义了一种新的SQL——分布式SQL（distributed SQL，DistSQL），用于管理分布式集群。
DistSQL是一种辅助SQL，它还与一些必要的功能（如流量管理和可观察性）一起对标签进行管理（例如定义标签、修改计算节点和存储节点之间的匹配关系等），以改变集群流量的方向。DistSQL强大且灵活，让控制平面能够通过编程动态地修改整个集群的流量控制和路由器。DistSQL很像服务网格的数据平面，但数据库网格位于不同的层。服务网格依赖的是网络流量，无须明白SQL语义，而数据库网格添加了云原生数据库流量控制。
实际上，数据库网格的数据平面就是能够理解SQL的负载均衡层，因为它接收控制平面发送的命令，并执行如限流、熔断和基于标签的路由等操作。
数据库网格能够将不同的环境完全隔离，让运维人员只需将数据平面的网络配置改为分布式数据库的网络配置，再通过修改使其适合开发环境、测试环境或生产环境；开发人员只需开发面向本地主机的数据库服务，而根本不用考虑与分布式数据库相关的问题。基于数据库网格提供的云原生服务功能，开发人员可完全忽略具体的数据库网络地址，这极大地提高了他们的工作效率。