企业官网建设流程全解析

• 人工智能
• 大模型
• AI 应用
• 后端
• AI Agent
• RAG
• 流程编排
• 微服务

导读

FIT（Fit Integration Technology）框架内置了一个基于内存存储的 Java 注册中心实现，随框架构建产物一同生成，无需额外安装任何服务端组件，即可在本地完成服务注册、服务发现、心跳保活与多进程服务调用。本指南以 framework/fit/registry-center.md 为核心，完整讲解该内存版注册中心的启动流程、验证方法、关键配置参数，并结合仓库源码剖析其注册、查询、过期清理与心跳机制的底层实现，帮助你快速在单机或测试场景下搭建 FIT 服务集群，甚至与 Python 运行时进行联调。

一、注册中心在 FIT 框架中的角色

FIT 框架采用"服务提供者（Fitable）— 注册中心 — 服务调用方（BrokerClient）"的经典服务治理模型：每个运行中的 FIT 进程（即 Worker）启动后，会把自己承载的服务实现元数据注册到注册中心；调用方在发起远程或本地调用前，先从注册中心查询目标服务的地址列表，再根据路由策略选定具体实例发起调用。

从框架默认配置文件 fitframework.yml 可以看出，运行时与注册中心相关的所有配置统一收敛在matata.registry前缀之下，默认值为：

matata: registry: host: 'localhost' # 默认连接的注册中心为本地 port: 8080 # 默认连接注册中心的端口为本地默认的 8080 端口 protocol: 2 # 注册中心默认使用 Http 的传输协议 mode: 'DIRECT' # 默认连接注册中心的模式为直连模式(内存版注册中心) environment: "local"

其中mode: 'DIRECT'即表示"直连模式"，也就是连接 FIT 框架自带的 Java 内存版注册中心（对应插件fit-service-coordination-simple）；而available-services配置则声明了调用方在启动时需要与注册中心交互的服务接口清单，例如订阅服务地址（subscribeFitables）、直接查询地址（queryFitablesAddresses）、查询运行中的服务（queryRunningFitables）、申请令牌（applyToken）、发送心跳（sendHeartbeat）以及注册服务（registerFitables）等，这些接口的 Fitable 唯一标识需要在注册中心侧有对应的实现。

二、前置要求

启动 Java 内存版注册中心前，请确保本机环境满足以下条件：

其中 Node.js 是build/bin/fit启动脚本的运行环境，脚本本身承担了类路径装配、JVM 参数透传等职责。

三、启动步骤（最简）

1. 编译 Java 侧框架

在仓库根目录下执行：

cd framework/fit/java mvn clean install

执行完成后，构建产物会输出到仓库根目录的build/目录，其中与本主题直接相关的产物包括：

• build/bin/fit：FIT 启动脚本；
• build/plugins/fit-service-coordination-simple-*.jar：内存注册中心插件。

插件 jar 之所以会自动落入build/plugins/，是因为 fit-service-coordination-simple/pom.xml 中的maven-antrun-plugin在package阶段将构建产物复制到了../../../../../../build/plugins目录；同时该插件模块依赖fit-heartbeat、fit-service-registry-and-discovery与fit-http-classic等基础服务模块，因此在框架整体编译时会被一并打包。

2. 启动 FIT 服务（默认启用内存注册中心）

./build/bin/fit start

由于默认matata.registry.mode为DIRECT、默认注册中心地址为localhost:8080，而当前 FIT 进程自身也会默认监听 8080 端口（即"进程即注册中心"），因此直接执行./build/bin/fit start即可把当前进程同时作为应用与内存注册中心启动。

可选：如果希望把当前目录作为动态插件目录，可直接在该目录执行；如需隔离插件，可自行进入其他空目录再执行。

3. 验证服务

curl http://localhost:8080/actuator/plugins

该端点由内置的 Actuator 插件提供，实现在 ActuatorController.java，返回当前进程已加载插件列表（按启动顺序排序，包含 group、name、version、category、level 等元数据）。若在返回列表中看到fit-service-coordination-simple，则说明内存注册中心插件已成功加载。

四、验证与观测：如何确认注册中心工作正常

除/actuator/plugins外，内存注册中心还提供了一个专门用于观测内部状态的 HTTP 端点：GET /fit/check，实现在 CheckController.java。该端点会一次性返回四张内部数据表：

• workers：当前注册的所有 Worker（进程）信息；
• applications：当前注册的所有应用（按名称+版本维度）信息；
• workerApplications：Worker 与 Application 的归属关系；
• applicationMetas：每个应用注册的服务实现（Fitable）元数据集合。

curl http://localhost:8080/fit/check

这对于排查"服务为何没有注册上""某个 Worker 是否已过期下线"等问题非常直观。例如当你同时启动了多个 FIT 应用（各自声明matata.registry.host指向同一个注册中心），就可以通过/fit/check观察到所有 Worker、Application 及其承载的 Fitable 元数据。

五、端口冲突与启动参数覆盖

默认端口为8080。若端口已被占用，可通过在启动命令中追加配置覆盖：

./build/bin/fit start server.http.port=8081

