Menu
If you go for a microservices architecture in your organization, they can share configuration via zookeeper or its equivalent. However, how should the various services share a common db schema? common constants? and common utilities?
One way would be to place all the microservices in the same code repository, but that would contradict the decoupling that comes with microservices...
Another way would be to have each microservice be completely independent, however that would cause code duplication and data duplication in the separate databases each microservice would have to hold.
Yet another way would be to implement functional microservices with no context\state, but that's usually not realistic and would push the architecture to having a central hub that maintains the context\state and a lot of traffic from\to it.
What would be a scalable, efficient practical and hopefully beautiful way to share code and schema between microservices?
518
The general guideline in microservices is to not share code. Things that can be shared are libraries that don't changed very often like US States, color, etc. To answer your question what about the code for the communication between the microservices , I would say not to share this code.
A basic principle of microservices is that each service manages its own data. Two services should not share a data store. Instead, each service is responsible for its own private data store, which other services cannot access directly.
The two commonly used protocols are HTTP request/response with resource APIs (when querying most of all), and lightweight asynchronous messaging when communicating updates across multiple microservices. These are explained in more detail in the following sections.
Using messaging to exchange lightweight data structures, often via a message broker that manages sessions and data queues. Via a shared data store, where the service might not communicate directly, but share a common source of information. Exchanging RESTful data, similar to the way they communicate with clients.
Regarding common code, the best practice it to use a packaging system. So if you use Java, then use maven, if you use Ruby then Gems, if python then pypi etc. Ideally a packaging system adds little friction so you may have a (say, git) repository for a common lib (or several common-libs for different topics) and publish their artifacts through an artifact repository (e.g. private maven/gems/pypi). Then at the microservice you add dependency on the required libs.So code reuse is easy. In some cases packaging systems do add some friction (maven for one) so one might prefer using a single git repo for everything and a multi-module project setup. That isn't as clean as the first approach but works as well and not too bad. Other options are to use git submodule (less desired) or git subtree (better) in order to include the source code in a single "parent" repository.
Regarding schema - if you want to play by the book, then each microservice has its own database. They don't touch each other's data. This is a very modular approach which at first seems to add some friction to your process but eventually I think you'll thank me. It will allow fast iteration over your microservices, for example you might want to replace one database implementation with another database implementation for one specific service. Imagine doing this when all your services use the same database! Good luck with that... But if each single service uses it's own database the service abstracts the database correctly (e.g. it does not accept SQL queries as API calls for example ;-)) then changing mysql to Cassandra suddenly become feasible. There are other upsides to having completely isolated databases, for example load and scaling, finding out bottlenecks, management etc.
So in short - common code (utilities, constants etc) - use a packaging system or some source code linkage such as git-tree
Database - you don't touch mine, I don't touch yours. That's the better way around this.
HTH, Ran.
186
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
