Bavardage

Quand les applications monolithiques sont divisées en petits microservices, les frais de communication augmentent, car les microservices doivent communiquer entre eux. Dans bien des implémentations, le service REST sur HTTP est utilisé, car il s'agit d'un protocole de communication léger. Cependant, il peut être confronté à des problèmes face à de grands volumes de messages. Dans certains cas, vous pourriez envisager d'utiliser des services de consolidation qui échangent beaucoup de messages. Si vous vous retrouvez dans une situation où vous consolidez de plus en plus de services dans le seul but de limiter les communications, vous devez vérifier les domaines qui posent problème et votre modèle de domaine.

Protocoles

Différents protocoles possibles sont présentés plus haut dans ce livre blanc, dans la section Communication asynchrone et messagerie légère. Pour les microservices, il est fréquent d'utiliser des protocoles simples tels que HTTP. Les messages échangés par les services peuvent être encodés de différentes façons, par exemple, dans un format compréhensible par les utilisateurs tels que JSON ou YAML, ou dans un format binaire efficace comme Avro ou Protocol Buffers.

Mise en cache

Les caches sont un excellent moyen de réduire la latence et le volume de communication des architectures de microservices. Plusieurs couches de mise en cache sont possibles en fonction du cas d'utilisation réel et des goulots d'étranglement. De nombreuses applications à microservices s'exécutant sur AWS utilisent ElastiCache pour réduire le volume des appels vers d'autres microservices en mettant en cache les résultats localement. API Gateway fournit une couche de mise en cache intégrée afin de réduire la charge sur les serveurs backend. De plus, la mise en cache est utile pour réduire la charge de la couche de persistance des données. Le défi, pour tout mécanisme de mise en cache, consiste à trouver le juste équilibre entre un bon taux d'accès au cache, et la rapidité et la cohérence des données.