frontier/README_es.md

English | 简体中文 | 日本語 | 한국어 | Español | Français | Deutsch

Frontier es una pasarela de conexión persistente de full-dúplex y código abierto, escrita en Go. Permite que los microservicios lleguen directamente a los nodos de borde o clientes, y viceversa. Ofrece RPC bidireccional full-dúplex, mensajería y flujos punto a punto. Frontier sigue los principios de arquitectura cloud-native, admite un despliegue rápido de clústeres mediante Operator y está diseñado para alta disponibilidad y escalado elástico hasta millones de nodos de borde o clientes en línea.

Tabla de contenidos

• Características
• Inicio rápido
• Arquitectura
• Uso
• Configuración
• Despliegue
• Clúster
• Kubernetes
• Desarrollo
• Pruebas
• Comunidad
• Licencia

Inicio rápido

1. Ejecutar una única instancia de Frontier:

docker run -d --name frontier -p 30011:30011 -p 30012:30012 singchia/frontier:1.1.0

2. Compilar y ejecutar los ejemplos:

make examples

Ejecutar el ejemplo de sala de chat:

# Terminal 1
./bin/chatroom_service

# Terminal 2
./bin/chatroom_agent

Vídeo de demostración:

https://github.com/singchia/frontier/assets/15531166/18b01d96-e30b-450f-9610-917d65259c30

Características

• RPC bidireccional: servicios y bordes pueden invocarse entre sí con balanceo de carga.
• Mensajería: publicación/recepción basada en temas entre servicios, bordes y MQ externo.
• Flujos punto a punto: apertura de flujos directos para proxy, transferencia de archivos y tráfico personalizado.
• Despliegue cloud-native: ejecución mediante Docker, Compose, Helm u Operator.
• Alta disponibilidad y escalado: soporte de reconexión, clustering y escalado horizontal con Frontlas.
• Autenticación y presencia: autenticación de bordes y notificaciones de conexión/desconexión.
• APIs del plano de control: APIs gRPC y REST para consultar y gestionar los nodos en línea.

Arquitectura

Componente Frontier

• Service End: el punto de entrada para funciones de microservicios, que se conecta por defecto.
• Edge End: el punto de entrada para funciones de nodos de borde o clientes.
• Publish/Receive: publicación y recepción de mensajes.
• Call/Register: invocación y registro de funciones.
• OpenStream/AcceptStream: apertura y aceptación de flujos punto a punto (conexiones).
• External MQ: Frontier admite el reenvío, según la configuración, de los mensajes publicados desde los nodos de borde hacia temas de MQ externos.

Frontier requiere que tanto los microservicios como los nodos de borde se conecten activamente a Frontier. Durante la conexión se pueden transportar los metadatos de Service y Edge (temas de recepción, RPC, nombres de servicio, etc.). Los puertos de conexión por defecto son:

• :30011: para que los microservicios se conecten y obtengan Service.
• :30012: para que los nodos de borde se conecten y obtengan Edge.
• :30010: para que el personal de operaciones o los programas utilicen el plano de control.

Funcionalidad

Función	Iniciador	Receptor	Método	Método de enrutamiento	Descripción
Messager	Service	Edge	Publish	EdgeID+Topic	Debe publicar a un EdgeID específico; el tema por defecto está vacío. El borde llama a Receive para recibir el mensaje y, tras procesarlo, debe llamar a msg.Done() o msg.Error(err) para garantizar la consistencia del mensaje.
	Edge	Service o External MQ	Publish	Topic	Debe publicar a un tema; Frontier selecciona un Service o MQ concreto según el tema.
RPCer	Service	Edge	Call	EdgeID+Method	Debe invocar a un EdgeID específico, indicando el nombre del método.
	Edge	Service	Call	Method	Debe invocar un método; Frontier selecciona un Service concreto según el nombre del método.
Multiplexer	Service	Edge	OpenStream	EdgeID	Debe abrir un flujo hacia un EdgeID específico.
	Edge	Service	OpenStream	ServiceName	Debe abrir un flujo hacia un ServiceName, especificado mediante service.OptionServiceName durante la inicialización del Service.

Principios clave de diseño:

1. Todos los mensajes, RPCs y flujos son transmisiones punto a punto.
   • De los microservicios a los bordes, debe especificarse el ID del nodo de borde.
   • De los bordes a los microservicios, Frontier enruta según Topic y Method, y finalmente selecciona un microservicio o un MQ externo mediante hashing. Por defecto, el hashing se basa en edgeid, pero puede elegirse random o srcip.
