Je construis une application énorme à l'aide de l'architecture de Microservices. L'application consistera en plusieurs microservices de backend (déployés sur plusieurs instances de cloud), dont je souhaite connecter à l'aide d'API de repos afin de transmettre des données entre elles.
L'application exposera également l'API publique à des tiers, mais les points d'extrémité susmentionnés ne devraient être limités qu'à d'autres microservices dans la même application créant une sorte de réseau privé.
Alors, ma question est la suivante:
Comment réaliser cet accès à l'API restreint à d'autres microservices dans la même application?
S'il y a de meilleurs moyens de connecter des microservices que d'utiliser la couche de transport HTTP, veuillez les mentionner.
Veuillez garder les réponses serveur / langue agnostique si possible.
merci.
6 Réponses :
Ouais facile. Chaque client d'un micro-service a une clé API. Micro Services n'accepte que des demandes de clients avec une clé API valide.
Aussi, c'est bon de savoir que le repos est simplement un protocole qui permet la communication entre les contextes bornés. P>
Il n'est pas nécessaire d'être sur http. L'exigence est qu'il a une interface uniforme (c'est pourquoi HTTP est utilisé avec ses méthodes de mise, de publication, d'obtention, de ... et qu'il est apatride (tout l'état étant transféré à travers une URI). P> Donc, si tous vos micro-services fonctionnent sur la même boîte, tout ce que vous avez à faire est quelque chose comme ceci: p>
class SomeClass implements RestfulMethods {
public function get(params){ // return something}
public function post(params){ // add something}
public function put(params){ // update something}
public function delete(params){ // delete something}
}
Le moyen le plus simple est de permettre l'accès de l'adresse IP que vos microservices fonctionnent.
Un moyen est d'utiliser HTTPS pour la communication interne MS. Verrouillez l'accès (en utilisant un magasin de fiducie) pour uniquement vos services. Vous pouvez partager un certificat parmi les services pour la communication de Backend. De préférence un certificat de carte générique. Il devrait ensuite fonctionner aussi longtemps que vos services peuvent être adressés au même domaine. Comme * .YourCompany.com.
Une fois que vous avez tout mis en place, cela devrait fonctionner bien. Les sessions HTTPS impliquent quelques frais généraux, mais c'est principalement dans le processus de la poignée de main. En utilisant Keep-Vive sur vos sessions, il ne devrait pas y avoir beaucoup de frais généraux avec des canaux cryptés.
Bien sûr, vous pouvez simplement ajouter des informations d'identification à vos en-têtes HTTP. Ce serait moins sûr.
restasibilité est non seulement un moyen de le faire, l'une des idées que j'ai semblables concerne l'utilisation de registre de service link eureka (Netflix), Zookeper ( Apache) et d'autres.
Voici un exemple:
... Les points finaux mentionnés ci-dessus ne doivent être limités qu'à d'autres Microservices dans la même application ... P>
Qu'est-ce dont vous parlez dans un sens large est l'autorisation. P>
L'autorisation est l'octroi ou la nie de "pouvoirs" ou "capacités" dans votre application aux utilisateurs authentiques. P>
Par conséquent, le travail de tout mécanisme d'autorisation est de valider la "réclamation" implicite Dans toute demande d'API entrante - que l'utilisateur est autorisé à faire la chose codée dans la demande. p>
Par exemple, imaginez que je suis arrivé à votre API avec une demande de widget 1234: p>
PUT /widgetservice/widget/5678 HTTP/1.1
L'autorisation basée sur les informations d'identification des utilisateurs n'est pas la meilleure façon d'y aller car elle peut arriver qu'un microservice veuille quelque chose d'un autre microservice qui n'est pas initié par un véritable utilisateur. Il peut s'agir d'une opération programmée par exemple. L'utilisation d'un utilisateur de service peut être une bonne approche, cependant, il n'est pas toujours simple de générer un tel type d'utilisateurs. Google utilise les touches API.
@pcjuzer merci pour votre commentaire. Lorsque je dis l'utilisateur, je voulais dire un compte utilisateur ou service. Je ne suis pas aussi familier avec la méthode des touches de l'API - vous pouvez peut-être vous éclairer et je vais mettre à jour ma réponse.
Je sais que je suis super tard pour cette question :)) Mais pour toute personne rencontrée sur ce fil, Kafka < / a> est une excellente option pour les opérations similaires à cette question.
Basé sur la propre introduction de Kafka
Kafka est généralement utilisé pour deux larges classes d'applications:
Note latérale: Kafka est créée par LinkedIn et est utilisée dans de nombreuses grandes entreprises, ce qui a donc été testé en matière de lutte.
Comment définissez-vous "la même application"?
Je voulais dire tout le système de microservices connectés par "la même application"