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 3 years ago.
Improve this question
I would like to know about the database design of microservice. The scenario is given below
Microservice A is using mysql database. If I am creating multiple instance of microservice A:
Each microservice A should point to the same database (common database for all instances) or
Each microservice A points to its own private database
If each microservice A instance points to its own private database how to sync the data of each instance? Can you please explain the best way.
I am creating multiple instance of microservice A:
I assume by this you mean that if you are deploying multiple instances of your micro-service A to one or multiple servers as separate instances of that micro-service?
Short answer:
In general every micro-service should have one database. This means that your micro-service A has a database (lets call it) micro-service-A_db.
Regardless of the fact that you micro-service-A is deployed to multiple servers(horizontal scaling) or on 1 server the deployment instances of your micro-service-A are accessing and using your one database micro-service-A_db.
All your instances of your micro-service-A should access the same database. This is the standard and most common use case. There are exceptions to this.
Long answer:
Each microservice A should point to the same database (common database
for all instances) or
In short yes.
Each microservice A points to its own private database
In short no. But...
As assumed above if you mean multiple instances of micro-service-A should point each to private database then NO. You should not do that.
In general your application Domain/Business logic is split into micro-services based on some criteria. As soon as you split your system to multiple micro-service per Domain(you can read about it here) each micro-service is responsible only for that part of Domain means all the logic related to it and its storage. Let me give an example. Lets say you have an online shop application and you have 3 micro-services:
products-inventory-micro-service
payment-micro-service
orders-micro-service
Each of these micro-service has its own database:
products-inventory-micro-service has inventory-micro-service-db
payment-micro-service has payment-micro-service-db
orders-micro-service has orders-micro-service-db
Those databases can only be used by their owner micro-service. If the micro-service is deployed on one or multiple servers as separate process/instance it does not matter. All of them access the same database. On the other hand you can for sure use a lot of different types of deployment of your micro-service databases like having multiple Read-only replicas, use Sharding to partition your data and so on. There are a lot of ways to scale your database. The point is that a micro-service can only use its own database.
Additionally to this I can say that there are exceptions to this rule: 1 database - 1 micro-service. Sometimes people use 2 databases per micro-service Domain. These are examples where the second db is some kind of read optimized db for particular read/query operations. This is often used together with CQRS pattern. If you want to know more about it you can read a lot about CQRS here on Stack Overflow and in general on the web.
Related
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 months ago.
Improve this question
My question is theoritical (I am not asking the steps about scaling) and related to keep the same performance.
For example our web site (Spring Boot based) is visited 100 person / day and after a year is şs started 1.000.000 visit per day. In this situation, I have the following ideas basically, but need to know more and if these ideas are good or bad:
Using Cloud services
LOad balancer
Using microservices and applying distributed system techniques.
If read operations are much more than write or update, a NoSQL db can be used.
If we use jwt token for authentication, dstributed system would not a problem for security auth side I think.
... etc.
Could you pls share your ideas and comment the idea above? Any help would be appreciated.
There have been several POC( proof of concept ) and proved deployment strategies for better availability.
Keeping your points, I am summarizing and possibly giving a bit more clarity!
Using Cloud services --> This is the platform you choose for e.g. One can choose on-premise service deployment or on cloud such as AWS,Azure GCP etc. Not related to scalability question at the moment.
Load balancer --> Balance the load when you have multiple instances of your Microservice, so for e.g. You can create docker images of your microservice & deploy as a Pod on Kubernetes platform where you can have more than one Replicas (Replica is copy of your same service). Load balancer will balance the HTTP requests among multiple pods.
Using microservices and applying distributed system techniques --> You can but make sure to adhere to best practices and proven Microservice deployment strategies. Read more about the more about them here https://www.urolime.com/blogs/microservices-deployment-strategies/
If read operations are much more than write or update, a NoSQL db can be used. --> Definitely, infact you can decompose your microservice based on number of transactions or read/write operations & you can use NoSql DB like Couchbase or MongoDb
If we use jwt token for authentication, dstributed system would not a problem for security auth side I think. --> Again such mechanisms are usually centralized and JWT token has some time validity!
So there might be several other options of scaling but most used is the one I mentioned in point 2.
I highly suggest you get a grip on basics, Here are few links which would be helpful!
https://microservices.io/patterns/microservices.html
https://medium.com/design-microservices-architecture-with-patterns/decomposition-of-microservices-architecture-c8e8cec453e
I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.
I'm managing a very large enterprise application in that I've implemented microservice architecture. Standalone microservices have been created based on business entities & operations.
For example,
User Operations Service
Product Operations Service
Finance Operations Service
Please note that each service implemented using an n-tier architecture with WCF. i.e have separate tiers(which is independently deployable to separate server) for business and data access.
There is a centralized database which is accessed by all the microservices. There are a couple of common entities like 'user' accessed by all the services, so we have redundant database calls in multiple services. More efforts required due to database access from many places(i.e a column rename requires deployment of all the apps)
To reduce & optimize code, I'm planning to create separate microservice and move all the database operations into it. i.e services can call "Database Operations Service" for any database operations like add/update/select.
I want to know if there are any hidden challenges that I'm not aware of. Whether should I go with this thought? What can I consider as improvements in this concept?
I'm planning to create separate microservice and move all the database operations into it
That's how you will lose all benefits from microservice architecture. One service is down — the whole application is down. Unless you have replication on several nodes.
If your app does not work if one service went down(not implying that it's that service that connects to database), then it's still bad architecture and you are not using benefits of microservice architecture.
Correct for of communication would be if service would have their own databases. Or at least that every service that wants, for example, entity User, will not fetch it from DB, but will fetch it from appropriate service. And that appropriate service could fetch it from common DB at the beginning.
Next step (improvement) in the process of accommodation to microservice architecture would be creation of separate databases for each service. And by “separate” I mean that temporal fault of one service or temporal fault of one database will allow the rest of the app to be alive and functioning.
Generally, there are no hidden challenges in your approach. It just does not give any benefits, as an intermediate form between monolith application and microservice-based.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 3 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Improve this question
We are on the initial stages of designing a micro service for my client from their standard monolith app that is sitting on 4 JBOSS servers in their own data center. Is micro service architecture target at only cloud based deployment? Can i deploy a micro service on premise production ready tomcat /JBOSS? Is that a good fit?
Sure you can.
Microservice architecture is a concept of having many small interracting components, where each of them performing well defined part of work, but good.
It's extention of the Linux way and the concept of decoupling components.
In your case you can split your service to several smaller services. Each one with own development and deployment cycles, each one with well defined API.
Is micro service architecture target at only cloud based deployment?
no it's is an architecture for application development. basic idea of micro services is separate complex application function to small functions to reduce complexity and get high performance.
there are few reasons you need to consider before moving micro services.
1.scale of you application.
if your application contain high number of complex functions its better go with micro services. and separate them and deploy separate, then easy to do changes and maintains.
2.performance of application
if some application function need high computing power. you can allocate separate hardware resources. if you implement it as micro services.
3.deploy and maintain
if you use micro services you can deploy and maintain service separate without effect other services.
4.data migration
if your databases contain high data table relation it will little bit difficult remove for function databases(each micro services need each DB) so as a first step keep DB as monolithic and separate function to services. then start to reactor DB
5.call each services
fronted end application keep clean and logic free. and wrap your micro services using API gate way and publish all the services as one service.
6.application security
each and every services running in separate no need to session tracking use JWT (oAuth2) API security.
7.multiple services & transnational
if you need to handle one business function but with more than one service you need to check each and every services function work correctly**(ex db operations ,rollbacks)** so need to developed transnational handler
implementing micro services
there is no specific technology stack for it but there are free more technology available
ex :
java spring boot for micro services (with inbuilt tom cat server )
zuul , eureka for API gate way
oAuth 2 and JWT for security
*Note
there is not fix way to implementation for micro services , use correct technology stack to get performance and implement small business function. and doesn't matter hosting in cloud or local servers.
strong text
There is definitely no limitations whether you deploy your microservices on local, physical servers or in the cloud. Both approaches are valid, but they impose different advantages and disadvantages.
With local/physical servers, you will have:
bigger operations overhead (it is better you have good DevOps in your team)
manual scaling (when you experience bigger traffic, you need to manually fire up new instances, or use some management tool for this)
manual fault detection - if a server goes down (this depends on your/company's server enviorenment) someone will need to fix this "manually"
it is cheaper (a friend is buying old server instances on Amazon and running their semi-microservice architecture on them, he calculated they achieve quite big savings this way)
With cloud infrastructure, you get some of the below advantages (in contrary to above disadvantages):
less operations overhead (the cloud will take care of most of operations)
flexible scaling (when your traffic goes up, cloud can automatically fire up new instances, when it goes down, it will shutdown instances)
error/fault handling - if there occurs a problem in the cloud, you do not need to worry
I did not mention all the advantages and disadvantages of given approaches, as it also depends on the project (will it receive different traffic on different times of day, does it need to keep data locally or can it be in a foreign country in a cloud, ...).
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
today I started reading about Microservice architectures - and it seems to be very interesting!
But I have one doubt I need some explanation on:
Assume I want to create a blog and would build 4 microservices for that: User/login Service, Article Service, Comments Service and Reporting/analytics Service(not a realistic example, I know...).
The Reporting/Analytics service is purely backend - no issue here for my understanding.
But the three others involve some UI part - and as to my understanding this UI part should also be part of the microservice itself, right?
How would the UI integration work? Would I then have a 5th "front door" service that collects the user requests, forwards them to the other services which then answer with HTML/CSS and the front door service would then compose the individual responses into what is returned to the user?
Any chance, you have an example/use case for such a scenario?
Thanks and regards!
From my experience, in a microservices architecture, it is often useful to have a service that acts like an API gateway that front loads to the more domain specific microservices that does the work. The responsibility of the API gateway could be to aggregate results and return them to the front end but consolidating responses that are returned from the microservices would be coupling the knowledge of the two services and leaking some domain knowledge into the API gateway layer. The API gateway should probably be as thin as possible and should reach out to services to accomplish something.
The use case here that you're describing would be trying to authenticate the user before reaching out to the login service and then the article or comments service. Altogether the front end would still stay monolithic if they are a part of the same application.
If the application becomes big enough, the application would be separated by products but probably still rely on a core set of services. In that case, they would probably live in different UIs so that would make it less complex (kind of like microservices on the back end). Just as a side note, that a microservices architecture usually introduces a set of core services that can be utilized by different teams and therefore different applications that have different UIs. An example being an ecommerce application, that has customer service department editing orders for servicing customers and customers using an orders service to make purchases. In effect, these are two applications and they will have two different UIs. Hope this helps!
The other thing that I'd like to point out is that a microservices architecture is only great when the application becomes too large and complex. A microservices architecture requires more resources as it has some additional overhead. Start with a monolithic first :).
There are a couple of different approaches that you can take. If it makes sense each microservice can have its own pages that it can render. Then you only need a front end that can create the appropriate navigation for the involved services. The menu is built for the application, each service presents its own UI. This approach works well when you need to have the ability to include or exclude services from the application, for instance, based on licensing.
Alternately, each microservice can provide a set of HTML Fragments. Then you need a front end service to compose the pages and navigation. The fragments must all use the same vocabulary for CSS or whatever means you use to define the look and feel. This approach can lead to odd pages when HTML fragments are composed without one or more service that might be included.
Finally, a complete application UI can be built on top of the microservices. This can result in a "tighter" UI with a better flow. It also will typically take longer and be more difficult to change as new services are added.
What is the best? As with most cases in software development, it depends on what you are building. In the case of the Blog application, you described I suspect that each service could have its one full page UI. More commonly having a full UI is the approach I have seen. The HTML Fragment approach is more versatile but takes longer to develop initially. Once it is built though you will have more flexibility in how you deploy your application. This could be a real benefit for a Software Product company.
Hope that helps.