共计 1316 个字符，预计需要花费 4 分钟才能阅读完成。
原文：https://wenda.swoole.com/detail/108785
前言
在传统架构下，咱们须要应用服务发现、服务注册等技术实现微服务架构。通常咱们须要将服务提供方（Service Provider）的节点（IP:PORT）保留在 ZooKeeper、ETCD、Consul、Nacos 等服务治理组件，服务调用方（Service Customer）能够读取到节点列表，发动 RPC 调用，建设连贯并发送申请、接管响应。
通常咱们须要依赖特定框架的实现，比方 Spring Cloud、Dubble、Hyperf 等框架。在云原生时代实现微服务不再须要这样，咱们能够 间接应用 K8s 提供的 Service 来实现微服务架构，将服务注册发现下沉到零碎底层。可靠性更高，稳定性更好，而且是人造跨语言的，Java、PHP、Golang 都能够应用，开发框架也会变得更简略，不须要做任何事件，只须要实现服务的逻辑，监听本机端口即可。
K8s Service 介绍
Service 是 K8s 提供的发现后端 Pod 的一种机制，为一组具备属于同一个 Deployment 的所有 Pod 提供了对立的入口地址，将申请进行负载散发到各个 Pod。
在 K8s 中 Pod 就相当于是 Linux 零碎的过程，是执行应用程序的容器组。如何拜访 Pod 中的服务呢？间接去连贯 Pod 的 IP:Port 必定是不行的，因为它是不稳固的，随时可能会产生调度而重启，Pod 的生命周期是十分短暂的。而 Pod 重启之后 IP 端口会发生变化。一个服务或利用通常会有 1-N 个 Pod，申请 Service 的 IP:PORT 时会主动负载平衡并转发到其中一个 Pod，Service 个别是应用 kube-proxy 和 Linux 内核提供的 IPVS 技术实现。也能够了解为 Service 其实就是一个 4 层代理，后端是利用的 Pod，在 Service 之前咱们能够设置 Ingress 接入网关，容许从集群内部拜访，个别对外服务的 HTTP 接口就是这个形式。也能够间接应用，只容许外部拜访，这就是微服务模式。
在 Code-Galaxy 平台上应用 Service
K8s 为每个 Service 调配了一个 Name，这个 Name 曾经注册到了 CoreDNS 中，可间接应用 gethostbyname 或其余 DNS 解析办法，将 Server Name 解析成 Service 的 IP 地址。一个 Service 须要设置对外端口，也就是拜访此 Service 对外裸露的端口，另外一个是外部端口，也就是 Pod 的端口。Pod 相干的信息会被保留在 K8s 的 ETCD 分布式存储中。
例如应用 Hyperf 框架，默认会监听 9501 端口，对外心愿服务调用方间接通过 80 端口拜访，那 Service 的内: 外别离就是 9501:80。这时就在其余服务中就能够应用 HTTP 客户端拜访 http://ServiceName:80/ 来申请此服务了。
不同的命名空间相互拜访时，须要在
Server Name之后追加.{$namespace}
参考：
- https://blog.csdn.net/huahua1999/article/details/124237065
- https://blog.51cto.com/u_15049785/4174726
