Small question regarding how to convert http requests into RSocket please.
The server setup is a very straightforward RSocket server.
The server is dockerized and deployed in Kubernetes.
Now there are many clients, I do not have control over them. The clients would like to talk to this RSocket server. The JSON payload the clients sends are all compatible with the RSocket server. However, all clients are just using http clients, not RSocket.
May I ask what is the easiest solution to convert the https requests send from the clients please?
What I tried: Built a layer in between, using Spring Cloud Gateway to take as input a http request, and forward it using a RSocket client.
The drawback of this solution is that there is now another app in the picture. Instead of maintaining one business RSocket application, there is a need to implement and maintain another web server entirely.
May I ask if there is some kind of sidecar pattern using maybe ngnix, istio, Kubernetes services, that can perform the same, without having to full blown develop another web app please?
May I ask what is the easiest solution to convert the https requests send from the clients please?
Thank you
May I ask if there is some kind of sidecar pattern using maybe ngnix, istio, Kubernetes services, that can perform the same, without having to full blown develop another web app please?
No, The concept maybe called broker gateway but not sidecar pattern. You should implements a broker gateway to conevert the protocol, such as HTTP(Rest), GraphQL, gRPC. You can refer a sample project alibaba-rsocket-broker.
Related
I want to consume the spring boot rest services deployed behind a firewall. Need a solution for the above scenario. Thank you.
To access a Rest API behind a firewall you need to open the default HTTP ports in that firewall(80 for HTTP and 443).
That has nothing to do with the technology that you are using to implement the Rest API.
Please provide more details about your question if this is not enough answer for you...
I'm beginer to micro-services, so please help me out on this issue,
I'm working on simple micro service project with spring boot, zuul, hystrix and eureka. One of service calls data from another service. But when the service is down, response is 500, so it needs to be send request again to get the expected result.
But end user shouldn't it see. So is there a way to send a http request for the failed service again with zuul if the previous request is failed/short circuited.
Thanks in advance.
First for an unavailable service http code 503 is probably more suitable.
Then Zuul is an api gateway not a service mesh. I think you mix up both concepts here.
The goal of an api gateway is to accept traffic from outside your network and distributes it internally...and so abstract his complexity(it is actually a distributed facade/router).
Example: zuul, spring cloud gateway
A Service mesh acts as a proxy between microservices and bring on communications aspects like automatic retries, circuit breaker, tracing, logging.
Example Istio, Linkerd
But you can go without service mesh to implement this concern. Your caller microservice can protect itself by implementing timeout, retries and circuit breakers by embed a powerful library like resilience4j.(hystrix is actually at the end of his life)
This library will provide you an api allowing you to wrap communications with outside (other microservices) through a special proxy that will handle retries or/and circuit breakers for you.
You should have a look : https://github.com/resilience4j/resilience4
I recently have learnt and practicing Microservice using Spring technology. I am currently writing a small program that has Eureka Server, Configuration Server, Gateway and Account service. I have all of my services register its instance to Eureka and have my Gateway gets its configuration from Configuration Server. After that, I got some question, should I my Account Service fetch its configuration directly from Configuration Server, or from Gateway because it can be done in both way. I think, if I decide to fetch it through Gateway, it might be better because Gateway is a load balancer, so in case if there are multiple Configuration Servers out there, I don't need to worry if any of them failed or down as Gateway can handle this for me. But, doing so, isn't I put too much weight on Gateway because it need to handle this and another requests. Furthermore, I am not sure and I can't find any information about if there is a way to load balancing Gateway or is it makes sense to do so?
Please advice and explain. Thank you.
Only user's requests from UI need to be passed via Gateway. Services should be able to fetch their configuration during startup disregarding whether gateway is online or doesn't exist at all.
Also I'd advise you to avoid registering config service in Discovery (Eureka). I suppose there is no need for your users to send requests to config service.
Along with spring cloud config and gateway documentation I'd recommend you to get familiar with these 2 books:
https://www.manning.com/books/enterprise-java-microservices
https://www.manning.com/books/spring-microservices-in-action
I have a restful application made in Go, now I have to make this app also serve as gRPC server (I already created the needed files). I have the restful endpoints running in the port 8000, now I have the next questions:
Can I server grpc as well as the restful app in the same instance?
Should I assign a different port to serve gRPC?
What is the recomended approach in this case? as the grpc stub will be only
consumed by some of our microservices, but the restful will be
consumed by the frontend of some apps
In the case that I can serve boths, how should I initialize the servers?
Yes! If you want to serve gRPC as a RESTful service, there is a gRPC Gateway project that allows you to annotate your Protos, so they can be served over REST.
Yes, but this gets a little trickier. The gRPC server in Go implements net/http.Handler, so you can add it to your existing HTTP server. Getting the URL paths to match is something you'll need to play around with, but it is certainly possible.
I don't think there is any recommended approach. It depends mainly on environment constraints (such as if there are proxies, how you encrypt your connections, etc.).
Initialize the gRPC Server first, and then add it to the HTTP server.
There is no doubt that API gateway should be the edge server to outside world.We are wondering that should we use API gateway in the communications between the microservices?
You can definitely use API gateway lets say for that matter (netflix -zuul) for inter-service calls, only thing of concern for you would be,
what happens when you start versioning your services, assuming you'll be using eureka as a naming server from which zuul gateway will fetch all registered services, but now in your case zuul will get two instances of your service (version previous and verison next) and ribbon will load balance the requests between the two, this point is already thoughtfully covered in
How to route in between microservices using Spring Cloud & Netflix OSS
Basically if you are familiar with BlueGreen Deployment model, implementing that would be a problem, surely there are proper workarounds for that as in defining/registering some metadata along with your previous and latest versions which would later be picked by ribbon client to route accordingly