Is there a way to find out or to determine the order of service binding with declarative services? My problem is that I have a logging service running in my OSGI among other services. Now, my component binds this logging service and a couple of other services. I want to write a log message each time a service is bound or unbound. However, if service A is bound before my logging service, no log entry for A can be written.
Can I configure the binding order somehow? I read about setting the binding policy of a service to "static", which is supposed to ensure this service to be bound first of all. But that isn't exactly what I want. I do not want my component to be recreated each time my logging service disappears due to some reason.
I agree with the person below about using slf4j.
Can I configure the binding order somehow?
Most likely not with Declaritive Services alone.
This sounds like a good candidate for ServiceTracker. Just keep it closed until your logging service binds. Luckily that's pretty compatible with Declarative Services.
There is also pax-logging, where you don't bind to the LogService but instead use log4j/slf4j APIs so you might not have to worry about the lifecycle of the LogService as much.
There is also a third option where you publish an OSGI Event for each service on bind, then have an event listener which will print the events on LogService, or queue them up until the LogService is available. This is more moving parts than you may like though.
Your DS runtime may have some optional logging or tracing options which may help to see what is going on under the hood.
Related
I wrote some micro-services using Quarkus that communicate via Artemis. Now I want to add OpenTelemetry for tracing purpose.
What I already tried is to call service B from service A using HTTP/REST. Here the trace id from service A is automatically added to the header of the HTTP request and used in service B. So this works fine. In Jaeger I can see the correlation.
But how can this be achieved using Artemis as messaging system? Do I have to (manually) add the trace id from service A into the message and read it in service B to setup somehow the context (don't know whether this is possible)? Or is there possibly an automatism like for HTTP requests?
I would appreciate any assistance.
I have to mention at this point that I have little experience with tracing so far.
There is no quarkus, quarkiverse extension or smallrye lib that provides integration with Artemis and OpenTelemetry, yet.
Also, OpenTelemetry massaging spec is being worked at the moment, because the correct way to correlate sent, received messages and services is under definition at the OTel spec level.
However, I had exactly the same problem as you and did a manual instrumentation that you can use as inspiration: quarkus-observability-demo-activemq
It will correlate the sent service as parent of receiving end.
I have an application separated in various OSGI bundles which run on a single Apache Karaf instance. However, I want to migrate to a microservice framework because
Apache Karaf is pretty tough to set up due its dependency mechanism and
I want to be able to bring the application later to the cloud (AWS, GCloud, whatever)
I did some research, had a look at various frameworks and concluded that Quarkus might be the right choice due to its container-based approach, the performance and possible cloud integration opportunities.
Now, I am struggeling at one point and I didn't find a solution so far, but maybe I also might have a misunderstanding here: my plan is to migrate almost every OSGI bundle of my application into a separate microservice. In that way, I would be able to scale horizontally only the services for which this is necessary and I could also update/deploy them separately without having to restart the whole application. Thus, I assume that every service needs to run in a separate Quarkus instance. However, Quarkus does not not seem to support this out of the box?!? Instead I would need to create a separate configuration for each Quarkus instance.
Is this really the way to go? How can the services discover each other? And is there a way that a service A can communicate with a service B not only via REST calls but also use objects of classes and methods of service B incorporating a dependency to service B for service A?
Thanks a lot for any ideas on this!
I think you are mixing some points between microservices and osgi-based applications. With microservices you usually have a independent process running each microservice which can be deployed in the same o other machines. Because of that you can scale as you said and gain benefits. But the communication model is not process to process. It has to use a different approach and its highly recommended that you use a standard integration mechanism, you can use REST, you can use Json RPC, SOAP, or queues or topics to use a event-driven communication. By this mechanisms you invoke the 'other' service operations as you do in osgi, but you are just using a different interface, instead of a local invocation you do a remote invocation.
Service discovery is something that you can do with just Virtual IP's accessing other services through a common dns name and a load balancer, or using kubernetes DNS, if you go for kubernetes as platform. You could use also a central configuration service or let each service register itself in a central registry. There are already plenty different flavours of solutions to tackle this complexity.
Also more importantly, you will have to be aware of your new complexities, but some you already have.
Contract versioning and design
Synchronous or asynchronous communication between services.
How to deal with security in the boundary of the services / Do i even need security in most of my services or i just need information about the user identity.
Increased maintenance cost and redundant side code for common features (here quarkus helps you a lot with its extensions and also you have microprofile compatibility).
...
Deciding to go with microservices is not an easy decision and not one that should be taken in a single step. My recommendation is that you analyse your application domain and try to check if your design is ok to go with microservices (in terms of separation of concenrs and model cohesion) and extract small parts of your osgi platform into microservices, otherwise you mostly will be force to make changes in your service interfaces which would be more difficult to do due to the service to service contract dependency than change a method and some invocations.
I am trying to register websocket dynamically.For instance, i have registered '/sampleEndpoint' at runtime so ServerWebSocketContainer will register it and start publishing data on that endpoint. But now if i do the same process during application initialization time in PostConstruct than i am unable to connect to '/sampleEndpoint' but have to append '/websocket' at the end so url become '/sampleEndpoint/websocket' when connecting from client side. Why we are getting different endpoints at different situations?
I have attached github url to the code.
https://github.com/pinkeshsagar-harptec/code-sample.git
Well, that's how that SockJS option works: https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#websocket-fallback.
If you client is not SockJS, then you have to add that /websocket sub-path.
Not sure though why it doesn't work for dynamically registered endpoints...
In the case of #PostConstruct it is not dynamic: we still do the stuff within configuration phase of the application context, so it is able to add our endpoint into a static HandlerMapping. The dynamic nature is applied a bit later, when all the #PostConstruct have done their logic. You don't need to start that flow registration manually though since the auto-startup phase has not passed yet withing #PostConstruct handling.
Re. IntegrationDynamicWebSocketHandlerMapping: it sounds more like a bug and I need to investigate more. I guess you still use there that SockJS option and it has to be applied for dynamic endpoint as well.
Thank you for your patience! I'll investigate and fix it ASAP.
UPDATE
The fix is here: https://github.com/spring-projects/spring-integration/pull/3581.
Say I have a user-accounts service and a profiles service. If the profiles service requires data from the user-accounts service for certain computations that means the profiles service depends on the user-accounts service.
Now, say additional functionality is being implemented for the user-accounts service. This functionality requires data from the profiles service.
This would create a cyclical dependency as each service depends on the other. Is this considered harmful?
What are some alternatives to introducing a cyclical dependency between microservices? Would it be best to add an additional service to serve as a broker?
I would try to avoid this scenario. Personally I try to avoid coupling microservices altogether and rely more on orchestration and/or event choreography.
Here are some ways that you might be able to avoid it:
Combine user-accounts and profiles as a single microservice. If they're closely related, perhaps you have your service granularity slightly wrong.
Create a higher-level orchestration layer that orchestrates calls between user-accounts and profiles.
Depending on your specific scenario, you might be able to choreograph events between user-accounts and profiles. One service might publish events, while the other service is subscribed to these events. You can use a message broker like RabbitMQ in this type of architecture.
There's no absolute right answer IMO - these are just some general guidelines - it really depends on your specific scenario...
I am working on the micro-service developed using Spring Boot . I have implemented following layers:
Controller layer: Invoked when user sends API request
Service layer: Processes the request. Either sends request to third-part service or sends request to database
Repository layer: Used to interact with the
database
.
Methods in all of above layers returns the CompletableFuture. I have following questions related to this setup:
Is it good practice to return Completable future from all methods across all layers?
Is it always recommended to use #Async annotation when using CompletableFuture? what happens when I use default fork-join pool to process the requests?
How can I configure the threads for above methods? Will it be a good idea to configure the thread pool per layer? what are other configurations I can consider here?
Which metrics I should focus while optimizing performance for this micro-service?
If the work your application is doing can be done on the request thread without too much latency, I would recommend it. You can always move to an async model if you find that your web server is running out of worker threads.
The #Async annotation is basically helping with scheduling. If you can, use it - it can keep the code free of the references to the thread pool on which the work will be scheduled. As for what thread actually does your async work, that's really up to you. If you can, use your own pool. That will make sure you can add instrumentation and expose configuration options that you may need once your service is running.
Technically you will have two pools in play. One that Spring will use to consume the result of your future, and another that you will use to do the async work. If I recall correctly, Spring Boot will configure its pool if you don't already have one, and will log a warning if you didn't explicitly configure one. As for your worker threads, start simple. Consider using Spring's ThreadPoolTaskExecutor.
Regarding which metrics to monitor, start first by choosing how you will monitor. Using something like Spring Sleuth coupled with Spring Actuator will give you a lot of information out of the box. There are a lot of services that can collect all the metrics actuator generates into time-based databases that you can then use to analyze performance and get some ideas on what to tweak.
One final recommendation is that Spring's Web Flux is designed from the start to be async. It has a learning curve for sure since reactive code is very different from the usual MVC stuff. However, that framework is also thinking about all the questions you are asking so it might be better suited for your application, specially if you want to make everything async by default.