Nacos：服务注册和配置中心

目录

一、概念

1.1 核心概念

1.2 核心价值

1.3 功能边界

1.4 应用场景

二、原理

2.1 架构详解

2.1.1 核心组件

2.1.2 数据模型与核心概念

2.2 核心原理

2.2.1 服务发现原理 (Naming)

2.2.2 配置管理原理 (Config)

2.3 集群部署与高可用

三、使用

3.1 Nacos搭建

3.1.1 NacosServer搭建

3.1.2 项目集成NacosClient

3.1.3 实战使用

3.2 生产环境最佳实践

3.3 配置项详解

---

Nacos文档

一、概念

1.1 核心概念

Nacos 的命名来源于 Naming and Configuration Service。这个名字精准地概括了它的两大核心功能：服务注册与发现 和 动态配置管理。

功能维度	服务发现与注册	动态配置服务
核心功能	服务注册、健康检查、服务列表同步	配置集中管理、动态刷新、版本控制
数据模型	服务名 ↔ 实例列表 (IP、端口、元数据)	Data ID、Group、Namespace
工作原理	实例注册、心跳维持、客户端拉取或服务端推送 (Nacos 2.0)	客户端拉取、监听配置变更
典型应用场景	微服务间的调用、负载均衡	应用参数动态调整、多环境配置管理
带来的好处	服务解耦、高可用、弹性扩展	无需重启应用、配置一致性、降低风险

核心功能：

• 服务发现与服务健康检查 (Naming Service)

  • 服务注册： 服务实例启动时，向 Nacos 服务器注册自己的元数据（如 IP、端口、服务名）。

  • 服务发现： 消费者通过服务名查询 Nacos 服务器，获取健康的服务实例列表，实现负载均衡调用。

  • 健康检查： Nacos 会定期检查注册的服务实例是否健康， unhealthy 的实例会被剔除，保证服务列表的可用性。

• 动态配置管理 (Config Service)

  • 集中式配置： 将分布式系统中所有服务的配置信息（如数据库连接、开关标志）集中存储在 Nacos 中。

  • 动态刷新： 应用在启动时从 Nacos 获取配置，并在运行时监听配置变化。当配置在 Nacos 界面上修改并发布后，Nacos 会实时通知监听的应用，应用无需重启即可获取新配置。

  • 多环境与灰度： 支持通过 Namespace、Group、Data ID 等维度管理不同环境（dev/test/prod）的配置，并支持配置灰度发布。

1.2 核心价值

• 服务治理与解耦：

  • 价值：实现了服务提供者和消费者之间的彻底解耦。服务实例可以动态地上下线，消费者无需感知，只需面向服务名进行调用。这极大地提升了系统的弹性和灵活性。

• 动态配置，无需重启：

  • 价值：改变了“修改配置 -> 打包 -> 重启应用”的传统模式。通过动态配置管理，可以实现配置的实时推送和生效，极大地加快了迭代速度，降低了运维成本，并保证了系统的高可用性（无需重启即可调整行为）。

• 一元化平台：

  • 价值：将服务发现和配置管理两大功能集于一身。在 Spring Cloud Alibaba 等生态中，开发者可以使用同一套标准和 API 来管理服务和配置，简化了技术栈，降低了学习和维护的复杂度。避免了同时维护 Eureka（服务发现）和 Apollo/Spring Cloud Config（配置中心）等多套系统的麻烦。

• 促进云原生转型：

  • 价值：Nacos 天生支持云原生环境（如 Kubernetes），但其设计并未与 K8s 强绑定。它可以帮助传统应用平滑地向云原生架构迁移，是构建现代化、动态化、敏捷化应用系统的基石。

1.3 功能边界

