注册中心以及演进

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

1:dubbo注册中心

 

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

 2:注册中心规模

2.1:小型注册中心

  1. 单数据中心
  2. 服务规模较小:接口数在 5K 以下,注册中心客户端数量在 50K 以下。

 2.2:中型注册中心

  1. 多数据中心
  2. 服务规模较大:接口数在 20K 以下,注册中心客户端数量在200K以下。

2.3:大型注册中心

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

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注册中心基本上理念一致。

5:总结

二种类型的注册中心,我司采用的是第二种数据中心,第二种的成本是很高的,大多数的公司完全是没有必要的,第一种注册中心是完全够用的,成本也更低,具体的选型根据自己公司的需要吧。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页