注册与发现的两种注册模式

​

其实常见的有两种注册模式，一种 client，一种是 proxy 模式。

两者各有特点，也各有合适的场景。

client 模式，明显的优势都是技术上的收益，比如不需要网络的两跳，没有 proxy 也不需要多做一个节点的高可用。

缺点是每次规则升级，都需要所有客户端升级，如果客户端太多，升级时就需要考虑可靠性。同时规则写在 client 代码里面，这部分规则如果没办法可视的话，对于研发人员也不友好。

很多分布式中间件采用这种模式，比如 redis、zebra。客户端存储元数据，多个客户端节点之间通过类似 gossip 的协议做数据一致性的近实时传播。

proxy 模式，需要在所有客户端节点和 server 之间做个聚合，优势是可以在这个 proxy 至上做一些对于流量的规则治理。比如我们常听到，计算机领域的很多问题，都可以通过加一层的方式解决，proxy 模式，就是这样的一层，很多服务注册与转发规则的注入可以放在这里。

比如服务注册的多种路由规则的可视化，因为有了这个平台，就有了治理的统一平台，但性能和可用性上存在不足。

所以对于中间件，如果对于延迟和高可用有要求的话，建议采用 client 模式。

如果在流量治理层面有很强定制性的，比如规则很多的话，可以引入 proxy 模式，比如网关层面的 api 编排就是这种情况。

当然好的方式是两者的结合，比如 mesh 就包含了控制面和数据面，控制面是 proxy 之外的 admin，数据面就是有规则的 client。

关键点是 client 要轻，便于升级，proxy 端要规则丰富，便于治理。

类似的 proxyless 也可以实现。

所有模式并不是那么重要的，关键点还在于如何实现，并不是某一个模式一定比其他一个要强，而是解决了对应的关键问题。