功能范畴	Nacos 能做什么 (Within Boundary)	Nacos 不做什么 / 需要其他组件配合 (Outside Boundary)
服务注册与发现	提供服务实例的注册、健康检查（TCP/HTTP/MySQL）、查询、元数据管理。	不负责服务的远程调用（RPC）。调用由 OpenFeign、Dubbo、gRPC 等客户端完成。
动态配置管理	存储、管理、推送各种格式（YAML, Properties, JSON等）的配置信息。支持灰度、回滚。	不提供复杂的配置版本管理、审计追踪（虽有基础功能，但不如专业系统强大）。
服务与配置的元数据管理	支持为服务和配置添加自定义元数据（Metadata）。	不解释元数据的含义。元数据的用途由客户端框架（如 Ribbon）来解析和使用。
负载均衡	提供服务实例列表。	不直接执行负载均衡算法。负载均衡由客户端负载均衡器（如 Ribbon, LoadBalancer）执行。
流量管理与路由	通过与 Dubbo、Spring Cloud Gateway 等集成，间接支持基于权重的流量调度。	不是一个全功能的 API 网关或服务网格（Service Mesh）数据平面。高级路由、鉴权、限流需依赖网关（如 Gateway, Zuul）或Sentinel。
高可用与持久化	自身支持集群部署，数据可持久化到 Derby（内置）或生产推荐的 MySQL 数据库。	不保证强一致性（CP），默认采用高可用（AP）模式，在服务发现场景下更注重可用性。也可切换为CP模式（用于配置管理）。

简单总结：Nacos 是一个服务与配置的“信息中枢”或“电话簿”。它负责存储和分发信息，但不负责基于这些信息执行具体的动作（如调用、限流）。这些动作由其他客户端组件完成。

1.4 应用场景

• 微服务架构的核心基础设施：

  • 场景描述：这是 Nacos 最经典的应用场景。在一个由数十甚至上百个微服务组成的系统中，Nacos 作为服务注册中心，管理所有服务的元数据；同时作为配置中心，统一管理所有环境的配置。

  • 案例：一个电商平台，user-service, order-service, product-service 等全部注册到 Nacos。它们之间的调用通过服务发现完成。各个服务的数据库连接、Redis地址、功能开关（如“是否开启秒杀”）等都存储在 Nacos 中。

• 动态配置驱动的应用：

  • 场景描述：需要频繁调整参数且希望立即生效，又不愿重启应用的系统。

  • 案例：

    • 日志级别动态调整：在线上环境，临时将某个服务的日志级别从 INFO 调整为 DEBUG 以排查问题，排查完毕后改回。

    • 业务规则热更新：修改营销活动的折扣阈值、限流规则的阈值等。

    • 功能开关 (Feature Flag)：灰度发布新功能，只对部分用户开放。通过修改 Nacos 中的配置值，实时控制功能的开启和关闭。

• 多环境与租户隔离：

  • 场景描述：公司拥有开发、测试、预发布、生产等多套环境，需要严格隔离，避免配置和服务互相串扰。

  • 案例：使用 Nacos 的 Namespace 功能，为每个环境创建一个独立的命名空间。dev 命名空间下的服务只能发现 dev 下的其他服务，并且只能读取 dev 下的配置，与 prod 环境完全隔离。

• 混合云与多数据中心部署：

  • 场景描述：业务部署在多个机房或混合云（公有云+私有云）环境中，需要实现跨云的服务发现和配置同步。

  • 案例：Nacos 可以通过集群模式和特定的部署方案（如每个数据中心部署一个 Nacos 集群，然后通过 Sync 组件或基于 DNS 的方式进行集群间同步），来实现全局的服务视图和配置管理。

• 传统应用向微服务架构迁移的过渡方案：

  • 场景描述：传统单体应用正在逐步拆分为微服务，需要一个轻量级、易集成的中心化组件来开始治理服务。

  • 案例：先将新拆分出的微服务注册到 Nacos，并开始使用其配置管理功能。原有的单体应用可以逐步改造，通过 Nacos 的 API 或 SDK 接入，最终平滑地过渡到完整的微服务架构。

二、原理

2.1 架构详解

2.1.1 核心组件

• Nacos Server： 服务端，提供核心的注册中心和配置中心功能。可以以单机或集群模式部署。

  • Naming Service (内置)： 处理服务注册、发现和健康检查的模块。

  • Config Service (内置)： 处理配置的 CRUD、推送和监听的管理模块。

  • 一致性协议层： Nacos 的核心，负责数据在集群间的同步。它支持两种一致性协议：

    • Raft： 用于持久化、非临时实例的服务数据和所有的配置数据。这是一种强一致性（CP）协议，保证数据的可靠性和一致性。集群中有一个 Leader，负责数据的写入和同步。

    • Distro： 这是 Nacos 自研的 AP 分布式协议。专门用于处理临时实例的服务数据。它优先保证可用性，通过异步复制实现最终一致性，性能更高，适合大规模服务实例的心跳上报和注册。

