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

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

基于环境变量的方式

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

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

因为是使用环境变量的方式，所以接下来必须定义一个服务。下图服务的名称是rpcx-server-demo-service，使用的应用是上述定义的rpcx-server-demo应用，服务的端口是9981，集群内的其他容器组可以通过9981去访问Service，然后Service会把请求转到相应的port 8972的端口上，通过命令就可以把这个服务发布出去。

发布了服务端的应用和Ser