2. Los mensajes requieren un reconocimiento explícito por parte del receptor.
   • Para garantizar la semántica de entrega, el receptor debe llamar a msg.Done() o msg.Error(err) para asegurar la consistencia de entrega.
3. Los flujos abiertos por el Multiplexer representan lógicamente una comunicación directa entre microservicios y nodos de borde.
   • Una vez que el otro lado recibe el flujo, toda la funcionalidad sobre este flujo llegará directamente al otro lado, omitiendo las políticas de enrutamiento de Frontier.

Uso

Guía de uso detallada: docs/USAGE.md

Configuración

Guía de configuración detallada: docs/CONFIGURATION.md

Despliegue

Para una única instancia de Frontier, puede elegir los siguientes métodos para desplegarla según su entorno.

Docker

docker run -d --name frontier -p 30011:30011 -p 30012:30012 singchia/frontier:1.1.0

Docker-Compose

git clone https://github.com/singchia/frontier.git
cd dist/compose
docker-compose up -d frontier

Helm

Si está en un entorno Kubernetes, puede usar Helm para desplegar rápidamente una instancia.

git clone https://github.com/singchia/frontier.git
cd dist/helm
helm install frontier ./ -f values.yaml

Su microservicio debería conectarse a service/frontier-servicebound-svc:30011, y su nodo de borde puede conectarse al NodePort donde se expone :30012.

Systemd

Consulte la documentación dedicada a Systemd:

dist/systemd/README.md

Operator

Véase la sección de despliegue en clúster más abajo.

Clúster

Arquitectura Frontier + Frontlas

El componente adicional Frontlas se utiliza para construir el clúster. Frontlas también es un componente sin estado y no almacena otra información en memoria, por lo que requiere una dependencia adicional de Redis. Debe proporcionar información de conexión a Redis a Frontlas, con soporte para redis, sentinel y redis-cluster.

• Frontier: componente de comunicación entre los microservicios y el plano de datos de los bordes.
• Frontlas: siglas de Frontier Atlas, un componente de gestión del clúster que registra en Redis los metadatos y la información activa de los microservicios y los bordes.

Frontier debe conectarse proactivamente a Frontlas para reportar su estado y el de los microservicios y los bordes. Los puertos por defecto de Frontlas son:

• :40011 para la conexión de microservicios, reemplazando al puerto 30011 de una única instancia Frontier.
• :40012 para la conexión de Frontier para reportar estado.

Puede desplegar el número de instancias Frontier que necesite; en el caso de Frontlas, desplegar dos instancias por separado puede garantizar HA (alta disponibilidad), ya que no guarda estado ni presenta problemas de consistencia.

Configuración

El frontier.yaml de Frontier necesita añadir la siguiente configuración:

frontlas:
  enable: true
  dial:
    network: tcp
    addr:
      - 127.0.0.1:40012
  metrics:
    enable: false
    interval: 0
daemon:
  # ID único dentro del clúster de Frontier
  frontier_id: frontier01

Frontier debe conectarse a Frontlas para reportar su estado y el de los microservicios y bordes.

Configuración mínima del frontlas.yaml de Frontlas:

control_plane:
  listen:
    # Los microservicios se conectan a esta dirección para descubrir bordes en el clúster
    network: tcp
    addr: 0.0.0.0:40011
frontier_plane:
  # Frontier se conecta a esta dirección
  listen:
    network: tcp
    addr: 0.0.0.0:40012
  expiration:
    # Tiempo de expiración de los metadatos de microservicio en Redis
    service_meta: 30
    # Tiempo de expiración de los metadatos de borde en Redis
    edge_meta: 30
redis:
  # Soporte para conexiones standalone, sentinel y cluster
  mode: standalone
  standalone:
    network: tcp
    addr: redis:6379
    db: 0

Uso

Dado que Frontlas se utiliza para descubrir los Frontiers disponibles, los microservicios deben ajustarse de la siguiente manera:

Obtención de Service desde un microservicio

package main

import (
  "net"
  "github.com/singchia/frontier/api/dataplane/v1/service"
)

func main() {
  // Usar NewClusterService para obtener Service
  svc, err := service.NewClusterService("127.0.0.1:40011")
  // Empezar a usar service; todo lo demás permanece igual
}

Obtención de la dirección de conexión por parte de los nodos de borde

Los nodos de borde siguen conectándose a Frontier, pero pueden obtener las direcciones de los Frontier disponibles desde Frontlas. Frontlas proporciona una interfaz para listar las instancias de Frontier:

curl -X GET http://127.0.0.1:40011/cluster/v1/frontiers

Puede envolver esta interfaz para proporcionar balanceo de carga o alta disponibilidad a los nodos de borde, o añadir mTLS para entregarla directamente a los nodos de borde (no recomendado).