• Nacos Client： 客户端，通常以 SDK 的形式集成到微服务应用中（如 Spring Cloud Alibaba、Dubbo）。负责与 Nacos Server 交互，包括服务注册、发现、配置获取和监听。

  • OpenAPI： Nacos 也提供 HTTP RESTful API，任何语言都可以通过调用 API 集成。

• Console (UI)： 基于 Web 的管理控制台，提供友好的用户界面进行服务管理、配置管理和命名空间管理。

2.1.2 数据模型与核心概念

• 服务 (Service)： 微服务的逻辑集合，例如 user-service。

• 实例 (Instance)： 提供服务的具体进程，有唯一 IP 和端口。分为两种类型：

  • 临时实例 (Ephemeral)： 通过客户端心跳（默认 5 秒）上报健康状态。如果心跳超时（默认 15 秒），服务器会将其自动删除。采用 Distro 协议。

  • 持久化实例 (Persistent)： 由客户端主动注册和注销，服务器不会因其心跳失败而删除它。采用 Raft 协议。

• 命名空间 (Namespace)： 用于实现环境隔离（如 dev, test, prod）或租户隔离。不同 Namespace 下的服务和配置完全不可见。

• 配置 (Configuration)： 由三个核心维度唯一确定：

  • Namespace： 默认是 public。

  • Group： 默认是 DEFAULT_GROUP。可用于区分不同应用或不同版本的配置。

  • Data ID： 通常对应一个配置文件的名字，如 user-service.yaml。

2.2 核心原理

2.2.1 服务发现原理 (Naming)

a. 服务注册：

1. 服务实例（如 user-service）启动时，内嵌的 Nacos Client 会向 Nacos Server 发送注册请求（HTTP 或 gRPC），包含自身的元数据（IP, Port, Service Name, 集群名等）。

2. Nacos Server 接收到请求后，根据实例类型（临时/持久化），将其信息写入对应的存储（内存注册表）。

3. 对于临时实例，Nacos Server 会为其创建一个健康检查任务。

b. 健康检查：

• 对于临时实例： 采用客户端主动上报模式（也称为“心跳模式”）。客户端会定期（如每 5 秒）向服务器发送一次心跳。服务器在指定时间内（如 15 秒）未收到心跳，则认为该实例不健康，并将其从服务列表中剔除。这是一种推拉结合、以推为主的模式，对服务器压力小，性能极高。

• 对于持久化实例： 采用服务器端主动探测模式。Nacos Server 会主动发送请求（如 TCP/HTTP/Mysql 检查）到客户端实例，根据响应判断健康状态。

c. 服务发现与订阅：

1. 消费者（如 order-service）在启动时，会通过 Nacos Client 查询它所依赖的服务（如 user-service）的所有健康实例列表，并缓存在本地。

2. 同时，消费者会向 Nacos Server 发起一个长轮询 (Long Polling) 订阅，监听 user-service 的变化。

3. 当 user-service 的实例列表发生变化（如实例上线、下线、健康状态变更），Nacos Server 会找到所有订阅该服务的客户端，并推送变更事件。

4. 消费者收到变更通知后，会立即从 Nacos Server 拉取最新的服务实例列表，更新本地缓存，从而实现实时的服务发现。

2.2.2 配置管理原理 (Config)

a. 配置获取：

1. 应用启动时，Nacos Client 会根据指定的 Namespace、Group、Data ID 等信息，向 Nacos Server 发起 HTTP 请求，获取配置内容。

2. 客户端将获取到的配置内容本地化（如写入本地文件或内存缓存）。

b. 配置监听与动态刷新：

1. 客户端在获取配置后，会创建一个长轮询任务，向 Nacos Server 发起监听请求，超时时间设置为 30 秒。