FIT 启动脚本支持在fit start后追加 Java 参数与程序参数，形如./fit start -Xmx1g myapp config.yaml，因此形如server.http.port=xxx的键值对同样会被解析为运行时配置。此外，注册中心地址本身也由matata.registry.host、matata.registry.port控制，这些配置项的语义定义可参考 MatataConfig.java（host、port、mode、protocol、environment等均有对应的读取接口）。

六、内存版注册中心的源码级实现原理

内存版注册中心由插件fit-service-coordination-simple提供，其核心类是 RegistryServer.java。类注释明确声明：该注册中心服务为内存版实现，仅提供于非生产环境测试使用。其内部使用四张ConcurrentHashMap维护状态：

1. 注册（registerFitables）

Worker 启动时调用@Fitable(id = "register-fitables")对应的registerFitables方法，将自身地址、应用信息与承载的 Fitable 元数据写入上述四张表，同时根据过期策略刷新进程存活时间，并触发一次过期清理（expire()）。

2. 查询与订阅（queryFitables / subscribeFitables）

queryFitables按 Fitable 标识过滤已注册元数据，为每个匹配项找出"尚未过期"的 Worker，组装成FitableAddressInstance返回；subscribeFitables在内存版实现中直接复用查询逻辑。单测 RegistryServerTest.java 验证了"注册成功后按 Fitable 查询能正确命中结果"的完整链路。

3. 心跳保活与过期清理

Worker 进程运行期间会周期性调用@Fitable(id = "send-heartbeat")对应的心跳接口 HeartbeatServer.java：心跳携带aliveTime（存活时长，毫秒），注册中心据此计算新的过期时间Instant.now() + aliveTime并刷新WorkerCache。过期时间缓存由 DefaultWorkerCache.java 维护：isExpired判断当前时间是否已超过记录的过期时刻，过期 Worker 会在下一次注册/心跳触发清理时被移除。

4. 容量与集群域扩展

• 容量上限：RegistryServer定义了MAX_WORKER_NUM = 500与MAX_APP_NUM = 20，超过上限时注册会抛出IllegalStateException，这是内存版实现面向单机/测试场景的显式约束。
• 集群域（cluster domain）：当应用扩展信息中带有cluster.domain键时，查询返回的 Worker 地址会被替换为该集群域地址，端口则从形如cluster.<protocol>.port的扩展键中解析（参见replaceAddresses与buildEndPoints），可用于网关/代理场景下的地址改写。

5. 插件默认配置

插件自带的 application.yml 定义了default-expire-time: 30（单位秒，即默认进程过期时间，可通过配置覆盖；若 Worker 扩展信息携带expire则以该值为准），并声明扫描modelengine.fit.heartbeat.server与modelengine.fit.service两个包下的 Bean。

七、关键配置参数一览

八、多进程示例：注册中心 + 服务提供者 + 服务调用方

仓库中的示例工程 04-complicated-apps 演示了"独立注册中心 + 服务提供者 + 调用方"三进程架构，三个应用的配置直观展示了内存注册中心的连接方式：

• 注册中心进程（app-registry-center/application.yml）：matata.registry.port: 8090且server.http.port: 8090，即注册中心监听 8090，启动类为 RegistryCenterStarter.java；
• 服务提供者（app-default-weather/application.yml）：自身 HTTP 端口 8081，matata.registry.host/port指向127.0.0.1:8090；
• 服务调用方（app-assistant/application.yml）：自身 HTTP 端口 8080，同样连接127.0.0.1:8090。

启动时先启动注册中心进程，再依次启动提供者与调用方，即可观察到调用方通过注册中心发现并提供者完成跨进程服务调用。该模式也适用于与 Python 运行时联调：只要 Python 侧将注册中心地址指向该 Java 内存注册中心，即可参与同一服务注册与发现体系。

九、适用边界与生产替代

需要特别强调的是，内存版注册中心仅适用于单机、测试与多语言联调场景。其数据完全驻留在 JVM 内存中，进程重启即丢失全部注册信息，且存在 Worker（500）与应用（20）的容量上限，不具备持久化、集群容灾与生产级治理能力。当需要生产环境的高可用注册中心时，应改用 FIT 框架提供的 Nacos 插件（fit-service-coordination-nacos），并在配置中将matata.registry.mode切换为PROXY、填写 Nacos 服务器地址与端口；Nacos 插件的完整配置项（用户名、密码、权重、心跳间隔、心跳超时等）可参考 fit-service-coordination-nacos/README.md，其配套示例位于 08-nacos-complicated-apps。

十、参考文件索引

• 官方说明：framework/fit/registry-center.md
• 注册中心核心实现：RegistryServer.java
• 心跳服务实现：HeartbeatServer.java
• 过期缓存实现：DefaultWorkerCache.java
• 内部状态观测端点：CheckController.java
• 注册中心单测：RegistryServerTest.java
• 插件默认配置：application.yml
• 框架默认运行时配置：fitframework.yml
• 注册中心配置项定义：MatataConfig.java
• fit命令使用说明：fit-launcher/README.md
• 三进程联调示例：04-complicated-apps

• 人工智能
• 大模型
• AI 应用
• 后端
• AI Agent
• RAG
• 流程编排
• 微服务