Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have been doing research on micro services. I have used spring boot seeing how simple it is to start with. During my research i have read that is a good approach that every micro service, that is the ones that do data access from a database, have its own database.
I am curious how this works when starting multiple instances of that same micro service. Can those instances of the same micro service work with just one database or they also need a separate database? The dilemma for me is the data would be different across multiple databases. How does load balancing micro services work for such situations?
edited after the first 3 comments
I appreciate the comments. I feel i was lacking in explaining my thoughts behind this question. I am used to building monolithic applications. I made use of spring and hibernate (hibernatedaosupport) and lately also hibernate envers. I use transaction management of spring to manage the commits and rollback situation of the database. This has worked for me so far. I have started looking into micro services and so far am unable to find a proper explanation of how spring transaction management used with hibernate and envers as a micro service would work with a single database. I can understand just one instance of this micro service working, but i am curious if multiple instances of this micro service would work properly with just one database. Especially considering the fact that hibernate would cache objects of the database for performance reasons, not to mention envers and its actions.
There is no requirement about that micro-service must have a different database, you could share one database across all your micro-services or have one per micro-service. It depends on you and architectural decisions taking into account the different tradeoffs.
If you decide one database per micro-service and you have many instances of the same micro-service. You must use just one database (like with monolith). About your concerns of Hibernate and Cache you must handle the cache in different way, by example using Hazelcast (https://hazelcast.com/use-cases/caching/hibernate-second-level-cache/) or EhCache.
Anyway the design patterns are just best practices with different tradeoffs, you must understand the advantages and disadvantages of every pattern for later take a decision.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I am new to microservices architecture, but I have learned that a key advantage of using such architecture is scaling.
Say we have one microservice instance and it is connected to one Mysql database.
Now we need to scale it up to be 3 instances instead of one, does that mean that each instance will have its own database? or it will be 3 instances and one database?
Any information is appreciated.
Usually you would like to have a single database backing a microservice. Otherwise you are just creating multiple instances of the same service. Challenges there are to avoid locking tables and/or rows so the services scaling is worth.
Classic SQL database are hard to scale horizontally (typically the do not support multiple write replicas and depends on a single node for writing). This also represents a challenge in case your services are geographically distributed. There are multiple ways to reduce those effects (using no SQL databases, messages queues) but which matches best depends on each context.
Just in case, sharing database amongst several microservices is definitely an anti-pattern. That is using the database as integration point.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I recently started reading a book that explains in more detail the manipulation of databases, in terms of the relationships between them, especially. The problem is that this book is a bit old, from 2014. So I come with the following questions, to which you can clarify, please:
In the book we use Dao, Dto and Service pattern, but we can't use JPA, Spring Boot Repository or other new technologies to "replace" the old implementation that the book presents?
If so, can you give me an alternative to the code below, and how does it work? What could I improve, what could I give up, what should be completed, what should I learn, please!
Book divide the implementations of an Application in 2 teams:
UserInterface (Data Transfer Object of the entity, singleton in Memory DB and Controller as Mock Service and view)
Development Team (with creating the Entity and testing using TDD, creating DAO for that Entity, Business Service Tier and Presentation Tier
So, I can change this way of creating and manipulating the applications and Databases, if yes, how, and why? What should I use, how should I do it?
This is the git of the book I'm currently reading: https://github.com/Spring-Hibernate-Book/spring-hibernate-datamodeling-tdd-rest/tree/master/Spring-OODD/src
As far as division of labor, the concept of having a separate team work on the controller layer seems antiquated. It could be that the single-page-UI has its own team, but many places prefer that the same people work on everything for a feature front to back, in order to reduce opportunities for communication problems between teams.
The extent to which you need DTOs should be up to the developer's discretion. It used to be a practice to routinely copy all entities into DTOs to avoid issues like lazy-loading in the UI. If you are building a single-page application where you're passing JSON to the UI that isn't an issue. The single-page application architecture provides better separation between UI concerns, making DTOs less necessary in most cases.
For the rest of this the concepts should map over. A Spring JPA repository has the same function as a data access object, it just provides more of the implementation for you. The biggest change associated with the Hibernate mappings is to use JPA annotations instead. Services haven’t changed.
TLDR
things that have changed:
single-page applications have replaced serverside approaches like JSPs
standardizing on JPA instead of Hibernate
configuration classes, no application context XML anymore
profiles
focus on microservices vs. monoliths
more batteries-included (h2 by default, deployable jars, convention over config)
things that haven't changed:
general layering scheme of controllers calling services calling data access
Hibernate mapping strategies and general ORM issues
Spring transaction support
general Spring programming model with beans, DI, AOP
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I already have a blog application which is built on Spring-Boot as a monolith.
There are 2 entities.
user
post
And the mapping is one to many.
A single user can create multiple blog posts.
How can i recreate the same functionality as separate microservice applications.
So far on researching through internet, what i see people saying is create database per service etc.
Suppose if i create 2 services say
UserService(which has separate DB and CRUD operations associated with it)
PostService(which has separate DB and CRUD operations associated with it)
How can i make communications in between them.
In the monolith app the POST entity has createdBy mapped to User.
But how this works in Microservices architecture?
Can any one please help me how can i design such architecture?
First list out the reasons why you want to break it in micro-services. To make it more scalable (in following scenarios for example).
Post comments becomes slow, and during this period registration of
new Users to remain unaffected.
Very few users upload/download files, and you want general users who simply view comments and post comments to be unaffected, while upload/download files may remain
slow.
Answers of the above question and analyzing,priotizing other NFR's shall help to determine how and what to break.
Additionally,
Post service only needs to validate whether the user is a valid logged in user.(Correct?)
User Service does not really need to communicate with post service at all.
Further you might want to decouple other minor features as well. Which in turn talk to each other which can be authenticated via other means like(Certificates, etc.) as they will be internal and updating some stats(user ranking), aggregates data etc.
The system might also have a lot of smaller hidden features, which might or might not have to do anything with Post Service at all, which can be separated in terms of different micro-services(like video/file/picture/any binary content upload/download) also and prioritized based on computation power needed, hit frequency and business priority.
After breaking it in to micro-services, you need to run some stress tests (based on current load) to know which services needs replication and which not and needs a automatic load balancing. Writing stress load first before breaking can also help to understand which features need to be move out of the monolith first.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have two micro services(ms) ms1 and ms2. In both of the ms there is duplicate reusable code(like hashing/security related/orm/etc). Just FYI this usable
code can sometimes maintain some state as well in DB (if it matters by any chance)
There are two ways, I can proceed
Either extract the reuable code as separate library and include in both ms
Create separate ms for this reusable code and expose it as rest end points
If I take approach 2, advantage is I just have to redeploy the ms3 in case of any change. If take approach 1, I need to redploy both ms. At the same
time approach 2 will require separate maintenance/resources/monitoring.
Which one is more ideal approach in terms of system design considering hardware resource is not a challenge. I just mentioned two microservicebut in some cases
there are more than two ms having duplicate code.
I am not sure what is the criteria which can help me to decide whether to go towards shared library or micro service ?
Update :-
I have got some clarity from below blogs but still have question. Will think and post anew question if required.
https://blog.staticvoid.co.nz/2017/library_vs_microservice/
https://dzone.com/articles/dilemma-on-utility-module-making-a-jar-or-separate-2
Microservices are only one of architectural styles. In some cases it is better, in some it is worse than other styles. If you don't use microservices it not mean that your architecture is not good.
If you still want to have microservices, then none of these approaches (shared library vs. library as a new "microservice") is good.
I'd suggest to consider following.
Microservice approach does not mean, that each end point should be encapsulated into a separate microservice. It is normal, that one microservice provides several different end points. If this is your case, then put your two services into a sinbgle microservice and make them reachable via two different end points. Then it is fine that both of them share some classes.
Microservices should normally have independent persistence layer. If there is a strong dependency on the common persistence layer, check, what was the reason to split them into different microservices. Do they really work with different business domains? Can these service be developed and deployed independently on each other? If not, then may be there is no reason to put them into different microservices and it could be better to put them into a single microservice. Then it would be fine if they share some classes.
A good microservice should be provide functionality for some domain. If you put shared code to a separate microservice, then it may be that your shared "microservice" does not provide any functionality for a domain, but is just a wrapper for utilities. That would be not a microservice.
If you have strong reason to separate your services into two different microservices, then duplicate the code. Each microservice should be independent on the others. It should be possible to replace database and to replace any classes of one microservice without affecting the other one. One normal way to make them independable is duplicate the classes that you (currently) consider as shared. If the services are really independent with the time this duplicated code will change and will be different in each microservice. If you have to change this code in both services simultaneously, then it means that your split is not correct and that what you have are not microservices.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My team is working on a medium size application (OLTP style). We were interested by switching to JPA instead of only using JDBC queries. Mostly for performance and practical reason. I'm not looking for a tutorial that shows me how to create a persistence.xml or Entity class in Eclipse. What i would like to know is what would be the steps to convert all the database queries into the JPA format. I know that the whole application must use JPA.
Many programmers has worked on this project over the years, so not everyone has the same SQL knowledge or the same programming skills. So there must be in this application 1000+ customs queries, using multiple tables (something that native JPA does not support very well), or query that is selecting only a few fields in a table... This is getting a bit out of control and i think that JPA would create a nice toolbox to make sure that everyone is going the same direction.
What should i look for to make sure that i'm not going into a process (convertion) that will never end ? Some sort of guideline.
(Again, i'm not looking for programming exemples, nor Eclipse tutorial.)
Thanks!
First step is convert you database schema into database model using JPA, you need to be clear what are the table, sequences, database objects that you are using in your existing application and start modeling all the schema with JPA you should consider use JPA annotation.
The step above will determine what will be your entities, embeddables and mapped superclass, their properties and the relationships they have, this step is very crucial as your logic will depends on the correctness of this model.
Then start looking for all the queries that are involved in your project, as you said that you have 1000+ queries consider use two scenario, convert all of them in JPQL queries or use a mix between native queries and named queries, I really prefer to convert all in JPQL unless are very database dependent. A step you must follow is find all of them, probably are some existing tool that convert from SQL to JPQL but I believe is better idea make by your own.
Once you have queries and model for the database start the creation of your new DAO using JPA and EntityManager stuff, I should recommend extract the interface for your exisiting DAO and start moving to a JPA implementation using the same interface, this will avoid break some code on your own, don't forget unit and IT test for your new DAO.
Also with the above approach you could start moving the application module by module, DAO or by DAO does not require to move full application at once. This will give you a kind of process in which you will see some progress each time you finish a new DAO or module.
Not sure what you mean about programming examples, I think those are the required steps but each project is different from each other, so consider this as some kind of guidelines.