Ainsi, l’API de gRPC me semble-t-il comme si le moyen envisagé d’avoir plusieurs services dans une application consistait à construire sur l’instance io.grpc.Server et à y ajouter autant de services que nécessaire.
Existe-t-il des raisons (en termes de robustesse / performance / disponibilité / résilience aux erreurs ...) connues pour lesquelles on voudrait plutôt utiliser plusieurs instances de io.grpc.Server pour héberger les différents services?
Je serais particulièrement intéressé par les points de repère, mais les liens vers de la documentation et / ou des discussions sur le sujet sont également appréciés.
Réponses:
1 pour la réponse № 1En règle générale, tous les services font partie d’un seul serveur io.grpc.Server.
Plusieurs io.grpc.Servers est probablement le plus utile pour séparer les services en fonction des accès / autorisations. Par exemple, si vous souhaitez un port ouvert supplémentaire "spécial", comme autoriser un accès administrateur avec des règles de pare-feu supplémentaires ou uniquement localhost. Ou si vous voulez plusieurs sockets de domaine Unix, chacun avec son propre accès utilisateur / groupe.
Mais il peut également être simplement utilisé si vous souhaitez écouter plusieurs fois. Par exemple, si cela est également utile si vous souhaitez écouter sur un port IP normal, mais également sur un socket de domaine Unix.
1 pour la réponse № 2
Du point de vue du client, se connecter à plusieursserveurs signifie créer plusieurs canaux, et les canaux sont des ressources coûteuses. Si les services associés peuvent être tous sur un serveur, il suffit au client de créer un canal pour appeler tous les services.