注册中心以及演进

最新推荐文章于 2024-06-11 15:51:10 发布

韩哥123456

最新推荐文章于 2024-06-11 15:51:10 发布

阅读量1k

点赞数 1

分类专栏： rpc 文章标签：分布式 zookeeper 数据库 java

本文链接：https://blog.csdn.net/u014274324/article/details/107735568

版权

rpc 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

注册中心现在是服务框架实现服务治理的核心，随着服务的增多，注册中心也是大势所趋，但是对于大多数的公司来说，小型注册中心是够用的，但是对于大厂来说，显起来不那么够用。

1：dubbo注册中心

服务提供方（Provider）所在的应用在容器中启动并运行（这个容器可以说是该应用部署的tomcat）
服务提供方（Provider）将自己要发布的服务注册到注册中心（Registry）
服务调用方（Consumer）启动后向注册中心订阅它想要调用的服务
注册中心（registry）存储着Provider注册的远程服务，并将其所管理的服务列表通知给服务调用方（Consumer），且注册中心和提供方和调用方之间均保持长连接，可以获取Provider发布的服务的变化情况，并将最新的服务列表推送给Consumer
Consumer根据从注册中心获得的服务列表，根据软负载均衡算法选择一个服务提供者（Provider）进行远程服务调用，如果调用失败则选择另一台进行调用。（Consumer会缓存服务列表，即使注册中心宕机也不妨碍进行远程服务调用）
监控中心（Monitor）对服务的发布和订阅进行监控和统计服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（Monitor）;Monitor可以选择Zookeeper、Redis或者Multiast注册中心等，后序介绍。

2：注册中心规模

2.1：小型注册中心

单数据中心
服务规模较小：接口数在 5K 以下，注册中心客户端数量在 50K 以下。

2.2：中型注册中心

多数据中心
服务规模较大：接口数在 20K 以下，注册中心客户端数量在200K以下。

2.3：大型注册中心

非常多的数据中心
服务规模十分大，单节点无法满足全量存储。

3：cp类注册中心演进

3.1：单注册中心高可用

部署奇数个节点，leader贮机，半数以上节点存活，就能重新选举一个leader，注册中心始终能够保证可用，这也是大多数公司的现状，数据量不大，完全hold的住。

3.2：单注册中心进阶（读写分离）

随着读的压力增大，如果把读写还放在选举节点，这些节点会压力很大，可能会导致选举发生，为了避免这种事情发生，会部署多台Zookeeper Observer节点，Observer节点承担读的任务，follower和leader不再担任读的任务，只负责写数据和选举，类似于主从的读写分离。

3.3：单注册中心进阶（监控中心）

通过Zookeeper的临时节点可以实现状态检测，但是一般不是很推荐。因为注册中心和服务提供者断开连接的时候，注册中心其实是无法判断服务提供者是服务异常还是只是网络分区，最好是有额外的辅助进行判断。例如提供一组状态检测服务，部署在机房的不同域（例如跨机架、跨交换机等，越分散越好），进行一定的投票，如果半数以上认为死了，则上报状态给注册中心。

3.4：单注册中心跨机房容灾（同城多机房）

随着业务量的增大，可能会出现同城多机房的情况。每个机房部署相同的节点，当其中一个机房出现网络分区，那么剩下的两个机房继续可用。状态检测服务只检查自己同机房的节点。一般机房也是奇数个的，最好3机房，为什么不是2机房？2机房的话，一个机房3个，一个机房2个，3个节点的挂了，剩下的另一个机房就不可用了。如果是3机房，每个机房3台机器，一个机房挂了，剩下的仍旧可用。

3.5：多注册中心（同城多机房，异地多机房，数据不共享）

随着公司的规模进一步的增大，需要同城多机房，异地的多机房，zookeeper保存全量的数据，对于体量很大的公司来说，同城多机房单注册中心已经满足不了需求了，可能zk的某台机器出问题，由于体量很大，可能整个集群被瞬间打死，起都起不来，这也是单点的问题，另外单注册中心推送的是全量的服务机器列表，压力也会集中在这一个集群上，这个时候我们不得不进行多注册中心的决策，但是多个注册中心的数据不共享，如果客户端需要多个注册中心的数据，不可避免的情况就是需要客户端需要连接多个注册中心，做数据的聚合，从而获得所有的注册数据，比方我们有海淀，房山，大兴的机房，我海淀的机房可能用到大兴的服务，如果海淀的注册中心只有海淀的数据，我不得不去拉取大兴注册中心的数据，这就是需要客户端聚合数据了。

3.6：多注册中心（同城多机房，异地多机房，数据共享）

客户端做数据的聚合，这并不是一个合适的操作，所以注册中心做数据同步是一个基本上的必然选择，客户端只关心注册的数据就好，不需要再去做数据的聚合，但是如果注册中心特别多，保存全量的数据是一个很奢侈的成本，有选择性的做哪些机房的同步也是一个不错的选择，所以我们一般只做同城多机房数据的聚合，异地机房，比如北京和上海，需不需要做，那只能看你自己的需要了，因为北京到上海的网络开销可能就导致你的服务性能提不上来，这个服务方也就没什么必要了。

4：ap类注册中心演进

4.1：注册中心高可用

我们采用数据库主备或者是 Redis 集群作为一个统一的数据源，然后开发 Registry Proxy 程序（以下简称注册中心实例），这些注册中心实例之间并无数据交互，数据统一存在后端的数据源里，实现数据最终一致。注册中心实例其实是可以无限扩展的。这种代理模式的注册中心还有个好处就是：代理的业务逻辑可以自己编写。这个地方可以优化的地方非常的多。例如服务节点推送，在CP系统里基本上都是推送全量的服务节点，而在代理里面可以做推送变化部分的服务节点。假如一个服务有1000个服务提供者，5000个服务调用者；当增加了1个服务提供者的时候，原来的推送数量是1001x5000，而代理模式可以进行特殊处理变成1x5000，大大减少推送数据。

4.2：注册中心跨机房高可用（同城多机房）和只读缓存

注册中心的高可用依赖数据源跨机房容灾，并在上层做缓存。注册中心的只读缓存，如果内存里放得下则可以放在注册中心实例的内存里，如果放不下则可以是单独的存储服务。当主库机房挂了，其它机房切到新的主库。切换期间只能从注册中心只读缓存里读数据，但是不能修改数据。

4.3：注册中心多数据源（同城多机房，异地多机房，数据共享）

异地多机房，注册中心同步数据

异地多机房，数据源多写

上面是二种数据源同步的方法，数据无限水平扩展，当数据量大到单机无法承受，那么就需要进行数据分片了。有了注册中心实例（Proxy）的存在，这个事情就很好处理了，只需要在这个注册中心实例上增加分片的逻辑，原则上数据是可以无限扩展的，而且也不用修改客户端的逻辑，实现真正的轻客户端，另外cp的注册中心没有详细介绍，和上面ap注册中心基本上理念一致。