第一可以更深入理解注册中心。以我个人经历来说，注册中心的第一印象就是Dubbo的Zookeeper（以下简称zk），后来逐渐深入，学会了如何去zk上查看Dubbo注册的数据，并能排查一些问题。后来了解了Nacos，才发现，原来注册中心还可以如此简单，工程围挡再后来一直从事服务发现相关工作，对一些细枝末节也有了一些新的理解。
第二可以学习技术选型的方法，注册中心中的每个模块，都会在不同的需求下有不同的选择，最终的选择取决于对需求的把握以及技术视野，但这两项是内功，一时半会练不成，学个选型的方法还是可以的。 的高可用标注只是个示意，高可用在很多方面都有体现。
至于其他花里胡哨的功能，工程围挡我们暂且不表。 "provider":"test_provider1", // 订阅的应用名 "protocol":"http", // 订阅的协议 "meta":{ // 携带的元数据，以下为示例 "cluster":"small", "idc":"shanghai", "tag":"read" } }, { "provider":"test_provider2", "protocol":"http", "meta":{ "cluster":"small", "tag":"read"
至于编程语言的选择，我觉得应该更加偏向团队对语言的掌握，以能hold住为最主要，这点没什么好说的，一般也只会在 Java / Go 中去选，很少见用其他语言实现的注册中心。
对于注册、订阅接口，工程围挡无论是基于TCP的自定义私有协议，还是用HTTP协议，甚至基于HTTP2的gRPC我觉得都可以。
我们这里介绍三个角色，后文以此为基础：
- 提供者（Provider）：服务的提供方（被调用方）
- 注册、注销可以是服务提供方的进程发起，也可以是其他的旁路程序辅助发起，比如发布系统在发布一台机器完成后，可调用注册接口，将其注册到注册中心，注销也是类似流程，但这种方式并不多见，而且如果只考虑实现一个注册中心，必然是可以单独运行的，所以通常注册、注销由提供方进程负责。www.hbxhtdq.com/
有了这三个接口，我们该如何去定义接口呢？注册服务到底有哪些字段需要注册？订阅需要传什么字段？以什么序列化方式？用什么协议传输？www.hbxhtdq.com/
这些问题接踵而来，我觉得我们先不急着
