主机独立进程方案是上面两种方案的折中，代理既不集中部署，也不嵌入在客户的应用程序当中，而是作为独立的进程部署在每个主机上，这个主机可以是物理的或者虚拟的。一个主机上的多个消费者可以共享这个代理，实现服务发现和负载均衡。
第三代结构和第二代是类似的，也需要引入服务注册中心进行配合，三代之间只不过代理的位置发生了变化。
这个方案目前有个更时髦的称谓叫ServiceMesh。
开源产品：Envoy，Linkerd，Istio对应到服务注册中心，当然K8S也内置支持服务发现机制，也是属于第三代的主机独立进程方案。
K8S服务发现机制考虑到K8S在业界比较火，而且内部服务发现机制比较复杂，这里独立出来就进行剖析。
如上图所示，在K8S中一个服务是由一组Pod构成的服务集群。
Pod是K8S当中最基本的调度单位，它相当于K8S集群当中虚拟机的概念。
每个Pod都有一个PodIP，并且相互之间是通过PodIP相互访问，但是服务的PodIP在K8S当中是不固定的，可能会变(包括预期和非预期)。
为了屏蔽这种变化，K8S引入了服务Service这个概念，一方面实现服务发现和负载均衡，另一方面屏蔽PodIP可能的变更。
在服务发布的时候，K8S会为每个服务分配一个虚拟的ClusterIP
在K8S的worker节点上，有kubelet和kube-proxy，其中后者是实现服务发现的关键，上面是简化的服务发现流程。
服务注册阶段：
其中kubelet负责启动Pod服务实例--->
启动完成后kubelet会把Pod的IP列表注册到Master节点上-->
最后通过服务Service的发布，K8S会为服务分配相应的ClusterIP，相关信息也会记录在Master上。
服务发现阶段：
kube-proxy会发现clusterIP和podIP列表之间的映射关系，并且修改本地iptables的转发规则，进行负载均衡和转发到对应的PodIP
当有消费者Pod要访问某个目标服务实例Pod的时候，通过ClusterIP发起调用，这个ClusterIP会被本地的Iptables机制截获，然后进行负载均衡，转发到指定的Pod实例。
实际消费这Pod也是通过服务名进行访问ClusterIP，因为ClusterIP本身也会变，为了屏蔽变化，K8S还引入了kubeDNS这个概念，它通过master可以发现服务名和ClusterIP之间的映射关系。这样消费者Pod通过kubeDNS间接的发现服务的ClusterIP。
比较总结和选型
三种方案各有利弊，没有绝对的好坏。他们都有大规模的成功落地的案例。架构师需要在理解这些方案优劣的基础上，根据企业的实际上下文，综合考量，做出技术选型。