首页
下载
文档
问答社区
视频
捐赠
源代码
AI 助理
赞助商
CRMEB
Apipost
腾讯云
微擎
禅道
51Talk
商业产品
Code-Galaxy
Swoole-Compiler
CRMEB 新零售社交电商系统
登录
注册
全部
提问
分享
讨论
建议
公告
开发框架
CodeGalaxy
发表新帖
云原生时代 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 ](https://blog.csdn.net/huahua1999/article/details/124237065 "https://blog.csdn.net/huahua1999/article/details/124237065 ") 2. [https://blog.51cto.com/u_15049785/4174726](https://blog.51cto.com/u_15049785/4174726 "https://blog.51cto.com/u_15049785/4174726")
发布于1年前 · 28 次浏览 · 来自
分享
R
Rango
## 前言 在传统架构下，我们需要使用服务发现、服务注册等技术实现微服务架构。通常我们需要将服务提供方（`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 ](https://blog.csdn.net/huahua1999/article/details/124237065 "https://blog.csdn.net/huahua1999/article/details/124237065 ") 2. [https://blog.51cto.com/u_15049785/4174726](https://blog.51cto.com/u_15049785/4174726 "https://blog.51cto.com/u_15049785/4174726")
赞
1
分享
收藏
提问
分享
讨论
建议
公告
开发框架
CodeGalaxy
评论
2022-05-26
Rango
赞！
赞
0
回复
微信公众号
热门内容
暂无回复的问答
- CodeGalaxy K3s 轻量集群节点之间如何实现负载均衡
- 关于openssl CURL WARNING swSSL_connect: SSL_connect(fd=69) failed. Error: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small[1|394]
- 多个模型如何进行事务异常回退？
- websocket开启wss报错
- 协程tcp服务器如何使用多进程？recv()方法接收信息，打印出来的pid一直是同一个。没用使用到多进程啊。
