vlambda博客
学习文章列表

没有Istio框架不行?云原生下的四种微服务发现实践

嘉宾 |晁岳攀(鸟窝)  整理 | 张雪蕊

出品 | CSDN云原生
2022年2月24日,Go微服务框架rpcx作者晁岳攀(鸟窝)在2022云原生超级英雄会直播中,分享了如何在云原生环境下进行微服务发现。在没有Service Mesh或Istio框架的情况下,如何实现微服务发现?如何充分利用云原生的机制来实现微服务发现扩缩容或者故障容灾的形式?


没有Istio框架不行?云原生下的四种微服务发现实践

基于环境变量的方式


传统的微服务发现平台,比如阿里的nacos、etcd、zookeeper等会把服务端注册到服务发现平台上,客户端去发现节点。但是在云原生的环境下,Pod并不会固定在某一个节点上,因为K8s会进行调度:扩缩容的时候会进行调度、有故障的时候也可能会被调度。这种情况下客户端如何发现服务端的Pod,进行相应的服务调用?在K8s的环境下,会自动为K8s的Service定义,定义了相应的Pod再定义服务。通过环境变化定义一组环境变量,再通过环境变量就可以发现服务的VIP和调用的端口,这样客户端就可以发现服务进行调用。

下图所展示的是定义了一个服务端的应用rpcx-sever-demo。以rpcx传统的微服务框架如何在云原生环境下进行服务发现来举例,图中显示服务端应用的副本是3,在发布Pod或者应用的时候,会取三个Pod提供服务。使用的镜像是比较简单的服务端测试程序,用来实现基本乘法,定义其端口为8972,继而使用命令把应用发布出去

没有Istio框架不行?云原生下的四种微服务发现实践

因为是使用环境变量的方式,所以接下来必须定义一个服务。下图服务的名称是rpcx-server-demo-service,使用的应用是上述定义的rpcx-server-demo应用,服务的端口是9981,集群内的其他容器组可以通过9981去访问Service,然后Service会把请求转到相应的port 8972的端口上,通过命令就可以把这个服务发布出去。
没有Istio框架不行?云原生下的四种微服务发现实践
没有Istio框架不行?云原生下的四种微服务发现实践
接下来是rpcx的配置。下图中服务的class IP和端口写出来后续都是rpcx的正常调用方法,调用的是算术乘法服务。把参数10和20填进去就可以不断循环调用这个服务,也可以查看log日志。通过环境变量的方式得到Pod形成的Service地址,Service会把相应的请求转到对应的Pod上。
没有Istio框架不行?云原生下的四种微服务发现实践
但是会有一个问题:客户端调用的时候把所有的请求都发在了其中一个Pod上。在下图中可以看到刚刚发布的三个服务端Pod,只有第二个Pod被调用了。
没有Istio框架不行?云原生下的四种微服务发现实践

因为rpcx框架是创建一个长连接,和服务端的长连接进行通讯,在长连接上不断把服务调用的请求发过去,然后在服务端的连接上收到这个请求。因此若创建了一个连接,这个连接在不中断或没有异常情况下,永远只和其中一个Pod进行通讯。所有的请求都是发在同一个Pod上,其他两个Pod处于空闲状态,在这种情况下服务端没有负载均衡的能力,这是它的一个缺点。


没有Istio框架不行?云原生下的四种微服务发现实践
基于DNS的方式

K8s会为Services和Pods生成相应的DNS记录,通过DNS记录可以查到相应的Service和Pod。Service可以根据其名称去查询,Pod根据IP地址生成域名。在微服务情况下客户端想查某一个Service下面所有Pod的信息,只需要使用Service的域名,查出一组相应的Pod记录就可以实现负载均衡的能力。 
直接使用服务的名称也可以访问。如下图演示,执行三次client端容器的ping服务,访问的分别是0.3、0.3、0.5,因此可以发现Pod的地址是随机的,不会固定在同一个地址上。

没有Istio框架不行?云原生下的四种微服务发现实践

没有Istio框架不行?云原生下的四种微服务发现实践

但DNS有一个限制,消息的大小是固定的。如果Pod非常多,有几十、上百个,服务端只能查询出来部分Pod,且每次结果可能都不一样,这会导致漏掉一些服务端或服务端总是来回变化。但在服务端比较少量的情况下仍可以通过DNS的方式,这种调用方式本身是没有问题的。

没有Istio框架不行?云原生下的四种微服务发现实践
通过k8s的API客户端从POD内读取服务的endpoints

从Pod内访问K8s的信息需要把权限设置好,允许Pod内能查询相关信息。下图所示通过“getPodsIPs”命令首先查询服务对应的Pod有哪些,利用查询出来的节点,为每一个endpoint设置一个链接,通过一些负载均衡的方式,比如轮巡、随机等方式去访问也能实现负载均衡。图中运行的程序实现了第一次查询,后续还需要启动一个定时任务查询,如果有变化,会通知rpcx client重新生成endpoint的信息来保证后续调用使用最新的服务器信息。

没有Istio框架不行?云原生下的四种微服务发现实践

没有Istio框架不行?云原生下的四种微服务发现实践

没有Istio框架不行?云原生下的四种微服务发现实践
基于第三方服务发现平台的方式

传统的框架有etcd、consul、zookeeper,rpcx使用的redis,一些大厂的服务发现平台也各有不同,如阿里nacos,腾讯polaris,微博vintage等等。其他一些公司也有基于自己具体情况开发的服务发现平台,把服务端的信息注册到平台上,客户端访问相应的节点得到服务端的信息,就能发现这些服务端,然后再根据一些算法就可以访问这些服务并实现负载均衡。
在传统的方式下,上述内容可以操作,但是在K8s情况下服务端的节点都是一个个Pod,这些Pod需要把自己的信息注册到这些平台之上,如果某些Pod被迁移到其他的节点上,需要把自己新的信息注册到新的节点,在这种情况下应该怎么去做? 
以nacos为例,在服务端程序启动的时候要把服务平台的信息通过环境变量的方式告诉服务端程序。图中把nacos的主机名、端口写出来,服务端通过环境变量就可以知道到去哪个nacos平台注册。服务端还需要把自己的Pod信息注册上去,因为在这种情况下其他rpcx的client就可以得到Pod的信息,通过这种方式得到机器的Pod IP地址放在环境变量里。

没有Istio框架不行?云原生下的四种微服务发现实践

没有Istio框架不行?云原生下的四种微服务发现实践

没有Istio框架不行?云原生下的四种微服务发现实践

在云原生的环境下,可以通过上述四种方式实现微服务发现。关于微服务发现的实践,大家有任何想法欢迎评论区留言交流。

END



云原生志愿者计划正在招募🔥 

精准把握技术趋势,深度学习新技术、新实践


扫描图片二维码立即申请加入


 
   
   
 
— 推荐阅读 —
  
    
    
  


一键三连 「分享」「点赞」「在看」

成就一亿技术人