使用头盔和kubernetes的微服务结构

Question

我们有几个微服务（基于NodeJS的应用程序）需要相互通信，其中两个使用Redis和PostgreSQL。以下是我的微服务的名称。他们每个人都有自己的SCM存储库和Helm Chart.Helm版本为3.0.1。我们有两个环境，我们有两个value.yaml，每个环境。每个集群中，也有三个节点。

首先，在最终用户执行操作之后，UI服务触发的次数将超过其进入后端的触发时间。根据最终用户的请求，后端服务需要与Market，Auth和API等任何服务进行通信。在某些情况下，API和市场微服务也需要与Auth微服务进行通信。

1. UI->
2. 后端
3. 市场->使用postgreSQL
4. Auth->使用Redis
5. API

我的问题是，

• 在相互之间交流微服务时应该注意些什么？这my-svc-namespace.svc.cluster.local是否足以提供开发人员，还是我们也应该在每个吊舱中指定ENV？

• 我们的微服务是NodeJS应用程序。如何开发。将在应用程序源代码中处理此问题？如果第一个问题的答案是肯定的，他们是否使用此服务名称？

• 我们想通过环境使用主机通过入口公开我们的应用程序吗？我想只能为UI微服务启用入口，对吗？

• 测试每个服务可以相互通信的最佳方法是什么？

---

kubectl get svc --all-namespaces

NAMESPACE     NAME                                         TYPE            

database      my-postgres-postgresql-helm                  ClusterIP                      
dev           my-ui-dev                                    ClusterIP 
dev           my-backend-dev                               ClusterIP 
dev           my-auth-dev                                  ClusterIP                 
dev           my-api-dev                                   ClusterIP 
dev           my-market-dev                                ClusterIP
dev           redis-master                                 ClusterIP                       
ingress       ingress-traefik                              NodePort            

Answer 1

在K8S中执行服务发现的两种方法

Kubernetes集群中有两种执行通信（服务发现）的方法。

• Environment variable
• DNS

DNS是在群集内实现服务发现的最简单方法。而且，不需要对每个吊舱进行任何其他的ENV变量设置。最简单的说，可以通过其服务名称访问相同名称空间中的服务。例如，http://my-api-dev:PORT可用于名称空间dev中的所有Pod。

标准应用程序名称和K8s服务名称

作为一种惯例，您可以为每个应用程序指定一个标准名称，例如。 my-ui，my-backend，my-api等。并使用相同的名称连接到应用程序。这种做法甚至可以在开发人员环境中本地应用测试，在/etc/host中输入

127.0.0.1 my-ui my-backend my-api

（以上与k8s无关，只是一种在本地环境中使用名称通信应用程序的实践）

[此外，在k8s上，您可以将服务名称分配为相同的应用程序名称（请避免使用类似-dev的后缀作为服务名称，以反映环境（开发，测试，生产等），而不是使用名称空间或单独使用集群）。因此，可以在每个应用程序的配置文件中使用目标服务的端点名称配置目标应用程序端点。

Ingress用于具有外部访问权限的服务

仅应为需要外部访问的服务启用入口。

自定义健康检查端点

[此外，最好进行一些自定义运行状况检查，以验证所有依赖的应用程序是否正常运行，这也将验证应用程序的通信是否正常。