Is there any way to achieve the service throttling ability to the rest services in Spring, particular with Spring boot.
The Expectation here is: My services are exposed to outside world, currently there are no restrictions on the number of service calls per second/min. We want to control this by putting the throttling limit.
I have an alternative option, by tracking the requests in concurrent Hash Map or any caching mechanism.
But more interested in the way spring in considering this. I know that i can be able to do it in node.js / scala
There is a fairly new opensource project which handles this:
https://github.com/shlomokoren/spring-boot-throttling
Declarative approach of throttling control over the Spring services.
#Throttling annotation helps you to limit the number of service method
calls per java.util.concurrent.TimeUnit for a particular user, IP
address, HTTP header/cookie value, or using Spring Expression Language
(SpEL).
Related
Since Spring Cloud team has abandoned development of Zuul module, we are moving to Spring Cloud Gateway or Zuul2 but I believe Zuul2 needs a lot of changes in the architecture and needs big changes in the microservices(correct me if i'm wrong), can anyone gives a recommendation on zuul2 or Spring-Cloud-Gateway, has anyone or you know any big player in tech using Spring-Cloud-Gateway?
Zuul1 is blocking whereas Zuul2 and spring cloud gateway are non-blocking and this is a major performance factor for a gateway, as a non-blocking model requires less resources to serve the same amount of requests as compared to a blocking gateway.
Now, coming to spring cloud gateway and Zuul2 - Spring Cloud does not provide any out of the box integration with Zuul2. Gateway has many features that are not available in the public version of Zuul2 such as Rate limiting, etc. Also, with the gateway you can have custom filters defined per route and there are tons of built-in filters defined as well, which helps a lot to get started.
Actually, there are many things which are not possible to explain here. You can follow the gateway documentation here - https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.0.2.RELEASE/single/spring-cloud-gateway.html
I think SCG is the way to go due to the agreements between Netflix and Pivotal, with the former leaning more toward the spring boot/cloud ecosystem as stated in https://medium.com/netflix-techblog/netflix-oss-and-spring-boot-coming-full-circle-4855947713a0
Performance-wise it also seems like a good bet: https://www.bytesville.com/zuul-spring-cloud-gateway-comparison-benchmarks-loadtesting/
They both are replacements, but Spring Cloud will only support Gateway, not zuul 2
I'm exposing functionality to access user details via a rest call.
From reading this post: Is Spring Boot MVC controller multithreaded? spring boot rest services are multithreaded. Does this mean using Akka to multi-thread web services does not serve any use?
Using Java Akka will not offer any multi-threaded advantages but will offer:
If a rest call fails with error (e.g 404) Akka can be used to restart the rest call or kill the thread, so stopping the service.
If the a certain rest call is taking much of time to complete Akka can be used to kill the call after a duration of time.
Akka can be used to throttle requests to rest client, useful if service allows max requests in period of time.
Are my assertions correct? If I'm not concerned with these points above, should I still use Akka or use the functionality to access the user details and not wrap the it with Akka? Could Java futures be also used for these points?
We have the following setup.
STM (Stingrey Traffic Manager) does load balancing + session stickiness
Weblogic 'cluster'
Auth handled by a third party tool
Therefore I do not have to worry about session with regards to horizontal scaling/ running multiple instances of the application. STM/ Weblogic cluster makes sure that the subsequent request come to same managed server.
What we currently have is a monolithic application and we are trying to move to microservices. Also we do not wan't to move out of current infrastructure (i.e. STM/ Weblogic cluster/ Auth tool). What we have planned is:
A Gateway WAR which routes requests to other microservices
N x Microservices (WAR) for each functional sub-domain
Only the API Gateway receives user requests and other microservices are not accessible from outside
So my question is
Should API Gateway be state-full while other microsevices are stateless?
If so, how should the user session data be shared between API Gateway and microservices?
Please suggest any better alternatives and resources/links as well. Thanks.
Let me share my opinion.
First of all, if you can keep your application stateless, by all means do so :)
It will be the best solution in terms of both performance and scalability.
Now, if its impossible, then you should maintain some distributed session management layer.
The gateway responsible for authentication could generate some unique session identifier which could later be used as a key.
This key could be propagated to all the microservices and be a part of the API or something.
In order to access the session, the microservice could 'get' value by key and work with it.
In terms of implementation: I would take a look on NoSQL solutions. Some of them that can suit your need are:
Redis. Take a look on ''hset'' there
Hazelcast. Its more a in-memory grid but if the solution is java only, you can also implement the required functionality
Memcache.d. It will give you an old good map, just distributed :)
There are also other solutions I believe.
Now, the performance is crucial here, otherwise the whole solution will be just too slow. So In my understanding, using an RDBMS would be not be good here, moreover potentially it would be harder to scale it out.
Hope this helps
1)Should API Gateway be state-full while other microservices are stateless?
Yes, As in 12 Factor App guide lines all the services should be stateless.
2)If so, how should the user session data be shared between API Gateway and microservices?
Your API should be stateless therefore do not share the session state to the microservices. The recommended approach is to set up a Redis cache to store session data.
I currently work on a trading application that does not use camel.
It essentially takes in trades, does some processing and sends the details to an external system.
We now have a need to integrate with 3 new systems uusing FTP for 2 systems and JMS for 1 system.
I would like to use Camel in my application for these integrations. I have read a good chunk of camel in action but I was unclear on how we could kick off our camel routes
Essentially, we dont want to modify too drastically any part of the existing application as its working well in production.
In the existing application, we generate a Trade Value Object and its from this object that that I want to kick off our camel integration.
I dont have a database table or jms queue where I can kick off the route from.
I had a quick look at the Chapter on Bean routing and remoting in the Camel in Action book but I wanted to get peoples advise first before proceeding with any steps.
What would be the best approach for this integration?
Thanks
Damien
You can use Camel's POJO Producing feature that allows you to send a message to a camel endpoint from the java bean. If you have no need in JMS or DB you can use "direct:" or "seda:" or "vm:" endpoint as <from> part of your route.
Pojo producing as Konstantin V. Salikhov stated. However, you need to be sure you have a spring application and are scanning your beans with spring or wire them.
"If a bean is defined in Spring XML or scanned using the Spring component scanning mechanism and a is used or a CamelBeanPostProcessor then we process a number of Camel annotations to do various things such as injecting resources or producing, consuming or routing messages."
If this approach will add too much changes in your application, you could use a ProducerTemplate and just invoke a direct endpoint. (Or SEDA for that matter).
The choice of protocol here might be important. The direct protocol is a safe choice, since the overhead is simply a method call. Also, exceptions will propagate well through direct endpoints, as will transactions. As SEDA endpoints is asynchronous (like JMS) but does not feature persistence, there is a slight chance of loosing in flight data in case of a crash. This might or might not be an issue. However, with high load, the SEDA protocol stages better and give your application better resistance for load peaks.
im using spring MVC and webflow to create a game server and serve some web pages to the users. Thing is, the javascript game will also make multiple ajax calls to restful services on the same server for some game logic. While the web page serving performance is not critical, the restful service calls need to be as efficient as possible (efficient as in response time).
For performance of the services, would it be better to use pure JAX-RS (jersey) web service calls without the spring ws overhead (since i understand the spring layer could affect performances negatively) or would it be the same if i used the spring webservices framework instead and maintain integration with the rest of the spring family?
thanks!
There aren't many clear benchmarks out there, but take a look here:
http://www.techempower.com/benchmarks/
It clearly shows the overhead of using Spring. Compared to Servlets that serve JSON manually Spring is "slower". Personally, I don't think that Spring cuts development time, unless you are very much familiar with it. Creating a simple servlet that will act as a REST API is very simple. Take a look at the servlet code from the benchmark:
Servlet benchmark
I don't think Spring per se will affect performance negatively. Where did you hear that?
Spring web services are "contract first" SOAP services. If you're saying that you don't want to pay the overhead of SOAP, XML, marshalling and unmarshalling, then you have a valid point. That's true whether you use Spring to implement the services or not.
REST is HTTP, so it's a natural for AJAX calls.
I believe Spring 3.0 supports REST, so it's not a "Spring or not Spring" choice:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/new-in-3.html#d0e1188