2. 如果在此期间，所监听的配置没有任何变化，这个请求会在服务器端“挂起”直到超时。超时后，客户端会立即重新发起一个新的监听请求，如此反复，维持一个长连接。

3. 当管理员在 Nacos Console 上修改并发布配置后，Nacos Server 会找到所有正在监听该配置的客户端长轮询连接。

4. 服务器会立即响应这些挂起的请求，返回配置发生变化的 Data ID 和 Group 信息（注意：不是返回具体的配置内容）。

5. 客户端收到“配置变更”的通知后，会主动从 Nacos Server 重新拉取最新的配置内容，然后触发 Spring 等框架的配置刷新机制（如 @RefreshScope），实现应用配置的热更新。

这种“长轮询监听 + 客户端拉取”的模式，完美结合了推送的实时性和拉取的可靠性，避免了单纯推送可能造成的消息丢失问题。

2.3 集群部署与高可用

生产环境必须使用集群模式以确保高可用。

• 节点关系： Nacos 集群节点间是对等的，没有主从之分（但从 Raft 协议角度看，有 Leader 和 Follower）。

• 数据同步：

  • 服务数据（临时实例）： 通过 Distro 协议异步复制。每个节点负责一部分数据，然后将写入操作同步给其他节点。

  • 服务数据（持久化实例）和配置数据： 通过 Raft 协议进行强一致性同步。所有写操作必须由 Leader 节点处理并同步给大多数 Follower 节点后才能成功。

• 持久化存储： 集群数据默认存储在內嵌的 Derby 数据库中。生产环境强烈推荐使用外部集中式数据库（如 MySQL 主从集群），让所有 Nacos 节点连接到同一个 MySQL 库，这样数据自然就是一致的，无需通过 Raft 同步配置数据（服务数据仍在内存中通过 Distro/Raft 同步）。

• 负载均衡： 通常会在 Nacos 集群前架设一个负载均衡器（如 Nginx、F5），客户端配置的是负载均衡器的地址，由它来将请求分发到后端的健康 Nacos 节点。

三、使用

3.1 Nacos搭建

3.1.1 NacosServer搭建

下载：从 Nacos Github Release 页面下载最新稳定版（如 nacos-server-$version.tar.gz）。

解压：

tar -xzf nacos-server-$version.tar.gz
cd nacos

目录结构：

• bin/: 启动/停止脚本

• conf/: 配置文件（如 application.properties, cluster.conf.example）

• logs/: 日志文件

• data/: 内嵌数据库数据

配置数据库（以 MySQL 为例）

1. 创建数据库 nacos_config（字符集 UTF8MB4）。

2. 初始化表结构，执行 conf/nacos-mysql.sql 脚本。

3. 修改 conf/application.properties 文件，取消注释并配置数据库连接：

spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user.0=your_username
db.password.0=your_password

启动 Nacos Server

• 单机模式（推荐开发使用）：

# Linux/Unix/macOS
sh bin/startup.sh -m standalone# Windows
cmd bin/startup.cmd -m standalone

• 集群模式（生产必用）：

1> 复制 conf/cluster.conf.example 为 conf/cluster.conf。

2> 在 cluster.conf 中配置集群所有节点的 IP:PORT（必须是 IP，不能是localhost）：

192.168.1.10:8848
192.168.1.11:8848
192.168.1.12:8848

3> 为每个节点重复上述步骤，确保配置一致。

4> 分别启动每个节点（无需 -m 参数）：

sh bin/startup.sh

访问控制台

打开浏览器，访问 http://<your_nacos_ip>:8848/nacos。

• 默认账号/密码：nacos / nacos。

3.1.2 项目集成NacosClient

步骤 1：添加依赖

在服务提供者和消费者项目的 pom.xml 中引入依赖。

对于 Spring Cloud Alibaba (推荐)：

<dependencyManagement><dependencies><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2022.0.0.0</version> <!-- 请使用与你的Spring Boot/Cloud匹配的版本 --><type>pom</type><scope>import</scope></dependency></dependencies>
</dependencyManagement><dependencies><!-- 服务发现 --><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency><!-- 配置管理 --><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency>
</dependencies>

• 非 Spring Cloud 项目：可使用 nacos-client SDK。

步骤 2：配置 Nacos Server 地址

