I am using vertx3.
As we know Vertx is very efficient handling many requests with it's reactor pattern.
The thing is that I have a second service which exposed as Rest-API on Spring-boot container(it was very easy for me to implement it over there).
I got two options: 1. Implement that logic on vertx and earn the api call.
2. Scale the spring-boot service to handle those millions rest api's reuqests from vertx.
Anyone had this dilema ?
will be easier to go with option two.
Any alternative how to scale the spring service ?
(I already aware to the physical solutions of adding many instances on diff machines and put load-balancers but than I am losing the power of vertx since the spring-service is a bottleneck
Thanks,
ray.
Usually service implementations are stateless, regardless from technology which are you going to use. So it means, that they are scalable.
Try to implement service logic, using spring, rest-api using vertx. Spring service service logic will be used from vertx.
And of cause do not block the threads in service implementation.
Related
So I've been working on a microservice-based architecture in Spring and my prototype uses Spring's WebClient to explicitly send a request to a different service and await a response. Recently I've tried to migrate the project to some RPC-based service remoting technology, and I figured out that all the technologies that just work out of the box (Hessian, RMI, HTTP Method Invoker) are deprecated, and the ones that Spring encourages to use (JAX WS and Spring WS) require to learn multiple additional DSLs and spend a week trying to deeply understand their principles just to export a service to the web. Also, just using WebClient feels far more flexible and seems to leave a lot of room for further improvements. Will creating my own REST-like APIs for each of the microservices and then explicitly using WebClient to call them turn my code into instant legacy spaghetti mess or is it a normal thing to do?
P.S. By "more flexible" I mean, for example, an ability to set up a reverse proxy load balancer with caching and different actions for different methods in between the actual microservice nodes and the requesting service, etc.
A very common practice on communication between frontend and backend of micro-service architecture is to use API gateways or adopt a BFF architecture.
However, backends of many modern sites consists of several domains.
What I mean is that they are actually using multiple public endpoints instead of a single one.
Thus, it seems that real-world practice is to use a combined method of a Direct-Client-Service method and an API-Gateway method.
Then how should we determine which service should be using a standalone endpoint while others should not?
Thanks.
I am trying to build a new application with spring boot microservice framework. I have tried some demo. The existing demo is too simple, doesn't introduce how to call another service from one service. Should still going through http, or should going through RPC? If going RPC, which RPC framework support?
The way of integrating among services depends on numerous factors, like synchronicity/asynchronicity, load that will be generated, etc. The most popular (I guess) way of integration is REST-based one. Because you tagged your question with spring I would recommend using declarative REST client - Feign that is very well described here. You can use message brokers as well, which are also very well abstracted by Spring Cloud Stream - you can read more here. I think that more in depth discussion should be based on your needs.
If another micro-services are exposing the REST API , then you can simple use jersey client
or httpclient to call them.
We have a Java API that needs to be supplemented/fronted with a SOAP/REST Web service Layer.
What does it take to implement Async Calls across process/server boundaries using
a) SOAP Webservices
b) RESTful webservices
Some of the methods might need multiple calls to respond to the request.
We will be using Java/J2ee to implement the SOAP/restful service using a library like CXF or Axis or Jax-RS/WS.
Any examples ? Gotchas ?
Thank you,
The Async Http Client is an open source library that was specifically designed for this type of problem. It utilizes futures and wraps up a lot of the detail and hassle out of making async calls.
The author has a very good getting started guide and there is an active discussion group. The author is a very talented developer and the project is under continuous development.
From the documentation:
The library uses Java non blocking I/O
for supporting asynchronous
operations. The default asynchronous
provider is build on top of Netty
(http://www.jboss.org/netty), the Java
NIO Client Server Socket Framework
from JBoss, but the library exposes a
configurable provider SPI which allows
to easily plug in other frameworks.
Your question is not clear. I am interpreting your question as you want your serverside code to call a remote REST web services in an Async manner. If so then your best bet is to use the Futures feature of java.util.concurrent it will do exactly what you want. If my interpretation of the question is wrong then please update your question with exactly where the async operations need to happen.
Akka http://akka.io/
Great framework, great performance - Here are their claims:
"""
Simpler Concurrency
Write simpler correct concurrent applications using Actors, STM & Transactors.
Event-driven Architecture
The perfect platform for asynchronous event-driven architectures. Never block.
True Scalability
Scale out on multi-core or multiple nodes using asynchronous message passing.
Fault-tolerance
Embrace failure. Write applications that self-heal using Erlang-style Actor supervisor hierarchies.
Transparent Remoting
Remote Actors gives you a high-performance transparent distributed programming model.
Scala & Java API
Scala and Java API as well as Spring and Guice integration. Deploy in your application server or run stand-alone.
"""
#Vivek
GET is async and other HTTP methods
are not.
This isn't true. Please go ahead and read about AJAX :-)
For REST web services (apart from GET) everything else (POST/PUT..) is Async, it returns you the HTTP status code of the opeeration.
If you want to make GET also Async then you will have to use Threads, We did it once in Spring framework using #Async annotation (which internally spawns a thread).
From get return the callback URL as the response and use threads to process the request asynchronously.
Apart from that, For both SOAP / REST once you get the request you can publish it on a JMS queue to make the service Async.
One of the best ways to implement asynch ops is to use callbacks. For REST APIs, design of APIs and Rest client should support this. For instance , client class should pass itself or it's inner class as listner. Rest API on server side should maintain request id and call back listener in map . Once processing is done , it can call method on listener based on request id from map.
Real question: why do you want to call it Async? Having looked at solutions for parallel processing on the Java EE side, it's not recommended that you spawn child threads within a container on your own.
In your case, it looks like the following:
1. you're looking to create a wrapper contract in WSDL (REST or SOAP or both) and if you clients are not just browsers (AJAX)(i mean you'd have adopters from the server-side), then, for JAX-WS -> you could create a #CallBack end-ponint (http://docs.oracle.com/cd/E15051_01/wls/docs103/webserv_adv/callback.html)
or
if it's REST end-point that requires being called from an adopter (server-side), use jAX_RS 2.0 feature
Note: Above assumes it's point to point but in an Async way
Here are a few options:
if you're looking to call REST Or SOAP or some other function asynchronously, you can use workManager API (JSR )
or
use JMS and use a request-reply model if you need it (short running) and calling multiple end-points in parallel
use WS-BPEL (only WSDL end-points) - this is a OASIS standard as well
use SCA (any component with any technology) that can contain assemblies of WS-BPEL component (stateless or stateful) running in BPEL engine like Apache ODE or IBM process server and other components and collaborates. This is a standard
I am writing a web service in Java which needs to handle a large number of requests / second. The general flow will be:
Web service receives a request from client
Returns a 'keep polling me' response to client
Calls another web service (or
services), and waits for them to
respond (with a timeout)
Client polls our web service, until
it receives a response (with a
timeout)
Researching on the Internet, I have found two general approaches to writing web services:
Spawn a thread for each request
Use the Reactor pattern (central dispatcher thread responds to IO events)
Do you have a recommendation for which approach is generally better, and what are the pros/cons of each approach? I would also appreciate pointers to examples.
Don't think multi-threading. Think asynchronously. I happened to have just coded an async handler that ran 2,000 RPS with <10 threads in IIS. Not sure how java works since I'm a .net guy but I gotta believe they have similar BeginXXX/EndXXX methods. If you ever spawn a thread then you're not considering all the places your code can block: data base IO, File I/O, web services, etc. These are the places your performance will cause your site to be slow.
Async, Async, Async.
Chant and repeat.
In addition to "No Refunds No Returns" response, I'd say yeah "Think Asynchronously" as you should be allowing your container to manage the multi-threading/scalability and high-availability issues of the web services it has deployed, this allows you to set-up things like clustering and so forth using your application container.
EDIT: So in conclusion, there isn't a pattern as such, maybe you should explore the scalability/availability features of your application container...
Asynchronism is indeed the right approach but don't manage this yourself, use something that supports asynchronous web service invocation like JAX-WS 2.0 (which uses the Future interface and/or the Executor framework from java.util.concurrent). See Asynchronous Web Service Invocation with JAX-WS 2.0.