I was learning micro service concepts in spring cloud and its service discovery mechanism. What I understand is all service providers register themselves in service discovery. Consumers get endpoint details for required service from discovery server and then connect to the endpoint. It's all works fine when consumer is a component built on spring cloud.
When we need to consume a service from Mobile client like react native, what should be the approach? Are we supposed to use a static endpoint which receives all requests from mobile and invoke actual endpoint using inputs from service discovery server?
Related
I'm building an application using spring boot. I'm planning to add a chat feature to it via websocket. Considering that I'm hosting it on AWS, how can I integrate the websocket properly via api gateway websocket? Do I do my spring controller mapping for websocket via api gateway websocket endpoint?
AWS API Gateway provides you with an option of HTTP integration, so you can keep your application in an ECS container and expose an endpoint that can be ingested by the API gateway side.
We have integrated API Management with Service Fabric in Azure as outlined in this document. Everything is up and running, but we would like to ensure that the traffic between API Management and Service Fabric Stateless Service (ASP.NET Core) is encrypted using HTTPS. Currently the API Management logs show that the traffic is HTTP.
Is there a way to enable HTTPS (or at least encrypted) traffic between API Management and Service Fabric?
APIM gets those http endpoint from SF itself by calling IServiceResolutionClient.ResolveServicePartitionAsync. Are you sure your stateless service is configured with HTTPS scheme at Service Fabric end?
The setup:
I have a set of Spring Boot based microservices that are fronted by Spring Cloud Gateway, meaning every request that comes from UI or external API client first comes to Spring Cloud Gateway and is then forwarded to appropriate microservice.
The routes are configured in Consul, and Spring Cloud Gateway communicates with Consul to get the routes accordingly.
Requirement:
There is a need of some microservices communicating with each other with REST APIs. I would prefer this communication to happen via the Spring Cloud Gateway as well. This will help in reducing multiple services going to Consul for getting other service's details.
This means every service should know Gateway's detail at least. And there can be multiple instances of Gateways as well. How is this dealt with in bigger architectures?
Any example that I look up contains one service using Consul, or Gateway using the consul with one microservice. Couldn't understand how to extrapolate that design to a bigger system.
We took a micro service solution base on spring cloud and spring boot.Now we have a Netty project as a IoT protocol service, how can this netty service keep running (beacuse it need to maintain the connect) and discover all api of a new service which registered to eureka.
I'm attempting to establish a discovery server with spring cloud Eureka which needs to connect to a secured client. I understand how to secure the Eureka sever itself - that isn't the issue. The issue is in the other direction - how to get Eureka to successfully communicate with a client service that itself is secured.
In other words; I have a discovery client that registers itself with Eureka. That client implements http basic authentication. It can and does successfully register itself with the discovery service, however when I attempt to utilize that service with a lookup to the discovery service, I get authentication failures (on the client service itself) which of course makes sense because I haven't specified any credentials anywhere and have no idea how to do so. Any assistance would be greatly appreciated.
Guessing from your tags you are using spring-cloud.
When you use your service (with RestTemplate or Feign or manually looking up and interacting with it), your request has nothing to do with Eureka. Eureka only provides you information about your services whereabouts. Once you (or some undelying logic) obtained the address of the service, you are directly communicating with it.