在 bootstrap.properties (或 bootstrap.yml) 中配置（此文件优先级高于 application.properties）：

# 应用名，也是注册到Nacos的服务名
spring.application.name=my-service# Nacos Server 地址
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
spring.cloud.nacos.config.server-addr=127.0.0.1:8848# 配置中心使用的文件扩展名，默认为 properties
spring.cloud.nacos.config.file-extension=yaml

步骤 3：启用服务发现

在主应用类上添加 @EnableDiscoveryClient 注解：

@SpringBootApplication
@EnableDiscoveryClient
public class MyServiceApplication {public static void main(String[] args) {SpringApplication.run(MyServiceApplication.class, args);}
}

3.1.3 实战使用

实战 1：服务注册与发现

• 启动服务提供者：服务（如 user-service）启动后，会自动注册到 Nacos。在控制台 “服务管理” -> “服务列表” 中可以看到。

• 编写服务消费者：使用 RestTemplate 或 OpenFeign 进行服务调用。

  • 使用 @LoadBalanced RestTemplate (集成Nacos的负载均衡)：

@Configuration
public class RestTemplateConfig {@Bean@LoadBalanced // 赋予RestTemplate负载均衡的能力public RestTemplate restTemplate() {return new RestTemplate();}
}@RestController
public class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@GetMapping("/callUserService")public String callUserService() {// 直接使用服务名“user-service”进行调用，无需关心IP和端口return restTemplate.getForObject("http://user-service/user/1", String.class);}
}

实战 2：动态配置管理

1> 在 Nacos 控制台创建配置：

• 进入 “配置管理” -> “配置列表”。

• 点击 “+” (新建配置)。

• Data ID：格式通常为 ${spring.application.name}-${profile}.${file-extension} (e.g., my-service-dev.yaml)。

• Group：分组，默认 DEFAULT_GROUP。

• 格式：选择 yaml 或 properties。

• 内容：写入配置，例如：

user:name: "Test User"age: 25
app:config: "This is a dynamic config!"

在应用中读取配置：

• 使用 @Value 注解：

@RestController
@RefreshScope // 添加此注解，配置更新时Bean会刷新
public class ConfigController {@Value("${user.name}")private String userName;@Value("${app.config}")private String appConfig;@GetMapping("/config")public String getConfig() {return userName + " - " + appConfig;}
}

• 修改 Nacos 控制台上的配置内容，点击发布。无需重启应用，刷新 /config 接口即可看到配置已动态更新。

3.2 生产环境最佳实践

• 高可用 (HA)：

  • 必须使用集群模式，至少 3 个节点，部署在不同物理机上。

  • 使用 VIP（虚拟IP） + SLB（负载均衡） 或 DNS 将集群节点对外暴露为一个统一地址（server-addr 可配置为这个统一地址）。

• 持久化与备份：

  • 必须使用外部数据库（如MySQL主从架构），并定期备份数据库。

  • 定期备份 conf/ 目录下的配置文件。

• 权限与安全：

  • 在 conf/application.properties 中修改默认账号密码。

  • 启用鉴权 (nacos.core.auth.enabled=true)。

  • 使用 Namespace 进行多环境（dev/test/prod）的彻底隔离。为每个环境创建独立的命名空间。

• 监控与告警：

  • 暴露 Nacos 的 metrics（通过 /nacos/actuator/prometheus），并集成到 Prometheus + Grafana 监控体系中。

  • 监控核心指标：服务实例数、配置监听数、CPU/内存使用率、API 响应时间等。

  • 配置告警规则。

• 资源规划：

  • 根据微服务规模和配置数量，为 Nacos Server 规划足够的 CPU、内存（建议 4C8G 起步）和网络带宽。

3.3 配置项详解

配置类别	配置项示例	简要说明	常见默认值或示例值
服务端全局配置	nacos.standalone	是否以单机模式运行	true/false (默认为 false)
	nacos.home	Nacos的根目录	通过 -Dnacos.home=/path/to/nacos 设置
	nacos.functionMode	启动模式，可选择只启动 config（配置）或 naming（命名）模块	留空则启动所有
	nacos.inetutils.ip-address	手动指定本机IP地址，用于集群通信
	nacos.inetutils.prefer-hostname-over-ip	是否在集群配置中优先使用主机名而非IP	false
