I have following architecture
API gateway(REST Public API) --> MBus --> Micro services(Windows Services).
I have implemented the URL based versioning in API Gateway that helps me backward compatibility. Based on the API request API Gateway translate the request to the message bus and send over topic for particular service listening. Now in my micro services that are over the message bus how I manage the Versioning of API for backward compatibility should I send the API version over the message bus from API gateway so that particular service know the version and execute the specific version of the request. What is the standard and ways to manage the API versioning across micro services when micro services are over message bus and not REST based.
Regards,
IK
If you are changing the contract you should use another topic.
Basically you should manage contract on topics.
And you should support both topics until there is no user for the old one.
Related
I'm quite a newbie to microservices architecture. I'm referring to one of my clients projects with microservice architecture. It has one of the service as Notification
Order ->(talks to)-> Notification client(as a lib) -> calls api from - > Notification service.
I don't really understand the purpose of having a client in between, where in it has a few exceptions handled for hitting the api. I understand, microservices communicate via api gateway but I feel Notification Client is just an addon. I tried to figure out the terminology used for this kind of implementation but in vain.
Please help me understand this use case.
It may feel that the client is redundant if Order service is the only microservice that is consuming the APIs. But considering the notification service is getting used by a few more microservices having a notification client as a lib makes sense. The reason is,
The client lib will wrap all the API calls and their implementation
so that other services can simply call it just like a method.
Other services don't have to write REST client for notification service when it wants to
make use of the APIs.
Same client lib can be shared by other microservices without actually
writing code to call the APIs.
Any changes/fixes made to the notification service can be cascaded to other services by simply changing the version of the client lib.
I think I understand what API Mgt is and Orchestration. E.g. SAP PO and SAP CPI allow Orchestration.
I was reading the following statement:
Modern applications and changes in protocols and message designs also
started to influence the ESB. A more lightweight integration components
started to emerge, known as the API Gateway. An API Gateway doesn't
have the overhead of adapters or the complex integration functionality
of the ESB but still allows encapsulation and provides the
management capabilities to control, secure manage and report on API
usage.
Reading this is all a little vague imho. The following:
Does an API Gateway not allow for Orchestration? I think it does, as AXWAY state this in https://www.axway.com/en/products/api-management/gateway. I guess my point is what does the phrase from above "An API Gateway doesn't
have the overhead of adapters or the complex integration functionality
of the ESB ...". That said, may be such products are doing this for microServices and for the REST APIs we need to use separate products?
E.g. having read https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do it is unclear to me if orchestration of REST API's is possible with an API Gateway or if this is only for MicroServices possible?
SAP CPI is clearly Orchestration, but is it part of API Mgt or API Gateway? I think the latter.
When I look at Amazon API Gateway it states nothing about Orchestration.
I am writing a microservice app by spring boot and spring cloud. I have five modules which are
API-Gateway (base on spring cloud gateway spect)
Discovery-Server (base on spring cloud Netflix Eureka service discovery)
Microservice-A (It is a spring boot app that includes our business)
Microservice-B (It is a spring boot app that includes our business)
Microservice-C (It is a spring boot app that includes our business)
All requests which come from users route to API gateway and through API gateway send to app A or B or C (these are not exposed out). Now I have a question, base on one business role, app A will need to call one rest endpoint of app B. Which approach is the best? I call app B endpoint from app A directly or I call by API-Gateway?
The API Gateway should serve as an ingress layer, it only accepts traffic which is coming from outside of your application (clients / external integrations). More details here.
Any internal communication between your microservices, should be a point-to-point interaction, that can be done in multiple ways. This answer describes that in more details.
So the API Gateway should not be concerned with orchestration of the microservices.
If I were you I'll use a message broker for microservices communication. Let the api gateway for external clients. I think we overuse the http protocol. With a microservice architecture we should try to think differently.
I have a few synchronous microservices working on production using Spring Boot 2.X version. Soon, we need to implement a gateway if the number of instances of each microservice is going to be increased. I read that Zuul was in a maintenance phase and was replaced by Spring Cloud Gateway which is by default asynchronous technology. My question is, can I still implement Spring Cloud Gateway with my microservices?
Yes, you can use Spring Cloud Gateway without any doubts.
Basically, asynchronous technology means that your resources/threads on Api Gateway won't be blocked waiting for the response from downstream services and that increases a throughput.
Now, once your blocking services complete their internal logic they respond back to Api Gateway using an originally opened connection. Api Gateway in turn responds back to your client.
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