无法往开启kerberos的zookeeper上注册服务_Spring Cloud Alibaba 微服务生态初探

最新推荐文章于 2024-01-31 14:37:23 发布

weixin_39885067

最新推荐文章于 2024-01-31 14:37:23 发布

阅读量105

点赞数

文章标签：无法往开启kerberos的zookeeper上注册服务

大局观

Spring Cloud Alibaba，是继Spring Cloud和Spring Cloud Netflix后，搞了一套自己的微服务生态，但实际两者存在一些功能重合。我找到了一张图，展示三者的关系，手绘图，真不容易：）。

区别

我们可以看到Spring Cloud Alibaba与Spring Cloud和Spring Cloud Netflix两者实际有些服务功能是重合的，例如

上面看到了，实际spring cloud alibba，核心功能上面做了一套，自己的服务，综其原因，我觉得主要alibaba想出一套自己的生态，不必依赖其他服务，不需要依赖其他开源厂商。

Sring Cloud alibaba组件的初探

我们先从alibaba的几个核心组件讲起

注册中心：nacos server

注册中心nacos是alibaba的一大能手，该有的功能基本都全了。下面列几点出来。

数据存储：nacos实际是对注册的微服务实例是支持临时实际，也支持实例持久化（实例数据持久化到磁盘文件）。

分布式协议：AP、CP两者之间是有很大的不同，临时实际才用的是AP原则，持久化模式才用的CP。

- AP：A是可用性（Availabilit）,P是容错性，表示当集群中如果要一台机器宕机，其他机器存活的情况下，客户端依旧能够正常使用。但是不支持一致性原则，也就是说三台机器，一台机器宕机，这期间可能有部分数据没有同步到另外两台机器，就会导致另外两台机器的数据是不全的，但是客户端client还是可以正常从另外两台机器获取服务实例信息。
- CP：C是一致性（Consistency）,P是容错性，这时候的集群模式就会变化，因为这种模式必须依赖主从模式，就是说三个机器必须只有一个主节点，其他机器只能是从节点，而只有主节点可以写数据，其他节点只能读数据，当有一台机器宕机后，必须选举出主节点后，数据同步完毕才可以提供给client请求，选举期间是不能操作数据的。但是可以保证数据肯定是一致性的。

注册实例变更：当有注册实例的时候发生数据，client和服务端之间怎么交互呢？

- 服务端主动推：
  - 服务端当有新的实例过来注册的时候，服务端监听到注册事件，就会给所有注册过的实例发生一个实例变更推送，这个推送使用的是tcp协议机制，通过tcp协议把当前的注册实例信息推送给client，client接收后修改本地的内存的实例信息。
- 客户端主动发现：
  - 一种：客户端client，就是微服务启动的立马注册到注册中心，同时会开启一个线程pushReceive线程，与nacos建立UDP无连接协议，用来接收UDP事件变更事件。
    - 这样实际上解决了一个服务器压力负载问题，因为当你有成千上百的微服务注册变更的时候，用tcp维护成千上百的连接，服务端压力极大的。而使用udp因为不用保持长连接，但是还是有可能出现因为网络抖动问题导致客户端接收不到，所以nacos还提供另外一种机制主动发现，接收主动获取实例信息，请见如下第二种。
  - 第二种：客户端ribbon会开启一个定时任务，每个一段时间从nacos服务获取到当前的所有服务器实例，然后比对本地内存版本信息，找到哪些需要删除，哪些需要更新，哪些新增，从而与nacos服务的注册实例信息一致。当有请求指定微服务的时候从中找到对应的实例信息，从而匹配到该微服务实例。

集群事件同步：

提出问题：当nacos模式是AP模式，即临时实例模式时，当有三台nacos服务，client注册的时候肯定只能选择其中一台机器进行注册，那这时候就会有一个问题，另外两台机器的服务是不知道的。实际nacos已经帮我们做好的。

