实训百度搜索引擎的总结,百度seo技术,校园招聘哪个网站做的好,做网站的字体大小前言
在之前的章节中#xff0c;我们已经成功地将Dubbo项目迁移到了云环境。在这个过程中#xff0c;我们选择了单机ZooKeeper作为注册中心。接下来#xff0c;我们将探讨如何将单机ZooKeeper部署到云端#xff0c;以及在上云过程中可能遇到的问题及解决方案。
ZooKeeper…
前言
在之前的章节中我们已经成功地将Dubbo项目迁移到了云环境。在这个过程中我们选择了单机ZooKeeper作为注册中心。接下来我们将探讨如何将单机ZooKeeper部署到云端以及在上云过程中可能遇到的问题及解决方案。
ZooKeeper是一个开源的分布式协调服务由Apache软件基金会开发。它主要用于实现分布式系统中的配置管理、命名服务、分布式同步和组服务等是一个功能强大、高性能、高可用性和可扩展性的分布式协调服务广泛应用于各种分布式系统和微服务架构中。ZooKeeper的主要特点如下 高可用性ZooKeeper通过在集群中选举领导者来确保系统的可用性。当领导者不可用时其他服务器可以自动选举出新的领导者从而保证了系统的持续运行。 数据一致性ZooKeeper使用一种称为“原子广播”的数据同步机制确保所有节点上的数据保持一致。这对于需要高度一致性的分布式应用(如金融交易系统)非常重要。 高性能ZooKeeper具有低延迟和高吞吐量的特点适用于处理大量并发请求。它使用了多种优化技术如内存管理和多线程以提高性能。 可扩展性ZooKeeper支持水平扩展可以通过增加服务器节点来提高系统的容量。此外ZooKeeper还提供了负载均衡功能可以根据服务器的负载情况自动分配客户端请求。 灵活性ZooKeeper提供了丰富的API和工具方便开发者进行集成和定制。同时它还支持多种编程语言如Java、C、Python等。
ZooKeeper的云端迁移
由于我们还有一些Dubbo服务并未部署在Kubernetes集群内因此我们需要在Zookeeper中采用NodePort方式来暴露相关端口。这样一来外部的Dubbo服务便可以通过访问Zookeeper节点的IP地址和NodePort号来建立连接从而实现对其他Dubbo服务的访问。
在之前的文章中我们提到了我们的Dubbo版本为2.7.22。因此在查阅了Dubbo官方文档中关于Dubbo版本与ZooKeeper版本之间的依赖关系后我们选择的ZooKeeper官方镜像为zookeeper:3.4.9。 基于以上的历史原因我们最终的部署文件如下所示
apiVersion: v1
kind: Service
metadata:name: zookeepernamespace: your-namespace
spec:selector:app: zookeepertype: NodePortports:- name: clientport: 2181targetPort: 2181nodePort: 30000- name: followerport: 2888targetPort: 2888nodePort: 30001- name: leaderport: 3888targetPort: 3888nodePort: 30002
---
apiVersion: apps/v1
kind: Deployment
metadata:name: zookeepernamespace: your-namespace
spec:replicas: 1selector:matchLabels:app: zookeepertemplate:metadata:labels:app: zookeeperspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: project.nodeoperator: Invalues:- your-namespacecontainers:- name: zookeeperimage: zookeeper:3.4.9imagePullPolicy: IfNotPresentterminationMessagePath: /dev/termination-logterminationMessagePolicy: Fileports:- containerPort: 2181- containerPort: 2888- containerPort: 3888volumeMounts:- name: datamountPath: /datavolumes:- name: datahostPath:path: /var/lib/docker/zookeeper在这个配置文件中我们使用了一个名为zookeeper的Deployment来部署单机ZooKeeper并使用了一个名为zookeeper的Service来暴露端口。Service的类型被设置为NodePort这样可以在集群外部链接ZooKeeper。Service的选择器指定了要暴露的Pod这里使用了一个名为zookeeper的标签。Service的端口被设置为2181、2888和3888分别对应ZooKeeper的客户端端口、跟随者端口和领导者端口。targetPort字段指定了要转发到Pod的端口这里使用了相同的端口号。nodePort字段指定了要暴露的端口号这里分别使用了30000、30001和30002端口。我们将/data目录挂载到了宿主机的/var/lib/docker/zookeeper目录。这个目录用于存储ZooKeeper的数据和日志。
启动一个Dubbo服务我们使用刚刚部署的Zookeeper作为注册中心。同时我们也部署了一个Dubbo-Admin,它同样链接到刚刚部署的Zookeeper上。登录到Dubbo-Admin前端页面我们发现服务已经成功注册。至此Zookeeper已成功迁移到云端。 ZooKeeper的平滑迁移
根据上述步骤我们已经成功部署了一个可用的单机ZooKeeper。那么如何将线上存量服务在不停机的情况下优雅的平滑迁移过来呢
其实在Dubbo官方文档中已经给了我们答案多注册中心地址不聚合。
Dubbo 注册中心和服务是独立配置的通常开发者不用设置服务和注册中心组件之间的关联关系Dubbo 框架会将自动执行以下动作
对于所有的 Service 服务向所有全局默认注册中心注册服务地址。对于所有的 Reference 服务从所有全局默认注册中心订阅服务地址。
dubbo:registry idone addresszookeeper://127.0.0.1:9090 /
dubbo:registry idtwo addresszookeeper://127.0.0.2:9010 /因此当我们配置如上所示独立配置的注册中心组件时Dubbo会将所有的Service服务同时注册到这两个ZooKeeper上并且所有的Reference服务也会同时订阅这两个ZooKeeper。地址列表在消费端默认是完全隔离的负载均衡选址要经过两步
注册中心集群间选址选定一个集群注册中心集群内选址在集群内进行地址筛选 注册中心集群间选址策略有如下几种 随机默认策略每次请求都随机的分配到一个注册中心集群。随机的过程中会有可用性检查即每个集群要确保至少有一个地址可用才有可能被选到。 preferred 优先如果有注册中心集群配置了 preferredtrue则所有流量都会被路由到这个集群。 dubbo:registry idone addresszookeeper://127.0.0.1:9090 preferredtrue/
dubbo:registry idtwo addresszookeeper://127.0.0.2:9010 /weighted基于权重的随机负载均衡以下集群间会有大概 10:1 的流量分布。 dubbo:registry idone addresszookeeper://127.0.0.1:9090 weight100/
dubbo:registry idtwo addresszookeeper://127.0.0.2:9010 weight10/同 zone 优先根据 Invocation 中带的流量参数或者在当前节点通过 context 上下文设置的参数流量会被精确的引导到对应的集群。 dubbo:registry idone addresszookeeper://127.0.0.1:9090 zoneone/
dubbo:registry idtwo addresszookeeper://127.0.0.2:9010 zonetwo/RpcContext.getContext().setAttachment(registry_zone, one);在这里我们采用默认的随机策略因为在随机的过程中会有可用性检查这确保了我们的消费者服务始终能够连接到可用的提供者服务为我们不停机迁移提供了基础。
接下来我们需要对代码进行修改具体操作如下 dubbo.xml 删除以下部分 !-- zookeeper注册中心 --
dubbo:registry address${dubbox.registry.address}/新增以下部分 !-- 老zookeeper注册中心 --
dubbo:registry idoldZkRegistry address${dubbox.registry.address}/
!-- 新k8s上zk注册中心 --
dubbo:registry idnewZkRegistry address${dubbox.registry.address.new}/配置文件在配置文件中新增以下配置 # 新k8s上zk注册中心地址ip为宿主机的ip端口为nodeport暴露的client的端口
dubbox.registry.address.new zookeeper://xx.xx.xx.xx:30000
在经过改造后我们的服务将同时注册到新的和旧的ZooKeeper上这就相当于我们搭建了一个ZooKeeper集群。当所有的存量服务都完成改造并成功部署上线后我们还需要对我们的代码进行进一步的改造。具体的步骤如下 dubbo.xml 删除以下部分 !-- 老zookeeper注册中心 --
dubbo:registry idoldZkRegistry address${dubbox.registry.address}/
!-- 新k8s上zk注册中心 --
dubbo:registry idnewZkRegistry address${dubbox.registry.address.new}/ 新增以下部分 !-- 新k8s上zk注册中心 --
dubbo:registry address${dubbox.registry.address.new}/ 配置文件在配置文件中删除以下配置 # 老zk注册中心地址
dubbox.registry.address zookeeper://xx.xx.xx.xx:2181
当我们的存量服务全部经过改造并成功部署上线后我们的老ZooKeeper才能够进行停机下线。至此ZooKeeper的平滑替换便顺利完成了。
小结
经过以上的阐述我们可以明确地认识到在决定ZooKeeper的部署版本时我们需要进行深入细致的分析充分考虑外部环境因素的影响例如Duboo版本之间的兼容性问题。为了确保ZooKeeper的平稳迁移并维持服务的连续性我们需要采取一系列策略如逐步升级、严格的功能测试和版本兼容性检查等。要在生产环境中实现ZooKeeper的平滑迁移并保持服务不间断这将需要投入大量的时间和精力。因此在我们正式上线生产环境之前必须进行详尽的规划全面预见未来可能出现的情况以最大程度地避免不必要的麻烦。只有这样我们才能确保项目的长期稳定运行。
