my project is created with Micro Service architecture, one business may need multiple services call. Currently, most of the services call need serial call, because the request of the next service call is generated from the last service call's response. This makes the invoke chain is very long, the performance is bad, is it any solution to deal with this scenario? Or I need to change my micro service design? Thanks!
You can try to solve part of your problem implementing a queue solution like an Apache Kafka, the first microservice process the data and post the data in the queue and the second microservice read from this queue.... process and post to another queue.
This approach can improve the performance because you can increase the numbers of partitions into Kafka, but you need to analyze what's you really need to process before sending the task to next service and if this can be paralyzed, if it can be paralyzed you can scale the microservice instances to process more data.
You have many options, but for microservices "talk" I recommend use queues.
Good luck with your project.
Related
This is more of an architectural question in programming to understand the possibility of my thinking. I have a java microservice rest endpoint that takes an int value. For example, If the int value is 10, the endpoint will get 10 users from database and run through the business logic one user at a time and update different things. This works but I want to know whats the best way to see response of each user at real time to know if there are any unknown exceptions and had to stop the job from running further. I am not sure if postman can do this or an executable? If so, please suggest how and I will get going. Thanks!
Firstly, if you want to see the processing as real-time stream of responses per each user in a task - you have to implement your microservice in reactive way.
If it is not possible - instead of executing one task of 10 users, you can feed you service by small chunks (10 x 1 user) in parallel threads from the client side.
To achieve it, you can create a simple executable leveraging one of the reactive frameworks. For example, RxJava or, in if you are using Spring/Spring Boot, WebFlux framework
Or, you can try to use some tools like Apache Jmeter, if you prefer to configure something instead of developing.
I want to build a standalone global audit trail application which can trace all the audit(events) logs sent to it from different applications through webservice call or any other channel.
The issue i see here is i don't want to hamper the performance of the calling application to wait for the response as ideally not expecting any response back to calling app.
If i go with webservice approach then the caller application will wait for the response (both case synchronized /asynchronized call) are there any other best approach for this solution.
There will be n no of application which will be sending their audit logger to this application so need idea which i can scale up parallel if required.
Thanks for going through my request!!!
We would be using Kafka for this approach.
Hopefully it is having good performance and scalable.
Best Architecture for implementing a WebService that takes requests from one side, save and enhance that and then call another service with new parameters.
is there any special Design Pattern for this?
There's not a lot to go on, but from what you've said it sounds like a job for "pipes and filters"!
To get a more precise answer, you might want to ask yourself some more detailed questions:
If you need to do any validation or transformation of the incoming message? Will you want to handle all requests the same way, or are there different types? Are the external services likely to change, and if so, will they do this frequently? What do you want to do if the final web service call fails (should you rollback the database record?)? How do you want to report failures/responses - do you need to report these back? Do you need a mechanism to track the progress of a particular request?
Since you are looking for a design pattern, I think you might want to compare the pros and cons of using microservices orchestration vs choreography in the context of your project.
If you do not need an immediate response to the calling system I would suggest to you to use event-driven approach if that's feasible. So instead of REST services, you will have a message broker and your services will be subscribed for certain events. This will hide your consumers behind the message broker which will make your system less coupled.
This can be implemented via Spring Cloud Stream, where you will have a Sink (microservice producing events, transformer - microservice that makes intermediate transformations possible and a source - microservice that receives a final result for further processing).
Another possible case could be Camel. It has basically all the integration patterns built in, so it should not be a problem to implement the solution either based on REST APIs or events.
In my environment I need to schedule long-running task. I have application A which just shows to the client the list of currently running tasks and allows to schedule new ones. There is also application B which does the actual hard work.
So app A needs to schedule a task in app B. The only thing they have in common is the database. The simplest thing to do seems to be adding a table with a list of tasks and having app B query that table every once in a while and execute newly scheduled tasks.
Yet, it doesn't seem to be the proper way of doing it. At first glance it seems that the tool for the job in an enterprise environment is a message queue. App A sends a message with task description to the queue, app B reads a message from the queue and executes the task. Is it possible in such case for app A to get the status of all the tasks scheduled (persistent queue?) without creating a table like the one mentioned above to which app B would write the status of completed tasks? Note also that there may be multiple instances of app A and each of them needs to know about all tasks of all instances.
The disadvantage of the 'table approach' is that I need to have DB polling.
The disadvantage of the 'message queue approach' is that I'm introducing a new communication channel into the infrastructure (yet another thing that can fail).
What do you think? Any other ideas?
Thank you in advance for any advice :)
========== UPDATE ==========
Eventually I decided on the following approach: there are two sides of this problem: one is communication between A and B. The other is getting information about the tasks.
For communication the right tool for the job is JMS. For getting data the right tool is the database.
So I'll have app A add a new row to the 'tasks' table descibing a task (I can query this table later on to get list of all tasks). Then A will send a message to B via JMS just to say 'you have work to do'. B will do the work and update task status in the table.
Thank you for all responses!
You need to think about your deployment environment both now and likely changes in the future.
You're effectively looking at two problems, both which can be solved in several ways, depending on how much infrastructure you able to obtain and are also willing to introduce, but it's also important to "right size" your design for your problems.
Whilst you're correct to think about the use of both databases and messaging, you need to consider whether these items are overkill for your domain and only you and others who know your domain can really answer that.
My advice would be to look at what is already in use in your area. If you already have database infrastructure that you can build into, then monitoring task activity and scheduling jobs in a database are not a bad idea. However, if you would have to run your own database, get new hardware, don't have sufficient support resources then introduction of a database may not be a sensible option and you could look at a simpler, but potentially more fragile approach of having your processes write files to schedule jobs and report tasks.
At the same time, don't look at the introduction of a DB or JMS as inherently error prone. Correctly implemented they are stable and proven technologies that will make your system scalable and manageable.
As #kan says, use exposing an web service interface is also a useful option.
Another option is to make the B as a service, e.g. expose control and status interfaces as REST or SOAP interfaces. In this case the A will just be as a client application of the B. The B stores its state in the database. The A is a stateless application which just communicates with B.
BTW, using Spring Remote you could expose an interface and use any of JMS, REST, SOAP or RMI as a transport layer which could be changed later if necessary.
You have messages (JMS) in enterprise architecture. Use these, they are available in Java EE containers like Glassfish. Messages can be serialized to be sure they will be delivered even if the server reboots while they are in the queue. And you even do not need to care how all this is implemented.
There can be couple of approaches here. First, as #kan suggested to have app B expose some web service for the interactions. This will heterogenous clients to communicate with app B. Seems a good approach. App B can internally use whatever persistent store it deems fit.
Alternatively, you can have app B expose some management interface via JMX and have applications like app A talk to app B through this management interface. Implementing the task submission and retrieving the statistics etc. would be simpler. Additionally, you can also leverage JMX notifications for real time updates on task submissions and accomplishments etc. Downside to this is that this would be a Java specific solution and hence supporting heterogenous clients will be distant dream.
I have to develop a web service that looks like this: I make a get call, including a string in the url, and I need to receive another string based on the initial string from the query.
I might have to make this call even for a thousands times a minute. Do you think that the server will be able to handle so much HTTP communication? Is a RPC approach better?
Any suggestion is welcomed, I am just starting to work on web services and I have no clue about the performance.
Thanks.
Thousands calls per minute means hundreds per second. I believe that modern computers can do more. I do not think that you will have serious performance limitations. But before you are starting check how long will it take to deal with the request. If this will take time I'd recommend you to decouple the HTTP WEB front end and business logic, i.e. process the request asynchronously. You can easily achieve this using JMS.
SOAP or REST? I personally prefer REST. It is simpler, it is faster. And it seems that you have only 2 String parameters, so SOAP does not give you any advantages.
IMHO, the main difference between SOAP and REST is that the former inserts an additional overhead (both processing and data) since it's data has to follow a somewhat strict structure. REST is simpler and leaner because it doesn't require you to explicitly define a message format, leaving this task to the software that will handle the message instead of the transport infrastructure.
So:
Do you want to enforce a message structure at the cost of additional overhead? Use SOAP;
You want a more lightweight option, at the cost of having senders and receivers piece together the messages into meaningful data? Use REST;
One of the key advantages of a REST web service is that its responses can be cached. In this way, the intermediate HTTP cache chain between your service and its clients bears a huge part of the total workload, so your web service can scale up. REST can be far more scalable than SOAP or RPC.
You may also want to check out Jersey at http://jersey.java.net/ as an alternative to Restlet.