大家好，我是小楼。在上一篇文章《??如何组装一个注册中心??》中，我们看到了如何使用一些现有的技术解决方案来组装最小的生产可用注册中心集。有同学说看了就学会了，也有同学看不够。可以手写一个注册中心吗？可以继续讲吗？由于精力有限，手写一个注册中心还不够，不过扩展一下再说吧。所以这一期，我打算谈谈注册中心的周边能力。这些能力是锦上添花。没有他们，注册中心也可以正常运作。有了他们，不一定会变强，但一定会更花哨。那么有的读者可能会问，花里胡哨有什么用呢？我觉得主要是学习一些新奇的知识，说不定哪天会有用，对吧？想要控制台把注册中心做的花里胡哨，首先要开发一个控制台。控制台的基本功能是显示服务的消费者和提供者。显示的用处是查找服务，排查问题等。下图是NacosConsole：除了基本的显示功能，我们还可以在控制台上做其他的事情，比如下面的。ServiceConfiguration配置不是注册中心必须的功能。配置一般由配置中心管理，但配置中心似乎离不开注册中心。Nacos是一个集成了注册中心和配置中心的组件。注册中心也可以做一些服务相关的配置事情，比如服务超时、断路器降级等元数据，但是需要注意的是，注册中心本身只能保存和修改。RPC框架适合。你可能会问，为什么注册中心要做配置中心呢？这不是责任不清吗？可以这么理解，服务发现基本上就是服务必须要连接，但是配置中心不一定要连接。如果只是想做一些简单的服务相关的动态配置，引入配置中心就有点重了。如果是公司的生产级服务配置，最好增加一个灰度能力。如果一次把配置分发到所有机器上，可能会出现故障，所以需要一个灰度分发机制，分批分发。控制风险。事件跟踪在进行故障排除时，仅显示提供者和消费者可能还不够。有时当一个提供者开始时，消费者只是没有察觉到它，或者需要很长时间才能察觉到。这个时候，就有点迷糊了。如果我们把这个事件的时间线拿出来，哪一个环节出了问题，一目了然。Nacos企业版支持类似的推送跟踪功能。当然，这么好的功能肯定是付费的。拓扑关系可能我们忽略了注册中心绘制服务之间拓扑关系的能力。开源注册中心基本不提这个。一般来说，拓扑关系就是链接跟踪的活动。其实注册中心大致可以做这个工作，只不过注册中心是根据服务的订阅关系画出来的，不是根据真正的调用关系画的，但是和调用关系差不多。有了这个，我们就可以做一些服务治理相关的事情，比如循环依赖，太深的依赖，都可以看到。流量控制流量控制不一定要在注册中心进行。比如Dubbo在RPC框架上做了很多流量相关的事情，比如集群选择、路由、负载均衡等。如果RPC框架没有这么强大的能力，或者RPC框架是多种语言实现的，能力还没有均衡，那么在注册中心实现也是一个不错的选择。RoutingpreferenceRoutingpreference简单的说，如果一个provider有多个集群，选择一个更合适的集群来提供服务，这就叫做routingpreference。比如消费者在杭州，提供者有两个集群，一个在上海，一个在北京，两个机房提供的服务是完全等价的。这时候消费者调用本地集群就比较合适了。更小。当然，我们也可以根据服务器的性能甚至自定义规则来做路由偏好。有了上面的路由偏好，大家可以想到这样一个场景，如果有一天上海的provider不可用，我们可以通过注册中心的介入，手动将北京的provider发布给消费者。或者，实现客户端的非侵入式动态流量切换。流量劫持流量劫持和动态切换的原理是一样的，实现方式也基本一样，只是传递的数据不同。原来的提供者列表被注册中心替换为本地端口127.0.0.1:8001。.这个替换有什么作用？比如用代理来承接流量，比如servicemesh，就有这个需求，注册中心就可以完成流量劫持。事实上，劫持还有其他功能。如果服务提供者压力太大想要降级，但是消费者和提供者都没有降级的能力。眼看着服务要挂了，关键时刻，你想到了注册中心，手动发出一个不存在的提供者地址，让消费者请求报错，保护其他服务的正常运行。这些奇怪的想法可能会在注册中心实现。探索和探测是注册中心的一个小功能。让我们看看我们还能用这个小函数做些什么。探测扩展最简单的探测是端口探测，即注册中心向提供者注册的端口发起TCP连接请求。如果可以成功建立连接，则服务正常。但有时情况并非如此。比如服务死了，端口还能连上，但是无法提供服务。这时候，我们就需要语义层面的检测。根据提供者提供的服务和配置发起请求，如果返回符合预期，则判定服务存活。我们通常把这个检测留作扩展点，一般可以扩展HTTP、MySQL、Redis、Thrift等协议的语义检测。以HTTP为例，服务提供者配置检测URI，注册中心发送提供者的IP、端口和URI拼接后发起请求。如果响应符合预期（例如返回码为2xx），则检测成功。同样，也可以扩展其他协议的语义级检测。找到工作的底部很好，但有时很危险。如果注册中心与提供商之间的网络突然断开，则可能会导致所有提供商被移除。这是一个非常危险的操作。为了防止出现这种情况，底层作业是非常必要的行为。比如同一个服务集群不能被移除超过1/3。当然，这个比例是一个经验值，最好是可配置的。优雅发布生态建设优雅发布包括优雅退出和优雅启动。优雅是指在退出和启动应用程序的过程中不报错。注册中心结合发布系统是优雅发布的最佳搭配。停止应用前，发布系统向注册中心发起关闭请求（停止接收流量），退出后停止应用。启动服务并启动完成后，再次启动服务接受流量。该框架适用于注册中心。想要更多人使用，就需要适配Go/Java/Cpp等各种主流开发语言，适配Dubbo/SpringCloud/gRPC等一些主流框架，这样，用户使用起来更方便，但缺点是维护成本变高。DNS服务发现对于无法接入服务发现SDK的用户，如果想享受服务发现能力，应该怎么办？业界的一种方式是定制一个DNS拦截器拦截DNS请求，通过域名（对应服务名）去注册中心找提供商。但是这样有个缺点就是DNS只能发现ip，不能??自动发现端口。一般这种拦截器可以通过中央DNS服务器或者本地DNS代理来实现，也可以通过自定义编程语言的DNS解析插件来实现，比如Go/Java可以自定义DNS解析插件中，但这属于入侵更强。