- 实际上nacos当接收到client注册实例，不仅会给当前所有instance实例发送事件变更通知，还会通知其他nacos服务，原理是通过http协议，调用其他nacos服务提供的http接口，把注册信息反馈给其他节点机器。其他两台nacos服务也是这种原理。

心跳机制：

提问问题：当有client实例过期了，获取网络中断，那这时候怎么把该实例剔除就是个问题了，不可能我实例网络断了，每次都访问该实例吧，那每次都会等待好多时间？

nacos提供的解决方案如下

- 开启心跳：client注册实例时，就会开启一个心跳定时任务，每隔一段时间就会触发心跳机制，往nacos服务发送一个请求，是通过http协议请求到nacos服务端。注意：这里跟上面注册实例一样，只针对其中一个实例，但nacos会把该信息变更同步到几台nacos服务，不需要client负责。
- nacos检查心跳：当接收到client的心态时，会修改内存中该实例的最后心跳时间。nacos服务端也会开启一个线程，不停地检查所有实例的最后心跳。
  - 当超过15秒则，就会修改该实例的healt状态为false，并同步其他机器服务。
  - 当超过30秒后，就会把实例删除，并同步其他机器服务。

选举机制：

这个机制实际上只有开启持久化模式才有生效，但是我想大概讲一下。

如果是集群模式，主节点的选举机制必须投票结果大于总数/2，也是说如果你有三台机器，但是如果一台机器挂了，投票数只有2票，大于3/2=1，即可以选举中主节点。

而如果只有1票，那选举不出来。

选举流程：出现宕机的时候会各种以为自己的老大，然后就会发送选票信号，给其他机器，说，你要给我投票，当然其他机器也可以这样方式发。当机器看到你的机器正常，没问题，对方就会同意选票。当大于3/2=1时，最先开始投票完成就当选老大，即主节点。
如何保证不会同时出现leader主节点的情况：nacos做了一个乱序机制，就是发起投票不能是同一个时间发起，比如说三个机器，A发起后，B必须等待ms后才可以进行，C也必须等待ms秒后才可以进行，达到时间上的一个先后顺序，保证不出现同时选举成功的情况。

数据隔离：

这是nacos另外一个强大的功能，不知道你有没有出现过这种场景，项目中需要搭建了一个环节，里面不仅存在开发环境，也要存在测试环境，有时候甚至是生产环境。各种配置是很头痛的事情，但是nacos帮你完成。

- 空间隔离：什么意思呢，就是说我支持一套环境中，多种环境同时出现，比如说支持开发环境，测试环境，联调环境，生产环境。
  - 但是各种环境之间都有不同的配置文件，nacos做的就是把不同环境之间分离开来，可以在nacos配置中心，定制一个通用的配置，比如说dev_common.yml，就是说所有开发环境都使用这个配置文件，这个配置连到开发库。
  - 比如说rm_common.yml，就是说所有测试环境都使用这个配置文件，这个配置连到测试库。
- 服务隔离：
  - 就是说微服务之间调用，是不能跨空间的，开发环境微服务A只能远程调用开发环境的微服务实例B，A测试环境的微服务只能远程调用测试环境的微服务实例B，这样就大大方便的，运维的操作性。
- 版本隔离：
  - 不仅支持不同环境的隔离，还支持金丝雀模式，就是说给每个微服务打个不同的版本，因为这时候上线我们只能上线一部分实例，测试确实可行，我们再把所有微服务上线，避免了影响全量用户。出现问题可以及时止损。
  - 使用也很简单，就是给你的微服务标记一个元数据，version：v1，如果是新上线的版本，则标记为version：v2。不过需要在路由规则做处理，就是说服务发现只能选择相同版本的微服务实例，因为这块属于业务逻辑，nacos让开发自己实现。
  - 当后面出现问题，也很简单，直接把version：v2，下线即可，只需在nacos控制台页面，点击下线，即可完成，平滑过渡，完美。

写得有点多了，有点累，暂且把nacos服务写完，下次再给大家讲解cloud的gateway，alibaba的seata。学会了吗，觉得有用请点赞，关注，谢谢。