I'm building a project which based on microservices architecture in spring boot.The project was divided multiple modules and I used maven dependency management.
Now I want to use services from one module in other module. I have many spring applications. For example, I have 2 application which is named A and B. I want to use classes from A in B and classes of B in A. In this case I used maven dependencies but it is not completely way to using services in one another because I faced with circular dependency.
What should do to use for solve this problem?
It is not a good idea to share classes between microservices, if you want to replace microservice A, you'll have to adapt Microservice B.
Every Service must implement its own data classes which holds the fields which are needed for the service.
MicroService A and MicroService B both can contain a class Foo but this classes can be different by its fields. Perhaps both contain the field 'id' and 'name' but only Microservice A also needs a field 'date' to do his work.
If you have classes that need to be in some of your Microservices, i think it's better to make a shared library and put your shared classes in that, then use your shared library in your Microservices.
Actually i think it's a good idea to put classes that need to be in most of your Microservices in a shared library and use that library. But should be careful, because it may comes to tight coupling which isn't a good thing in Microservices Architecture.
Personally i think some Configuration classes and some Event models that most of your Microservices use are good candidates. But i don't think sharing your Service classes between your Microservices are a good idea. Instead they should use each other's services as they are completely independent and are using external services.
create one common entity application and add that entity application as a dependency. For example assume you have stored user data in micorservice1(MC1) and need this class(User) in other microservices(like MC2, MC3,MC4, and so on) then you can create one entity application like util and add this dependency in required microservices.
Related
I am working on 2 micro-services currently, microservice A includes microservice B's SDK to call B's API and access some entity classes.
Similarly microservice B also includes microservice A's SDK and accesses microservice A's enitity classes.
Now I am facing one issue when I need to bump up the version of microservice B in microservice A and vice versa.
How should I solve this problem?
You've already broken the cardinal rule of microservices by tightly coupling the two services.
The right answer here is going to be to refactor these services such that they properly and completely encapsulate functionality. That could involve combining them (if B is always and completely dependent on A, they may not really be separate services), splitting them out into more services, or just shifting responsibility.
But, the path you're on with tight-coupled microservices leads to a distributed monolith which is unlikely to provide the benefits you're after (specifically including the co-dependent revision concern you mention here).
Here's a good answer to a related question that might offer some more insight.
For a project, we will develop some micro services. They will have many common parts like configurations class, filters...
I search the best practice et method to develop it.
For the moment, i had create a generic micro service, forked by all to develop module above it. But is not convenient and some modification in one web service may be would cause some difficult for the next merge of the generic MS.
Do you have any idea to develop it or sources to inspire me?
Thanks for your responses.
Create one or more libraries containing Abstract classes that implement the shared functionality.
Import one or more of the libraries into each individual project.
Extend the Abstract classes in the individual projects.
Use Spring annotations (for instance #Component or
#RestController) in the individual projects,
not in the common libraries.
Use some Spring annotations (for instance #Scheduled) in the common libraries.
If you do this, allow the individual projects to override the values in these annotations.
For example,
#Scheduled(initialDelayString = "${common.thing.initialDelayString:10_000}",
fixedDelayString = "${common.thing.fixedDelayString:60_000}")
The example annotation includes default values and allow the individual projects to override the values as desired.
I am reading spring micro services for next project. Tut said that "The architecture style the main application divided in a set of sub applications called microservices. One large Application divided into multiple collaborating processes.". So already we have a framework maven multi module There I separated the project in my experience. even though it is. why do we need micro services to separate a project?. please differentiate it. thanks in advance..
Every service in the microservice architecture should be isolated which means that the team in charge of that service is able to put continuous deployment in practice without need to deploy other services. In practice, IMHO I think that we can use two approaches using our favourite build tool such as maven or gradle:
Monoproject: domain, repositories, services and controllers are all in the same project.
Multiproject: domain, repositories, services and controllers can be grouped in different modules. i.e domain and repositories are in repository module and services in another module with the same name and controllers in front module.
But, doesn't matter which approach you use the project (mono or multi) should represent one service.
I have a Spring Integration project that has several flows (some where between 10-15). I would like to keep my namespace clean since several flows might have similar sounding components (for ex - several flows might have a channel named fileValidatorChannel). I think I have a couple of different options to keep names from colliding with each other:
A. Preface every component name with the flow that it belongs to. For ex - flowAFileValidatorChannel, flowBFileValidatorChannel, etc
B. Create a context hierarchy where every flow is it's own context and every flow inheriting from a master context where all the common beans/sub-flows are.
What's the better approach? Is there are better way to keep my name space clean?
To be honest your problem isn't clear.
Any Spring Integration component is a bean finally. So, their ids are just to distinguish them from other bean.
Let's imaging if you don't have Spring Integration in your application. So, you would worry about some clean naming strategy for all your beans anyway?
From other side consider to use Spring Integration Flow project:
The goal is to support these, and potentially other semantics while providing better encapsulation and configuration options. Configuration is provided via properties and or referenced bean definitions. Each flow is initialized in a child application context. This allows you to configure multiple instances of the same flow differently.
We are writing a new set of services and have decided to make them share a common interface... calling it a BaseService. The idea is that whenever anyone wants to develop a new service in our organization, they should be just able to extend and use this BaseService.
We have written a few other classes which also form a part of this base jar, it does things like handle transactions and connect to database using hibernate etc.
Right now all the services that extend the BaseService are a part of the same project (Eclipse + Maven), and some of the services are dependent on each other, but because they are in the same project we don't have a problem with dependencies.However, we expect 40-50 services to be written which would extend base service and would also be interdependent.
I am worried that the size of the base project would be huge and that just because when someone has to use one service they might have to depend on my base jar which has 50 services.
Is there a way that we can make some projects dynamically dependent on others?
Lets say I have a service A which depends on service B, when I build/compile Service A,it should be able to realize that it has a dependency on service B and automatically use the Service B jar.
I have heard of OSGi, will it solve my problem or is there a way I can do it with Maven or is there a simpler solution ?
Sorry about the long post !
Thanks in advance for your suggestions
It doesn't make any sense to "dynamically" manage project dependencies, since build dependencies are by definition not dynamic.
Your question, at least for the moment, seems to be entirely about how to build your code rather than about how to run it. If you are interested in creating a runtime system in which new service implementations can be dynamically added then OSGi may be the solution to look at. An extra advantage here would be that you could enforce the separation of API from implementation, and prevent the implementing services from invalidly depending on parts of your core module that you do not want them to have visibility of.
You could also use OSGi to manage evolution of your core service API through versioning; for example how do you communicate the fact that a non-breaking change has been made to the API versus a breaking change etc.
I would say there are two options depending if i understand your question correct. First one. You have already defined an interface (java term) and now you have different implementations of that. The simple solution for Maven would be to a have a module which is called for example: service-api and than this will be released and can be used by others as dependencies. On their side they simply implement the interface. No problem with the dependencies. If you are more talking about OSGi than you should take a look to maven-tycho.