云原生时代 PHP/Golang 项目如何实现微服务

前言

在传统架构下，我们需要使用服务发现、服务注册等技术实现微服务架构。通常我们需要将服务提供方（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}

参考

1. https://blog.csdn.net/huahua1999/article/details/124237065

2. https://blog.51cto.com/u_15049785/4174726