Registration & Heartbeat Performance Optimization

[chuntaojun]

注册当前性能问题

• 每次实例注册，都需要从数据库中查询一下这个实例对应的服务信息是否存在以及是否是别名服务，一次实例注册动作，每次都需要和存储层进行 1次写操作 + 2次读操作，增加了存储层的计算消耗，增加了单个注册请求的响应时耗
• 服务端对于实例注册开启了批量写操作机制，但是每个注册请求依然要等待数据库中具体的处理结果才能返回给客户端，无法进一步提高服务端处理注册请求的TPS

优化方案

• 由于实现了注册服务实例时连带自动创建服务，因此无需在进行判断实例对应的服务数据是否存在，减少存储层的查询操作
• 调整注册整体流程，将注册动作与数据在存储层持久化动作进行拆分，实例开启了心跳的注册请求，不在等待存储层的写入结果，直接提交一个注册任务变立即返回给客户端

服务端处理

• 来自客户端的注册实例请求，如果实例开启了心跳上报，则服务端直接异步注册实例
• 原本的 future.Wait 放在一个协程池中异步处理消费，记录 future 的结果进行打印
• 需要提前设置实例的 id 信息，返回给客户端
• 注册实例时，根据 BatchRestoreInstanceIsolate 方法，判断出哪些实例时为首次注册，首次注册的实例，不再需要执行 BatchDeleteInstanceMetadata的操作
• 由于注册实例允许重注册，因此不再需要执行 BatchDeleteInstance 的操作

客户端处理

• 调用客户端注册接口时
  • 通过北极星客户端的注册接口注册的实例，全部都开启基于心跳的健康检查机制（不可关闭）
    • 如果需要注册不上报心跳的实例，只能在控制台创建或者使用 open-api 进行创建
  • 心跳动作交由 SDK 处理，则将该注册实例信息 & 心跳信息创建一个心跳任务
  • 心跳任务需要记录在一个 map 中
• 调用客户端心跳接口进行上报实例心跳
  • 如果上报心跳的返回结果，出现两次实例不存在
    • SDK会自动主动根据注册实例时的缓存进行实例重注册动作，用户无感知
• 调用客户端反注册接口时
  • 根据实例信息，判断是否在 SDK 内维护了心跳任务，如果存在，则对心跳任务进行关闭动作
  • 执行反注册请求发送至服务端

心跳当前性能问题

• 当前心跳动作，必须等到server将心跳数据写入 redis 之后，才能回包给客户端，对于客户端来说，只需要服务端接收到客户端的心跳包即可，至于服务端怎么处理，客户端不应当关心，背后的逻辑应该由服务端自行兜底承担

优化方案

• 心跳直接异步写入redis，写入的 future 结果放在一个协程池中异步消费打印心跳结果

[chuntaojun]

当前注册性能（8c16g，三节点）

指标名称	指标
TPS	6425
P99 时延	683.59 ms
Server CPU	49.21%
Server Mem	40.32

预计优化后的注册性能（8c16g，三节点）

指标名称	指标
TPS	25000+
P99 时延	200 ms
Server CPU	50%
Server Mem	40%