Nacos
首先先说说比较常规的nacos的服务注册与发现。
用spring cloud为例，ali集成了spring-cloud和nacos，因此加入以下依赖
然后我们配置nacos server的地址，并通过 Spring Cloud 原生注解 @EnableDiscoveryClient 开启服务注册发现功能，在 application.properties 中配置 Nacos server 的地址，启动服务之后，服务会将自己的元数据注册到nacos上，最主要的是服务名，ip，端口，namespace等。服务注册成功后，服务将与注册中心维持心跳，心跳机制可以保证当服务中的某个实例不健康之后，服务中心将该实例剔除，以保证服务正常提供服务。
当服务注册上去之后，消费者就可以调用服务了，那么消费者是怎么发现服务的呢，消费者向注册中心订阅某个服务，并提交一个监听器，当服务提供方实例发生变化，比如ip变了，消费者会收到通知，更新本地的服务列表，nacos client获取到服务列表之后，通过负载均衡，spring一般都是结合ribbon，获取一个可用的实例，得到它的ip和端口号，以及服务路由，然后进行调用。
由于客户端将获取到的服务实例保存在一个 map 中，而该 map 中的内容是由调度任务定时去更新的，存在一定的延时。
k8s
一般来说，在k8s中一个服务有多个实例，是通过pod去部署的，多个实例则有多个pod，每一个pod都会有自己的容器组ip，在集群内，直接通过这个容器ip和端口是可以访问服务的，但是每次服务重启，也就是pod销毁重建的时候，ip也会改变。k8s并没有一个注册中心让我们注册实例的ip和端口到服务下面，并且其他服务通过这个注册中心去发现服务。在k8s里是通过service去实现的。
这是一个service定义的例子， 这个 Service 将被指派一个 IP 地址（通常称为 “Cluster IP”），上述的selector代表这个service代理的pod选择器，也就是说具有这个app标签的选择器的一组pod，可以通过service这个统一的访问入口去做服务发现。
比如说我们现在有一组pod叫base-opc-biz
查看它的service
信息包括：name，namespace，selector，labels等基础信息
type是ClusterIP,IP这个值 即是在集群内部，其他所有的pod都可以通过这个虚拟的ip来访问service，service就会将这个请求负载均衡到后端的所有pod上去。
Port是访问service的端口
TargetPort是代理的pod的端口
Endpoints是当前service代理的所有pod的ip地址，当某个pod被销毁重建的时候，这里的ip地址也会随之变化
集群内其他pod访问我们创建的service有三种方式：
1、通过clusterIp+port直接去访问
2、同一个namespace直接访问服务名，不同的 namespace 里面，我们可以通过 service 名字加“.”kube-dns可以解决Service的发现问题，k8s将Service的名称当做域名注册到kube-dns中，通过Service的名称就可以访问其提供的服务。
Kubernetes 集群中部署了一套 DNS 服务，通过 kube-dns 的服务名暴露 DNS 服务。您可执行以下命令查看 kube-dns 的服务详情。
kubectl get svc kube-dns -n kube-system
服务后端是两个名为 coredns（下文会介绍 CoreDNS 解析原理） 的 Pod。您可执行以下命令查看 coredns 的 Pod 详情。
kubectl get deployment coredns -n kube-system
3、通过环境变量访问，在同一个 namespace 里的 pod 启动时，kubelet 会为每个活跃的 Service 添加一组环境变量，会把 service 的一些 IP 地址、端口，以及一些简单的配置，通过环境变量的方式放到 K8s 的 pod 里面。因此我们可以通过环境变量去直接访问。
上面三种方式都是在k8s集群内部互相访问的情况，对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。 Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。
我们看下我们原本的service 的yaml文件
把type改成NodePort 或者 LoadBalancer
然后重新创建service，再看看信息
发现有了EXTERNAL-IP，这个ip是一个公网的ip，因此我们就不只可以在集群上访问我们的服务了。