命名原则

介绍Pigsty默认采用的实体命名原则

名之必可言也，言之必可行也。

概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。本文介绍 Pigsty 中的相关实体，以及其命名所遵循的原则。

结论

Pigsty中，核心的四类实体为：集群（Cluster），服务（Service），实例（Instance），节点（Node）

  • 集群（Cluster） 是基本自治单元，由用户指定唯一标识，表达业务含义，作为顶层命名空间。
  • 集群在硬件层面上包含一系列的节点（Node），即物理机，虚机（或Pod），可以通过IP唯一标识。
  • 集群在软件层面上包含一系列的实例（Instance），即软件服务器，可以通过IP:Port唯一标识。
  • 集群在服务层面上包含一系列的服务（Service），即可访问的域名与端点，可以通过域名唯一标识。
  • 集群的命名可以使用任意满足DNS域名规范的名称，不能带点（[a-zA-Z0-9-]+）。
  • 节点命名采用集群名称作为前缀，后接-，再接一个整数序号（建议从0开始分配，与k8s保持一致）
  • 因为Pigsty采用独占式部署，节点与实例一一对应。则实例命名可与节点命名保持一致，即${cluster}-${seq}的方式。
  • 服务命名亦采用集群名称作为前缀，后接-连接服务具体内容，如primary, replica,offline,delayed等。

entity-naming.png

以上图为例，用于测试的数据库集群名为“pg-test”，该集群由一主两从三个数据库服务器实例组成，部署在集群所属的三个节点上。pg-test集群集群对外提供两种服务，读写服务pg-test-primary与只读副本服务pg-test-replica。

实体

在Postgres集群管理中，有如下实体概念：

集群（Cluster）

集群是基本的自治业务单元，这意味着集群能够作为一个整体组织对外提供服务。类似于k8s中Deployment的概念。注意这里的集群是软件层面的概念，不要与PG Cluster（数据库集簇，即包含多个PG Database的单个PG实例的数据目录）或Node Cluster（机器集群）混淆。

集群是管理的基本单位之一，是用于统合各类资源的组织单位。例如一个PG集群可能包括：

  • 三个物理机器节点
  • 一个主库实例，对外提供数据库读写服务。
  • 两个从库实例，对外提供数据库只读副本服务。
  • 两个对外暴露的服务：读写服务，只读副本服务。

每个集群都有用户根据业务需求定义的唯一标识符，本例中定义了一个名为pg-test的数据库集群。

节点（Node）

节点是对硬件资源的一种抽象，通常指代一台工作机器，无论是物理机（bare metal）还是虚拟机（vm），或者是k8s中的Pod。这里注意k8s中Node是硬件资源的抽象，但在实际管理使用上，是k8s中的Pod而不是Node更类似于这里Node概念。总之，节点的关键要素是：

  • 节点是硬件资源的抽象，可以运行一系列的软件服务
  • 节点可以使用IP地址作为唯一标识符

尽管可以使用lan_ip地址作为节点唯一标识符，但为了便于管理，节点应当拥有一个人类可读的充满意义的名称作为节点的Hostname，作为另一个常用的节点唯一标识。

服务（Service）

服务是对软件服务（例如Postgres，Redis）的一种命名抽象（named abastraction）。服务可以有各种各样的实现，但其的关键要素在于：

  • 可以寻址访问的服务名称，用于对外提供接入，例如：
    • 一个DNS域名（pg-test-primary）
    • 一个Nginx/Haproxy Endpoint
  • 服务流量路由解析与负载均衡机制，用于决定哪个实例负责处理请求，例如：
    • DNS L7：DNS解析记录
    • HTTP Proxy：Nginx/Ingress L7：Nginx Upstream配置
    • TCP Proxy：Haproxy L4：Haproxy Backend配置
    • Kubernetes：Ingress：Pod Selector 选择器。

同一个数据集簇中通常包括主库与从库，两者分别提供读写服务（primary）和只读副本服务(replica)。

实例（Instance）

实例指带一个具体的数据库服务器，它可以是单个进程，也可能是共享命运的一组进程，也可以是一个Pod中几个紧密关联的容器。实例的关键要素在于：

  • 可以通过IP:Port唯一标识
  • 具有处理请求的能力

例如，我们可以把一个Postgres进程，为之服务的独占Pgbouncer连接池，PgExporter监控组件，高可用组件，管理Agent看作一个提供服务的整体，视为一个数据库实例。

实例隶属于集群，每个实例在集群范围内都有着自己的唯一标识用于区分。

实例由服务负责解析，实例提供被寻址的能力，而Service将请求流量解析到具体的实例组上。

命名规则

一个对象可以有很多组标签（Tag）与元数据（Metadata/Annotation），但通常只能有一个名字（Name）。