服务端数据库配置	spring.datasource.platform	数据库类型	mysql (默认)
	db.num	数据库数量	1
	db.url.0, db.user, db.password	数据库连接信息	jdbc:mysql://127.0.0.1:3306/nacos?useUnicode=true&characterEncoding=utf-8&serverTimezone=UTC
服务端命名模块 (Naming)	nacos.naming.data.warmup	启动时是否预加载数据	true
	nacos.naming.expireInstance	是否自动移除过期的临时实例	true
	nacos.naming.empty-service.auto-clean	是否自动清理空服务	false
	nacos.naming.distro.taskDispatchPeriod	同步任务调度周期（毫秒）	200
服务端配置模块 (Config)	nacos.cmdb.dumpTaskInterval	全量数据导出间隔（秒）	3600
	nacos.cmdb.eventTaskInterval	变更事件拉取间隔（秒）	10
客户端公共配置	spring.cloud.nacos.server-addr	Nacos 服务器地址	localhost:8848
	spring.cloud.nacos.namespace	命名空间ID，用于环境隔离	(默认为 public 命名空间)
	spring.cloud.nacos.username spring.cloud.nacos.password	Nacos 服务端认证信息
客户端服务发现 (Discovery)	spring.cloud.nacos.discovery.service-name	注册的服务名	your-service-name
	spring.cloud.nacos.discovery.group	服务分组名	DEFAULT_GROUP
	spring.cloud.nacos.discovery.metadata	服务实例的元数据（如权重、版本等）	version: 1.0
客户端配置管理 (Config)	spring.cloud.nacos.config.group	配置分组名	DEFAULT_GROUP
	spring.cloud.nacos.config.file-extension	配置格式	yaml, properties (默认)
	spring.cloud.nacos.config.refresh-enabled	是否自动刷新配置	true
	spring.cloud.nacos.config.timeout	读取配置的超时时间（毫秒）	3000
	spring.cloud.nacos.config.config-long-poll-timeout	长轮询超时时间（毫秒）	10000
	spring.cloud.nacos.config.shared-configs	共享配置列表，常用于多个应用间共享通用配置（如数据库、Redis等）	data-id: common-db.yml, group: COMMON_GROUP, refresh: true
	spring.cloud.nacos.config.extension-configs	扩展配置列表，优先级高于共享配置，可用于覆盖共享配置或加载特定配置	data-id: special-feature.yml, refresh: false

提示：共享配置 (shared-configs) 和 扩展配置 (extension-configs) 都允许应用加载多个配置文件。它们的主要区别在于优先级：主配置 (spring.application.name) > extension-configs > shared-configs。同一类型配置中，数组下标越大，优先级越高。这常用于分离不同职责的配置（如公共组件、应用专属配置）。

配置须知：

• 配置的来源与优先级：Nacos 的配置可以通过 application.properties（或 application.yml）、JVM 系统参数 (-D参数名=参数值)、环境变量等方式设置。通常需要结合使用这些方式，例如在启动脚本中通过 -D 设置数据库连接。

• 环境隔离与数据隔离：命名空间 (Namespace) 常用于隔离不同环境（开发、测试、生产）的配置和服务。分组 (Group) 则可用于在同一环境内对不同的应用或组件进行逻辑分组。Data ID 通常用于唯一标识一个配置集。

• 敏感配置处理：生产环境中，切勿将数据库密码等敏感信息明文写在配置文件中。Nacos 本身提供权限控制（AK/SK或用户名密码）。对于客户端，敏感信息也可考虑通过环境变量或命令行参数注入，或在 Nacos 配置中结合运维提供的密文存储方案（如Jasypt）。

• 动态刷新与长轮询：Nacos Config 客户端默认采用长轮询机制监听配置变更，这意味着配置更新后通常能在不重启应用的情况下快速生效。确保 refresh-enabled 为 true。

• 集群与高可用：生产环境强烈建议使用集群模式部署 Nacos 服务端。需要正确配置 cluster.conf 文件（列出集群所有节点地址）以及相关的数据库连接。