Para el gRPC del plano de control, véase la definición Protobuf.

El plano de control de Frontlas difiere del de Frontier en que está orientado al clúster, y actualmente solo proporciona interfaces de lectura para el clúster.

service ClusterService {
    rpc GetFrontierByEdge(GetFrontierByEdgeIDRequest) returns (GetFrontierByEdgeIDResponse);
    rpc ListFrontiers(ListFrontiersRequest) returns (ListFrontiersResponse);

    rpc ListEdges(ListEdgesRequest) returns (ListEdgesResponse);
    rpc GetEdgeByID(GetEdgeByIDRequest) returns (GetEdgeByIDResponse);
    rpc GetEdgesCount(GetEdgesCountRequest) returns (GetEdgesCountResponse);

    rpc ListServices(ListServicesRequest) returns (ListServicesResponse);
    rpc GetServiceByID(GetServiceByIDRequest) returns (GetServiceByIDResponse);
    rpc GetServicesCount(GetServicesCountRequest) returns (GetServicesCountResponse);
}

Kubernetes

Operator

Instalar CRD y Operator

Siga estos pasos para instalar y desplegar el Operator en su entorno .kubeconfig:

git clone https://github.com/singchia/frontier.git
cd dist/crd
kubectl apply -f install.yaml

Comprobar CRD:

kubectl get crd frontierclusters.frontier.singchia.io

Comprobar Operator:

kubectl get all -n frontier-system

FrontierCluster

apiVersion: frontier.singchia.io/v1alpha1
kind: FrontierCluster
metadata:
  labels:
    app.kubernetes.io/name: frontiercluster
    app.kubernetes.io/managed-by: kustomize
  name: frontiercluster
spec:
  frontier:
    # Frontier de instancia única
    replicas: 2
    # Puerto del lado de microservicio
    servicebound:
      port: 30011
    # Puerto del lado de nodo de borde
    edgebound:
      port: 30012
  frontlas:
    # Frontlas de instancia única
    replicas: 1
    # Puerto del plano de control
    controlplane:
      port: 40011
    redis:
      # Configuración de Redis del que se depende
      addrs:
        - rfs-redisfailover:26379
      password: your-password
      masterName: mymaster
      redisType: sentinel

Guarde como frontiercluster.yaml y ejecute

kubectl apply -f frontiercluster.yaml

En 1 minuto tendrá un clúster con 2 instancias de Frontier + 1 de Frontlas.

Compruebe el estado del despliegue de los recursos con:

kubectl get all -l app=frontiercluster-frontier  
kubectl get all -l app=frontiercluster-frontlas

NAME                                           READY   STATUS    RESTARTS   AGE
pod/frontiercluster-frontier-57d565c89-dn6n8   1/1     Running   0          7m22s
pod/frontiercluster-frontier-57d565c89-nmwmt   1/1     Running   0          7m22s
NAME                                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/frontiercluster-edgebound-svc      NodePort    10.233.23.174   <none>        30012:30012/TCP  8m7s
service/frontiercluster-servicebound-svc   ClusterIP   10.233.29.156   <none>        30011/TCP        8m7s
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/frontiercluster-frontier   2/2     2            2           7m22s
NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/frontiercluster-frontier-57d565c89   2         2         2       7m22s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/frontiercluster-frontlas-85c4fb6d9b-5clkh   1/1     Running   0          8m11s
NAME                                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)               AGE
service/frontiercluster-frontlas-svc   ClusterIP   10.233.0.23   <none>        40011/TCP,40012/TCP   8m11s
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/frontiercluster-frontlas   1/1     1            1           8m11s
NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/frontiercluster-frontlas-85c4fb6d9b   1         1         1       8m11s

Su microservicio debería conectarse a service/frontiercluster-frontlas-svc:40011, y su nodo de borde puede conectarse al NodePort donde se expone :30012.

Desarrollo

Roadmap

Véase ROADMAP.

Contribuciones

Si encuentra algún error, abra una issue y los mantenedores responderán con prontitud.

Si desea enviar funcionalidades o resolver problemas del proyecto con mayor rapidez, los PR son bienvenidos bajo estas sencillas condiciones:

• Mantener un estilo de código coherente
• Cada envío incluye una única funcionalidad
• El código enviado incluye pruebas unitarias

Pruebas

Funcionalidad Stream

Comunidad

Únase a nuestro grupo de WeChat para debates y soporte.

Licencia

Publicado bajo la Apache License 2.0.

---

¡Una estrella ⭐️ sería muy apreciada ♥️!