管理数据库和软件与管理宠物类似，都需要花心思照顾。而起名字就是其中非常重要的一项工作。肆意的名字（例如 XÆA-12，NULL，史珍香）很可能会引入不必要的麻烦（额外复杂度），而设计得当的名字则可能会有意想不到的惊喜效果。

总体而言，对象起名应当遵循一些原则：

  • 简洁直白，人类可读：名字是给人看的，因此要好记，便于使用。

  • 体现功能，反映特征：名字需要反映对象的关键特征

  • 独一无二，唯一标识：名字在命名空间内，自己的类目下应当是独一无二，可以惟一标识寻址的。

  • 不要把太多无关的东西塞到名字里去：在名字中嵌入很多重要元数据是一个很有吸引力的想法，但维护起来会非常痛苦，例如反例：pg:user:profile:10.11.12.13:5432:replica:13。

集群命名

集群名称，其实类似于命名空间的作用。所有隶属本集群的资源，都会使用该命名空间。

集群命名的形式，建议采用符合DNS标准 RFC1034 的命名规则，以免给后续改造埋坑。例如哪一天想要搬到云上去，发现以前用的名字不支持，那就要再改一遍名，成本巨大。

我认为更好的方式是采用更为严格的限制：集群的名称不应该包括点（dot）。应当仅使用小写字母，数字，以及减号连字符（hyphen）-。这样，集群中的所有对象都可以使用这个名称作为前缀，用于各种各样的地方，而不用担心打破某些约束。即集群命名规则为：

cluster_name := [a-z][a-z0-9-]*

之所以强调不要在集群名称中用点，是因为以前很流行一种命名方式，例如com.foo.bar。即由点分割的层次结构命名法。这种命名方式虽然简洁名快，但有一个问题，就是用户给出的名字里可能有任意多的层次，数量不可控。如果集群需要与外部系统交互，而外部系统对于命名有一些约束，那么这样的名字就会带来麻烦。一个最直观的例子是K8s中的Pod，Pod的命名规则中不允许出现.。

集群命名的内涵，建议采用-分隔的两段式，三段式名称，例如：

<集群类型>-<业务>-<业务线>

比如：pg-test-tt就表示tt 业务线下的test集群，类型为pg。pg-user-fin表示fin业务线下的user服务。

节点命名

节点命名建议采用与k8s Pod一致的命名规则，即

<cluster_name>-<seq>

Node的名称会在集群资源分配阶段确定下来，每个节点都会分配到一个序号${seq}，从0开始的自增整型。这个与k8s中StatefulSet的命名规则保持一致，因此能够做到云上云下一致管理。

例如，集群pg-test有三个节点，那么这三个节点就可以命名为：

pg-test-1, pg-test-2和pg-test-3。

节点的命名，在整个集群的生命周期中保持不变，便于监控与管理。

实例命名

对于数据库来说，通常都会采用独占式部署方式，一个实例占用整个机器节点。PG实例与Node是一一对应的关系，因此可以简单地采用Node的标识符作为Instance的标识符。例如，节点pg-test-1上的PG实例名即为：pg-test-1，以此类推。

采用独占部署的方式有很大优势，一个节点即一个实例，这样能最小化管理复杂度。混部的需求通常来自资源利用率的压力，但虚拟机或者云平台可以有效解决这种问题。通过vm或pod的抽象，即使是每个redis（1核1G）实例也可以有一个独占的节点环境。

作为一种约定，每个集群中的0号节点（Pod），会作为默认主库。因为它是初始化时第一个分配的节点。

服务命名

通常来说，数据库对外提供两种基础服务：primary 读写服务，与replica只读副本服务。

那么服务就可以采用一种简单的命名规则：

<cluster_name>-<service_name>

例如这里pg-test集群就包含两个服务：读写服务pg-test-primary与只读副本服务pg-test-replica。

一种流行的实例/节点命名规则：<cluster_name>-<service_role>-<sequence>，即把数据库的主从身份嵌入到实例名称中。这种命名方式有好处也有坏处。好处是管理的时候一眼就能看出来哪一个实例/节点是主库，哪些是从库。缺点是一但发生Failover，实例与节点的名称必须进行调整才能维持一执性，这就带来的额外的维护工作。此外，服务与节点实例是相对独立的概念，这种Embedding命名方式扭曲了这一关系，将实例唯一隶属至服务。但复杂的场景下这一假设可能并不满足。例如，集群可能有几种不同的服务划分方式，而不同的划分方式之间很可能会出现重叠。

  • 可读从库（解析至包含主库在内的所有实例）
  • 同步从库（解析至采用同步提交的备库）
  • 延迟从库，备份实例（解析至特定具体实例）

因此不要把服务角色嵌入实例名称，而是在服务中维护目标实例列表。毕竟名字并非全能，不要把太多非必要的信息嵌入到对象名称中。

最后修改 2021-03-17: v0.8 update (bf0ea3b)