今天在一个朋友的群里聊起 RPC 这类框架，恰好我也在写 RSF（一个分布式RPC框架）对于分布式环境来说，一个服务会有多个副本，调用端在多个副本之间如何抉择是一个很明显的问题。于是注册中心应运而生。
可是我心中一直有一个疙瘩，总觉得注册中心这个东西大可不必要的。于是索性设计一个套去中心化的解决方案，用以去中心化的分布式 RPC 框架的设计。
先说一下中心化的分布式 RPC 工作方式， 一般情况下“注册中心”负责接受服务上线时的心跳请求，并且“注册中心”会维持一个活跃的服务列表。当有消费者上线时“注册中心”会告诉消费者可用的服务列表。然后消费者会自己去轮询调用不同服务地址已完成调用。
如果某一个服务节点当掉了“注册中心”就检测不到节点的心跳于是会通知消费端服务下线。其实“注册中心”要做的一件事情就是监控死掉的服务。要想知道死掉的服务有两种办法：一种心跳监听、另一种主动发现。
“注册中心”走的是心跳监听的路线。如果遇到刚死的服务“注册中心”还没来得及通知，那调用发起的肯定还要在做一次异常重试。于是在客户端又多了一个主动发现的容错方案。
我觉得这是完全重复的工作是没必要的，两者留一个就可以了。况且客户端去调用远程服务时候，既然都要去发现服务是否真的死掉，为嘛还要搞一个“注册中心”？
而且“注册中心”一旦挂掉，新上线的机器无法及时更新到 IP 列表，这样的影响会更大。为了避免这种事情，我们又把“注册中心”做了热备。 这种设计是不是太重了呢？
所以我觉得一定要去中心化！
BT 软件下载，有一个很好的思想。
BT在下载软件你只要知道一个种子地址，剩下的客户端会根据种子地址去发现更多的可用源来下载文件。我们可以使用这种思想让服务端在启动时通过一个源自动发现更多的服务可用地址。
但是这里有一个问题，我们先回归生产环境。一个庞大的集群可能会有几十万个服务在跑，这个已经是很大规模了。你不能要求这几十万的服务之间相互P2P的调用通信，这不科学。
于是我想到，只保留 BT 思想里种子的概念，然后用爬虫的机制让机器与机器之间相互分享自己的地址列表和服务列表。这样一来台机器只需要知道我想要什么，然后到本地地址池里去找自己的资源就可以了。
本地地址池的建立可以首先通过种子服务器预热，只要获取到一个可用的IP地址列表在本地缓存起来。第二次启动时就完全不需要源了。
这个就是自动发现的原理。剩下的就是你只需要一台种子服务器，负责提供初始的 IP 地址列表就行了。一旦完成第一次启动RPC客户端从源中取到了更多可用的源，那么就不再需要这个最初的源服务器了。从而也就完成去中心化。
至于死去的服务， 每台客户端在遇到调用长时间无响应时候会自动去做降权处理。当超过一定次数之后自动将这个死掉的IP地址处理掉。
有朋友会问，你的种子服务器一旦挂掉怎么办？
要知道在这种去中心化的架构里，种子服务器不是中心。任何一台服务器都是种子服务器。你只需要让最先启动的两台服务器之间知道彼此的存在，后面启动的服务器都会纷纷加入到这个网络中，分享彼此的地址本。这样一来每台服务器都是“中心”了。
当选定的种子服务器当掉了怎么办？
每台服务器在启动的时候，都会在本地建立一个缓存的地址本。里面会有很多备选服务地址可以去连接，这些地址都是种子服务器，所以只要你服务成功跑起来一次那么就什么都不怕了。
服务挂掉当请求超时对服务地址做降权处理。长期不再活跃的服务 IP 会被剔除。这样一来就清爽很多了。
另外一个问题也会涉及到注册中心，那就是“服务治理”，所谓服务治理是指一大堆策略性的配置，比方说流量管控、服务降级、服务热下线、服务监控以及多机房路由优化。
而我觉得这些东西最总落实在注册中心上的只能是一些策略性的配置，真正执行策略的还是分散各个节点上的服务器。因此注册中心在其中的作用也仅仅是统一策略管理和策略的分发。
如果去中心化的这些策略分发，可以利用服务器之间分享的方式来传播变更。这样一来你只要把策略下发到其中一台服务的机器上，它便会为你传播到所有机器上，服务治理的问题也就解决了。
1418
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
