原文：https://wenda.swoole.com/detail/108785前言传统架构下，我们需要用到服务发现、服务注册等技术实现微服务架构。通常我们需要在ZooKeeper、ETCD、Consul、Nacos等服务管理组件中保存服务提供者（ServiceProvider）节点（IP:PORT），服务调用者（ServiceCustomer）读取节点列表并发起一个RPC调用。建立连接并发送请求和接收响应。通常我们需要依赖特定框架的实现，比如SpringCloud、Dubble、Hyperf等框架。这对于在云原生时代实现微服务已经没有必要了。我们可以直接使用K8s提供的Service来实现微服务架构，将服务注册发现下沉到系统底层。它具有更高的可靠性，更好的稳定性，并且天然是跨语言的。Java、PHP、Golang都可以用，开发框架也会变得更简单。你什么都不用做，只需要实现服务的逻辑，监听这个机器端口即可。K8sService简介Service是K8s提供的一种发现后端Pod的机制。它为属于同一个Deployment的一组所有Pod提供了一个统一的入口地址，并将请求负载分配给各个Pod。在K8s中，Pod相当于Linux系统的进程，是一个执行应用程序的容器组。如何访问Pod中的服务？直接连接Pod的IP:Port是肯定不行的，因为不稳定，随时可能因为调度而重启，Pod的生命周期很短。Pod重启后IP端口会发生变化。一个服务或应用程序通常有1-N个Pod。当请求Service的IP:PORT时，它会自动负载均衡并转发到其中一个Pod。本服务一般使用kube-proxy提供的IPVS技术和Linux内核实现。也可以这样理解，Service其实就是一个4层代理，backend就是应用的Pod。在Service之前，我们可以设置Ingress访问网关，允许集群外访问。一般对外服务的HTTP接口都是这样的。也可以直接使用，只允许内部访问。这就是微服务模型。在Code-Galaxy平台上使用ServiceK8s为每个服务分配一个名称。这个Name已经在CoreDNS中注册过了，你可以直接使用gethostbyname或者其他DNS解析方式将ServerName解析为Service的IP地址。一个Service需要设置一个外部端口，就是访问Service时暴露给外界的端口，另一个是内部端口，就是Pod的端口。Pod相关信息会存储在K8sETCD分布式存储中。比如你使用Hyperf框架，默认会监听9501端口。如果想让服务调用者直接通过80端口访问，那么Service的内部和外部分别是9501:80。这时候你可以使用HTTP客户端访问其他服务中的http://ServiceName:80/来请求这个服务。当不同的命名空间相互访问时，需要在ServerName后面加上。{$namespace}参考：https://blog.csdn.net/huahua1999/article/details/124237065https://blog.51cto.com/u_15049785/4174726
