If the web service A is down, how can you make the osb business service point to web service B.
This is like a back up web service.
So, try invoking web service A, but if it is unavailable invoke web service B.
OSB supports multiple endpoint URLS with load balancing algorithm, and you can provide retry count there so in case if the service is not available on one endpoint then it will be tried to second endpoint.
You will need to handle it with Stage (or Route) Error Handler in the Proxy Service
If it is truly the same Business Service (same WSDL), then look at the Load Balancing Algorithm and the Endpoint URI list on the Business Service properties.
Related
I have an EDG service which is a gateway in front of some services,
those services were reached by feign client so all requests come to edge and it's controllers will forward the request to back end service using fegin client.
I thought that's bad so I wanted to change this by fully using Zuul integration, that will automatically do the routing to the backend services , load balancing ...etc
The problem is: handing zuul filters to do centralized logging is not so cool vs fegin client which is just a call and I can make global Exception handler to handle exceptions ...etc
so what is the correct way of implementing the Edge layer?
I am currenly learning microservices. I have two services Service A and Service B. Service A registered with Eureka server. Service B is calling Service B via Eureka server to get the response. My question is
why Service B has to register with Eureka service in order to call Service A?
Service B can get the Service A url and portno through service discovery from Eureka server. What is the significance of Service B to register with Eureka server?
Typically in Microservices architecture, we have a lot of small applications running independently together, and ofcourse they will all have their own URLs and ports.
In that scenario, it would be very cumbersome to maintain all these microservices to run in synchronization, and more importantly, with monitoring. This problem will increase manifold when we start implementing load balancers.
To solve this issue, we need a tool that will monitor and maintain the registry of all the microservices in the ecosystem.
That's why Eureka server acts as directory and service discovery system to make sure they is no direct binding between services and it make sure to have health check for those services.
Can Eureka be used by outside world to discover my service? Below is the flow:
Public client( developed in any technology and not using Eureka) --> Eureka server (hosted on my organization server, exposed to outside world) --> My Eureka aware services.
I am trying to understand how Netfilx Eureka works from overall architecture point of view.
Basically Load Balancer and discovery service are two completely different things.
Discovery service = a registry of currently available services
Load Balancer = a routing of requests based on various rules
So, Eureka, as a discovery service, cannot be used a Load Balancer by itself.
However Eureka, being an application by itself, exposes an HTTP REST API
So if you want to build a load balancer by yourself based on the information provided by eureka, you can call rest APIs like this.
For example, Ribbon, being a client side load balancer, calls these APIs internally.
Having said that, its not unclear why to use the tool for the purpose for which is not intended to be...
So I have a very small micro service architecture built using Eureka service discovery. The problem I am facing right now is that I only want my service endpoints to accept request from my api gateway, as it is right now you can just make a request straight to the service and hit that service endpoint. Is this a problem Kubernetes would solve? Or Is there a more practical way of doing this?
You should be using network policies to control the traffic between the services.
In kubernetes the services you want to expose internally use service type ClusterIP. This is default anyway which means services are accessible within cluster only. your api gateway is exposed as load balancer service type which then takes traffic from external world and talks to services internally. Depending on your cloud provider you can use firewall in front of load balancer since you can compromise security by simply exposing load balancer. e.g. azure kubernetes you could use application gateway. You can also replace the api gateway with ingress controller. it's very powerful reverse proxy controller which you can expose directly to traffic and that would talk to your services internally.
You really need to understand concepts so i would recommend following links
https://kubernetes.io/docs/concepts/services-networking/service/
https://blog.getambassador.io/kubernetes-ingress-nodeport-load-balancers-and-ingress-controllers-6e29f1c44f2d
i have created two java spring-boot micro services they are
1) producer
2) consumer
and i have used spring eureka server for service registration and discovery . it worked fine . then what is the use of Netflix Zuul.
Let's suppose you have 20 services to which user can interact to, and of course we are not going to expose each and every services publicly because that will be madness (because all services will have different ports and context), so the best approach will be to use an API gateway which will act as single entry point access to our application (developed in micro service pattern) and that is where Zuul comes into picture. Zuul act as a reverse proxy to all your micro-services running behind it and is capable of following
Authentication
Dynamic Routing
Service Migration
Load Shedding
Security
Static Response handling
Active/Active traffic management
You can go through documentation here
If you have enough experience in the domain, you could look at zuul as an API gateway like Apigee. It is very feature rich and touches up on a lot of different concerns like routing, monitoring and most importantly, security. And eureka as a service discovery platform that allows you to load balance (in Linux terms the nginx or haproxy) and fail over between your service instances.
Typically the backend services that perform the server side business operations (i.e. core) are not exposed publicly due to many reasons. They are shielded by some Gateway layer that also serves as reverse-proxy. Netflix Zuul serves as this gateway layer which easily gives you the capabilities as mentioned by #Apollo and here