I have trouble understanding the connection between Zuul and Ribbon.
I think I got Zuul clear. It's a reverse proxy I can contact to reach one of my several instances of a service. It will pick the right server using a round-robin algorithm or whatever you configure it to do. It's a traditional load-balancer. To know the instances available it can use a registry like Eureka.
But I've got more trouble with Ribbon. It's sold as a client-side load balancer but what does it mean ? It doesn't need an external server ? Ribbon is embedded in the client the same way an Eureka client is ? If so how does it work ? Do I need Zuul when I use Ribbon, and vice-versa ?
On some articles, I saw that in fact, Zuul uses Ribbon by default for the load balancing part and it got me even more confused. If this is true what does "client-side" mean ? What does Zuul do except routing ?
I hope you can help me.
Client and Server is always relative. Zuul is a client for your service instances and your service instances are servers for Zuul.
When we are using traditional load balancer (server-side load balancer), API caller (client) only knows a single endpoint that is a load balancer and the client doesn't know the list of servers. Load balancer chooses a server from the list.
When we are using client-side load balancer like Ribbon, API caller (client) should know the list of servers and choose one of them from the list. That's why we call it client-side load balancer.
As you know, Ribbon is a client-side load balancer module and is integrated to many http client modules. As an example, Feign and Load-balanced RestTemplate support Ribbon. Namely Feign and Load-balanced RestTemplate can choose a server from the given list or the list from eureka when used with ribbon.
Regarding Zuul, there is a RibbonRoutingFilter that routes your request to an actual service instance. RibbonRoutingFilter is using Ribbon to choose a server from the list that is given from your configuration or from Eureka. So if you want to use Zuul as a load-balanced reverse proxy, Zuul needs Ribbon.
Related
I am having issue using the Serverless NEG and URL Masks with Custom domains. Here is some background:
I have multiple services deployed as CloudRun services (login service, search service, feedback service). I am trying to setup a custom domain mapping and use URL Masking so the requests are routed to appropriate services.
I followed the steps outlined here - https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless
I have created a Load Balancer, Backend Service and a Serverless NEG with a Serverless Network Endpoint Group type as "Cloud Run" and selected "use URL mask" checkbox and provided my custom domain URL like this mycompany.com/ where mycompany.com is the custom domain I have.
NOTE: I am planning to use just one Serverless NEG and leverage URL mask so it can route the requests to appropriate CloudRun service in the backend.
I have updated mycompany.com to use the Public IP address created by the LB from the above steps.
Now, When I type mycompany.com/login or mycompany.com/search, it is not directing me to the appropriate CloudRun services and instead get an error - "This site can’t be reached"
My question: Do I need to setup Custom Domains and add mappings on the CloudRun page specifying mycompany.com and select one of the CloudRun service for me to leverage URL masks ?
I am slightly confused here and the documentation is not helping me here.
Please help.
Regards,
Raj
My backend is a simple dockerized Node.js express app deployed onto elastic beanstalk. It is exposed on port 80. It would be located somewhere like
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
I can call my APIs on the backend
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/hello
mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com/postSomeDataToMe
and they work! Yay.
The URL is not very user friendly so I was hoping to set up API gateway to allow to me simply forward API requests from
api.myapp.com/apiFamily/ to mybackend.eba-p4e52d.us-east-1.elasticbeanstalk.com
so I can call api.myapp.com/apiFamily/hello or api.myapp.com/apiFamily/postMeSomeData
Unfortunately, I can't figure out (i) if I can do this (ii) how to actually do it.
Can anybody point me to a resource that explains clearly how to do this?
Thanks
Yes, you can do this. For this to happen you need two things:
a custom domain that you own and control, e.g. myapp.com.
a valid, public SSL certificate issued for that domain.
If you don't have them, and want to stay within AWS ecosystem, you can use Route53 to buy and manage your custom domain. For SSL you can use AWS ACM which will provide you with free SSL certificate for the domain.
AWS instructions on how to set it up all is:
Setting up custom domain names for REST APIs
IBM has MQIPT (IBM MQ Internet Pass-Thru) that acts as MQ forwarder/reverse proxy to implement messaging solutions between remote sites across the internet. Is there such an equivalence for Solace?
Solace has all kinds of fancy advanced features for load balancing and hybrid/multi-site deployments like bridges and dynamic message routing, but I don't really know those, and where's the fun in having everything ready-made and pre-solved for you anyway? :-)
So here I am going to assume you want to roll your own solution and use an actual reverse proxy:
You can switch to HTTP-based protocols, and just use any regular HTTP reverse proxy. Solace message brokers have a REST message interface, or if your application already uses the Solace API for messaging (or needs its advanced features), you can switch over to HTTP streaming or WebSockets as a transport by modifying the scheme portion of the broker URL in your application configuration. (http:// or ws:// instead of tcp://) This will only allow you to balance sessions, not individual messages within a single elephant flow.
Preface
I am currently trying to learn how micro-services work and how to implement container replication and API gateways. I've hit a block though.
My Application
I have three main services for my application.
API Gateway
Crawler Manager
User
I will be focusing on the API Gateway and Crawler Manager services for this question.
API Gateway
This is a docker container running a Go server. The communication is all done with GraphQL.
I am using an API Gateway because I expect to have different services in my application each having their own specialized API. This is to unify everything.
All it does is proxy requests to their appropriate service and return a response back to the client.
Crawler Manager
This is another docker container running a Go server. The communication is done with GraphQL.
More or less, this behaves similar to another API gateway. Let me explain.
This service expects the client to send a request like this:
{
# In production 'url' will be encoded in base64
example(url: "https://apple.example/") {
test
}
}
The url can only link to one of these three sites:
https://apple.example/
https://peach.example/
https://mango.example/
Any other site is strictly prohibited.
Once the Crawler Manager service receives a request and the link is one of those three it decides which other service to have the request fulfilled. So in that way, it behaves much like another API gateway, but specialized.
Each URL domain gets its own dedicated service for processing it. Why? Because each site varies quite a bit in markup and each site needs to be crawled for information. Because their markup is varied, I'd like a service for each of them so in case a site is updated the whole Crawler Manager service doesn't go down.
As far as the querying goes, each site will return a response formatted identical to other sites.
Visual Outline
Problem
Now that we have a bit of an idea of how my application works I want to discuss my actual issues here.
Is having a sort of secondary API gateway standard and good practice? Is there a better way?
How can I replicate this system and have multiple Crawler Manager service family instances?
I'm really confused on how I'd actually create this setup. I looked at clusters in Docker Swarm / Kubernetes, but with the way I have it setup it seems like I'd need to make clusters of clusters. That makes me question my design overall. Maybe I need to not think about keeping them so structured?
At a very generic level, if service A calls service B that has multiple replicas B1, B2, B3, ... then it needs to know how to call them. The two basic options are to have some sort of service registry that can return all of the replicas, and then pick one, or to put a load balancer in front of the second service and just directly reach that. Usually setting up the load balancer is a little bit easier: the service call can be a plain HTTP (GraphQL) call, and in a development environment you can just omit the load balancer and directly have one service call the other.
/-> service-1-a
Crawler Manager --> Service 1 LB --> service-1-b
\-> service-1-c
If you're willing to commit to Kubernetes, it essentially has built-in support for this pattern. A Deployment is some number of replicas of identical pods (containers), so it would manage the service-1-a, -b, -c in my diagram. A Service provides the load balancer (its default ClusterIP type provides a load balancer accessible only within the cluster) and also a DNS name. You'd configure your crawler-manager pods with perhaps an environment variable SERVICE_1_URL=http://service-1.default.svc.cluster.local/graphql to connect everything together.
(In your original diagram, each "box" that has multiple replicas of some service would be a Deployment, and the point at the top of the box where inbound connections are received would be a Service.)
In plain Docker you'd have to do a bit more work to replicate this, including manually launching the replicas and load balancers.
Architecturally what you've shown seems fine. The big "if" to me is that you've designed it so that each site you're crawling potentially gets multiple independent crawling containers and a different code base. If that's really justified in your scenario, then splitting up the services this way makes sense, and having a "second routing service" isn't really a problem.
I want to build my web services serving JSON data utilizing RESTful architecture.
But I want my own client apps only that can request from my web services.
Basically, my web services contain sensitive data that is not for public consumption, but I wanted to build it that way so I can build many different client apps that connects to my web service.
Would appreciate any ideas for this, thanks.
The fact that it's RESTful or uses JSON isn't a relevant factor when it comes to securing a web service. Any web service would need to be secured in the same manner. There are a few things you should do:
If possible, don't host your web service on the Internet. If the web service is hosted within your company's LAN, for example, it won't be exposed to public consumption unless you specifically exposed it through your router.
Set up authentication and authorization rules. If you're hosting your web service inside of a Windows domain, you could simply use Windows authentication and set up rules based on Active Directory users and groups. Other options are to use HTTP authentication, client certificate authentication, or if you're developing in .NET, forms authentication.
Use encryption (HTTPS), especially if your web site is hosted on the Internet.
You just need a couple things in place to do this. First, the service client will need to authenticate against your service (over HTTPS) to make a request. Once the client is authenticated, you can return a private token which the client has to include with this token. As long as the token expires after a reasonable amount of time, and a secure algorithm is used to generate it, this should do what you want.
If you have more strict security requirements, you can follow Jakob's suggestion, or have the client start a VPN session prior to making requests.