如何组装一个注册中心

hello，大家好呀，我是小楼。今天不写BUG，来聊一聊注册中心。

标题本来想叫《如何设计一个注册中心》，但网上已经有好多类似标题的文章了。所以打算另辟蹊径，换个角度，如何组装一个注册中心。

组装意味着不必从0开始造轮子，这也比较符合许多公司对待自研基础组件的态度。

知道如何组装一个注册中心有什么用呢？

第一可以更深入理解注册中心。以我个人经历来说，注册中心的第一印象就是Dubbo的Zookeeper（以下简称zk），后来逐渐深入，学会了如何去zk上查看Dubbo注册的数据，并能排查一些问题。后来了解了Nacos，才发现，原来注册中心还可以如此简单，再后来一直从事服务发现相关工作，对一些细枝末节也有了一些新的理解。

第二可以学习技术选型的方法，注册中心中的每个模块，都会在不同的需求下有不同的选择，最终的选择取决于对需求的把握以及技术视野，但这两项是内功，一时半会练不成，学个选型的方法还是可以的。

本文打算从需求分析开始，一步步拆解各个模块，整个注册中心以一种如无必要，勿增实体的原则进行组装，但也不会是个玩具，向生产可用对齐。

当然在实际项目中，不建议重复造轮子，尽量用现成的解决方案，所以本文仅供学习参考。

需求分析

本文的注册中心需求很简单，就三点：可注册、能发现、高可用。

服务的注册和发现是注册中心的基本功能，高可用则是生产环境的基本要求，如果高可用不要求，那本文可讲解的内容就很少，上图中的高可用标注只是个示意，高可用在很多方面都有体现。

至于其他花里胡哨的功能，我们暂且不表。

我们这里介绍三个角色，后文以此为基础：

• 提供者（Provider）：服务的提供方（被调用方）
• 消费者（Consumer）：服务的消费方（调用方）
• 注册中心（Registry）：本文主角，服务提供列表、消费关系等数据的存储方

接口定义

注册中心和客户端（SDK）的交互接口有三个：

• 注册（register），将服务提供方注册到注册中心
• 注销（unregister），将注册的服务从注册中心中删除
• 订阅（subscribe），服务消费方订阅需要的服务，订阅后提供方有变更将通知到对应的消费方

注册、注销可以是服务提供方的进程发起，也可以是其他的旁路程序辅助发起，比如发布系统在发布一台机器完成后，可调用注册接口，将其注册到注册中心，注销也是类似流程，但这种方式并不多见，而且如果只考虑实现一个注册中心，必然是可以单独运行的，所以通常注册、注销由提供方进程负责。

有了这三个接口，我们该如何去定义接口呢？注册服务到底有哪些字段需要注册？订阅需要传什么字段？以什么序列化方式？用什么协议传输？

这些问题接踵而来，我觉得我们先不急着去做选择，先看看这个领域有没有相关标准，如果有就参考或者直接按照标准实现，如果没有，再来分析每一点的选择。

服务发现还真有一套标准，但又不完全有。它叫OpenSergo，它其实是服务治理的一套标准，包含了服务发现：

OpenSergo 是一套开放、通用的、面向分布式服务架构、覆盖全链路异构化生态的服务治理标准，基于业界服务治理场景与实践形成通用标准规范。OpenSergo 的最大特点就是以统一的一套配置/DSL/协议定义服务治理规则，面向多语言异构化架构，做到全链路生态覆盖。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是标准微服务还是 Mesh 接入，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都可以通过同一套 OpenSergo CRD 标准配置针对每一层进行统一的治理管控，而无需关注各框架、语言的差异点，降低异构化、全链路服务治理管控的复杂度。

官网：https://opensergo.io/

我们需要的服务注册与发现也被纳入其中：

说有但也不是完全有是因为这个标准还在建设中，服务发现相关的标准在写这篇文章的时候还没有给出。

既然没有标准，可以结合现有的系统以及经验来定义，这里我用json的序列化方式给出，以下为笔者的总结，不能囊括所有情形，需要时根据业务适当做一些调整：

1. 服务注册入参

{
   
  "application":"provider_test", // 应用名
  "protocol":"http", // 协议